@lperoma Thank you for the detailed write-up. The detection notes made this quick to scope.

FOG 1.6 covers this as follows:

FOG Client cannot authorize. This was the real gap, and a pull request now adds it: https://github.com/FOGProject/fogproject/pull/2089. The server records each host whose client fails the handshake: since when, how many times, the source address and the reason. A new list report, Reports > Client Authentication Failures, shows them with the fix next to each one. A host leaves the list when its client authenticates again. Two reasons are recorded:

The security token does not match. Reset Encryption Data fixes this. The server cannot decrypt the client’s key. This means the certificate the server publishes for clients does not pair with its private key, so every host fails at once. A reset does not help. Running the installer with --recreate-keys issues a new pair.

One case stays invisible to the server. A client that trusts a different FOG CA refuses the server’s certificate and never sends a login, so there is nothing to record. Its fog.log shows “Certificate is not from FOG CA”.

Rejected iPXE menu logins. 1.6 already records each rejected login in the audit trail, with the username and the address. Look under Reports > Audit Report.

Hosts with no contact. 1.6 stores the last check-in and the last ping for each host. Fleet Report shows the last check-in, so you can sort on it.

All of this is 1.6 only. 1.5.x does not get these changes, so your script remains the answer there until you move to 1.6.

@heix75 No.

Not because it’s not a QOL improvement (it is) but because what you see in 1.5.x.x is NOT what is the end goal.

If you want to see what the UX is moving toward install the version of FOG on working-1.6.

You’ll understand (I hope), then, why I’m saying this.

I know this is an ancient topic, but I wanted to make sure I updated anybody who was interested in a docker image to my new one.

please check my post here

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

@Tom-Elliott Really for the purposes of user tracking. It is helpful for us to keep track of who is deploying and capturing. This is purely for transparency and accountability. I can instruct my team to always register devices they are imaging but I cannot force it.

EDIT: Is there a way to force full reg prior to image deployment? Like a prereq for deployment.

@ramone

I got your message on the github repo. In regards to the DHCP issue, I’ve updated the code and it should work now. Please test and follow up in the issue thread. Please note that some of the variables in the .env file have changed so you might want to review that before starting it up.

thanks!!

88

@Tom-Elliott What’s the difference between the full and quick registration processes then? because AD join exists in full, but not in quick…

@Tom-Elliott ah, that would work! Sorry, the documentation is such a mish-mash that it’s hard to find answers for some of this stuff!

Not sure if anybody has actually had a chance to look at my docker image yet. I’m throwing my hat in the ring for maintaining an official image, but I’d need some help with it.

Because I’m not affiliated with FOG in any official capacity and I’ve never actually contributed to it in any way before, I completely avoided making any actual changes to the source. I have noticed that there could be a couple of things that could make the docker implementation a little easier though, specifically around the FOG services themselves. I’m not entirely sure they are completely container friendly, but I really need more hands on this to test it out thoroughly.

Also, I used Debian 13 as the base image for this and it ends up being pretty large (2.5GB). It might be possible to shrink this with alpine-linux but I didn’t want to break a bunch of stuff and then have to spend more time chasing those bugs. Anybody that wants to work that angle, please feel free.

@Frode-Woldsund

I created an image. Give it a go and let me know

https://forums.fogproject.org/topic/18000/unofficial-docker-image-beta

Haven’t really found a great fix here, I’d love to get some logging to work. But this seems to be working better than before. It moves the argument from the calling command and embeds it into the Snapin Arguments:

Snapin Type: Normal Snapin Snapin Run With: powershell.exe Snapin File (exists): runCmd.ps1 Snapin Arguments: "%ProgramFiles%\FusionInventory-Agent\Uninstall.exe /S"

the command in runCmd.ps1 then no longer passes an argument so needs to be changed to:
start-process -filepath "$exe"

@george1421 Thanks! I wonder if a chat bot could help with reading through what worked and make a tutorial.

@fabritrento As you stated it, UAC is preventing access. There is no real way to fix user cleanup that I’m aware of.

We have started working to remove the features that we cannot manage.

case 'service-autologout': $this->serviceAutologoutPost(); break; case 'service-displaymanager': $this->serviceDisplaymanagerPost(); break; case 'service-hostnamechanger': $this->serviceHostnamechangerPost(); break; case 'service-hostregister': $this->serviceHostregisterPost(); break; case 'service-powermanagement': $this->servicePowermanagementPost(); break; case 'service-printermanager': $this->servicePrintermanagerPost(); break; case 'service-snapinclient': $this->serviceSnapinclientPost(); break; case 'service-taskreboot': $this->serviceTaskrebootPost(); break; case 'service-usertracker': $this->serviceUsertrackerPost();

Sorry that it isn’t “pretty” but this is the code moving forward. You can think of anything not on this list, but still accessible in the 1.5.x versions as being deprecated (to non-functionality)

@baovipboy156
thanks for your input, but cannot get it working with it…
would you please post more details and steps by steps to get it work, please…

iventoy1.20
fog 1.5.10.1615

@Tom-Elliott

Yes, I even spun up a new FOG VM where the mount points were created before FOG was installed to makesure the FOG installer created all the files and set permissions.

edited - words

@Tom-Elliott yay, thank you

@Tom-Elliott Looks like its working now, thank you!