@Clebboii Figured it out and should be workign without breaking security, in dev-branch. Please give it a shot or as I asked earlier, happy to have another tester on 1.6 branch

@Tom-Elliott This was not the proper fix, looking deeper.

@Clebboii Okay, I think I found a fix, though it’s probalby super ugly, but I do seem to see the log viewer is working once again.

please change to dev-branch and do a git pull then install, and hopefully your Log Viewer will be working and functional again.

@Clebboii This is probably true. We learned about a security issue and worked to solve that problem. I’m seeing what i can do to recover this feature, but it may take some time.

This feature is working on the working-1.6 branch if you’re willing to be a little on the bleeding edge (testing would be good for this branch. I’m pretty sure it’ll work for 99% of your needs without much issue, but without enough testers testing this, it’s a slow process.)

My testing shows with the security issue that was fixed, I’m still able to see the log viewer.

It’s difficult to simulate between the different 1.5.x and 1.6 for me.

I’m seeing if I can build a VM that would do the 1.5 side of things, but I’m not putting all my focus into that version of things any more. We are close to 1.6 finally, just need more people letting us know of anything they see.

If you’re unable to test that I understand, and I’m going to try to fix what I can if I can figure it out, but it’s not a top priority for me at least.

This feature is useful, but not a make or break thing for FOG’s operationality in my eyes. I hope that makes sense.

Often time,s this seems to be due to UEFI Secure boot being enabled when it should be disabled.

@eoli3n Versions are impossible to give because they keep changing, so we do try to have the version that are supported between masters/dev-branch/etc… for the os’s at that point in time (and backward)

Debian Based (Mint, Ubuntu, Debian), Redhat Based (Redhat, Rocky, Alma, Fedora).

The versions, dev-branch is more likely going to be in line with latest/greatest. Some what of a delay of course, but there’s no list that clearly spells out what version of specific OS is supported.

In my opinion, Redhat based OS’s are the best as we don’t have to continually update the installer code to support future versions. Most will just work right out of the box.

Migration process? No, if you’re moving one machine to another that’s one thing of a migration and there is a process for that, but if you’re meaning “I’m on bookworm and without moving anything, I’m going to do an in place upgrade?” I don’t believe there will be problems but what I would suggest is re-installing FOG once the upgrade is complete as any services or config files that got changed would need to be rebuilt for the new OS. It’s not hard and I don’t think there will be any issues. If there are, please let us know.

@sideone Specifically regarding the Invalid Security Token issue you’re seeing, you would need to reset the host’s Security Tokens.

This can be done per host of course. I believe the option is also available on groups: Specifically the Reset Encryption Data

@sideone Please run an update, I just released what I believe should fix this problem.

The reason you’re seeing that in the browser is the url is expecting a mac address being sent in. #!im == “Invalid MAC”

@Robert Can you post examples of the errors you’re seeing?

ftp is one thing, which uses the fogproject user, though this was migrated from a user named “fog” in the past. So I think this is what you’re referencing but there’s also password syncing that may need to happen, but to try to provide more direct and helpful information, examples would be awesome.

Thanks!

@Greg-Plamondon I forget what version of fog you’re running but I suspect (and had just forgotten initially, apologies) that you need to get the token:

Process for that is as such:
Would be to change:

curl -A "" -Lkso /tmp/hinfo.sh "${web}/service/hostinfo.php?mac=$mac"

To:

    base64mac=$(echo $mac | base64)
    token=$(curl -Lks --data "mac=$base64mac" "${web}status/hostgetkey.php")
    curl -A "" -Lkso /tmp/hinfo.sh --data "sysuuid=${sysuuid}&mac=$mac&hosttoken=${token}" "${web}service/hostinfo.php"

Hopefully this helps?

@Robert FOG 1.5.10 was not written when Debian 13 was built. Stable branch hasn’t updated for the month of September but this fix is in the dev-branch.

Please, for now, switch to the dev-branch and install where this should be resolved.

@Greg-Plamondon Are you sure the machien that’s loading has an other1 tag defined to it?

Looking at the php that returns the export variables, other1 maps to $othertag and other2 maps to $othertag1

@Greg-Plamondon Are you willing to run a debug mode and echo what’s coming out of $othertag? just to ensure that’s being set accordingly? This won’t fix the issue, but will let us know that it’s being pulled in correctly.

@plegrand I’m not sure i understand what you’re saying here.

If you installed Stable branch and it completed successfully you should be on 1.5.10.1673, not 1.5.10

Did it complete successfully?

@plegrand Something on your network is not allowing the file to download.

Can you try the curl you see it erroring out and see what you see?

@plegrand

It seems like maybe you’re behind a proxy? or something, I don’t know. If this were broken in general, i’m certain we’d have known about it by now.

@plegrand IT seems to me you manually edited yoru lib/common/functions.sh

So you need to stash the changes or revert those changes.

This can be done in many different ways, usually the simplest method being:
git checkout lib/common/functions.sh but this would only fix this one file, if you’ve any others you changed manually, then you may need to do any/all of those files.

The stash method is another simple way to move all custom changes out of the way:

git stash then the steps.

I don’t know what changes you were making so this is entirely up to you on what steps you’re willing to part with. Have a backup handy of your installation directory just in case.

@plegrand

cd /path/to/fog-project/installer/folder
git checkout stable
git pull
cd bin
./installfog.sh

That should be all that’s necessary. The stable can then be changed to master for 1.5.10 official release, and dev-branch for whatever the bleeding edge of FOG is based on the 1.5.10 branches. and working-1.6 to see the beta version.

@plegrand 1.5.10 is very old, run on stable branch or working-1.6 you will be fine.

@AngryITGuy The iPXE file likely needs the boot shim or whatever to allow things to work correctly and with upgrades this isnt’ really feasible as every newly built ipxe file (snp.efi, snponly.efi, etc…) would need that shim configured and installed in place.

It’s possible there was a step in the original installer from your collegue that may have moved the ipxe files from a backup where these were shimmed appropriately?

I don’t know exactly just spitballing.

Ultimately, yes, I’m glad you got this working by disabling secure boot.

Technically, it’s possible to do this with secure boot, but not in an easily scalable way that we can include as part of the install script. Nor, in reality, do I think we want to do such a thing. While it’d be nice to do it as an installer, I am hoping we can get a document that more clearly details what steps to do. This is mainly due to the constantly changing nature of fog, so if we have an easily repeatable knowledgebase on what steps to do in a well documented sort of way, it’d be a lot better than trying to have us maintain some installer that could easily have some issue on a new iteration and continually have to maintain yet more blocks of potentially os dependent code.