Categories

  • Get help with your FOG system.
    FOG Problems Hardware Compatibility Windows Problems Linux Problems Mac Problems General Problems
    13k Topics
    115k Posts
    K

    @Tom-Elliott said in Task 0:

    root@fog:~# ls -la /etc/fog/pki /etc/fog/pki/root/ca /etc/fog/pki/secureboot /etc/fog/pki/secureboot/ca /etc/fog/pki/secureboot/leaf /opt/fog/snapins/ssl/CA /etc/fog/pki: insgesamt 16 drwxr-xr-x 4 root root 4096 25. Sep 16:38 . drwxr-xr-x 4 root root 4096 25. Sep 16:38 .. drwxr-xr-x 3 root root 4096 25. Sep 16:38 root drwxr-xr-x 4 root root 4096 25. Sep 16:38 secureboot /etc/fog/pki/root/ca: insgesamt 8 drwx------ 2 root root 4096 25. Sep 16:38 . drwxr-xr-x 3 root root 4096 25. Sep 16:38 .. lrwxrwxrwx 1 root root 34 25. Sep 16:38 .fogCA.pem -> /opt/fog/snapins/ssl/CA/.fogCA.pem /etc/fog/pki/secureboot: insgesamt 16 drwxr-xr-x 4 root root 4096 25. Sep 16:38 . drwxr-xr-x 4 root root 4096 25. Sep 16:38 .. drwx------ 2 root root 4096 25. Sep 16:38 ca drwxr-xr-x 2 root root 4096 25. Sep 16:38 leaf /etc/fog/pki/secureboot/ca: insgesamt 8 drwx------ 2 root root 4096 25. Sep 16:38 . drwxr-xr-x 4 root root 4096 25. Sep 16:38 .. /etc/fog/pki/secureboot/leaf: insgesamt 8 drwxr-xr-x 2 root root 4096 25. Sep 16:38 . drwxr-xr-x 4 root root 4096 25. Sep 16:38 .. /opt/fog/snapins/ssl/CA: insgesamt 16 drwxrwxr-x 2 fogproject www-data 4096 8. Sep 22:17 . drwxrwxr-x 3 fogproject www-data 4096 8. Sep 22:17 .. -rwxrwxr-x 1 fogproject www-data 1818 2. Mai 13:31 .fogCA.pem -rwxrwxr-x 1 fogproject www-data 41 8. Sep 22:17 .fogCA.srl lrwxrwxrwx 1 root root 33 8. Sep 22:17 .fogWebCA.key -> /etc/fog/pki/web/ca/.fogWebCA.key lrwxrwxrwx 1 root root 33 8. Sep 22:17 .fogWebCA.pem -> /etc/fog/pki/web/ca/.fogWebCA.pem root@fog:~# ls -ld /opt/fog/pki lrwxrwxrwx 1 root root 12 8. Sep 22:17 /opt/fog/pki -> /etc/fog/pki root@fog:~# grep -E '^PKI_(root|sb)_' /opt/fog/.fogsettings PKI_sb_enabled='yes' PKI_root_dir='/etc/fog/pki' PKI_root_ca_cert='/opt/fog/snapins/ssl/CA/.fogCA.pem' PKI_root_ca_key='/etc/fog/pki/root/ca/.fogCA.key' PKI_sb_ca_cert='' PKI_sb_codesign_cert='' PKI_sb_codesign_key='' root@fog:~# find / -xdev -name '.fogCA.key' 2>/dev/null /opt/fog/service/etc/pki/root/ca/.fogCA.key root@fog:~#

    Sorry—I had to work—here are the expenses from earlier

  • Get the latest news on what's happening.
    Security Advisories
    185 Topics
    826 Posts
    Tom ElliottT

    FOG 1.6.0 Release Candidate 1 is available

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

    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.

    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 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.
    General Tutorials
    2k Topics
    19k Posts
    R

    Now I read the AI summary and got what I need:

    It stores one row for each address in the hostNetwork table. Limits of this method The sleeping host must run fog-agent. The server uses the sleeping host’s own last report to find its subnet. A host with the legacy FOG Client, or with no client, has no rows, so the relay cannot help it. The old path still runs for it.

    So If I populate the hostNetwork table for the hosts that I need manually, It will work. Thank you for the details.

  • Report bugs, request features, or get the latest progress.
    General Feature Request Bug Reports
    2k Topics
    21k Posts
    Tom ElliottT

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

57

Online

12.8k

Users

17.6k

Topics

157.2k

Posts