This post is more than 5 years old
2 Intern
•
300 Posts
0
1604
July 16th, 2015 02:00
What happend to smbtime?
Hi all,
does anyone know what happened to smbtime? I can't find the smbtime service in 7.1.1 and 7.2. Neither in the cron nor in isi services.
Not that I need it - I just want to make sure it is down.
I wasn't able to find anything in the Documentation / Releasenotes.for 7.1 / 7.1.1
Regards
-- sluetze
0 events found
No Events found!
BernieC
76 Posts
0
July 16th, 2015 03:00
Very astute observation! Smbtime was removed in 7.1.1 and later and instead the cluster will use the built-in NTP capabilities in a joined domain. Windows provides this via its own w32time service, so Isilon sets a DC as an NTP source and begins to synchronize from that.
This has been found to be much more reliable than the 6-hour update interval that was had with smbtime.
You can always check ntpq -pn to see the current state of NTP on the cluster, but isi_ntp_config list will not show the DC in its config.
If you desire a different NTP source, you can configure that directly and that will override using an AD DC as NTP source.
sluetze
2 Intern
•
300 Posts
0
July 16th, 2015 03:00
Thanks Bernie,
seems to be a much better implementation than before
What happens, when the DC becomes unavailable? are the same mechanisms used as for the DC-selection? So is my active DC for the configured domain also my active ntp server?
What happens in a multi-domain environment without separate ntp-configuration?
Best Regards
Steffen
BernieC
76 Posts
1
July 16th, 2015 08:00
/etc/ntp.conf is generated automatically via MCP via another script on the cluster that controls NTP configuration. That script looks to see if you've configured an NTP source and, if you haven't, looks to see if the cluster is joined to an AD domain. Then, it gets the connected DC and uses that in the resulting /etc/ntp.conf.
If your DC goes away, then the NTP configuration has to be regenerated, but ntpd-reconfig runs fairly frequently and you should be able to grep for that in /var/log/isi_mcp to see it running. We rely on accurate time for many things so many reconfigurations also happen to call ntpd-reconfig. You'll see something like this...
2015-07-14T15:01:31+01:00 <3.6> bernie-7114-1(id1) isi_mcp[21473]: Executing '/etc/mcp/scripts/ntpd.py /etc/mcp/templates/ntp.conf /etc/ntp.conf' command of actionlist 'ntpd-reconfig'.
When you mention multi-domain are you talking about domains in potential different zones? From what I see from ntpd.py it just uses the DC from the first joined domain (admittedly my Python is a bit weak, but I believe that's what I'm reading).
Hope this helps!
sluetze
2 Intern
•
300 Posts
0
July 16th, 2015 23:00
Hi Bernie,
yes it helps.
Different timezones should not make an difference regarding ntp. The timezone is just a "display" for the users. internally all PCs using ntp rely on UTC.
My thoughts more went into an area where I have multiple domains and one domain goes down completely (i.e. case of migration scenario / consolidation when two companys join together and one domain gets deleted. So if the ntp "ignores" the domains.
I'll take a look on the ntpd.py to answer this
Thanks!
--Steffen
BernieC
76 Posts
0
July 17th, 2015 00:00
Hi Steffen,
When I said zones I actually meant access zones, as I was trying to think of how this would be affected by disparate networks potentially in different forests, etc. That's my mistake for not using the full terminology!
The ntpd.py script checks to see if the list of joined AD domains is greater than zero, saves that list, and then gets the DC for the first domain returned. I believe the first domain returned by this function will always be the primary domain on the cluster. So, for the primary domain, the cluster will get the DC for that domain and will then add that to the NTP configuration.
In your case, if a domain goes down completely, but the cluster doesn't leave the domain, then I believe the NTP config would still be incorrect and wouldn't be updated. But, if you remove the cluster from that domain and join it to another one, MCP should be calling ntpd-reconfig and forcing a regeneration of ntp.conf based on the primary joined domain on the cluster.