https://news.fogproject.org/fog-client-v0-11-12-released

@Troye-Johnson this issue is patched in v0.11.12.

@jbrabhamMSD I’d need to remote into a problematic machine to identify why the new client still thinks the legacy is present. Send me a PM and we can work out some time that works for both of us sometime next week if it’s alright with you.

@Amh PXE is definitely an insecure protocol, unfortunately it also so happens to be the standard every machine has. I am working on a new system for Windows machines to boot to FOG without PXE along with secure boot compatibility, but they won’t be available until FOG 2.0.

The best approach to remain secure is to have some network monitoring software keep an eye out for rouge dhcp/dhcp proxy servers.

@kleanthis just like any other software you’d want on that machine; install it in the image before capture.

@wwwanaya see the link @falko posted. Unfortunately there is no way to regain control of the client if you did not preserve your server certificates. You will need to re-install all deployed clients to regain control of them.

@pmonstad is that for Bokmål or Nynorsk? Right now I’m assuming its for Bokmål.

@kwisher in addition to what @Tom-Elliott asked, did you follow the sysprep instructions for the client? https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

Also per the log 4/10/2017 9:34 AM HostnameChanger ERROR: Required domain information is missing, if you’re trying to manage the machine’s domain binding you need to fix in all the required fields.

@utopia you are correct that the client should be using the SHA512 to see if it needs to re-download the banner. It would seem I forgot to put that into production. When 0.11.12 is released I will also include a patch for this, thanks for bringing it up!

@kylebeth94 the client does not follow 301 / 302 http codes (redirects). I run one of my development servers on https, and with a webroot of /. You’ll need to configure your webserver to serve out / without using redirects. You can redirect http to https traffic if you desire, but just make sure the client is set to use https then.

@Bob-Henderson there’s really 2 factors going into it (keep in mind this is a very simplified / high level overview of what we’re doing). First is the removal of NFS (it’s still an image storage option if you want, but not how FOS reads the images now). The server is now the one responsible for streaming an image to the client, this means we can use protocols such as http/2 streams, SPDY, on-the-fly packet compression, so on.

Secondly is making the server and client more intelligent (giving it a basic ai of sorts). FOS will basically be running a custom build of the linux FOG client to give us access to our existing framework, and real-time server communication. This means the server / client can automatically take care of throttling on congested networks and on-the-fly transferring which server (assuming you have a multi server setup) FOS is receiving the image from incase of high workload, or if a more optimal server frees up.

TL;DR By making FOS smarter, and upgrading our transport protocols.

@Obi-Jon @Junkhacker it would be interesting to see the speed difference using our new fog 2.0 transfer protocols / techniques when it’s more ready for testing. Generally speaking our new approach we’re working on is far more stable in transit (less packet loss), and capable of a much higher throughput / network efficiency.

@tonytonyistony Nothing else is needed after hitting reset encryption button, the client should have automatically recovered from the failed state. I’ll send you a developer build of the client later today, if you could install it on a single problematic host that would be extremely helpful as it should log what’s causing the error. However, keep in mind developer builds of the client are extremely verbose and not meant for production use as it will likely log sensitive information.

@Cyril-Fleury said in Conditional execution of a snapin ?:

How can I make some snapins to waiting for domain integration ?

Are you using a network share in your script?

@tonytonyistony while the client is in this bad state, (continually logging Could not parse data), could you try going to the host in the web portal and clicking Reset Encryption Data? Its not needed, but I want to see if it’ll force the client to re-authenticate and fix this issue itself.

@tonytonyistony Yeah it basically becomes unresponsive to the Server., does the client continue to log, or does the process itself just stop. I ask because if it crashes completely (the process dies), then its likely an OS-specific issue. Whereas if the client continues to log but is unresponsive to the server, then its possible that an irrecoverable bad state does exist in the client’s code, and that needs to be patched.

As for these messages:

Mar 31 10:09:51 Pascua-02 systemd[1]: FOGService.service: Unit entered failed state.
Mar 31 10:09:51 Pascua-02 systemd[1]: FOGService.service: Failed with result 'timeout'.

they are likely due to how we wrap the client on Linux. Keep in mind we are actually making a Windows oriented service run under every common *nix based daemon / service system. It’s likely that Ubuntu’s daemon system does not like how our service wrappers handle things, but it definitely won’t harm anything or cause any failed code. We could probably fix the client’s service wrapper for Ubuntu, but we’re a tad stretched for developers right now and its a fairly low priority ticket.

@tonytonyistony said in Fog Client service stops responding:

can no longer successfully run the service without a reboot. The only way to restore connectivity to the FOG server from the client host is to reboot the OS and have the service start at boot.

First off thank you for gathering all the information ahead of time, it definitely helps us out.
Does the client stop entirely, or are the logs essentially all:

 3/31/2017 10:12 AM Middleware::Response ERROR: Unable to get subsection
 3/31/2017 10:12 AM Middleware::Response ERROR: Object reference not set to an instance of an object

@Warget can you try this build: https://download.mono-project.com/archive/4.3.2/macos-10-universal/MonoFramework-MDK-4.3.2.macos10.xamarin.universal.pkg if it still doesn’t work I can make another bug report to mono about this issue.

@Warget could you try uninstalling mono, and installing this version instead? https://download.mono-project.com/archive/4.6.2/macos-10-universal/MonoFramework-MDK-4.6.2.16.macos10.xamarin.universal.pkg

@Warget unfortunatly this is a bug with mono we’ve been waiting to get patched for awhile now. Once upon a time they did fix it for that version of OS X.

What version of mono are you running (do mono --version)?