Subcategories

• General

  General FOG related questions.
  2k Topics

  16k Posts

  L

  Hello,

  We are preparing a lab with 44 MacBooks (Apple M4, 16 GB RAM).

  Currently, we have not implemented any imaging solution yet. At the moment, we only use our Samba Active Directory domain for user authentication (LDAP/Kerberos) on the Macs.

  All machines have the exact same hardware configuration, and we need a way to create a standardized macOS image and replicate it across all devices. This deployment process is performed once every semester, so we are looking for a reliable and repeatable solution.

  We are evaluating the FOG Project as a possible solution, but we are unsure whether it supports cloning and deploying macOS images on Apple Silicon devices (M4).

  We would like to ask:

  Is FOG suitable for capturing and deploying macOS images on Apple Silicon Macs?
  How does the cloning process for macOS work in this scenario?
  If FOG is not recommended, what tools or best practices would you suggest for mass macOS deployment and domain integration with Samba AD?

  Thank you for your guidance.

• Tutorials

  Share your knowledge
  341 Topics

  3k Posts

  K

  @Florent Hi Florent,

  I actually have been meaning to look into this some more, but the likely answer is no, or at least, not entirely. The way that support works is, you download a signed iPXE 2.0 binary from iPXE and a copy of their signed shim. That shim is signed with the Microsoft keys and trusts the iPXE signing keys. What this means in practical terms is, all the steps above would still need to occur, it’s just that the signing of the iPXE binary is managed by iPXE, and you don’t need to enroll a key to boot iPXE.

  That said, I would imagine this only covers you for booting iPXE, any chainloaded binaries would still need to be signed either with Microsoft’s key or a MOK key you’ve enrolled on the machine. In FOG’s case this means the FOS kernel has to be signed and trusted on the system, in addition to any other binaries (for example memtest, refind) you plan to boot via FOG.

  The other likely blocker is the build itself. Naturally, only iPXE can sign binaries that the iPXE Shim will support. Currently the FOG installer actually builds a slightly modified iPXE binary from source. While I’m unsure if these are all that different from the pre-built binaries from 2.0 in terms of support and functionality, it would at the very least need to be changed to instead pull the iPXE 2.0 binaries.

  I don’t think any of these are particularly hard to overcome or deal with though. The bottom line is, 2.0 makes it easier, but only to a point. To get real proper Secure Boot support in FOG, they’ll likely need to generate their own signing keys, and start signing at least the FOS kernels (if not iPXE itself) and update FOG to include shim support somehow.

  That said, for basic support, I doubt they would need to go the full mile and get a Microsoft approved signing key, I think distributing a certificate/key you can enroll via MokManager and using a pre-existing signed shim (like the iPXE provided one) would more than suffice for most usecases. I’m not sure how difficult it would actually be to implement any of this into FOG, that’s a question for someone who knows PHP and is more familiar with the FOG codebase than I.

  Sorry if that’s a bit long winded, it’s not an easy topic to distill. Hope that helps though.