So, this is super weird
I have 3 FreeBSD VMs on 3 separate ESXi servers that I use for storage with passthrough LSI 2008s
HW clocks are all set to local time, not UTC. TZ data are all set to PDT, which is where I live near Seattle.
They all connect to my Windows 2016 domain controller w/ samba and winbind, they all use krb5-116 and ntp
The krb5.conf and ntp.conf files are taken straight off the Samba wiki page for domain members and are working fine on two out of 3 of the VMs
Two of the VMs work great, one of them is having weird time issues. I wanted to think it was just a daylight savings time issue but it appears to be weirder than that -- it had been an hour ahead, but now it's a few minutes shy of that.
Working:
vs problematic:
ntp.conf (same on all 3 VMs) - source https://wiki.samba.org/index.php/Time_Synchronisation
krb5.conf (same on all 3 VMs) - source: https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member#Configuring_Kerberos
ntp polling:
Like I said, works fine for two out of 3 of the VMs - just started being an issue on the 3rd VM, which actually resides on the same ESXi host as my domain controller (which has no issues with time). It's an important VM for me because it's what I use for general file serving and physical computer backups - and I can't get the MFer to connect to the domain because of the clock skew:
I just set the time using date command. I have no confidence that it will stay set correctly, though, and would like to work towards a more long-term solution.
Any ideas? Anyone?
I have 3 FreeBSD VMs on 3 separate ESXi servers that I use for storage with passthrough LSI 2008s
HW clocks are all set to local time, not UTC. TZ data are all set to PDT, which is where I live near Seattle.
They all connect to my Windows 2016 domain controller w/ samba and winbind, they all use krb5-116 and ntp
The krb5.conf and ntp.conf files are taken straight off the Samba wiki page for domain members and are working fine on two out of 3 of the VMs
Two of the VMs work great, one of them is having weird time issues. I wanted to think it was just a daylight savings time issue but it appears to be weirder than that -- it had been an hour ahead, but now it's a few minutes shy of that.
Working:
Code:
[root@fbsd111 /home/local]# date
Wed May 23 10:33:25 PDT 2018vs problematic:
Code:
[root@fabby111 /home/local]# date
Wed May 23 11:30:58 PDT 2018ntp.conf (same on all 3 VMs) - source https://wiki.samba.org/index.php/Time_Synchronisation
Code:
[root@fabby111 /home/local]# cat /etc/ntp.conf
server 127.127.1.0
fudge 127.127.1.0 stratum 10
server 192.168.1.2 iburst prefer
server 192.168.1.3 iburst
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp
# Default restriction: Disallow everything
restrict default ignore
restrict 127.0.0.1
restrict 192.168.1.2 mask 255.255.255.255 nomodify notrap nopeer noquery
restrict 192.168.1.3 mask 255.255.255.255 nomodify notrap nopeer noquerykrb5.conf (same on all 3 VMs) - source: https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member#Configuring_Kerberos
Code:
[root@fabby111 /home/local]# cat /etc/krb5.conf
[libdefaults]
default_realm = HAPPY.HUT
dns_lookup_realm = false
dns_lookup_kdc = truentp polling:
Code:
[root@fabby111 /home/local]# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*LOCAL(0) .LOCL. 10 l 4 64 377 0.000 0.000 0.000
WINGATEWAY.happ .INIT. 16 u - 1024 0 0.000 0.000 0.000
1709dc02.happy. .INIT. 16 u - 1024 0 0.000 0.000 0.000Like I said, works fine for two out of 3 of the VMs - just started being an issue on the 3rd VM, which actually resides on the same ESXi host as my domain controller (which has no issues with time). It's an important VM for me because it's what I use for general file serving and physical computer backups - and I can't get the MFer to connect to the domain because of the clock skew:
Code:
[root@fabby111 /home/local]# kinit
administrator@HAPPY.HUT's Password:
kinit: krb5_get_init_creds: Clock skew too greatI just set the time using date command. I have no confidence that it will stay set correctly, though, and would like to work towards a more long-term solution.
Any ideas? Anyone?