Active directory Join issue
-
Wayne, thanks for the reply. We are setting up the client service with the IP address of the fogserver. We named the fogserver “fogserver”.
-
This is interesting on the time issue.
From within the linux console if you type
datedoes linux know the correct time? If it does then we may have to dig into the php.ini to ensure that the proper timezone is set there. -
I do see something suspicous in your posted log.
1/19/2016 3:56 PM FOG::MODDebug MAC ID 0 44:A8:42:E9:57:4A
1/19/2016 3:56 PM FOG::MODDebug MAC ID 1 34:02:86:92:41:86
…
1/19/2016 4:06 PM FOG::SnapinClient No Tasks found for: 44:A8:42:E9:57:4AThe target computer has 2 network adapters. FOG knows about the network adapter asscoiated with 44:A8:42:E9:57:4A. Is 44:A8:42:E9:57:4A the ethernet adapter or the wireless adapter? To answer the question another way is net0 your pxe boot adapter or is net1 your pxe boot adapter.
-
George, on the date question yes The time is coming back correct, CST. On the NIC question the first is the ethernet NIC. I assumed the second was the wireless that fog was detecting. How can I tell which is my PXE boot adapter? I assumed all was well with that as I can contact the fogserver to both upload and download images. I just can’t get them to join to the domain.
-
Just to answer some of your questions. The delayed task time thing is a bug that I have had too, haven’t actually found a solid fix for it. But with a little testing you can figure out how many hours it’s off and get delayed tasks working. However, this time issue doesn’t effect active directory joining.
Also the fog server not being on the domain is also not an issue. My fog server isn’t on the domain and the AD joining works no problem.
Can you show us a screenshot of the active directory default settings you have set in the fog gui?
-
Arrowhead,
I am wondering if this is a DNS issue? My host are all “unable to resolve”.
-
I also did not mention, that I do not have the product key field filled out in the host section. Would this cause the domain joining issue?
-
@anthonyglamis Ok, continuing with the time issue. Since linux knows the proper time, then it is probably a php or FOG offset that is coming into play. Can you inspect the value of FOG_TZ_INFO at Settings->Fog Settings->General make sure that has the right timezone is set. If that setting is correct then I want to try adjusting the php.ini setting. But lets start with easy first.
-
On the mac / task issue. Can you confirm which mac address is the ethernet and wireless? You may have to update the registration in FOG to ensure that the mac address used is for the pxe boot adapter.
-
George,
Interesting, but I do not have FOG_TZ_INFO under “general settings” I was reading that was a new option in fog 1.3.0. Is that correct?
Yes I can confirm that 57-4A is my ethernet and 41-86 is wireless. -
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.
