Categories

  • 13k Topics
    115k Posts
    Tom ElliottT

    @rogalskij To answer your two questions directly:

    How does FOG know to use only ITStaff? The LDAP Group is that reference. Create an LDAP Group named ITStaff on your server, and give it a role on its Role Association tab. The Group Search DN only tells FOG where to look for groups. When a user signs in, FOG checks which of your LDAP Groups the user belongs to. A user in none of them gets no access.

    That check runs only when Group Matching is ticked on the LDAP server. Please confirm it is ticked. When it is off, every account that can bind to your AD can sign in, and gets the fallback role (Technician by default).

    Username: yes. Set User Name Attribute on the server to sAMAccountName, and users sign in with their plain AD username.

  • 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
    Tom ElliottT

    @Dominique I can’t promise that, no.

    1.5.10 is the original release, and it is a long way behind now. It was built and tested against PHP 7.x. It may run fine on PHP 8, but I don’t know which PHP 8 version, if any, would be safe for it.

    What we do know works on PHP 8 is the current stable branch. Here is how the branches fit together:

    master is the official 1.5.10 release. We don’t work on it directly. dev-branch is where all the bug fixes and maintenance happen. stable gets everything from dev-branch rolled into it once a month.

    So stable is 1.5.10 plus a few years of fixes, PHP 8 support among them.

    If you want to move to PHP 8 before 1.6.0 comes out, I’d do it in this order:

    Snapshot the server first, so you can roll back. Update FOG to the stable branch and run the installer. Do this while you are still on PHP 7.2. Then move PHP to 8.2. On Red Hat 8 the installer will not do that for you; it installs whichever PHP module is enabled. Run dnf module reset php then dnf module enable php:8.2, then dnf distro-sync. Re-run the FOG installer, so it picks up the new PHP packages. Test the web console, a host registration, and a unicast and a multicast deploy before you call it done.

    Since this is production, your plan to wait for 1.6.0 and try the RC in a test environment first is a good one too.

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

    @sgennadi Thanks for this, and for the detail. You were right: the check matched no_root_squash anywhere in /etc/exports, not just on the /images/dev export.

    It is fixed now, much the way you proposed. The new nfsDevExportHasNoRootSquash() checks only the <share>/dev export. It ignores comments, other exports, and look-alike paths such as /images/dev2. Your ISO export with no_root_squash no longer triggers the warning.

    Issue: https://github.com/FOGProject/fogproject/issues/1988 1.6 (working-1.6): https://github.com/FOGProject/fogproject/pull/1989 (merged) 1.6 RC: https://github.com/FOGProject/fogproject/pull/1990 (merged) 1.5 dev-branch: https://github.com/FOGProject/fogproject/pull/1991 (merged)

    To get it now, pull dev-branch (1.5) or rc-1.6.0 (1.6) and re-run the installer. It reaches the 1.5 stable branch with the monthly roll-up on November 11th.

    The warning was only a message, so your exports were never changed. If /images/dev is already all_squash, you can ignore it until then.

69

Online

12.8k

Users

17.7k

Topics

157.3k

Posts