Ntpd neden sunucumdaki saati güncellemiyor?

Sunucumda ntpd çalışıyor. Diğer makinelere sunucu olma yeteneğini yorumladığım hariç, tüm varsayılan ayarlar:

# restrict -4 default kod notrap nomodify nopeer noquery                                                                    
# restrict -6 default kod notrap nomodify nopeer noquery   
restrict default ignore

Eğer koşarsam ntpdate -q ntp.ubuntu.com, makinemin saatinin 7 saniye kapalı olduğunu söylerim.

Neler oluyor? Olanları nasıl teşhis edebilirim, açabileceğim bir günlük var mı?

daha fazla bilgi # 1

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.189.94.4     193.79.237.14    2 u   30   64    7  108.518   -0.136   0.361

daha fazla bilgi # 2

Soruyu sorduğumda şöyle görünüyordu:

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec

Ve şimdi ntpd'yi birkaç kez yeniden başlattıktan sonra şu şekilde görünüyor (bunu düzelttiğim varsayıyorum):

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec

daha fazla bilgi # 3

Ntp'yi kaldırdım ve openntpd'i yükledim ve koştum /usr/sbin/ntpd -dve şöyle çıktı görüyorum:

reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s

Benim için oldukça açık bir şekilde sunucumda zaman ayarlayamadığımı gösteriyor (düzenli ntp ile bazen güncelleniyor gibi görünüyor ...).

daha fazla bilgi # 4

VPS sağlayıcım diyor ki:

En son çekirdekler sisteminizi dom0'ımızın saatine kilitlememelidir, güvenli tarafta olmak için sysctl.conf dosyasında xen.independent_wallclock = 1 ayarını yapabilirsiniz.

Sanırım hala doğru zamanlama hesaplamaları yapmak için mevcut bir CPU ihtiyacı VPS sorununu gidermiyor.

Ntp.conf dosyasına ekleyerek ntpd'de günlüğe kaydetmeyi etkinleştirebilirsiniz:

logfile /var/log/ntpd.log

Kaynak: ntp manual

Ntpd'yi kapatırsanız, saati komut satırıyla güncelleyebilir misiniz? Ntpdate komutunu çalıştırır ve şöyle bir hata alırsanız:

# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted

Bu muhtemelen bir VPS'de olduğunuz anlamına gelir ve bu durumda sistem saatini değiştiremezsiniz - bu sadece ana makinede yapılabilir.

Pekala millet, bu soruyu sorduğundan bu yana, ntp'yi varsayılan satıcı (Ubuntu 10.0.4) yapılandırmasıyla yeniden kurdum ve birkaç gün çalışmasına izin verdim. Bu yazı itibariyle, ntpdate -q ntp.ubuntu.comzamanımın 0.000216 saniye içinde doğru olduğunu gösteriyor. Yani, sahip olduğum sorunlar benim özelleştirilmiş yapılandırma ile olmalıydı (burada harici ana bilgisayarlar sunucumu sorgulamak imkansız yapmaya çalışıyordum, bu yüzden zaten çok endişeli değilim benim güvenlik duvarı ile yapıyorum). İşte Ubuntu 10.0.4 ntp.conf'un tamamı, yorumları kaldırıldı:

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server ntp.ubuntu.com

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

Bu yapılandırmanın nasıl geliştirilebileceğine ilişkin geri bildirimleri memnuniyetle karşılıyoruz.

Ayrıca VPS sağlayıcımla en iyi şey hakkında ayrıntılı bir öneri isteyen bir bilet yaptım. Onları bu iş parçacığına ve CPU tahsisinin bir zamanlama sorununa neden olabileceğini gösteren diğer belgelere işaret ettim. İşte söyledikleri:

En son çekirdekler sisteminizi dom0'ımızın saatine kilitlememelidir, güvenli tarafta olmak için sysctl.conf dosyasında xen.independent_wallclock = 1 ayarını yapabilirsiniz. Bu, sunucu örneğinin ana sunucudaki saati izlemediğinden emin olur.

ve:

Sanırım bu sorunun sanallaştırılmış bir ortamda NTP istemcilerini etkileme derecesini yanlış anlıyor olabilirsiniz. Bir Xen ana bilgisayarındaki (Rackspace Cloud'daki kurulumumuz gibi) sanallaştırılmış bir sistemle ilgili deneyimime göre, kesintileri işlemek için özel bir sistem saatine sahip olmamakla ortaya çıkan yanlışlık, yüksek yüklü sistemlerde bile saniyenin kesirlerine eşittir. Bu hafif yanlışlık, sunucuların günde sadece bir kez (hatta bundan daha az sıklıkta) güncellenmesi için ayarlanmış olsa bile NTP tarafından kolayca yönetilir.

Yorumlarınızdan biri bir hayalet üzerinde çalıştığınızı söylüyor. Bu durumda, muhtemelen çok fazla başarı elde edemezsiniz çünkü hayaletinizin zaman duygusu, hem çalıştığı gerçek ana bilgisayara hem de genel olarak ne kadar meşgul olduğuna bağlı olacaktır.

Kullanılan sanallaştırmaya bağlı olarak, vhost belirli bir süre içinde kesinti payı alamayabilir. Bu, saatin gerçekten olduğundan daha hızlı veya daha yavaş çalışmasını sağlayacaktır. Ntp, saatinizin dünyanın geri kalanından daha hızlı veya daha yavaş olduğu varsayımındaki değişiklikleri ölçmeye çalıştığından, bu hızlanma ve yavaşlama ntp uyumlarını verecektir ve sonuçta muhtemelen vazgeçecektir. bu ntp -npgösterileri zaman sunucularına o ntp uygun bulunmama etti.

Durum buysa, en iyi bahis, muhtemelen rdate -s $serverher altı saatte bir (her altı saatte bir) burnundan sarkıtmak için kaba bir kuvvettir , böylece aşırı senkronizasyondan sürüklenmez. Ancak hassas doğruluk muhtemelen ulaşılamaz.

Geçmişte bulduğum şeyler, openntpd yerine ntpd kullandığımda:

1. Ntpd'nin düzgün başlaması ve aslında bir şeyler yapması için localhost'a erişim izni vermeniz gerekir

   restrict 127.0.0.1
   restrict ::1
   

2. Sunucu kuralları için ana bilgisayar adlarını kullanabilmenize rağmen, bu sunucularla konuşmak için delik açmak restrict, IP adresleri gerektiren anlamına gelir , bu yüzden her şey için IP kullanmak zorunda kaldım.

3. Sen kullanarak söz etmeyin restrictSunucularınıza kadar açık erişim arkasına. Bu bir sorun. Aşağıdaki gibi blokları deneyin:

   # ntp.xs4all.nl
   server          194.109.22.18
   restrict        194.109.22.18
   

4. Kötü bir oyuncu ile başa çıkmak için çoğunluk kuralları oylamasını kullanmaya çalıştığından, ntpd için birden çok eş veya sunucuya ihtiyacınız vardır. Yani en az 4, yine de kaybettiğinizde çoğunluğa sahip olabilmek için, tercihen 5.

5. Varsayılan erişimi kilitlemek için şunu kullanabilirim:

   restrict default notrust nomodify
   

   böylece hala sorgulamak mümkün, ama ben restrict default ignorentpd 4.2 anlamını değiştirdiğiniz gibi kullanarak sona erdi notrust. iç çekmek

6. Başkalarına zaman hizmeti sunmuyorsanız, muhtemelen normal ntpd'nin tam gücüne ihtiyacınız yoktur ve openntpdbunun yerine düşünmelisiniz . OpenBSD ekibi tarafından yazılan, ayrıcalık ayırma ve çok daha basit bir yapılandırma dosyası kullanarak çok daha az bir uygulama. İddiaya göre ntpd'nin sağlayacağı son derece kesin zamanı sağlamıyor, ancak normal bir sunucu veya iş istasyonu için yeterince iyi.

• Ntpd uzak sunucuya bağlanamazsa, o sunucu için bir uzaklık görmezsiniz.
• Eğer ntpq ntpd tarafından engellenirse, ntpq'den net bir hata mesajı görürsünüz.
• Başka bir hizmet de saati ayarlayacaksa (vmware araçları gibi), sunucu için bir atlama ofseti görürsünüz (70 saniyede bir ntpq -p komutunu çalıştırın).

Belirtilen reach 7ntpq çıkışı, ntpd'nin yalnızca yaklaşık 4 dakika çalışmasına izin verdiğinizi gösterir. 7, 111 ikili olduğu için sunucuya 3 kez ulaşıldığı anlamına gelir. ntp her 64 saniyede bir ( polldeğer) uzanır whenve son temastan bu yana 30 saniyeyi ( değer) bekledi .

offset -0.136Sistem zaten senkronize edildiğini, belirtti. Yalnızca ntpd henüz sunucuyu kaynak olarak işaretlemedi. Sadece daha fazla zaman verin ve küçük bir yıldız görünecektir.

Yani aslında ntpd'niz senkronize oluyordu. Ancak ntpd genellikle büyük bir atlamada (ntpdate gibi) senkronize olmaz, ancak zamanı yavaşça ayarlamaya çalışır ve zamanın sabit kalmasını sağlar.

Not: Sorunun çok eski olduğunun farkındayım. Ancak mesele zamansız. Ve diğer tüm cevaplar IMHO'yu yanıltıcı. ntpd, zamanı senkronize tutmak için VMWare tarafından bile önerilmektedir.

Sistemimi kapalı buldum ve HW saatinin neden temiz bir kapatma sırasında sistem saati ile senkronize olmadıklarını şaşırdım. Sysconfig'de bunun gerçekleşmesi için düzenleme yapılması gereken bir NTP ayarı var gibi görünüyor.

İçinde /etc/sysconfig/ntpd:

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

Bunu ben ayarladım yes. Elbette önce sağlam bir NTP sunucunuz olduğunu ve sistem saatinizin güvenilir olduğunu doğrulayın.

Bunun olduğunu biliyordum - çarpıklığım 47 saniye ve HW saatim de 47 saniye kapalıydı. Bingo! İlk ipucum günlüklerde görülen Kerberos hatalarıydı. Kerberos ve birçok NAS, saat eğriliği çok büyükse çalışmaz.

İyi günler!

vmware üzerinde vhost çalıştırıyorsanız aşağıdaki makaleyi kontrol edin .. size yardımcı olacaktır http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

Hai ..

Sorununuzu gidermeye yardımcı olup olamayacağını görmek için bu referansa göz atın:

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch24 : _The_NTP_Sunucu

ntpd.conf dosyanızın içeriğini, ntpq -p gibi hata ayıklama komutlarının çıktısını yayınlamak isteyebilirsiniz

Tarih ve saatinizi kontrol edin.

Ve bunu da doğrulayın, ntpdate ve startup ntpd'yi çalıştırın, zaman senkronize mi?

en iyi dileklerimle