@lukebarone Great to hear that you intend to participate in this! You can do it either way. I am pretty sure both ways should give us the same results but I’d recommend using the FOG debug mode as you are using the very same tools as would be used in the initrd later on anyway.

Schedule a task for those clients you want to check. Does not really matter if it’s an upload or deploy task. But just before you create the task check “Run as debug task”. The PC will boot up as normal into the FOG system but then drop you to a shell. The you can just run the command and post results here. Please make sure to double check when typing the results. Thanks!

@kwetiaw The professional version allows for network deployment, they also offer a msi repackager for the professional version. http://support.horizondatasys.com/Knowledgebase/Article/View/97/0/rollback-rx-deployment-guide

@jdd49 said in File Formats - HFS & XFS:

XFS
Does not have the ability to shrink period. It can only grow. The only possible solution is to do a file backup using something like xfsdump, then recreate the filesystem. Or make the smallest partition possible when you first install, then grow after imaging.

Thanks for the info, I guess it’s the best way to go for XFS (for now).

The snapin issue is known about, it’s fixed in RC-9 already.

For now, hosts need images assigned in order to deploy snapins via groups.

And, you can clear host settings via groups already. It’s exactly the same as clearing them on the individual host - but with groups.

Please note that it’s been said that the DisplayManager has been built back into the client.

https://forums.fogproject.org/topic/8383/svn-5949-screenres-manager/8?loggedin

@Joe-Schmitt said in Host Screen Resolution:

@networkguy 0.10.0+ removed DisplayManager from the client. As @Sebastian-Roth pointed at, its a very “Windows only” thing and never received much use compared to how much effort went into maintaining it. @Tom-Elliott, perhaps we can add some kind of “warning” next to display manager stating it isn’t present in 0.10.0+ ?

Obviously if there is enough support for it, we can add back display manager, but we won’t be porting it to OSX or Linux.

If it’s an imaging task (or rather an init needed tasking, there should not be any menu’s presented to the user) so I’m just guessing this is if the host is in a snapin tasking you’re seeing the issue?

@Tom-Elliott Ok then.

@Wayne-Workman The other option is for the OP to extract the inits make the change to fog registration script and then recompress the inits and then exchange the “fixed” inits on his fog server with the official ones.

@Tom-Elliott Thanks for that reply.
I am only (really) interested in the Serial/MAC address combination of the devices that I boot, so I’ll develop a bootmenu.php that posts these values to my own database and waits for the user to create a multicast task then.

Is it possible to remove the auto reboot feature however? (replace it with a … press any key to continue), that way the engineer can still quick register, but doesnt need to be present (and thus can move on to start/register different machines)

@Tom-Elliott O ok. Well I will wake up from my dream then lol.

I wouldn’t see it as something to go in the next release, as you say it will complicate things.
It would help in cases were the imaging process fails, and then the host auto reboots and loses the log. A debug will allow you to see the error if it happens again, but uploading it to the server would make it available via the fog console without the need to deploy again.

@JJ-Fullmer Nah, I don’t think you made a mistake. If you look at the change log for RC-6 it addresses an issue that sounds like what you described here. I’ve also had this happen at work with RC-5 and RC-3. I’m hoping it’s fixed, it’s something we definitely need to pay attention to. We need to really pay close attention to all things in the RC at this point, and bring up all concerns so that the release is as solid as is humanly possible.

An option to block mobile user agents seems easiest to implement.

@sudburr I can see that post you removed, It uses TCP.

Also, see here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

That is oriented for migrating to a new server, but it’s the same thing to just move certs to another server for use there too.

I added a zero to the value, that should do it.

I’d be against that.

The certificate is the central and single point of success or failure of security for the fog client. If an attacker could get it by any means at all, all security is compromised. Having an actual feature that allows it to be downloaded would increase the risk of compromise several times fold.

a local admin ought to be the only person that can touch it.

@Tom-Elliott said in Location plugin by subnet:

As if you’re on subnet 255.255.192.0 and you originally set the DB value up to 255.255.0.0, you’d be far and away off.

People should have their settings correct. This is another thing that can be corrected for at installation time for storage nodes.

@george1421 If you know the IP address of the host requesting imaging (which you can get via PHP), and you have an IP and subnet mask for all nodes in the DB, you can just calculate what one it should use. The individual host doesn’t need to pass a subnet mask.

This setup would require the least amount of change to FOS and/or client (none at all), and a subnet mask field for nodes would be needed.

This already exists. It’s the fog log files that show the storage node name as part of the file name.