Posts made by Joe Schmitt

@Quantum thanks for the resource! We’ll take a look at possibly integrating that net-boot configuration automatically. This would make using FOG in a Mac environment much easier. This trick for us will be adapting this to any distribution FOG runs on, which shouldn’t be too difficult.

@giejo63 Can you upload the fog.log anyways? I can’t help unless I know exactly what is or isn’t happening.

I’d just like to step and and thank you @AsGF2MX. You’re doing an AMAZING job helping us debug this.

@Kiweegie @ch3i The “Reset encryption” button will only fix “Invalid security token” errors. What you have is an untrusted server. Did you reset the CA keys or swap out FOG servers recently?

@nengelhardt I need to see a fog.log file from one of the clients that failed to update.

Can you press “Reset encryption data” for the host on the fog server?

@Claude-Girard @Matthieu-Jacquart @Wayne-Workman @Trevelyan @Brian-David
I need the fog.log file from disappeared hosts (preferably relatively soon after they vanished). Logs from the new client will be most helpful.

@Matthieu-Jacquart The “Reset encryption data” is mainly doing one thing: Clearing the security token for a host.

Each host has a security token used by the client. This token is private; only the client knows it and is protected. It is used to prove the identity of the host, ensuring no one ‘fakes’ being a certain host. So when you 'Reset Encryption Data", you are essentially telling the server that the first host to say that they are the host in question gets ‘locked’ in (pinned is the technical term).

Now, as to why hostnamechanger doesn’t work. Well, up to 0.9.X, encryption is only required for hostnamechanger. The next major release (0.X) of the client will force encryption on all modules. In order to have encrypted traffic, our handshake must occur. During the handshake the server proves its identity to the client, and the client proves its identity to the server (using the security token). If the handshake fails (due to a bad security token), encryption cannot occur.

The most common scenario where the security tokens for a client will be incorrect is if you manually uninstall a client, and then install it.

@midas1989 Your logs indicate this is for the legacy client. Mind posting this in a new thread?

I will attempt to replicate your issue and get back to you.

@tian unfortunately I cannot replicate your issue.Would I be able to teamviewer in sometime today / tommorow ? (PM me with details).

@Wayne-Workman

@Matthieu-Jacquart is dead on, one way to think of it is:

{Snapin Run With} {Snapin Run With Argument} {SNAPIN} {Snapin Arguments}

So if you were to execute an msi via cmd, you would do:

msiexec /i MSI_NAME /quiet

This would break down into:
Snapin Run With: msiexec
Snapin Run With Argument: /i
Snapin File: The MSI
Snapin Arguments : /quiet

@mtmulch I advice against using wget to keep up-to-date with dev builds. We release several new dev versions daily, and wget will not work well for keeping up to date. I recommend using git instead.

Just run

git clone https://github.com/FOGProject/fogproject.git

And a fogproject folder will be made with the latest and greatest. Then just run

git pull

inside of the fogproject folder whenever you want to update the installer.

For valuable snapins, I would probably start with basic cmd scripts, and then play around with silently installing some exes / msis. (For an exe installer the silent parameter is usually /s or /S).

I may be a tad bias when it comes to this, but I would recommend trying out our development builds on another vm / server. You’ll find imaging speeds are significantly faster, and there are some added security benefits. You should also check out the new beta client (my baby) which works with our development builds. It’s far more responsive than the 1.2.0 client, has quite a few security patches, and is more … ‘professional’ in areas, such as shutdown prompts and such.
(See https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk)

Awesome! You’ll notice that your logs will be filled with “DEBUG” messages, this is because I gave you a debug build. These builds are incapable of being imaged without throwing constant errors (inorder to prevent debug builds from being used in production). So be sure not to use that in your images.

I’ll release v0.9.5 as soon as possible for you though.

I believe I have patched the issue. When you are available for teamviewer, PM me and I’ll test it.

Thanks for the information. They don’t work because I have not had any network printers to test with before. I have a fairly busy weekend, but when I get time I’ll contact you and have you help test some possible patches.

Just an FYI, most software packages are already snapin compatible and don’t need to be made into self extracting archives.

For example, Java can be done by uploading the jre exe and setting “Snapin Arguments” to “/s”. Basically you want to find out the silent installation command line arguments for the software package and use that.

I found the issue, a fix has been pushed. A variable was misnamed. Soon as you apply the patch the clients will work again.

I just had another person report the same “Invalid host certificate” error to me. The one thing I am absolutely positive of is that this is a server issue. I’ll let you know when I learn more.