@Infojoe I believe I pushed a fix for this already, but I’ll have to check again tomorrow morning.

@Infojoe right now this is understood (they typo I’ll get fixed in the morning, but the auth check is preventing inventory from sending, so fixing will be more likely deleting the auth check entirely again. This is where which side of the coin is needed. I’ll probably remove the line so things just work as they once did. Thanks for letting me know.

@kratkale So things are working under the latest with dev-branch?

@kratkale Install using dev-branch

@kratkale I’m confused what you mean their serial numbers are erased?

FOG isn’t overwriting the serial numbers on these devices.

Furthermore, Serial numbers aren’t stored directly on the host, they’re stored on the inventory table.

That column (hostDevice) is about storing what device a host will be using to image against.

If somebody is updating the group, the empty hostDevice (Group device for groups) would likely be overwriting it.

I’ve pushed a code change to hopefully address this particular issue in the latest dev-branch.

@Chandlerbing Can you do a look for all files that contain:

grep -r 'display_errors' /etc | grep -v '#'

This should only display things where display_errors is defined directly.

I suspect there’s one that is doing this for you natively.

@Chandlerbing

This appears like you have your php file setup to output errors to the display.

If you look at your /etc/php.ini (I don’t know os you’re running so you may have to find this file in your /etc folder (find /etc -type f -name php.ini)

Look in this file for display_errors = On

You should look for one where it doesn’t look similar to # display_errors = On

if you don’t find one that isn’t already commented (that’s what the # means) then by default display_errors is on so in that stanza after the comments create a new line that is:

display_errors = Off

Once done, save the file and restart php-fpm and I like to restart html just in case:

sudo systemctl restart php-fpm httpd # for redhat based OS's

sudo systemctl restart php-fpm apache2 # for debian based OS's

@GregorS

Found it. The ~1KB you were seeing isn’t a truncated snapin — it’s a 6-byte #!auth error response that the FOG Client wrote to disk and then hashed (which of course doesn’t match the real snapin’s SHA512).

The root cause is on me. A recent security patch on dev-branch added a token check on the snapin download/checkin endpoints, but the deployed FOG Client doesn’t know to send that token — so every legitimate snapin download was getting rejected with #!auth. Closing one hole, opening a different one. Sorry about that.

I’ve reverted the patch on both dev-branch and working-1.6. If you pull the latest and re-run the installer (or just git pull + your usual deploy method), snapins should start working again. Versions to look for:

dev-branch: 1.5.10.1856
working-1.6: 1.6.0-beta.2336
The underlying security issue this was meant to address still needs a real fix, but that requires coordinated changes to both the server and the FOG Client itself, so it’ll be a future release rather than a hotfix.

Let me know if pulling the revert gets your snapins running, and thanks for the detailed report — the “binary garbage” file you described was the clue that cracked it.

@GregorS Well the good news is it is binary data (that’s why it looks so garbled) bad news is it’s not downloading the whole file which is why you’re getting the error. Do any snapins work? Or are all snapins broken?

@GregorS Right, the problem is the download failed. Why it failed, I don’t know.

Basically the FOG Client isn’t downloading the file right now, at least not fully.

Are you able to read the file as in a text?

Maybe there’s textual data hidden in there:

You can usually do that with something like opening cmd and running:

type “filename”

If the file is still recognized as binary data the command window may show wonky characters, but otherwise no less wear or tear or anything and you’re not accidentally running a broken application on the system. You’re literally just trying to read the contents of the file.

I am sneakily suspecting a change to how we’re trying to cleanup potential XSS Unauth paths is causing this problem and will want to get it fixed.

While i could try to replicate the problem myself, it’s not a simple thing to replicate at least on my side of things anymore

@GregorS The file size is likely the problem. The EXE you have is literally 1KB (on th emachine I suspect was the one expecting the file?

How big is the actual file on the server? FOG Client is saying “the file we got doesn’t match what is expected as per the information on the server”

@GregorS Should be fixed apologies. Trying to fix XSS issues.

@kratkale You don’t need the clonezilla to see this information though admittedly it’s not exactly straight forward.

You can load FOG into debug mode and it will drop you to a shell where you can then run the lsblk command as well.

That said, if booting to clonezilla isn’t that difficult a thing, then it’s all good either way.

@kratkale I’m unsure I understand?

If the Group Primary Disk is empty, nothing should be changing on the hosts within the groups.

Just update the group’s Image, and save.

@kratkale I don’t know what you are asking.

what’s nvme1n1 this boot cycle, might very well be nvme0n1 next cycle.

While you may see some level on consistency, SERIAL based devices (PCI, SATA, USB, etc…)

All load their identifiers (/dev/sda, /dev/nvme0n1, etc…) on a first come first serve basis.

What’s /dev/sda1 this boot may be /dev/sdb1 next boot and so on. There’s 0 method to guarantee they will always get the same label which is why many Linux machines use a UUID for the fstab file now instead of their path names (which was used for a long period of time).

FOG just returns the list of devices lsblk sees in the order lsblk sees it.

@kratkale I didn’t know you were updating the serial of a group of devices, you should not do that. Groups are just mass updating hosts with the information you provide for the Host base settings (snapins, primary drive, kernel, etc…).

@kratkale That seems correct to me, yes. If this is a drive you’re testing proof of, I’d first just replace the actual second disk with something you don’t care to lose to test.

What I don’t want is you to just trust me at my word for the sake of things and lose actual data.

Another method you can use in case this isn’t sufficient, it’s a little more involved I suppose is to simply unplug the disk you don’t want being written, but that’s a part of the problem. At a glance you of the hardware you have no idea what drive is which. That’s the basic problem you’re running into now:

nvme0n1 this time might be the right disk, but next boot nvme0n1 might be the student disk. It’s all dependent on who starts up and responds first.

@kratkale Like I said, if you know which nvme drive has the student data, and which is expected to be the OS:

On a registered host you can explicitly call out which drive using “serial, wwn” or otherwise.

You type in the wwn or serial number: lsblk -pdno PATH,SERIAL,WWN,SIZE --nvme respective of your device. (I lowercase them for simplicity.)

Find your “primary” drive, and put in either one of those details in the form field and give it a shot. It should work and will leave the other drive completely alone so long as the type of image you’re using is “single disk” style.

@Mr_K This seems to be a routing issue:

Your fog server lives at 192.168.0.3

Your machine is getting an IP of 192.168.1.148

Your router providing 192.168.1.X is likely unable to route 192.168.1.X -> 192.168.0.X

@neodawg Can you provide the systems php error log, for Alma I think its RPM based so you would -> go to the page and see this -> get the last 100 lines or so (sudo tail -n 100 /var/log/php-fpm/www-error.log) This should tell us where it’s failing.

If you’re also able, can you tell us what version of FOG you’re running?

(Login to fog, bottom right hand corner should tell you the version you’re running.)