Categories

  • 13k Topics
    115k Posts
    Tom ElliottT

    @Shuttleu The fix is now in stable release 1.6.0.158. Update to it, and a refused task shows its reason in the modal instead of hanging on “Loading, please wait…”.

  • Get the latest news on what's happening.
    207 Topics
    848 Posts
    Tom ElliottT

    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.

  • View tutorials or talk about FOG in general.
    2k Topics
    19k Posts
    C

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

  • Report bugs, request features, or get the latest progress.
    2k Topics
    21k Posts
    Tom ElliottT

    @lperoma Thank you for the detailed write-up. The detection notes made this quick to scope.

    FOG 1.6 covers this as follows:

    FOG Client cannot authorize. This was the real gap, and a pull request now adds it: https://github.com/FOGProject/fogproject/pull/2089. The server records each host whose client fails the handshake: since when, how many times, the source address and the reason. A new list report, Reports > Client Authentication Failures, shows them with the fix next to each one. A host leaves the list when its client authenticates again. Two reasons are recorded:

    The security token does not match. Reset Encryption Data fixes this. The server cannot decrypt the client’s key. This means the certificate the server publishes for clients does not pair with its private key, so every host fails at once. A reset does not help. Running the installer with --recreate-keys issues a new pair.

    One case stays invisible to the server. A client that trusts a different FOG CA refuses the server’s certificate and never sends a login, so there is nothing to record. Its fog.log shows “Certificate is not from FOG CA”.

    Rejected iPXE menu logins. 1.6 already records each rejected login in the audit trail, with the username and the address. Look under Reports > Audit Report.

    Hosts with no contact. 1.6 stores the last check-in and the last ping for each host. Fleet Report shows the last check-in, so you can sort on it.

    All of this is 1.6 only. 1.5.x does not get these changes, so your script remains the answer there until you move to 1.6.

58

Online

12.8k

Users

17.7k

Topics

157.4k

Posts