Martin Hochreiter, Montag, 6. März 2006 12:10:

xinetd ist angepasst und läuft ... den großen Erfolg hat das leider noch nicht gebracht - es wird noch immer "Server nicht erreichbar gemeldet" .. noch Ideen?

Was passiert denn, wenn Du die Firewall abschaltest, und ein nmap gegen die Maschine laufen läßt - ist dann der Port 37 offen? -- Andre Tann

Ich hab es nicht mit nmap sonder vorher schon mit einem simplen netstat -tulpen versucht: udp 0 0 192.168.1.104:123 0.0.0.0:* 0 16391 9814/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 0 16390 9814/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 0 16383 9814/ntpd udp 0 0 :::123 :::* 0 16384 9814/ntpd Also das Ding lauscht auf allen Ports. xinetd ist desöfteren schon neu gestartet worden, ohne irgendwelchen Erfolg. Ich find das sehr mysteriös alles ... lg --- Ursprüngliche Nachricht --- Absender: Andre Tann Datum: 06.03.2006 12:47

Martin Hochreiter, Montag, 6. März 2006 12:10:

...

xinetd ist angepasst und läuft ... den großen Erfolg hat das leider noch nicht gebracht - es wird noch immer "Server nicht erreichbar gemeldet" .. noch Ideen?

Äh, nochwas: rcxinetd restart gemacht? Sonst kriegt der nix mit von den Änderungen...

On Mon, Mar 06, 2006 at 11:46:29AM +0100, Andre Tann wrote:

Martin Hochreiter, Montag, 6. März 2006 11:11:

...

Kann mir wer einen Tipp geben?

Jo, das liegt daran, daß der xtnp nicht dauernd läuft, sondern über den xinetd gestartet wird.

Das mach fuer den NTP-Dienst sehr wenig Sinn. Peter

Martin Hochreiter wrote:

Moment - brauch ich jetzt den xinetd oder nicht?

Eindeutig nein, /etc/xinetd.d/time hat nichts mit ntp zu tun, und selbsverständlich benutzt ntpdate das ntp-Protokoll. Dass du warten musstest, dürfte damit zusammenhängen, dass der ntp-Server erst dann Verbindungen von Peers zulässt, wenn er selbst synchronisiert ist. Das dauert nach Neustart ca. 10 Minuten. Es lässt sich sehr schön mit 'ntpq -p' und 'ntptrace' beobachten, wann das der Fall ist. -- Viele Grüße ------------------------------------------------------------------------ Michael

On Mon, Mar 06, 2006 at 05:56:19PM +0100, Andre Tann wrote:

Michael Behrens, Montag, 6. März 2006 17:31:

...

Eindeutig nein, /etc/xinetd.d/time hat nichts mit ntp zu tun, und selbsverständlich benutzt ntpdate das ntp-Protokoll.

Bei mir jedenfalls kriege ich keine Zeit vom Server abgefragt, wenn da nicht der xinetd läuft, und der time-Eintrag nicht aktiviert ist.

Mit welchem Kommando holen deine Clients ihre Zeit? Ich hab jetzt hier mal das Paket xntp aus SUSE OSS 10.0 installiert - ein /etc/xinetd.d/ntp wird nicht mit ausgeliefert. Du hast zwar recht, das man weniger Resourcen verbrauchen wuerde, wenn der ntp nur ueber xinetd startet, aber das Protokoll und die Verfahrensweise des Daemons machen einen Dauerlauf des Daemons sinnvoll. Und mit stabilen 4 Megabyte ist das ja auch kein dicker Fisch. Peter

Hi Andre, Am Dienstag, 7. März 2006 14:11 schrieb Andre Tann:

PS: wie sagt man eigentlich dem Time-Service von XP, daß wo er die Zeit abholen soll?

afair über eine dhcp option, sofern man dhcp verwendet. Gruss FaLk

Hi Andre, Am Dienstag, 7. März 2006 15:43 schrieb Andre Tann:

Falk Sauer, Dienstag, 7. März 2006 15:21:

...

afair über eine dhcp option, sofern man dhcp verwendet.

Habe ich mal probiert, und zwar

option time-servers timeserver;

Aber das hat irgendwie nicht gefruchtet. Jedenfalls Linux-Clients haben sich hiernach nicht gerichtet.

das zieht da glaub ich auch nicht, zumindest müssten entweder irgendwelche Mechanismen im dhcp-client am ntp-client rumschrauben oder der dhcp-client selber müsste den zeitserver befragen ...

Bei XP-Clients weiß ich es nicht, weil ich nicht weiß, wie man nachsieht, woher der XP-Client seine Zeit bezieht.

im logfile des Zeitservers? ;-) Schau aber spasseshalber auch mal im sambalog nach wenn auf der Büchse einer läuft, es könnt auch gut sein das xp dann diesen zeitserver meint nehmen zu müssen. Gruss Falk

Andre Tann schrieb:

Peter Wiersig, Montag, 6. März 2006 20:36:

...

...

Bei mir jedenfalls kriege ich keine Zeit vom Server abgefragt, wenn da nicht der xinetd läuft, und der time-Eintrag nicht aktiviert ist.

Wie schon an anderer Stelle in diesem Thread erwähnt, ist das "time"-Protokoll ein sehr altes, eines der ersten, die zur Zeitsynchronisierung verwendet wurden. Das Protokoll überträgt dabei die lediglich die Unix-Zeit in Sekunden seit 1970. Es werden keine Bruchteile der Sekunden ausgewertet, und auch die Laufzeit der Pakete im Netzwerk wird nicht berücksichtigt. Das Protokoll verwendet Port 37, und wenn konfiguriert, wird die Aufgabe eines "time"-Servers meist nebenbei von einem inetd bzw xinetd erledigt. NTP dagegen ist weitaus komplexer. Da ist einmal das Netzwerk-Protokoll, mit dem NTP-Clients von einem NTP-Server die Zeit abrufen können, und zum anderen die Verarbeitung der Pakete im NTP-Daemon. Der NTP-Daemon stellt nicht nur als Service an Port 123 anderen NTP-Daemons seine Zeit zur Verfügung, sondern er wertet auch NTP-Pakete, die er selbst von einer Zeitquelle empfängt, in einem komplexen Regelalgorithmus aus. Dabei wird nicht nur die eigene Systemzeit einfach nachgestellt, sondern auch die Drift der Systemzeit wird ermittelt und kompensiert, so dass erst gar keine großen Zeitabweichungen auftreten. Das funktioniert natürlich nur vernünftig, wenn der NTP-Daemon dauernd läuft. Das Protokoll unterstützt eine Zeitauflösung im Nanosekundenbereich. Bei entsprechender Unterstützung durch das Betriebssystem lassen sich Zeitsynchronisierungen mit einer Genauigkeit von besser als 1 Millisekunde erreichen. Bei der Zeitsynchronisierung wird auch geprüft, ob die verwendete Zeitquelle sich als "synchron" ausgibt. Das gilt sowohl für Upstream-NTP-Server als auch für Funkuhren, die als Zeitquelle verwendet werden. Wenn eine Zeitquelle nicht synchron ist, wird sie von einem NTP-Daemon nicht akzeptiert.

...

Mit welchem Kommando holen deine Clients ihre Zeit?

Sangmers so: die Zeit wird v.a. von Windows-Clients abgeholt, mit dem ntp-Client tardis2000 von www.kaska.demon.co.uk. Was der genau macht weiß ich nicht, aber ohne den xinetd liefs eben in der Vergangenheit nicht. Habe mich aber nicht weiter drum gekümmert.

Ich kenne Tardis nicht näher, aber es wäre denkbar, dass das Programm alternativ das "time"-Protokoll oder das NTP-Protokoll verwenden kann.

...

Du hast zwar recht, das man weniger Resourcen verbrauchen wuerde, wenn der ntp nur ueber xinetd startet, aber das Protokoll und die Verfahrensweise des Daemons machen einen Dauerlauf des Daemons sinnvoll. Und mit stabilen 4 Megabyte ist das ja auch kein dicker Fisch.

Da hast Du recht, und nur für den xntpd ist xinetd etwas zuviel des guten.

Der xinetd ist dazu gedacht, Netzwerkdienste, die nicht dauernd benötigt werden, nur bei Bedarf zu starten. Wie gesagt, ist (x)ntpd für den Dauerbetrieb ausgelegt, daher ist es nicht sinnvoll, diesen Dienst über xinetd zu starten. Direkt nach dem Start hat der NTP-Daemon den Status "nicht synchron", d.h. echte NTP-Clients werden sich nicht darauf synchronisieren. Weitere grundlegende Informationen zu NTP sind hier zu finden: http://www.meinberg.de/german/info/ntp.htm Aus den genannten Gründen sollte (x)ntpd im Yast-Runlevel-Editor auf aktiv gesetzt werden, damit er nach dem Booten direkt gestartet wird. Wenn ich mich recht erinnere, habe ich unter xinetd noch keinen Eintrag für (x)ntp gesehen. Neuere SuSE-Versionen können auch die NTP-Konfiguration mehr oder weniger gut über Yast verwalten (Netzwerkdienste->NTP-Client). Dabei kann dann auch der Start des Dienstes beim Booten festgelegt werden. Eine potentielle Fehlerquelle besteht darin, dass neuere DHCP-Clients die NTP-Konfiguration /etc/ntp.conf überschreiben können, wenn ein DHCP-Server auch Daten für einen NTP-Server übermittelt. Gegebenenfalls muß überprüft werden, ob das Verhalten gewünscht ist oder nicht. Bei aktuellen SuSE-Versionen bietet Yast auch dafür eine Konfigurationsmöglichkeit.

Gruß. AT

PS: wie sagt man eigentlich dem Time-Service von XP, daß wo er die Zeit abholen soll?

Unter Windows gibt es den "net time"-Befehl, der ein proprietäres Protokoll aus NETBIOS-Zeiten verwendet, das nichts mit den oben genannten Protokollen zu tun hat. Windows 2k/XP usw. verwenden den Dienst "Windows-Zeitgeber" mit dem Service-Namen "w32time", der auch SNTP (Simple NTP, eine Untermenge von NTP) versteht. Die Konfiguration über die Kommandozeile kann mit Hilfe des "net time" Befehls erfolgen, z.B.: net time /querysntp zeigt die aktuelle Zeitquelle net time /setsntp:server konfiguriert "server" als Zeitquelle Zu beachten ist, dass sich einige Einzelheiten zwischen den w32time-Versionen von W2k und WXP geändert haben. Z.B. gibt es bei letzteren das Programm "w32tm", welches anstelle der oben genannten Befehle verwendet werden sollte. Zu den Details bitte bei Microsoft nachlesen. Falls sich ein w32time-Service nicht mit einem NTP-Server synchronisiert, kann folgender Artikel hilfreich sein: Warum synchronisiert sich mein Windows Zeitdienst (w32time) nicht mit meinem NTP-Server? http://www.meinberg.de/german/faq/faq_28.htm Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany

Andre Tann wrote:

...

Ob Martin den xinetd braucht oder nicht, weiß ich nicht. Bei mir jedenfalls kriege ich keine Zeit vom Server abgefragt, wenn da nicht der xinetd läuft, und der time-Eintrag nicht aktiviert ist.

Oder, um es anders auszudrücken: Brauche ich den xinetd? Eindeutig ja. (jedenfalls bei SuSE-Standard-Installation)

Das muss ein anderer Standard sein als hier ;-)

Hier läuft auf einem SLES9 und einem Suse 9.3 jeweils xntpd als Dämon, und 80 Clients synchronisieren ihre Uhr damit, obwohl "time" in xinetd ausgeschaltet ist.

Benutzt du wirklich "ntpdate"? Oder vielmehr "netdate", das verwendet das "time"-Protokoll. Und dann muss es natürlich am Zeitserver eingeschaltet sein.

Ich bin kein Kenner des xinetd aber ich hab nun den NTP Dienst auf 2 Maschinen (Suse 10.0) laufen, einmal mit xinetd (allerdings nicht aus Gründen des NTP) und einmal ohne. Laufen tut NTP auf beiden ... lg

Peter Wiersig, Montag, 6. März 2006 13:08:

Das mach fuer den NTP-Dienst sehr wenig Sinn.

Ist halt die Standard-Einstellung für Susis. Kann man natürlich auch anders konfigurieren. Hat man nur eine Anfrage täglich, dann xinetd, bei dauernden Anfragen halt direkt. Aber den xinetd einzig wg. ntp ist natürlich auch wieder overkill... -- Andre Tann