@Tom-Elliott

Just lyk that I updated the main FOG server to Debian 13 and installed the latest stable release of FOG.

Replication working well now that the OS and FOG server versions match the Storage Node server.

Thanks again

@kratkale I want to fully understand:

this is after a fresh install/fresh update from the installer and your’e having all these issues?

it seems (at least at first glance) ftp isn’t liked very much.

As for the snapins I’m at a loss. If you’d be daring can you install the branch working-1.6?

This shifts from FTP in preference of actual SSH and might be better. Of course working-1.6 is more or less in “beta” so this is understandable to be hesitant, but at the same time, without enough testing and feedback, little can move the needle closer and closer to RC -> Master.

Even in the age of AI, there’s not enough data (for me at least) to feel comfortable moving it toward master/stable yet so if you’re daring please upgrade to working-1.6

I will highly recommend making a backup or snapshot pre-upgrade to it just in case something is significantly worse.

The error message you got (OOPS: cannot change directory) seems to indicate authentication is now working but ftp is failing because it cannot drop you to the users’ home directory. The why of that I do not know but I do believe this would be fixed in working-1.6 (or at least I’ll have more assistance to troubleshoot things with you as I’m generally working from that branch).

@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

@Tom-Elliott

I’ve updated my FOG to the stable release and also updated my script with the following three lines, and everything’s fine – the database has been backed up successfully, it’s perfect!

fogApiToken="XYZ=" fogUsrToken="ZYF" curl -ik -X GET "http://$fogServerAddress/fog/system/export" -H "fog-api-token: $fogApiToken" -H "fog-user-token: $fogUsrToken" -o $backupDir/mysql/fog.sql 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1

Thanks again for all your hard work on the FOG project!

Thanks @Tom-Elliott !

Perhaps we could include a brief note stating that it is possible the database schema may not need updating.

@Tom-Elliott said in Unauthorized error:

@Jamaal I’m not sure I follow? The database isn’t insecure, it was being able to download the database, or force an upgrade without authorization that was the piece being secured, nothing about the normal day to day operation of the database changed.

Got it, ok thanks for your help today on this.

Shoutout “The Minester”

https://github.com/FOGProject/fogproject/issues/685

On the storage node, create a .my.cnf file in root’s home directory:

sudo tee /root/.my.cnf << ‘EOF’
[client]
skip-ssl = true
EOF

MariaDB will try to connect with SSL by default but that’s not enabled on the main FOG server. This is why I had to use the --ssl=FALSE flag when I connected to mysql manually.

The installation succeeded!

@Nono Edit your /opt/fog/.fogsettings file and replace entries of ‘mysql-client’ with ‘mariadb-client’

I suspect they’ve updated the repo to solely exist for mariadb-client, but you had it before that package switch/change occurred so your fogsettings file is just expecting mysql-client always.

I might also recommend removing the existing mysql-client package just to ensure clean flow, though of course get a backup before any such actions.

Works well ! 😊

Works well ! 😁

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

update the kernals on fog server / nodes

seems to work when copying the directory from another host over to /opt/fog-service and creating a runit file /etc/sv/fog-service/run with content

#!/bin/sh exec 2>&1 echo "Starting FOG Client..." exec mono-service /opt/fog-client/FOGService.exe -d /opt/fog-service -l /opt/fog-service/service.lock

Hi,
I know this is a bit old, but I found it when I was searching for an answer to the following question:

I have prepared USB bootable image based in WinPE. I use it to boot from USB. I have this image in iso file and I use it to place it on USB with rufus software.

I wonder if I can use this tutorial of yours in exactly same way only to use my custom iso image instead of your mentioned WinPE.

I know this may be trivial question and I may just try it, but I am really only beginner in WinPE and fog project.

Thank you for your kind answer.
-r-

Hello @Tom-Elliott

Sorry for the delay 😞

I checked what you told me to do. It appears I have a file that I didn’t check : /etc/php/8.4/fpm/pool.d/www.conf
I set display_error=off and now I don’t have all those warnings.

Thank you for your help.

This is perfect 🙂

@GregorS I have 3 Dell Models that are also doing this, but I will try the change to DHCP Boot file.

I will post back when I have an update.

Thanks!

So I am alone ?

@Tom-Elliott

I pulled latest dev-branch version 1.5.10.1856, re-run installer and snapins are working again.

Thank you very much for help.

We can mark this closed. Turns out it was a old/bad snapin package on the old server. I set up Fog with a new DB and everything worked fine. Once I removed the snapins and exported and imported the DB again it all worked as expected.

Thanks for the help.