@x23piracy All of these should now be fixed. Remember, you do have to update first to see the fixes. You shouldn’t need to delete and readd though.

To add on, events such as what you’re describing, would need to work based on a return. I can have it say it did such a thing, but if there was an error the information would be incorrect.

Returning a code, I think, is not necessary at least from the GUI’s perspective.

Hostname changer does not come with a return code, nor do I think it should.

The only reason snapins have this is because they are their own thing. They have a return that let’s the FOG system know they are complete. There are no other client files that do this.

Just make a cron script (see https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man5/crontab.5.html#//apple_ref/doc/man/5/crontab)

So for example

@reboot /my/expand/script

Just be sure to delete the cron entry after it runs (you can probably make the script do this).

@Wayne-Workman It happens much faster than that sometimes. (sub 15 second patch?)

@Junkhacker said:

@george1421 honestly, i thought that checkbox was in to change how often host encryption keys were changed…

That would sound more logical though…

Maybe a plugin for OCS Inventory or Fusion Inventory 😄

For right now, I can only implement disabling auto-update based on global setting. This is because the client doesn’t return any identifying host information for us to filter by host.

However, this is, I think, a very needed “feature” of FOG and the new client.

My posting seems a bit strange I’m sure, but just know it’s trying to say this has now been implemented.

@moses I would recommend using post-install scripts to modify the unattend xml, then just disable hostnamechanger all together.

It appears that the OP is asking for an endpoint management solution (akin to the beast know as Altiris). FOG is an image deployment tool, not (currently) an endpoint management tool.

With that said, I could see a path forward with OCS and puppet to fill in the missing bits from FOG. But as Tom said, that is more inline with FOG 2.0 or later as fog 1.3 is already under a new feature freeze. Integrating OCS shouldn’t be that difficult since I know a few other open source projects use that as their inventory engine since its cross platform and its system requirements are in line with a standard LAMP stack.

(just thinking out loud)
Actually you wouldn’t need puppet if you could create a policy engine to bridge between OCS and snapin deployment. That policy engine would take a policy (i.e. all computers in FOG group XX shall have MS Office 2016 installed or remove Notepad++ if installed on any computer). Based on what OCS reports the policy engine could create a snapin deployment task for the required action. In theory it should work. FOG would need to have persistent groups for sure (currently not available) and additional dedicated developers to pull it off. But in theory it sounds plausible.

@Tom-Elliott while I don’t have a dog in this race, I agree with Wayne that fog should keep all of its bits in its one location. /opt/fog/… is a logical choice. Typically with rhel based distros /home is placed on its own partition so technically its OK to use that since filling up the /home partition won’t bring down the system. But unfortunately not all linux distros place the /home in its own partition. If its an option in the installer to change it to another location, set the default to /opt/fog/backup and still allow the user to change the location if they want to. I also understand that unless installers take the extra step to move /opt to its own disk/partition they will not be any better off than just placing it on the root partition today.

But that is just my opinion on the topic.

@Arrowhead-IT Of course I can script it. But not everyone is familiar enough with whats involved to do that. My intention is to eliminate extra manual work in the back-end involving FOG. I’ll see about writing a patch.

@Tom-Elliott thanks again sir

@Tom-Elliott is iPerf still in the $PATH variable in the inits, and available?

If your DB and PHP talented, and in order to prevent a re-write of the web GUI in full, I’d suggest creating MySQL users for each actual fog user, and only give certain actions permissions to certain tables, and switch over what MySQL credentials are being used right after login. I’d even say the mysql Credentials used for logging in could be restrictive as well to just logging in.

@Arrowhead-IT It speeds up a fast connection because there’s additional bandwidth to use that wouldn’t otherwise be used. On a 1Mb connection, that is not the issue - there simply isn’t any more bandwidth available to use.

@loosus456 While it may be possible, I wouldn’t recommend it.

Ask and thy will be done (sometimes.)

@george1421 said:

But again no joy for use who need it today with the 1.3(ish) release. Fog 2.0 sounds really nice.

We could probably hack something together.

Btw, when clicking on the “Home” icon (dashboard link), I see the new hosts that needs to approve in a popup small java banner with a hyperlink “here” that directs to the hosts-waiting-for-approval webpage.

I can’t recall what git version I’m running though, will update tommorow.