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

  @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.

• Announcements

  Get the latest news on what's happening.

  Security Advisories
  187 Topics

  828 Posts

  T

  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.

• General Topics

  View tutorials or talk about FOG in general.

  General Tutorials
  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!

• Developers

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

  General Feature Request Bug Reports
  2k Topics

  21k Posts

  T

  @servicedesk-pianezza Yes, FOG writes that boot code, and I can show you where. Your finding holds up against our
  source and against a reproduction here.

  Where it comes from. On capture, saveGRUB() in funcs.sh copies the first 1 MiB of the
  source disk into d1.mbr with dd — LBA0 included, boot code and all. On deploy,
  clearPartitionTables() runs sgdisk -Z, which does clear the MBR, and then restoreGRUB()
  writes d1.mbr straight back over it. The next two commands are sgdisk -z, which destroys
  the GPT structures only and leaves the MBR bytes alone, and sgdisk -gl, which rewrites only
  the protective partition entry. So the captured Windows bootstrap survives the whole
  sequence, and gdisk supplies the entry in its own convention: EndCHS ff ff ff and the exact
  sector count.

  I replayed that sequence here on a loop-backed disk with one of our own Windows 11 resizable
  images. The result matches what you found byte for byte in shape:

  LBA0 : 33 c0 8e d0 bc 00 7c 8e ... (Windows MBR stub) 0x1BE : 00 00 02 00 ee ff ff ff 01 00 00 00 af 32 cf 1d

  Why it is not simply a bug. On a BIOS-booted GPT Linux disk that same region is GRUB’s
  boot.img, and d1.grub.mbr exists precisely so we keep it. We cannot blanket-zero LBA0 on
  every GPT restore. On a Windows GPT image it is dead weight — Windows only boots GPT through
  UEFI — so a targeted change is available to us. But we should change the right bytes.

  Which byte is it? Your diskpart disk differs from ours in three places at once, so we do
  not yet know which one the firmware chokes on. Three one-liners settle it. Start from a fresh
  deploy that hangs, run one of them, power off, power on, press F2. Redeploy between tests so
  each one is measured on its own:

  # 1 - the bootstrap, nothing else dd if=/dev/zero of=/dev/nvme0n1 bs=1 count=446 conv=notrunc # 2 - the size field -> sentinel printf '\xff\xff\xff\xff' | dd of=/dev/nvme0n1 bs=1 seek=458 conv=notrunc # 3 - EndCHS -> the diskpart value printf '\xfe\xff\xff' | dd of=/dev/nvme0n1 bs=1 seek=451 conv=notrunc

  Each writes inside LBA0 only and leaves the GPT untouched. Test 1 is the one I expect to
  matter, on the theory you already stated — a CSM path in that firmware reading or validating
  a bootstrap it should be ignoring.

  Name the byte and the fix is small: for a GPT image whose OS is Windows, clear that field
  during the restore and leave Linux images alone. That also gives the two 2020 reports on this
  hardware an explanation, which is worth having on its own.