Linux host name change after imaging?
-
@Tom-Elliott Sorry it took me a bit, I’ve been trying to figure it out… I keep getting these weird reboots while the snapins are trying to run, I see it checks in and reboots… then it reboots a couple more times and seems to finally run the snapin (still working on the script)… The hostname isn’t changed though… fog.log
-
@Tom-Elliott Yeah, I’ve tried all afternoon. I only have the script doing 3 things now. Create an admin account, delete my account and then make the pc immutable using overlayroot.
After the install it just reboots once the VM has checked in (same as earlier). It will continue to reboot until I log in.
Once I actually log into the system the snapin seems to be able to do what it’s supposed to.
While I was waiting for the snapin to kickin (while I’m logged in) I checked the hostname… still no change.
Is there a trick to installing the client that I missed maybe? I followed the instructions and downloaded the .exe …
Note: The namechange DOES run after I actually log in and the snapin reboots the VM twice and when I log in it seems to have changed it
-
@adam1972 if you want to do this in fos right after deploying you could probably use a postdownload script to set the contents of /etc/hostname
You would just need to mount the disk that was just imaged and use sed to edit the file with the $hostname variable. Well there’s a few other steps but I’m on my phone.
I don’t know for sure if that’s still all there is to it as I feel like hostnamectl has gotten more robust in newer Linux releases across all distros, but it’s a good start. -
@adam1972 the double reboot is reminiscent of joining windows computers to the domain and then rebooting a second time to rename in the domain, though fog client has long since done it in one go. Are you setting the ad settings for the Linux hosts? Do the snapins have the reboot box checked in their definition?
-
@JJ-Fullmer no domain. I get a feeling it’s a permission thing. The double reboot is actually more… I let it go a few times as a test. It’ll keep rebooting until I log in and the snapin runs. Once the snapin runs, the client changes the host name as it’s supposed to…
I would’ve sworn it was doing it without my logging in… I think before I added the account creation to the snapin… -
I’m looking at a vm on it’s 7th reboot. It has the client, I’m almost 110% sure it’ll run through the snapin as soon as I log in. Is it suposed to wait for me to log in? I thought when i installed the service it would have the required permissions to do what it needs to? or am I completely wrong about it?
-
Yup, as soon as I logged in, it did it’s thing 100%… This can’t be right?
fog.log -
@adam1972 I was about to ask for the log.
So it looks like you don’t have the enforce option enabled for renaming the hose and the client thinks that someone is logged in. I’d try enabling enforce, I think it’s actually under the Active Directory settings a little checkbox there, might be under service or client settings on the host.
I’m using 1.6 where it’s moved to under service settings on a host. -
@JJ-Fullmer THANK YOU for geting back to me!
These? They seem by default set to work…
There’s nothing in AD
-
@Tom-Elliott I’ve now updated the Fog Server and uninstalled rebooted, re-installed the client and rebooted. I re-captured the image again and proceeded to image a different VM… Same result. The snapin won’t run until I log in.
The hostname has changed by the time I login, but snapins don’t run until (as I stated above) I log in.
Is this as expected? -
@adam1972 I believe the snapin running is expected to happen anytime, but I do know know the FOG Client code as I do pretyt much every other aspect of FOG unfortunately.
It is possible snapins cannot run until a user has logged in, but I don’t really have a means to validate that. (This would be specific to linux machines. I suspect mono engine that helps perform those tasks may need the user to login to establish permissions so this may not even be directly a fog client problem, but the installed mono package?)
The enforce host change thingy, that is under the host -> Active Directory and labelled:
Name Change/AD Join Forced reboot? -
@adam1972 said in Linux host name change after imaging?:
There’s nothing in AD
That checkbox at the bottom of AD is where you enforce hostname changes I believe. Which I just noticed is also what @Tom-Elliott said 20 minutes ago.
I would also look at the snapin definition, this screenshot is from 1.6, but these boxes still existed on snapin definitions in 1.5 (minus the No action, it’s just checkboxes for shutdown or reboot I believe)
If those are checked it could be part of why it’s doing so many reboots.
The fog client runs things in windows without being logged in, there’s actually 2 services running for it, a system service and a user service, I imagine linux works the same way.
However, if it’s waiting to perform the hostname change, there could be something else that’s causing a reboot at the linux OS level when the hostname is attempted to be changed without a reboot? If that is waiting to happen I believe the client waits for that to finish before attempting snapins. It causing the random restarts is still perplexing.
-
@JJ-Fullmer @Tom-Elliott I was going off of this for the services that should be running…
I haven’t messed with anything AD since it’s not joined. I can give ita try though…
Tried. Makes no difference. I also disabled a bunch of the FOG Services that I didn’t need,
These are the only ones running besides the one from AD that you said should be turned on -
Yeah… That AD setting for host name actually kept the snapins from running at all… It just kept rebooting every few minutes after I logged in. Once I unchecked it, the snapins ran after i logged in again … whew!!!
-
@adam1972 The
ADsetting isn’t general. Basically it’s enforcing the reboot happens to change the hostname and/or complete joining the domain.I think since there’s multiple points of hostname changing this isn’t working correctly (obviously) as the hostname shouldn’t need more than maybe 1 or 2 times to change it. Snapins running still is the end of the problem though? Not sure how to approach. Since hostname change is expecting to reboot maybe this is preventing the snapins from running. We could test that by disabling the hostname changing option altogether on this host?
