@kratkale The issue isn’t domain join but rather that machine (or those machines?) security tokens no longer match the security token they were initially given, most likely because the machine you cloned had a security token it passed in?

From the host(s) in question in the uI you can reset the security token:
b8102a2d-7604-4272-9975-3d6ad0211b17-image.png

I believe it’s similar for groups (if you wanted to put the 5 having issues into the same group and click reset encryption data.)

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

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

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

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 🙂

@JCS-RVK Understood and apologies there’s not a good method around this.

Thanks for at least understanding. I wonder if some of the similar types of issues we’ve seen historically have a similar style of problem that I’m only coming to realize now-a-days.

@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

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.

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

Thanks @Tom-Elliott !

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

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

@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

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!

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

update the kernals on fog server / nodes

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-

So I am alone ?