Active directory Join issue
-
Timezone: Nuts, I’ve been running the trunk build for so long I forgot about not everything being in 1.2.0.
just for clarity can you run this command from the linux console. This should be accurate for the ubuntu systems.
cat /etc/timezoneWhile your system time is correct, I want to make sure the system timezone is correct. I would expect the results to be something like “America/Chicago”.
In the /etc/php.ini there is a timezone property. Please set that to the proper timezone that is listed in the OS. Once you do that restart the apache service so that php will pick up the proper timezone.
-
George,
The syntax is America/Chicago should I have entered with quotation marks “America/Chicago” in the following files?
/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini -
@anthonyglamis I believe this is the right location /etc/php5/apache2/php.ini (sorry I live in the rhel camp so I have to guess a bit for the debian folks)
The answer is you need the double quotes because this is a string literal. Also I don’t think you confirmed the output of the cat command. Can you do this? (yes, I’m a type “A” person [including double quotes])
-
George,
I apologize for not being more descriptive. The output of the cat command was America/Chicago
I am changing the files now to reflect “America/Chicago” -
@anthonyglamis Thank you it helps me visualize how you system is setup.
I’m not saying that the php.ini setting will fix the problem. But, I remember this was a solution for some FOSS software I used in the past. The 1.3.0 may have been a fix to address this issue.
On the MAC issue. This is good the registered mac on the device IS the mac address when PXE booted and is nic0. Once you get the tz setting updated it will be interesting to know when you schedule a task does it get entered for the right time. We may have to dig into the database, but I might like a little feedback from the @Developers before we go that far. There may be more value with you upgrading to the latest trunk version (pre 1.3.0) if you can tolerate a little instability as we try to get all of the bugs identified and ironed out.
-
George,
No it did not fix the timing issue. I did figure out even though the fog server and my Ubunutu box have the same time displayed, they are off by about roughly 5 hours. I am open to updating fog, I am not sure what version of Trunk to run. Would I just download that from Sourceforge and install it on top of fog 1.2.0? Thanks again for all your help. -
@anthonyglamis said:
I am open to updating fog, I am not sure what version of Trunk to run. Would I just download that from Sourceforge and install it on top of fog 1.2.0?
Basically, yes. Here’s a guide: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk
I did figure out even though the fog server and my Ubunutu box have the same time displayed, they are off by about roughly 5 hours.
Check out this article: https://wiki.fogproject.org/wiki/index.php?title=Time_off
-
@anthonyglamis Interesting off by 5 hours. While I think upgrading to the latest trunk is a good idea, out of curiosity if you use the linux OS as a standard, which way is FOG off? With out putting too much thought into it CST is (UTC – 5) hours. So if fog is using the system time thinking it is UTC and it subtracts 5 hours from the system time which is already 5 hours from utc I could see how things could get mucked up.
If / when you upgrade be sure to remove the tz setting in the php.ini file, because that value is not set by default.
-
While attempting to create a delayed task I have to go forward 5 hours, so essentially the delayed task thinks it is tomorrow. This is weird. I’m upgrading to Trunk now.
-
Ok I won’t stretch this topic out since the trunk upgrade is underway. But I find it intriguing that it went the other direction and set the task to UTC time instead of double dipping on the CST offset the other direction.
Please understand that upgrading to the latest trunk may not solve the problem, but we can then engage the devs since this is a current issue with the latest build.
-
I understand. I’m looking for a stable option to image devices for my company. We were using clonezilla, but are looking for a solution to be placed at each of our sites so we can have a person local that can image a device via PXE boot and that’s it. I need a tool that will image and add to the domain because I can’t physically be there.
Upon investigating fog, I assumed this was the right tool for me so I’m hoping to educate myself further and get this rolling. I’ll update tomorrow with my progress. Thanks again for the help -
Thanks @ Wayne Workman for your help as well. I am installing via the instructions.
-
@anthonyglamis Honestly, fog trunk has drastically greater and wider support for more devices, and newer devices. Including newer style HDDs and newer boot methods.
I won’t lie, there are bugs sometimes, but they are usually minior. You just report them here in the bugs section, say “Hey ABC happens when I do 123, here’s the error and the version I’m on.”
1.2.0, while mostly stable, is really old. It won’t install out of the box on newer Linux OSs, and doesn’t support newer devices, and has basically zero GPT support.
My org has been using FOG Trunk since February 2015. We haven’t looked back.
Just the massive speed improvements alone in FOG Trunk make it worthwhile.
-
@anthonyglamis said:
Arrowhead,
I am wondering if this is a DNS issue? My host are all “unable to resolve”.
So the unable to resolve thing doesn’t necessarily affect the active directory issue, but it is something of a dns issue. For example, If your dns or perhaps dhcp server assigns hostnames to the computers based on ip address unless you reserve it in the server (It’s an issue I had at my last job where the university had a custom dhcp server that set the hostname based on the ip address unless you manually reserved by mac address, it was annoying). My point is they could relate, but I’ve seen the active directory join work even when the host isn’t showing as green/up in fog. So I would make sure everything else is right first before seeing if this is the cause. For example, does wake on lan work, because that only works if the host is down, because well it has to wake it from being off. Point is the ad join functionality doesn’t depend on the gui host up/down function in my experience.
Are you also setting the hosts to join the active directory in the gui, or are you doing it in the pxe imaging menu at the computer. Your configuration looks correct for the joining default settings. So as long as that user can join a computer to the domain and the hostname doesn’t already exist on the domain it should work. Just want to make sure you’re clicking the checkbox to tell the host to join the domain.
Also, is the latest fog client/service installed on the computer’s in question?
Also once that box is checked it typically just joins the domain right then restart and all. And if someone takes it off the domain it will just join right back again.Hope that helps in some way
-
Well one step forward and two steps back. I used the Git option to update to Trunk via this website
https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk#wgetI do not know if has not been updated but I am not on version 1.3.0 for starters. The version is 6032. Everything seamlessly migrated over, however after trying 2 image deployments on Lenovo E431 models Fog loads but errors with “Image Store Corrupt” Unable to locate MBR (restore partition table and bootloaders)
Ha and now both will not boot via the HDD
I downloaded 1.3.0 and it goes through the motions of installing but I am on 6032 still after several restarts. Thoughts?
-
@Arrowhead I have since attempted to migrate to the latest version of fog however I seem to be having issues. I am looking for the latest version now.
Upgrade was a success, version is 6038
-
@anthonyglamis 6038 is the latest version. That’s the git/svn revision number. It won’t say 1.3.0 until that version is officially released, so don’t worry about that.
For the image store corrupt error, did that go away after upgrading from 6032→6038?
If not check that image folder on the fog server withls /images/imageNameand make sure there’s a d1.mbr or something of that sort.
Also make sure the permissions are correct on the image storesudo chmod -R 775 /imagesalso what does /etc/exports say?
cat /etc/exports -
The error did not go away, and my laptops will not boot via the HDD any longer. I deleted the image I had on the fog server and am uploading another image. I will reply with the results.
-
@anthonyglamis I don’t know what reimaging would do to get active directory working. With that said I really wish you hadn’t have deleted the image. I’ve been working to make the scripts that do the work of imaging quite a lot lately. While some of those changes likely caused the problem you were having, it would have been better to keep the “bad” image and upload a new image. This would’ve at least had you do both things and given a point that i can look at. But that is now gone
Of course I can still help but it would’ve been nice to fix the original problem you had. Only if you’re having issues with uploading would I say to delete the image, especially if you’re running trunk. I am very frequent on the forums and most often fix issues as they come up here.
-
With Fog 6038 in the management console, Fog Configuration>Fog Settings> Active Directory I see that the plain text password gets automatically encrypted. Is Fogcrypt obsolete? It is still available via download @x.x.x.x/fog/client
Also I noticed in Group Management>Active Directory, as well as Host Management>Active Directory the auto generated encryption hashes are different. Will that be an issue when it comes time to attempt to auto join to AD?
