FOG Client 0.11.5 messages don't reflect snapin exit codes

[Darrin Enerson]

I’m using RC8 with client 0.11.5 and noticed that the messages given by the FOG Client don’t accurately reflect the exit codes of failed snapins. For example I have a snapin that exited with code 1618 yet still received the “Installation has finished and is now ready for use” message. Since a 1618 means that the installer halted due to another install being in progress the software didn’t install at all. Since the exit codes are being logged it appears that either they’re not being checked before the message is sent or the checking is broken.

Tangential to that it would be nice if the client could detect installs in progress and delay snapin execution until they’re completed but that’s more a feature request than a bug.

Let me know if you need any log files and I can provide them.

[Joe Schmitt]

@Darrin-Enerson Now that I have some free time, here’s my 2 cents.

Snapin Notification Message

The notification message just says the snapin has finished. While I could certainly add a lookup table of all of the common return codes, why? Return codes are not global, the return codes for msiexec vs the return codes for bash/batch are completely different. Furthermore that message is showed to logged in users. In the fog.log the actual return code is logged and its also sent to the server.

Msiexec Detection

Snapins don’t just run msiexec, or even install software for that matter. The concept of snapins is to allow remote file execution, nothing more. Now a large percentage of our user bases uses that system to install software. But it’s not a software management system and isn’t intended to be one. It also targets Linux, OSX and Windows. If we were to have msiexec detection it would also demand apt-get, yum, dnf, pacman, and every other possible single-lock software system? In addition, having some halting mechanism introduces a way for a random user to render the client useless. Let’s say you have some mischief user wanting to screw up your client for some malicious reason. They could simple make an exe named msiexec and run it. Then when the client is instructed to run a snapin, the whole client becomes effectively disabled. I could certainly write prevention code for this, such as doing analysis on the detected msiexec process, but as you can see it introduces much more complexity.

TL;DR

Snapins don’t just run msiexec, or even install software for that matter. The concept of snapins is to allow remote file execution, nothing more.

[Wayne Workman]

@Darrin-Enerson said in FOG Client 0.11.5 messages don't reflect snapin exit codes:

Tangential to that it would be nice if the client could detect installs in progress and delay snapin execution until they’re completed but that’s more a feature request than a bug.

If the other installs are snapins, it would wait and do one at a time. It would be a nice feature to have extra detection though. It’s up to @Joe-schmitt

[Darrin Enerson]

@Wayne-Workman In this case it was the first snapin in the chain that spit out the 1618 so I’m guessing a Windows update or GPO install hadn’t quite finished with msiexec yet in the background. All of the installs specifically handled by the FOG client waited appropriately so it doesn’t appear to be an issue there.

[Tom Elliott]

@Darrin-Enerson The exit codes you do see ARE the exit codes from the snapin.

It’s a bit weird how it all works, but it does work. Even in the case of a batch script snapin, the exit code returned (typically in a script file from another executable as launched) the exit code is of the “Primary” execution of the script.

So I’m a bit confused. I don’t think the client is in a state that can say such and such exit code means a failure occurred. The return code is the issue is returned, and once the client knows the snapin is “done”, regardless of state, it’s going to continue on. Maybe @Joe-Schmitt can add some way to more appropriately present, but as far as the client is concerned (at that point) the snapin is finished (therefore it must be ready for use).

[Wayne Workman]

@Tom-Elliott I think mainly the request was to detect if an installation/update is in progress, and if so, to wait.

[Tom Elliott]

@Wayne-Workman I don’t think that’s accurate though. See, the client, currently, only knows the state of the items it’s working on. So if another install is happening (separate of snapin installations) it really doesn’t have a good means to know if a prior running installer is happening (particularly this is the case for MSI’s).

I’m not aware of a way though Joe probably has some idea to approach it better than I do. As far as exit code message goes, that shouldn’t be too difficult (though the message likely wouldn’t display the exact message of the exit code as that can change between applications.

[Darrin Enerson]

@Tom-Elliott I’m wondering if just a simple process check for msiexec and the like before starting snapins would address detecting installs.

As for the exit codes my feeling is that since these are generally standardized for most installers a simple success/failure/unknown message based on a general group of codes for each category would be helpful. If this isn’t the intended behavior already then that would fall under a feature request as well but if it is meant to do a check there then, at least for the 1618 exit code, it’s not serving the correct message.

[Joe Schmitt]

@Darrin-Enerson Now that I have some free time, here’s my 2 cents.

Snapin Notification Message

The notification message just says the snapin has finished. While I could certainly add a lookup table of all of the common return codes, why? Return codes are not global, the return codes for msiexec vs the return codes for bash/batch are completely different. Furthermore that message is showed to logged in users. In the fog.log the actual return code is logged and its also sent to the server.

Msiexec Detection

Snapins don’t just run msiexec, or even install software for that matter. The concept of snapins is to allow remote file execution, nothing more. Now a large percentage of our user bases uses that system to install software. But it’s not a software management system and isn’t intended to be one. It also targets Linux, OSX and Windows. If we were to have msiexec detection it would also demand apt-get, yum, dnf, pacman, and every other possible single-lock software system? In addition, having some halting mechanism introduces a way for a random user to render the client useless. Let’s say you have some mischief user wanting to screw up your client for some malicious reason. They could simple make an exe named msiexec and run it. Then when the client is instructed to run a snapin, the whole client becomes effectively disabled. I could certainly write prevention code for this, such as doing analysis on the detected msiexec process, but as you can see it introduces much more complexity.

TL;DR

Snapins don’t just run msiexec, or even install software for that matter. The concept of snapins is to allow remote file execution, nothing more.

[Darrin Enerson]

@Joe-Schmitt Thinking of it that way I see your point. I hadn’t considered the malicious halting but now that you mention it I could see that being a major issue. I withdraw my request/suggestion on this one. Thanks for the time to explain your thinking.