Hallo, Wo muss ich meinen netdate Eintrag zum Uhrzeit synchronisieren machen, der nachdem eine Internet-Verbindung aufgebaut worden ist, ausgeführt werden soll? Bis jetzt hatte ich ihn immer in der /etc/ppp/ip-up als letztes aufgeführt. Das klappt jetzt aber bei der SuSE 8.0 anscheinend nicht mehr. Christoph
24.05.2002, SuSE Listen Treffen in der schönen Hansestadt Hamburg. Da will ich hin und Du doch sicherlich auch. On Sunday 14 May 2000 19:54, Christoph Strins wrote: [...]
Wo muss ich meinen netdate Eintrag zum Uhrzeit synchronisieren machen, der nachdem eine Internet-Verbindung aufgebaut worden ist, ausgeführt werden soll? Bis jetzt hatte ich ihn immer in der /etc/ppp/ip-up als letztes aufgeführt. Das klappt jetzt aber bei der SuSE 8.0 anscheinend nicht mehr. [...] So langsam sollte ich mir einmal eine Vorlage für die automatische Beantwortung dieser Frage erstellen. :o)
Aus dem Archiv: probleme mit uhrzeit Datum: Fri, 12 Apr 2002 12:38:03 +0200 ---8<--- Probleme gibt es immer wieder mit der Unterschiedlichen Behandlung der Uhrzeit auf deinem Motherboard, man spricht von der real time clock (rtc), durch das jeweilige Betriebssystem. Dabei wird von Betriebssystemen aus dem Evil Empire beim booten diese Zeit einfach ausgelesen und als die Systemzeit des Betriebssystemes übernommen. Also: rtc Zeit = systime Damit bestimmt die rtc-time auch die Zeitzone in der Du dich befindest. Man schaut also einfach auf seine Armbanduhr und trägt diese Zeit im BIOS Setup ein. Früher musste man dann bei jeder Sommer/Winterzeit Umstellung die Zeit wieder neu einstellen, reichlich nervig. Mitlerweile können NT und W2k/XP selber eine Umstellung nach Winter/Sommerzeit. Dazu verwenden sie Tabellen in denen die Umstellungen vorgegeben werden. Auf vernünftigen Betriebssystemen wird das schon seit ewigen Zeiten anders gehandhabt. Wir nemen einmal ein Unix System *grins* Die rtc, wir wissen damit ist die Hardware Clock auf dem Board gemeint, wird auf UTC (früher nannte man das GMT) eingestellt. Im Betriebssystem wird die Zeitzone definiert, in der sich der Rechner gerade befindet. Also in unserem Fall Europe/Berlin oder UTC+1. UTC+1 ist unsere normale Zeitzone also MEZ. Wie wird die Zeit jetzt aber von einem Unix System interpretiert? Das wird etwas komplexer und weitaus pfiffiger als auf der Systemen aus dem Evil Empire ausgewertet. Das System bootet und holt sich die Zeit aus der rtc. Wie Dieter ja schon sagte wird jetzt erst einmal eine feste Spanne für die lokale Zeit hinzugefügt, normalerweise eine Stunde. Diese Informationen und die Informationen über Umstellungen während des Jahres wie die Sommer/Winterzeit Umstellung ist hinterlegt in der Datei /usr/share/zoneinfo/Europe/Berlin. ---nur falls interessiert Im Verzeichnis /usr/share/zoneinfo werden daneben auch noch eine Datei mit den ISO 3166 2-letter country codes , definiert z.B. das DE für Deutschland, iso3166.tab und eine Datei mit Angaben zu Längen und Breitengraden einiger Städte wie Berlin , zone.tab ---ende Damit wird schon einmal die aktuelle Zeitdifferenz zur rtc grob vorgegeben, jetzt wird das noch genauer eingegrenzt. Dieter hat ja bereits geschrieben, dass die Board Uhren nicht als sehr genau gelten, alle gehen mehr oder minder vor oder nach, man spricht vom sogenannten time-shift. Um auch noch diese Ungenauigkeiten zu eleminieren gibt es die Datei /etc/adjtime dort wird ein Korrekturfaktor für Deine rtc angegeben. Allerdings nur, wenn Du sie irgendwann einmal nachgestellt haben solltest und das auch nur dann wenn Du es mit hwclock gemacht hast. Aber dazu etwas später. Solch eine Datei kann folgendermassen aussehen: ---/etc/adjtime--- -3.127072 1018601965 0.000000 1018601965 UTC ---/etc/adjtime--- Und damit kann auch eine kleinere Ungenauigkeit der rtc bei jedem booten des Systemes wieder korrigiert werden. Die so bestimmte Systemzeit gilt jetzt als das "Mass aller Dinge" bis zum nächsten boot Vorgang des Systemes und das kann ewig dauern. Kurz gefasst: Booten - rtc auslesen - Timezone auslesen - timeshift auslesen - Unix Systemzeit ermitteln Soviel zur Zeit eines Unix Systemes oder Systemzeit. Jetzt zum Nachstellen der Zeit von einem Zeitserver aus dem Internet: Es gibt von der Physikalisch technischen Bundesanstalt in Braunschweig einige Zeitserver die Ihre Urzeit wieder aus der/?den? Atomuhren der PTB beziehen. Mit einer Genauigkeit von Sekunde/Jahrmillion soweit ich mich erinnern kann. Die kann man z.B. bei jeder Verbindung, die man mit dem Modem aufbaut automatisch zur korrektur der Systemzeit und auch der rtc heranziehen. Dazu wird eine eigene Datei /etc/ppp/ip-up.local erstellt in der folgende Zeilen einzutragen sind: \\ ist ein Zeilenumbruch ---/etc/ppp/ip-up.local--- # Timeserver aufruf, ptba Braunschweig echo "Netdate aufgerufen" 1> /dev/xconsole netdate -l 1 tcp ptbtime1.ptb.de ptbtime2.ptb.de \\ 127.0.0.1 1> /dev/xconsole hwclock --systohc ---/etc/ppp/ip-up.local--- Mit netdate wird einer der Zeitserver ermittelt der ausgelesen wird. Die 127.0.0.1 sollte man unbedingt einfügen damit es keinen Ärger gibt. Falls die Zeitserver mal nicht erreichbar sind wird deine eigene Zeit genommen. Mit "hwclock --systohc" wird die rtc auf die systime neu gestellt. Und dabei wird auch ein eintrag in die Datei /etc/adjtime geschrieben. Das wars, puhh. Ich glaub viel mehr gibts dazu nicht zu sagen. Damit solltest Du schon einmal in der Lage sein deine Zeit zu bestimmen*grins* Tschüss, Thomas p.s. David unser Liststatist(iker), ist es eigendlich zulässig so seine Statistik nach oben zu pushen oder habe ich mit Repressialien zu rechnen *lach* -- SuSE Listen Treffen in der schönen Hansestadt Hamburg am 24.05.2002. Das ultimative, spannende, komunikative, enthusiastisch erwartete, von allen gewünschte und lang herbeigesehnte und nun endlich stattfindende SuSE Listen Treffen im Variable" (Karolinenstr. 23 / U2 Messehallen) im sonnigen und immer eine Reise werten Hamburg.
Hallo, netdate ist eigentlich völlig veraltet (RFC 868). Wenn die möglichkeit besteht, würde ich immer ntpdate verwenden. Dieses verwendet das Network Time Protokoll (NTP). NTP ist im Gegensatz zum Time-Protokoll welches netdate verwendet nicht laufzeitabhängig. Ob die Uhr nur nun ms oder µs abweicht dürfte für viele nicht so dramatisch sein. Ein weiterer Vorteil von ntpdate ist aber auch das die Uhr einfach durch eine Firewall hindurch synchronisiert werden kann, ohne das man diese explizit dafür öffnen muss.
Jetzt zum Nachstellen der Zeit von einem Zeitserver aus dem Internet: Es gibt von der Physikalisch technischen Bundesanstalt in Braunschweig einige Zeitserver die Ihre Urzeit wieder aus der/?den? Atomuhren der PTB beziehen. Mit einer Genauigkeit von Sekunde/Jahrmillion soweit ich mich erinnern kann. Die kann man z.B. bei jeder Verbindung, die man mit dem Modem aufbaut automatisch zur korrektur der Systemzeit und auch der rtc heranziehen. Dazu wird eine eigene Datei /etc/ppp/ip-up.local erstellt in der folgende Zeilen einzutragen sind: \\ ist ein Zeilenumbruch
---/etc/ppp/ip-up.local--- # Timeserver aufruf, ptba Braunschweig echo "Netdate aufgerufen" 1> /dev/xconsole netdate -l 1 tcp ptbtime1.ptb.de ptbtime2.ptb.de \\
Anstatt netdate würde ich folgenden Aufruf verwenden: ntpdate -u ntp1.ptb.de ntp2.ptb.de
127.0.0.1 1> /dev/xconsole hwclock --systohc ---/etc/ppp/ip-up.local---
Die Option -u bewirkt das der Abgleich nicht über die normalen NTP-Ports durchgeführt wird, sonder über die Highports. Diese sind für die Meisten Firewalls durchlässig. ntp2.ptb.de dient nur als Backup, falls ntp1.ptb.de mal ausfallen oder belegt sein sollte. Gruß Bastian
24.05.2002, SuSE Listen Treffen in der schönen Hansestadt Hamburg. Da will ich hin und Du doch sicherlich auch. On Tuesday 14 May 2002 23:10, Bastian Schern wrote:
netdate ist eigentlich völlig veraltet (RFC 868). Wenn die möglichkeit besteht, würde ich immer ntpdate verwenden. Dieses verwendet das Network Time Protokoll (NTP). NTP ist im Gegensatz zum Time-Protokoll welches netdate verwendet nicht laufzeitabhängig. Ob die Uhr nur nun ms oder µs abweicht dürfte für viele nicht so dramatisch sein. Ein weiterer Vorteil von ntpdate ist aber auch das die Uhr einfach durch eine Firewall hindurch synchronisiert werden kann, ohne das man diese explizit dafür öffnen muss. Ich dachte bisher immer das die Laufzeitabhängigkeit von Netdate bedeutet, dass der Ticket Timestamp mit ausgewertet wird. Aber wenn ich es überlege, Du scheinst Recht zu haben. Weia, da war ich aber lange Zeit auf dem Holzweg. *schwitz*
Wird wohl mal wieder Zeit einige man-Pages zu inhalieren. Tschüss, Thomas -- SuSE Listen Treffen in der schönen Hansestadt Hamburg am 24.05.2002. Das ultimative, spannende, komunikative, enthusiastisch erwartete, von allen gewünschte und lang herbeigesehnte und nun endlich stattfindende SuSE Listen Treffen im Variable" (Karolinenstr. 23 / U2 Messehallen) im sonnigen und immer eine Reise werten Hamburg.
Hallo, On Tue, 14 May 2002, Thomas Templin wrote:
[...] So langsam sollte ich mir einmal eine Vorlage für die automatische Beantwortung dieser Frage erstellen. :o)
Sollten wir :) Wie waere's als Eintrag in der neuen nicht-mini FAQ [1]? *g* [..]
Jetzt zum Nachstellen der Zeit von einem Zeitserver aus dem Internet: Es gibt von der Physikalisch technischen Bundesanstalt in Braunschweig einige Zeitserver die Ihre Urzeit wieder aus der/?den? Atomuhren der PTB beziehen. Mit einer Genauigkeit von Sekunde/Jahrmillion soweit ich mich erinnern kann.
Jup.
Dazu wird eine eigene Datei /etc/ppp/ip-up.local erstellt in der folgende Zeilen einzutragen sind: \\ ist ein Zeilenumbruch
---/etc/ppp/ip-up.local--- # Timeserver aufruf, ptba Braunschweig echo "Netdate aufgerufen" 1> /dev/xconsole netdate -l 1 tcp ptbtime1.ptb.de ptbtime2.ptb.de \\ 127.0.0.1 1> /dev/xconsole hwclock --systohc ---/etc/ppp/ip-up.local---
Mit netdate wird einer der Zeitserver ermittelt der ausgelesen wird. Die 127.0.0.1 sollte man unbedingt einfügen damit es keinen Ärger gibt. Falls die Zeitserver mal nicht erreichbar sind wird deine eigene Zeit genommen.
Korrekt. Aber ich habe mich neulich nochmal damit beschaeftigt, und entgegen dem, was ich bisher oft geschrieben habe, sollte man die Stratum 1 Server der PTB moeglichst NICHT verwenden. Ich habe zwar die Erfahrung gemacht, dass der Abgleich mit ptbtime[12].ptb.de sehr flott ist (i.a.Regel), aber dennoch sollte man diese Server nur verwenden, wenn man selber einen (oeffentlichen) Stratum 2 Zeitserver bereitstellt. IIRC steht dazu auch auf den Webseiten der PTB genaueres. Natuerlich _darf_ man die Server verwenden, sollte aber nicht. Als Alternativen gibt es diverse Stratum 2 Zeitserver, viele Unis haben oeffentliche, viele Provider stellen ebenfalls einen Zeit- server bereit. Aus meiner (aktualisierten) /etc/ppp/ip-up.local: ==== /etc/ppp/ip-up.local (ueberlange Zeilen!) ==== # [..] TIMESERVERS="\ rustime01.rus.uni-stuttgart.de # RZ Uni Stuttgart; S1 (DCF) ntp1.t-online.de # T-Online; S1 ?? ntp0.fau.de # Universität Erlangen; S1 (GPS) # ntp2.fau.de # Universität Erlangen; S1 (DCF) # bernina.ethz.ch # Eidgen. Techn. Hochschule, Zürich; S2 # ntp.cs.strath.ac.uk # Strathclyde University, Glasgow; S2 # ntps1-{0,1,2}.uni-erlangen.de # Universität Erlangen; S1 (DCF) # ntps1-{0,1}.cs.tu-berlin.de # Techn. Universität Berlin; S1 (GPS) # ptbtime1.ptb.de # Phys. Techn. Bundesanstalt, Braunschweig; S1 (CS) # ptbtime2.ptb.de # Phys. Techn. Bundesanstalt, Braunschweig; S1 (CS) " TIMESERVERS=`echo "$TIMESERVERS" | sed 's/#.*//g' | xargs echo` # [..] /usr/sbin/netdate -l 1 \ localhost \ $TIMESERVERS \ && /sbin/clock -uw \ && /usr/bin/play /usr/share/sounds/wav/clock.wav & # [..] ==== Zeichenerklaerung: S<n> Stratum <n>. Stratum ist ein Mass der Genauigkeit, bei Zeitservern meist die "Schritte" zwischen "offizieller" Zeit und dem Zeitserver. Eigentlich muessten die beiden ptbtime-Server S0 sein, aber das ist nicht definiert. DCF Die Zeit des Servers laeuft nach einem DCF77 Funkempfaenger (der die Zeitsignale vom MW-Senders bei M*?? bekommt, welcher wiederum die Zeit (direkt) von der PTB bekommt). GPS Zeit wird nach nem GPS-Empfaenger gestellt, die GPS-Satelliten haben ebenfalls Atom- (ebenfalls Caesium-, IIRC) Uhren "an Bord", GPS _basiert_ auf den Laufzeitdifferenzen (berechnet eben nach dem Zeitsignal, das mitgesendet wird) zwischen den Satelliten [2]. CS Zeitserver wird mit Caesium-Atom-Uhr syncronisiert. Im konkreten Fall mit der CS-Uhr bei der PTB, die die offizielle Zeit fuer Deutschland definiert. Anmerkungen: 0. den Uni-Stuttgart Server verwende ich als ersten, weil der auch und nicht nur Netztopographisch nah ist[9]. Ggfs. also bitte einen "naheliegenderen" Zeitserver verwenden, man mache einfach mal ein 'traceroute' auf die Server... Bitte verwendet _nicht_ den der uni-stuttgart... 1. Ich wollte eine Liste der Zeitserver, die kommentiert werden kann und bei der ich ggfs. einzelne Server ein- und auskommentieren kann. 2. Man achte auf die "" beim ersten 'TIMESERVERS='(!) 3. Man achte drauf, dass *.ptb.de auskommentiert sind 4. siehe 'man netdate' zum Unterschied wenn a) localhost als erstes: Die Zeit wird nur gestellt, wenn es eine Abweichung groesser als die mittels -l <sek> angegeben gibt, b) localhost als letztes und ohne '-l <sek>': localhost wird "nur" als "fallback"-Zeitserver verwendet. Ich habe mich nun fuer a) entschieden. 5. Ich habe aus einer Liste mit Timeservern einige _explizit_ oeffentliche und fuer DE/Europa "zustaendige" (ausser t-online, da weiss ich nix genaueres) herausgesucht. Ausserdem habe ich nach der Anbindung der Zeitserver selektiert (z.B. sind FR und ES im Vergleich zu UK oder US deutlich schlechter an die DE-Backbones angeschlossen... bzw. umgekehrt.) Leider habe ich die URL der Liste nicht zur Hand... 6. Am genausten sind (per Definition) die mit der (IIRC den!) CS-Uhr(en) der PTB syncronisierten Zeitserver der PTB, die aber, s.o., moeglichst nur verwenden sollte, wenn man selbst einen Stratum 2 Zeitserver betreibt. Die mit GPS/DCF syncronisierten Server sollten in etwa gleich genau sein (und zwar locker im Toleranzbereich, der eh durch netdate und Laufzeiten im Internet bedingt wird), DCF hat eine gewisse Latenz; GPS weicht u.U. etwas von den CS-Uhren der PTB ab (sind ja US Uhren, ob die damals exakt mit denen der PTB syncronisiert wurden bezweifle ich! ;) 7. ntp[0-2].fau.de != ntps1-[0-2].uni-erlangen.de Die Namen zeigen auf verschiedene IPs und ich gehe mal davon aus, dass das verschiedene Institute der Uni sind, die da (mehr oder weniger aus Eigeninitiative/nebenbei) Zeitserver betreiben. Fazit[3]: Alle, die nicht auf eine Zeitdifferenz < 1ms angewiesen sind oder einen (oeffentlichen!) Stratum2 Zeitserver betreiben, sollten ihre Zeit _nicht_ direkt von den beiden Servern der PTB beziehen, um diese nicht zu ueberlasten. Hm. Wenn man das (evtl. gekuerzt / in eine Fussnote ausgelagert o.ae.) noch in den Rest der Erklaerung gut einbaut... :) [..]
Das wars, puhh. Ich glaub viel mehr gibts dazu nicht zu sagen.
ACK! Klasse Erklaerung / Zusammenfassung anderer Quellen[4] :))) Mehr davon! :)
p.s. David unser Liststatist(iker), ist es eigendlich zulässig so ^^^^^^^^^^^ *lol* seine Statistik nach oben zu pushen
Wo denkst du hin!?! Natuerlich nicht!
oder habe ich mit Repressialien zu rechnen *lach*
Aber hallo! Du wirst mit DAU-Fragen-Beantworten nicht unter 42 Exemplaren bestraft! *SCNR* Quatsch. Noe. Wieso auch? Bei dem, was du sonst so schreibst faellt das bisschen oben, das du rausgekramt hast, auch nicht auf... Ausserdem ist es IMO sinnvoll, so eine gute, ausfuehrliche Anwort auch mal komplett einzufuegen... In der Statistik auffallen wuerde noch am ehesten die Statistik selbst (so 11KB ca., bei mir aber evtl. nichtmal das ;), aber die schick ich ja unter ner anderen Addy[7], die Pointer zur mini-FAQ und auf die Etikette fallen IMO auch nicht weiter auf, bzw. koennen sowieso legitim Helga bzw. Sebastian "zugerechnet" werden (selbst wenn das nicht ganz "ideal" ist[5]). -dnh [1] Evtl. leg ich mir demnachst mehr Webspace zu, dann koennte ich die FAQ hosten bzw. evtl. auch betreuuen. [2] Die GPS Satelliten senden IIRC im Prinzip nur eine ID und einen Zeitstempel. Aufhand der Differenzen der Zeitstempel von (mind. 3 IIRC) Satelliten, sowie der Kenntnis der Umlaufbahnen, wird dann die Position berechnet (IIRC). [3] Ja, ich _habe_ frueher eine andere Meinung gehabt (und auch hier geschrieben). [4] muehsam? Auf jeden Fall absolut legitim. Sonst muesste ich mir ja wg. einer der hier (ausser google/linuxdoc/sdb) wohl mit am meisten erwaehnten[8] URLs an die eigene Nase fassen ;)) Aus einem Haufen einzelner Brocken eine gute Zusammenfassung zu erstellen ist IMO gar nicht einfach. [5] Apropos: Helga: Wenn du ne (ggfs. dummy) Email-Adresse willst[6], ich hab hier noch genug frei ;) Sebastian duerfte ja selbst die Moeglichkeit haben, eine alias zu definieren... [6] Analog 'slstats@' [7] die Statistik "zaehlt" nach dem 'Envelope-From'! [8] jaja, schon gut, davon oft von mir, aber hoffentlich nur zu "passenden" Gelegenheiten :) [9] IIRC naeher als der von T-Online (und das aus deren Netz ;)... ARG! Ausgerechnet jetzt geht das traceroute nicht durch *grmpf* -- Das höhrt sich an, wie die Beschreibung eines Dildos für gewesene Jungfrauen. [WoKo in dafb]
On Wednesday 15 May 2002 02:31, David Haller wrote:
So langsam sollte ich mir einmal eine Vorlage für die automatische Beantwortung dieser Frage erstellen. :o)
Sollten wir :) Wie waere's als Eintrag in der neuen nicht-mini FAQ [1]? Da bringst Du mich auf was, darüber hab ich gerade einiges am Laufen. Was meinst Du könnte die SuSE Liste FAQ als Basis für einen exemplarischen Fragen- und Lern- Katalog für die Ausbildung herhalten? Ich habe Momentan gerade einige Leute in "Bearbeitung" denen ich versuche ein gemeinsames Linux Vademecum schamckhaft zu machen. Dabei soll es im Endziel ein unter der LDGPL stehendes modulares Referenzwerk / ein Informationspool für die Ausbildung von Netzwerk SystemtechnikerInnen mit dem Schwerpunkt Linux ergeben.
Das ganze ist noch nicht ganz ausgegoren (also pssst), aber ich werde mich im Laufe des Vormittagesages noch mal mit Georg C. F. Greve zusammensetzen und was passendes ausbaldovern. Tschüss, Thomas
* David Haller schrieb am 15.Mai.2002:
On Tue, 14 May 2002, Thomas Templin wrote:
Ich sehe, Ihr verwendet alle netdate. Aber damit springt AFAIK die Zeit. Ich verwende chrony, damit wird die Zeit kontinuierlich angepaßt, auch wenn man nur sporadisch online ist. Vor allem wird nicht in der Zeit zurückgesprungen, was zu Verwirrungen führen könnte. Bernd -- Umsteiger von Microsoft Windows xx? Hast Du schon file://usr/doc/howto/de/DE-DOS-nach-Linux-HOWTO.txt gelesen? Auch file://usr/doc/Books/Linuxhandbuch.dvi ist zu empfehlen. |Zufallssignatur 1
* Christoph Strins schrieb am 14.Mai.2000:
Wo muss ich meinen netdate Eintrag zum Uhrzeit synchronisieren machen, der nachdem eine Internet-Verbindung aufgebaut worden ist, ausgeführt werden soll? Bis jetzt hatte ich ihn immer in der /etc/ppp/ip-up als letztes aufgeführt. Das klappt jetzt aber bei der SuSE 8.0 anscheinend nicht mehr.
ip-up wird beim Update überschrieben, daher sollte man sich sein /etc/ppp/ip-up.local anlegen. Bernd -- Homepages von deutschsprachigen Linux-Gurus: Kristian Köhntopp: http://www.koehntopp.de/kris/artikel/ Sven Guckes: http://www.math.fu-berlin.de/~guckes/sven Robin S Socha: http://socha.net/index2.html |Zufallssignatur 10
Hallo Christoph, hallo Leute, Am Sonntag, 14. Mai 2000 19:54 schrieb Christoph Strins:
Wo muss ich meinen netdate Eintrag zum Uhrzeit synchronisieren machen, der nachdem eine Internet-Verbindung aufgebaut worden ist, ausgeführt werden soll? Bis jetzt hatte ich ihn immer in der /etc/ppp/ip-up als letztes aufgeführt. Das klappt jetzt aber bei der SuSE 8.0 anscheinend nicht mehr.
Was Wunder, die ip-up wurde wohl beim Update überschrieben. /etc/ppp/ip-up.local (ich hoffe, der Pfad stimmt noch für SuSE 8.0) sollte Dir länger erhalten bleiben ;-) Falls die ip-up.local nicht existiert: einfach anlegen und ausführbar machen. Gruß Christian Boltz -- Registrierter Linux-Nutzer #239431 Linux - life is too short for reboots.
Am Dienstag, 14. Mai 2002 23:55 schrieb Christian Boltz:
Am Sonntag, 14. Mai 2000 19:54 schrieb Christoph Strins:
Wo muss ich meinen netdate Eintrag zum Uhrzeit synchronisieren machen, der nachdem eine Internet-Verbindung aufgebaut worden ist, ausgeführt werden soll? Bis jetzt hatte ich ihn immer in der /etc/ppp/ip-up als letztes aufgeführt. Das klappt jetzt aber bei der SuSE 8.0 anscheinend nicht mehr.
Was Wunder, die ip-up wurde wohl beim Update überschrieben.
/etc/ppp/ip-up.local (ich hoffe, der Pfad stimmt noch für SuSE 8.0) sollte Dir länger erhalten bleiben ;-) Falls die ip-up.local nicht existiert: einfach anlegen und ausführbar machen.
Ich habe mir jetzt die ip-up.local mit folgendem Inhalt angelegt und ausführbar gemacht: rcpersonal-firewall stop netdate ntp1.ptb.de ntp2.ptb.de clock -w rcpersonal-firewall start rm /etc/adjtime Die Zeit wird aber trotzdem nicht synchronisiert. Wenn ich den Eintrag "rcpersonal-firewall start" rausnehme und nach dem Verbindungsaufbau ein "rcpersonal-firewall status" mache, wird gemeldet, dass die Firewall läuft. Es wird also kein Befehl ausgeführt. Wenn ich die Befehle per Hand eingebe, läuft alles. Christoph
Hallo Christoph, hallo Leute, Am Dienstag, 15. Mai 2001 18:08 schrieb Christoph Strins:
Am Dienstag, 14. Mai 2002 23:55 schrieb Christian Boltz:
Was Wunder, die ip-up wurde wohl beim Update überschrieben. /etc/ppp/ip-up.local (ich hoffe, der Pfad stimmt noch für SuSE 8.0) sollte Dir länger erhalten bleiben ;-)
Ich habe mir jetzt die ip-up.local mit folgendem Inhalt angelegt und ausführbar gemacht:
rcpersonal-firewall stop netdate ntp1.ptb.de ntp2.ptb.de
Und das liegt im (eingeschränkten) Pfad der ip-up.local? Füge mal eine zusätzliche Zeile ein: echo $PATH > /tmp/ip-up.local.path Was Du daran erkennst: Falls die Datei /tmp/ip-up.local.path hinterher existiert, wurde ip-up.local ausgeführt. Anschließend schaust Du mal mit less in /tmp/ip-up.local.path. Dann wirst Du feststellen, dass man besser bei _allen_ Befehlen, die in einem Script stehen, den Pfad mit angibt ;-)
[...]
Die Zeit wird aber trotzdem nicht synchronisiert. Wenn ich den Eintrag "rcpersonal-firewall start" rausnehme und nach dem Verbindungsaufbau ein "rcpersonal-firewall status" mache, wird gemeldet, dass die Firewall läuft. Es wird also kein Befehl ausgeführt. Wenn ich die Befehle per Hand eingebe, läuft alles.
siehe oben - eingeschränkter Pfad. Gib bei allen Befehlen den Pfad mit an und es sollte laufen. Gruß Christian Boltz -- Registrierter Linux-Nutzer #239431 Linux - life is too short for reboots.
Am Donnerstag, 16. Mai 2002 00:53 schrieb Christian Boltz:
Hallo Christoph, hallo Leute,
Am Dienstag, 15. Mai 2001 18:08 schrieb Christoph Strins:
Am Dienstag, 14. Mai 2002 23:55 schrieb Christian Boltz:
Was Wunder, die ip-up wurde wohl beim Update überschrieben. /etc/ppp/ip-up.local (ich hoffe, der Pfad stimmt noch für SuSE 8.0) sollte Dir länger erhalten bleiben ;-)
Ich habe mir jetzt die ip-up.local mit folgendem Inhalt angelegt und ausführbar gemacht:
rcpersonal-firewall stop netdate ntp1.ptb.de ntp2.ptb.de
Und das liegt im (eingeschränkten) Pfad der ip-up.local?
[...]
Die Zeit wird aber trotzdem nicht synchronisiert. Wenn ich den Eintrag "rcpersonal-firewall start" rausnehme und nach dem Verbindungsaufbau ein "rcpersonal-firewall status" mache, wird gemeldet, dass die Firewall läuft. Es wird also kein Befehl ausgeführt. Wenn ich die Befehle per Hand eingebe, läuft alles.
siehe oben - eingeschränkter Pfad. Gib bei allen Befehlen den Pfad mit an und es sollte laufen.
Hab ich jetzt gemacht und es läuft. Danke. Christoph
Hallo Christoph, * Christoph Strins <chr.strins@gmx.de> schrieb am 14 Mai 2000:
Wo muss ich meinen netdate Eintrag zum Uhrzeit synchronisieren machen, der nachdem eine Internet-Verbindung aufgebaut worden ist, ausgeführt werden soll? Bis jetzt hatte ich ihn immer in der /etc/ppp/ip-up als letztes aufgeführt. Das klappt jetzt aber bei der SuSE 8.0 anscheinend nicht mehr.
Schau dir mal die /etc/ppp/poll.tcpip (ab Zeile 46) an. Prüfe auch ob ntpdate installiert ist und editiere die /etc/ntp.conf. Gruss, Uwe
participants (7)
-
B.Brodesser＠t-online.de -
Bastian Schern -
Christian Boltz -
Christoph Strins -
David Haller -
Thomas Templin -
Uwe Trust