Categories

  • 12k Topics
    114k Posts
    Tom ElliottT

    @kratkale You’re not stuck in a loop

    You didn’t follow the installer instructions and use the link the installer provided you for the database.

    There’s a different url because to you security doesn’t matter, but to many others, it most certainly does.

    As for the userdel fogproject, don’t do that, please:

    That’s actually more likely why you were having ftp issues in the first place. In 1.5.10.x the installer tried to prevent anyone from ever using the fogproject user, but many did. If the account had been used, the only fix was to delete the user. Deleting that user could change the password for the account (and thus the password used on the storage node causing the likely first problem you had encounted).

    In either case, this is not a loop, this is a URL on the display where you’re used to just doing it one way. That way changed (in an effort of security). It’s not hidden though, so please use that whole link for this stage or better yet, use the -y option.

  • Get the latest news on what's happening.
    184 Topics
    825 Posts
    A

    @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

  • View tutorials or talk about FOG in general.
    2k Topics
    19k 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.

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

    @Valer Hi Valer,

    You can see my tutorial on using Secure boot with Shim, and my thoughts on what 2.0 means for Secure Boot with FOG here: http://forums.fogproject.org/post/158170

127

Online

12.7k

Users

17.6k

Topics

156.6k

Posts