Categories

• Technical Help

  Get help with your FOG system.

  FOG Problems Hardware Compatibility Windows Problems Linux Problems Mac Problems General Problems
  13k Topics

  115k Posts

  T

  @JYost With agent 0.1.23 or later, you do not need to stop or disable it before Sysprep, and you do not need the SetupComplete.cmd line. The agent waits until Windows setup has finished before it enrolls, checks in, or reboots. It starts on its own after OOBE completes.

  On an older agent, update it on the reference machine first. Or use the same steps as before with the new service name: sc config fog-agent start= disabled before Sysprep, then sc config fog-agent start= delayed-auto and sc start fog-agent in SetupComplete.cmd.

  You also do not need to clear the agent’s key before capture. Each deployed machine has different firmware IDs, so the agent drops the captured key and enrolls as itself. A deploy from your server approves it automatically.

  No firewall rule is needed. The agent opens no listening port. It only connects out to the FOG server over HTTPS.

  Details: https://docs.fogproject.org/installation/client/install-fog-agent#capturing-an-image-with-the-agent-installed

• Announcements

  Get the latest news on what's happening.

  Security Advisories
  207 Topics

  848 Posts

  T

  FOG 1.6.0 is released. It is on the stable branch and reports version 1.6.0.

  This is the first release of the 1.6 line, and it replaces 1.5. The upgrade from 1.5 to 1.6 is one-way: it changes the database schema, and there is no down-migration. Back up before you upgrade.

  Thank you to everyone who tested the 21 release candidates. Thank you also to everyone who reported a problem, on the forums or on GitHub, and to everyone who sent a pull request. Each report and each fix helped make 1.6.0 what it is.

  Highlights

  Role-based access control is part of core. Roles and their permissions are built in. You no longer install a plugin before permissions exist. Sites are part of core. Multi-site scoping is built in. The upgrade moves the site plugin’s data into the core sites table. Groups grant snapins, printers and modules. A host that joins a group later gets the grant, and a host that leaves loses it. Mass edit on the host list. It replaces the group page’s one-time push. Each field has its own No change, Set on all, or Clear on all choice. LDAP and OIDC sign-in are built-in identity providers. Directory groups map to FOG roles, so an external user no longer gets full admin by default. API Bearer tokens. Create one on a user’s API tab and send it as Authorization: Bearer <token>. Each token has its own label and on/off switch, and you can rotate it without touching your other integrations. FOG stores only a hash and shows the token once. The old fog-api-token plus fog-user-token pair still works, but a Bearer token is simpler to use and to maintain. Use it for new integrations. An audit trail. FOG records who changed what, and shows it as an activity view. A retention policy. A retention daemon removes log and audit records older than the number of days you set. The default keeps everything. The database enforces its relationships. Real foreign keys now cover every core relationship that can carry one. The upgrade cleans up orphan rows first and logs each cleanup. Plugins are installable artifacts. A plugin has its own install, update and removal, and it survives a FOG upgrade. Secure Boot enrollment is a task type. You schedule and track it like any other task.

  Plugins removed in 1.6

  These 1.5 plugins are removed. Do not copy them into a 1.6 server.

  accesscontrol: removed. Core role-based access control does its job. The upgrade removes its registration. site: removed. Core sites do its job. The upgrade copies its data into core and drops its tables only when the row counts match. persistentgroups: removed, with its database trigger. Core group grants do its job. Installing it again would re-create the trigger. fileintegrity and hoststatus: not carried into 1.6. No replacement ships.

  Every 1.5 plugin needs a 1.6 build to load. The 1.6 plugins are in https://github.com/FOGProject/fog-plugins .

  FOS 1.6.0 (kernel and init)

  Linux kernel 6.18.59 (LTS), Buildroot 2026.02.1. FOS verifies TLS when it talks to the server. x64 and x86 boot an initramfs, not an ext2 initrd. The file names stay init.xz and init_32.xz. Warning: a customized init can no longer be loop-mounted. Add your files as an overlay cpio appended to init.xz: https://docs.fogproject.org/en/latest/kb/how-tos/customize-the-fos-init/ . A post-init script needs no rebuild: https://docs.fogproject.org/en/latest/kb/how-tos/post-init-scripts/ master installs FOS release 1.6.0. stable and dev-branch installs download the Latest FOS release.

  What happens to your branch and update channel

  stable (--channel stable) now carries 1.6.0, then the monthly 1.6.0.N releases. dev-branch (--channel patches) now carries the 1.6 patches. rc-1.6.0 (--channel rc) and working-1.6 (--channel beta) are retired. Move to --channel stable. No branch was force-pushed. A 1.5 git checkout reaches 1.6 with an ordinary git pull.

  Before you upgrade

  Known issue: the upgrade from 1.5 fails at the schema update if the database holds multicast sessions (Truncated incorrect INTEGER value: ''). Do not upgrade a 1.5 server until 1.6.0.1 is released. Back up your database and /opt/fog/.fogsettings. Read the release notes: https://github.com/FOGProject/fogproject/blob/stable/docs/release/1.6.0-release-notes.md 1.6 removes Display Manager, Directory Cleaner, User Cleanup, Client Updater, Green FOG and the persistentgroups plugin. Their data is dropped. PHP 7.4 or later is required. Plugins built for 1.5 do not load.

  Install or update (as root)

  A 1.5 server installed from git: run bin/updatefog.sh --channel stable from the checkout. A 1.6 beta or RC server: run bin/updatefog.sh --channel stable. A new server, or a 1.5 server installed from a tarball:
  curl -fsSL https://raw.githubusercontent.com/FOGProject/fogproject/stable/bin/bootstrap.sh | bash -s -- --channel stable

  If an upgrade fails, bin/revertfog.sh in the 1.6 checkout restores the pre-upgrade backup. Run it with --list, then --dry-run, first.

  1.5 support

  1.5 is end of life. The last 1.5 release is 1.5.10.2534. It gets no further fixes, security fixes included. Every 1.5 tag stays in the repository. Details: https://github.com/FOGProject/fogproject/blob/stable/docs/release/1.5-support-statement.md

  Report problems

  Open an issue at https://github.com/FOGProject/fogproject/issues. Include your FOG version, your OS, and the installer log from bin/error_logs/. Report a security problem through “Report a vulnerability” on the same repository, not in a public issue.

• General Topics

  View tutorials or talk about FOG in general.

  General Tutorials
  2k Topics

  19k Posts

  C

  @88fingerslukee Yop mate, are you on discord or something ? Would be easier to talk about this docker images !

• Developers

  Report bugs, request features, or get the latest progress.

  General Feature Request Bug Reports
  2k Topics

  21k Posts

  L

  Hello everyone,

  First of all, thank you for FOG. We run it in a school (about 320 hosts, FOG 1.5.x on Debian 12) and it is a core part of how we deploy and maintain our PCs.

  I would like to propose a feature: a “Troubleshooting” (or “Host health”) menu in the web UI that lets an administrator find, in a few clicks, which hosts are failing to authenticate and what to do about it. Today this requires digging through server logs and the database, which is complicated and not realistic for most FOG admins. We had to write a script to do it, and I am sharing what it does as a starting point for the design.

  The problem

  FOG does not tell you when a host fails to authenticate. Nothing appears in the web UI or in any error log, because the server answers these requests with HTTP 200 even when it rejects the login. We only found out when somebody stood in front of the machine. Two cases kept hitting us:

  Rejected login in the iPXE menu. The user picks Deploy Image, types the credentials, the screen flickers and the menu comes back with no message. Server side, the only trace is the menu (boot.php) being requested again a few seconds later, and the kernel (bzImage / init.xz) never being downloaded. Our working theory (not fully confirmed yet) is the keyboard layout: iPXE uses a US layout, so passwords with symbols typed on another layout would arrive differently. Windows FOG client that cannot authorize. The host retries forever. The database shows no security token, or one that has not been renewed for days (hostSecToken / hostSecTime), and the client’s fog.log shows token or certificate errors. The usual fix is Reset Encryption Data, but nobody knows which hosts need it. What the menu should show

  Each item is something we currently detect by hand:

  Hosts whose FOG client cannot authorize: missing or stale security token, or an abnormal number of authorization requests (a retry loop). Suggested action: Reset Encryption Data, then check fog.log on the client. Hosts that fail the PXE login: repeated rejected logins without the kernel ever being downloaded. Suggested action: check the keyboard layout and the credentials. Hosts with no contact for N days (configurable): so that machines that no longer exist can be removed and machines in use whose client silently stopped can be fixed. For each one: host name, IP, since when, and the suggested action next to it. Optionally, an e-mail digest through the existing notification mechanism. How our script detects it (for reference)

  A read-only shell/awk script that runs weekly from cron on the FOG server and e-mails a report. It never writes to FOG. It uses:

  Apache access log (other_vhosts_access.log plus the rotated .gz files): Rejected PXE logins: two POSTs to boot.php from the same IP within 120 s, with no kernel download in between. A host is listed after 3 rejections in the period. Client not authorizing: we take the most frequent response size of /management/index.php?sub=requestClientInfo and of the authorize POSTs as “normal”, and flag IPs with several abnormal responses, or with too many authorizations in a single day (a normal host does about 47 a day; we flag above 100, which means a retry loop). Mapping IP to host: the mac= parameter of requestClientInfo links an IP to the host MACs in the database. FOG database (hosts, hostMAC) : the host token and its last renewal time. A host is flagged when its token is missing or older than its last failed request. It also gives the hosts with no sign of life for more than 15 days.

  Example of the summary it produces (host names removed):

  OVERALL STATUS: NEEDS ATTENTION SUMMARY Hosts whose FOG client cannot authorize....... 4 Hosts that could not log in on PXE............ 4 Hosts with no contact (over 15 days).......... 64 Hosts active this week........................ 189 1) HOSTS THAT CANNOT CONNECT TO FOG (Windows client) The client cannot authorize against the server. -> In the FOG web UI, open the host and click "Reset Encryption Data"; then check the FOG log on the client. - HOST-A, since 03 Nov ...

  In a few weeks it found hosts with broken tokens that nobody had reported, a laptop that repeatedly failed the PXE login, and several machines in daily use whose FOG client had silently stopped working.

  Why it belongs inside FOG

  Parsing Apache logs is fragile and only works because we know the response sizes by heart. FOG already has the information: the hosts table, the token times and the requests it serves. The simplest native design would be to record an event (or a counter on the host) whenever a PXE login or a client authorization is rejected, with the reason, and build the menu on top of that.

  You are very welcome to take our script and keep it, use it, change it or build on it however you like, with no conditions. We do not have a public code repository, so if any developer wants it, reply here or send me a private message and I will share it. I can also explain the heuristics and thresholds in more detail, share anonymised log samples, or test a patch or plugin on our server if that helps.

  Thank you again for your work.