Categories

  • 13k Topics
    115k Posts
    Tom ElliottT

    @Coolguy3289 Thanks for the log line. It points at a bug, not at your approach.

    The installer creates a “FOG Agent CA” under the server root CA. It only creates it when the file is missing. If the root CA changes later (for example, you copy the old server’s /opt/fog/snapins/ssl onto the new box so existing clients keep trusting it), the agent CA stays signed by the first root. Every enrollment then fails with the error you see, and the agent gets a 503.

    The fix is in PR #1810: the installer now re-creates the agent CA when the current root did not sign it.

    To fix your server now, without waiting for the PR:

    sudo grep PKI_AGENT_CA_CERT /opt/fog/.fog-pki

    Move the .fogAgentCA.pem and .fogAgentCA.key files in that directory to a backup location. Then re-run the installer. It creates a new agent CA under your current root, and enrollment works.

    You do not need your internal PKI for this. The FOG-generated root is fine for production.

  • Get the latest news on what's happening.
    187 Topics
    828 Posts
    Tom ElliottT

    The third release candidate for FOG 1.6.0 is available on the rc-1.6.0 branch. It reports version 1.6.0-RC-3.

    Test it on a lab or non-production server first. The upgrade from 1.5 to 1.6 is one-way: it changes the database schema, and there is no down-migration.

    Upgrade from RC-2 now if you use fog-agent, a wildcard web certificate, or more than one master node. RC-3 fixes failures in all three.

    Fixed since RC-2

    Agent enrollment failed with a 503 after the root CA was replaced (#1810). The installer created the FOG Agent CA only when its file was missing. If the root CA changed later, for example when you copy an older server’s /opt/fog/snapins/ssl onto a new install, the Agent CA stayed signed by the old root. Every enrollment then failed, and the Apache log showed FOG agent enroll: signing for host <id> ... failed: the issued certificate does not verify against /opt/fog/snapins/ssl/CA/.fogCA.pem. The RC-3 installer re-creates the Agent CA when the current root did not sign it. It keeps the old pair beside the new one with a date suffix. A wildcard web certificate broke the installer (#1800). The installer used the certificate’s commonName, for example *.example.org, as the server name. Apache refused the configuration, and the installer’s own calls to the server failed. --hostname was ignored. The installer now uses --hostname and checks that the certificate covers it. With no --hostname, it uses the server address. Constant ssh connections between master nodes (#1806). The services opened a connection to the ssh port of every master node on each pass. sshd logged Connection closed by <server> every few seconds. The services no longer probe the nodes for this check. fog-agent waited up to five minutes to see a task (#1802). The server told the agent to poll every 300 seconds. It now sends the client check-in interval, FOG_CLIENT_CHECKIN_TIME, which the legacy client already uses. With the default setting, agents poll every 60 seconds.

    New since RC-2

    Windows activation through fog-agent (#1804). The server sends the host’s product key to the agent when the key is valid and the host enrolled as Windows. It needs a fog-agent release that supports activation. An older agent ignores it.

    Before you upgrade

    Back up your database and /opt/fog/.fogsettings. Read the release notes: https://github.com/FOGProject/fogproject/blob/rc-1.6.0/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. The site and accesscontrol plugins move into core. PHP 7.4 or later is required. Plugins built for 1.5 do not load.

    Install or update (as root)

    A 1.6 beta, RC-1 or RC-2 server: run bin/updatefog.sh --channel rc from your FOG checkout. A 1.5 server installed from git: update to the current 1.5 stable, then run bin/updatefog.sh --channel rc from the checkout. A new server, or a 1.5 server installed from a tarball:
    curl -fsSL https://raw.githubusercontent.com/FOGProject/fogproject/working-1.6/bin/bootstrap.sh | bash -s -- --channel rc

    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
    8

    @Cpasjuste I just wanted to let you know that I’ve added in your method of using userland NFS support to my container. I have given you credit for the method in the README. I’d love for you to test it out if/when you get a chance. Thank you again for your work!

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

    Hi @Tom-Elliott,
    follow-up on this thread: I never found the root cause of the intermittent firmware hang on the Latitude 3400 (16 hypotheses ruled out, including the Protective MBR fields we discussed, thanks again for the help with that), but deploying these machines with diskpart + DISM from a WinPE booted via wimboot (through a small FOG plugin) has worked reliably so far, while every other model stays on FOS/Partclone. The attached report covers the investigation, the workaround and a few side findings (WinPE deploys leaving the task queued, Secure Boot/MOK, a vsftpd home-directory pitfall). If anyone has seen the same hang or has ideas about the cause, I’d like to hear it.Report_Latitude3400_FOG_BootIssue_EN.md.txt

    Thanks for your help

64

Online

12.8k

Users

17.7k

Topics

157.2k

Posts