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.

@MRCUR Inits are uploaded.

@Developers What if - the full host registration process detects if the location plugin is installed - and if it is, make picking a location mandatory via the Full Host registration menu even if no image is chosen? Thoughts?

It might be a better idea to just add the settings to the DB instead… thoughts?

@Wayne-Workman I’d definitely go with George’s suggestion and skip iPXE entirely if booting from a USB stick anyway. This way you can skip on part that might cause head aches along the way. On the other hand you cannot use iPXE configuration (loaded via HTTP) from the FOG server then. You’d need static parameters configured right on the USB stick - possibly have several entries for different taskings.

You probably know George’s posting on how to build a USB stick for booting and Tom’s article on building a custom kernel. Give it a try and you sure will learn a lot of new things.

@Sebastian-Roth the only reason I’m thinking that is because it’s the only thing I added that I can think of that could be giving the bad sector. I don’t know if it causes issues or not and I’m leaning more that it likely isn’t. But just seeing if maybe it will work?

@Wayne-Workman Well yeah, I don’t want to hold up 1.3, hence the plugin/module idea.