ntpd setzt keine systemzeit

source

Member
Hallo,

seit langer Zeit versuche ich meine Systemzeit automatisch per NTPd setzen zu lassen. Leider funktioniert dies nicht! NTPd starte ich automatisch per rc.conf, meine Konf sieht so aus:
server ntp0.fau.de
driftfile = /etc/ntp.drift

Securelevel ist auf 1, sollte also da auch keine Probleme geben! Hat Jemand das gleiche Problem? Wenn ich per "ntpdate" die Zeit setzen will, funktioniert dies einwandfrei. Sprich die Firewall o.ä. muss richtig konfiguriert sein.

MfG Source
 
Aus den Logfiles des NTPd's werde ich auch nicht viel schlauer:
23 Jul 17:37:03 ntpd[18919]: logging to file /var/log/ntp.log
23 Jul 17:37:03 ntpd[18919]: ntpd 4.1.74@1.998-r Thu Mar 20 03:36:40 MST 2003 (1)
23 Jul 17:37:03 ntpd[18919]: signal_no_reset: signal 31 had flags 12
23 Jul 17:37:03 ntpd[18919]: signal_no_reset: signal 13 had flags 12
23 Jul 17:37:03 ntpd[18919]: precision = 3.000 usec
23 Jul 17:37:03 ntpd[18919]: signal_no_reset: signal 23 had flags 12

Scheint ja so nichts extrem schlimmes drinn zu sein...

MfG Source
 
1. Ist "driftfile = /etc/ntp.drift" falsch, es muss einfach nur heissen "driftfile /etc/ntp.drift"

2. Sollte der "driftfile" Eintrag der erste im ntp.conf file sein (macht aber wohl nichts falls nicht)

3. Probiers mal mit der IP-Adresse statt dem hostname, oder starte ntpd neu, wenn deine Namensauflösung definitiv funktioniert (also du die server ping-en kannst)

4. Poste bitte mal den Output von "ntpdc -c peers" und "ntpdc -c kerninfo" wenn's immer noch nicht tut
 
Original geschrieben von source
Hallo,

seit langer Zeit versuche ich meine Systemzeit automatisch per NTPd setzen zu lassen. Leider funktioniert dies nicht! NTPd starte ich automatisch per rc.conf, meine Konf sieht so aus:
server ntp0.fau.de
driftfile = /etc/ntp.drift

Securelevel ist auf 1, sollte also da auch keine Probleme geben! Hat Jemand das gleiche Problem? Wenn ich per "ntpdate" die Zeit setzen will, funktioniert dies einwandfrei. Sprich die Firewall o.ä. muss richtig konfiguriert sein.

MfG Source

Wie wäre es, wenn du einfach mit ntpdate die Systemzeit einrichtest.

In der rc.conf trägst du Folgendes ein: ntpdate_flags="DEIN_NTPSERVER"

oder du machst dies in der rc.conf.local.

So wird schon beim Systemstart die Zeit justiert.

Du kannst dir auch einen Cron-Job einrichten, bei dem ntpdate alle paar Minuten die Zeit holt.


Gruß

CW
 
Zuletzt bearbeitet:
die loesung mit dem ntpdate und start-up setzt halt voraus, das die box ueberhaupt ab und an neu gestartet wird. und was den cronjob angeht, mit ntpd waere das natuerlich eleganter :) (ich weiss ich weiss... bin ein verdammter haarspalter ;P)

dieser link koennte evt. interessant sein:
http://www.linuxnetmag.com/de/issue6/printm6time1.html

dort wird auch beschrieben wo moegliche fehler, oder faelschlicherweise fuer fehler gehaltene effekte herkommen koennen.
 
Zuletzt bearbeitet:
Original geschrieben von kith
die loesung mit dem ntpdate und start-up setzt halt voraus, das die box ueberhaupt ab und an neu gestartet wird. und was den cronjob angeht, mit ntpd waere das natuerlich eleganter :) (ich weiss ich weiss... bin ein verdammter haarspalter ;P)

Ja klar, dass dies gehen würde. Jedoch ist ntpdate für solche Sachen, meiner Meinung nach, besser geeignet, da es kein Daemon ist und somit nicht ständig im Speicher herumschwirren muss.

Es holt die Zeit und wird beendet.

Das wars.

Während ein zusätzlicher Daemon immer auch ein zusätzliches Risiko ist.

Ich weiß, ich weiß ... bin ein verdammter Paranoiker ;)

Gruß

CW
 
ja sicher, kommt natuerlich darauf an wo der ntpd laufen soll. auf meiner fw und in meiner dmz mach ich auch nur ntpdate (und dass auch nur manuell!).

"die frage ist nicht ob du paranoid bist, sondern ob du paranoid genug bist!" (oder so aehnlich...).
 
Hallo!

current:
zu 1/2: ich hab jetzt probeweise das driftfile command vollstaendig aus der Konfig-Datei genommen um alle Fehler auszuschliessen.
zu 3: werd ich mal ausprobieren
zu 4: ntpdc -peers:
localhost.localdomain: timed out, nothing received
***Request timed out
Das gleiche bei ntpdc -kerninfo


ColdWisdom:
jo die Idee mit dem ntpdate+cron fand ich auch besser, gerade weil das Dingen auf ner Firewall laufen soll (da brauche ich Zwecks den Logfiles die richtige Systemzeit). Jedoch moechte ich spaeter den Securelevel auf 2 setzen (im Moment [Testzwecke] laeuft er noch in 1), und gerade da funzt dann ntpdate nicht mehr. Meckert er wegen /bsd Zeit rueckwaerts setzen usw. Falls es dafuer eine Loesung gaebe waere ich natuerlich noch besser drann ;)

MfG Source

-hinzugefuegt------------------------------------
habe gerade die ip anstelle des namens genommen und siehe da ntpdc -c peers spuckt volgendes aus:
remote local st poll reach delay offset disp
=======================================================================
=ntp0-rz.rrze.un 192.168.0.3 1 64 3 0.08406 49.468398 3.93774
ntpdc -c kerninfo sagt volgendes:
***Server doesn't implement this request

Jetzt bin ich mal gespannt ob er auch wirklich die Zeit richtig setzen wird! Habe extra ca. 1 Minute nach hinten gesetzt.
-ende----------------------------------------------
 
Zuletzt bearbeitet:
Das sieht doch gut aus. Übrigens: Wenn Du nicht gerade mehr als 1000 Maschinen mit genauer Zeit versorgen musst, solltest Du keinen Stratum 1 Server benutzen. Nimm bitte einen mit Stratum 2, z.B. einen der folgenden:

ntp.tuxfamily.net
fartein.ifi.uio.no
bear.zoo.bt.co.uk
 
Original geschrieben von source

ColdWisdom:
jo die Idee mit dem ntpdate+cron fand ich auch besser, gerade weil das Dingen auf ner Firewall laufen soll (da brauche ich Zwecks den Logfiles die richtige Systemzeit). Jedoch moechte ich spaeter den Securelevel auf 2 setzen (im Moment [Testzwecke] laeuft er noch in 1), und gerade da funzt dann ntpdate nicht mehr. Meckert er wegen /bsd Zeit rueckwaerts setzen usw. Falls es dafuer eine Loesung gaebe waere ich natuerlich noch besser drann ;)


Hallo

Es stimmt zwar, dass die Zeit nicht mehr justiert werden kann, jedoch bedeutet es nicht, dass du im Securelevel=2 auf die richtige Zeit verzichten musst.

Folgendes steht in der manpage von securelevel:

--------------------------------------------------------------------------------

Preventing the system clock
from being set backwards aids in post-mortem analysis and helps ensure
the integrity of logs. Precision timekeeping is not affected because the
clock may still be slowed

--------------------------------------------------------------------------------

Und wie dies eingerichtet wird, steht in der Dokumentation zu ntpd/ntpdate.


Gruß

CW
 
Hallo,

die Zeit wird leider immer noch nicht per ntpd gesetzt! Ich habs nun mal mit ntpdate versucht. Die man-page zu securelevel sagt folgendes:
2 Highly secure mode
blabla...
settimeofday(2) and clock_settime(2) may not set the time backwards or close to overflow
.....

Dies wuerde ja bedeuten, dass die Zeit nicht rueckwaersts gesetzt werden darf! OK, dann sagt die Manpage von ntpdate das mittels "-B" Option die Zeit "geslowed" werden kann.
Hab ich ausprobiert, nur leider wird die Zeit "nicht schneller", sprich falls sie 30 Sekunden nach gehen wuerde.
Und wenn die Zeit 5 Sekunden in der Zukunft liegt und er sie "slowen" sollte kommt die Meldung von /bsd dass es nicht erlaubt sei die Zeit zurueck zu setzen!
Gibt es noch andere Optionen, die ich vielleicht uebersehen habe?

MfG Source
 
Original geschrieben von source
Hallo,

die Zeit wird leider immer noch nicht per ntpd gesetzt! Ich habs nun mal mit ntpdate versucht. Die man-page zu securelevel sagt folgendes:
2 Highly secure mode
blabla...
settimeofday(2) and clock_settime(2) may not set the time backwards or close to overflow
.....

Dies wuerde ja bedeuten, dass die Zeit nicht rueckwaersts gesetzt werden darf! OK, dann sagt die Manpage von ntpdate das mittels "-B" Option die Zeit "geslowed" werden kann.
Hab ich ausprobiert, nur leider wird die Zeit "nicht schneller", sprich falls sie 30 Sekunden nach gehen wuerde.
Und wenn die Zeit 5 Sekunden in der Zukunft liegt und er sie "slowen" sollte kommt die Meldung von /bsd dass es nicht erlaubt sei die Zeit zurueck zu setzen!
Gibt es noch andere Optionen, die ich vielleicht uebersehen habe?

MfG Source

Hallo

Bei dieser Website findest du eine genaue Erklärung darüber, wie man es machen muss, damit es auch unter Sec-Level=2 mit der Time-Einstellung klappt: http://www.geodsoft.com/howto/harden/OpenBSD/no_changes.htm


Die Anleitung ist zwar für OpenBSD 3.0 geschrieben worden, kann aber auch für 3.3 angewandt werden.

Und hier der für dich wichtige Ausschnitt:

--------------------------------------------------------

If you normally run a system at securelevel 2 and also use NTP you should add the "-x" option to the command line that starts ntpd. Securelevel 2 will not allow the system time to be set back. As NTP's sole function is to keep a system time correct by checking with outside servers, it's normal operation will occasionally try to set the clock back by some fraction of a second. Securelevel 2 prevents this. The "-x" option prevents ntpd from stepping the clock but instead it "slews" the clock. In other words, instead of changing the time directly, ntpd either speeds up or slows down the clock until it comes into alignment with the correct time. As long as the clock is within several seconds of the correct time, this will have no negative effect on ntpd's operation. If the clock is significantly off, then slewing will take a long time to reach the correct time.

------------------------------------------------------------

Gruß

CW
 
Hi,

des ist ja des komisch. Seit geraumer Zeit wird ntpd wie folgt aufgerufen:
/usr/local/sbin/ntpd -x -p /var/run/ntpd.pid -l /var/log/ntp.log
Doch seit ueber 4 Tagen wird die Zeit nicht korrekt gesetzt. Ich habe sie extra 4 Minuten nach hinten gesetzt. Auch wenn ntpd die Zeit "slowed" sollte er es schaffe innerhalb von 4 Tagen 4 Minuten aufzuholen! In den Log's steht nichts neues drinn, nur das Startdatum.
Neija ich werd jetzt noch en bissel mit ntpdate und cron rumspielen, ich hoffe des wenigstens ans Laufen zu bringen.


MfG Source

Thx for all your help!!!
 
Zurück
Oben