NTP unter Debian Etch auf Virtuellen Servern

[phx1024]

Hi,

sorry das ich nu nen Thread aufmache obwohl es schon einige gibt.
Ich habe auch schon mehrere Tage im Netz mit Suchen verbracht, aber leider erfolglos.

Ich habe 3 virtuelle Server die dummerweise alle irgendwie eine zu schnelle Systemuhr haben (ca. 5 minuten/4 stunden zu schnell), und wollte daher einen der 3 Server dazu bestimmen sich von der Firewall (welche NTP anbietet) die Zeit zu holen, und dann Netzintern (mit die Firewall entlastet ist) als Timeserver für die anderen 2 (später evtl. mehr) Rechner zur verfügung zu stehen.

Ich habe auf allen Rechnern die Pakete "ntp" und "ntpdate" installiert (auf einem auch "ntp-simple" aber das referenziert nur auf "ntp").
Mit
ntpdate <ip-der-firewall>
kann ich auch die Zeit von der Firewall ins System holen. Aber es kann doch nicht der Sinn von NTP sein das man sich nen "stupiden" Cronjob einrichtet um dann alle paar Minuten (da meine Zeitverzerrung so hoch ist) die Zeit zu aktualisieren, und dabei zu riskieren das Cron einige jobs mehrfach mach da durch ntpdate die Zeit teilweise sprunghaft zurückgesetzt wird.

Ich habe hier mal 2 Konfigdateien wie ich sie derzeit verwende, sie könnten teilweise "falsch" sein, aber das liegt daran das ich schon zig sachen ausprobiert habe und langsam ratlos bin.

Einmal meine Serverkonfig <192.168.0.1> (also der Rechner der sich von der Firewall die Zeit holt):

Code: Alles auswählen

### Server:/etc/ntp.conf *******************************

# Abweichungen
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log
statsdir /var/log/ntpstats/

# Statistiken
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

# NTP-Server
server 192.168.0.254 iburst burst
server 127.127.1.0 iburst burst
fudge 127.127.1.0 stratum 10

# Zugriff durch NTP-Server gestatten
restrict 192.168.0.254

# Zugriff durch NTP-Clients gestatten
restrict 192.168.0.2
restrict 192.168.0.3

# Zugriff vom Localhost gestatten
restrict 127.0.0.1
restrict 127.127.1.0

# allen anderen Rechnern aendernden Zugriff verwehren
restrict default nomodify

Und hier die conf eines meiner Clients <192.168.0.2>:

Code: Alles auswählen

### Client:/etc/ntp.conf ###############################

# Abweichungen
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log
statsdir /var/log/ntpstats/

# Statistiken
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

# NTP-Server im LAN
server 192.168.0.1 iburst burst

# Zugriff durch NTP-Server gestatten
restrict 192.168.0.1

# Zugriff durch localhost gestatten (ntpq -p)
restrict 127.0.0.1

# allen anderen Rechnern aendernden Zugriff verwehren
restrict default nomodify

Die Server bekommen scheinbar ihre differenzen mit, die sie zu den anderen Rechnern haben, aber sie scheinen nicht die Zeiten von den Rechnern mit niedrigenen Stratum-werten zu übernehmen sondern nur die differenzen zu protokollieren. Das driftfile aller Rechner hat dauerhaft 0.000 drin stehen. Und der Server nimmt nach einer weile lieber die Lokale Uhr als Referenz, anstelle sie nach der Firewall-Uhr zu stellen.

Ich weis nicht wirklich was ich falsch mache ... oder woran mein Problem liegen könnte.
Solltet ihr irgenwie mehr speziellere Infos und Systemausgaben brauchen postet mir eure Anfragen. Ich werde sie nach bestem Gewissen gern beantworten. Ich will doch nur das meine Uhren stimmen und das NTP funktioniert. (Hab auch schon viel von anderne tools wie chrony und so gelesen, aber wozu gibts ein NTP-Protokoll und ein NTP-Protokoll-unterstützendes Paket in Debian wenn man immer wieder auf irgendwelche Not- oder Alternativlösungen ausweichen soll?)

Ich hoffe ihr könnt mir ein wenig weiterhelfen, mit freundlichsten Grüße, phx1024

[phx1024]

Schade, scheint wohl keiner helfen zu können oder helfen zu wollen.

Derzeit zieh ich mir per NTP behelfsmäßig die Zeiten immer direkt von der Firewall. Geht zwar auch, aber ist halt nicht der Weg der geplant war/ist.

Falls wem was einfällt bin ich dankbar für Tips die mir helfen könnten.

Grüße, phx1024

[Sarem_Avuton]

Hallo,

Wie sind denn die Server virtualsiert?

Grüße Jörg

[phx1024]

Laufen alle drei auf einem DELL-Server der 2,8GHz P4 CPU hat und 3GB Ram
Als virtualisierungssoftware muss ich Virtual-PC von MS nehmen. Auf dem Server läuft daher ein V-PC-Server-System in dem die ganzen virtuellen Rechner (derzeit meine 3) verwaltet werden.
Alle 3 virtuellen Rechner sind gleich. 512MB Ram und 16GB HDD eine Lan-Karte.

Ich hoffe die infos sind die die du wolltest

Danke im Voraus, phx1024

[sentolacco]

Hallo,

ich habe mich vor längerer Zeit damit beschäftigt und weiß deswegen nichtmehr viel über das Thema.

Soweit ich weiß gibt es aber eine Schalter mit dem die Zeit nicht direkt umgestellt wird, sondern sich im Laufe von x Minuten dynamisch anpasst. Schau mal in der man-Seite nach.

MfG
Thomas

[phx1024]

diesen Schalter habe ich anktiviert, wenn ich mit PS -aef nachsehe steht der benötigte Schalter im gestarteten Kommando mit drin.
Laut den Logs schafft er es aber wohl nicht die Zeit korrekt per drift-file zu steuern und springt alle 10 Minuten um 10-20 Sekunden zurück.
Mein ur-problem ist ja, das sich die NTP-Dienste nicht gegenseitig aktualisieren wollen, und das ich es nicht schaffe einen der Clients zum Zeitserver zu machen. derzeit holen sich nun alle die Zeit bei der Firewall, aber das soll so nicht sein. Es soll sich nur ein Rechner die Uhrzeit holen, und alle anderen sollen untereinander die Zeiten abgleichen, und als Referenz sich auch die Zeit vom Zeitserver holen.

Grüße, phx1024

[cosmac]

hi,

das sieht so aus, als ob die virtuellen Uhren einfach eine zu
hohe Drift haben. NTP verlässt sich darauf, daß die System-Uhr
wenigstens die Qualität einer schlechten Quarzuhr hat. Es kann
vom Prinzip her max. 1/2000 Sekunde pro Sekunde ausgleichen.

chrony ist toleranter bei schlechtem Netzwerk. O.k., das ist nicht
dein Problem, aber vielleicht kommt chrony auch besser mit der
starken Drift zurecht. Wobei es natürlich keine Chance hat, wenn
die 1/2000 Sekunde ein Kernel-Limit ist:(