---------- Original Message ---------------------------------- From: "Michael Kollender" fedoraliste@web.de Date: Fri, 27 May 2005 13:34:01 +0200
Holm wrote:
Wie kann ich denn das beheben ?
Mit ntpd, aber das willst du ja nicht.
Michael
Hallo Michael,
doch klar warum nicht ? Hab ich ja auch probiert zu installieren, aber wie gesagt, hat ja auch nicht funktioniert, weil wahrscheinlich noch andere Zeitserver laufen.
Wie bekomme ich denn jetzt mein System sauber, so daß z. Bsp. nur ntpd funktioniert ? Muss ich in irgendwelchen Systemdateienn erstmal nach einen anderen Zeitserver suchen ? Es ist ja nicht normal, daß meine Zeit, wenn ich "date" eingebe, jetzt nach 5 Stunden , schon 1/2 Tag nachgeht.
thx und cya
Holm Kapschitzki
________________________________________________________________ Sent via the WebMail system at oleco.net
Am Fr, den 27.05.2005 schrieb Holm um 16:53:
doch klar warum nicht ? Hab ich ja auch probiert zu installieren, aber wie gesagt, hat ja auch nicht funktioniert, weil wahrscheinlich noch andere Zeitserver laufen.
Wie bekomme ich denn jetzt mein System sauber, so daß z. Bsp. nur ntpd funktioniert ? Muss ich in irgendwelchen Systemdateienn erstmal nach einen anderen Zeitserver suchen ? Es ist ja nicht normal, daß meine Zeit, wenn ich "date" eingebe, jetzt nach 5 Stunden , schon 1/2 Tag nachgeht.
Holm Kapschitzki
Du solltest damit beginnen, deine Prozessliste durchzusehen (ps axuwww) und den von dir installierten "ntpd dienst" (O-Ton gestrige Mail) sauber entfernen. Dann schaust du dir die Konfiguration des ntpd von FC3 genau an und passt sie deinen Wünschen gemäß an.
Alexander
Hallo Alexander Dalloz,
am Freitag, 27. Mai 2005 um 16:57 hast Du geschrieben:
Am Fr, den 27.05.2005 schrieb Holm um 16:53:
doch klar warum nicht ? Hab ich ja auch probiert zu installieren, aber wie gesagt, hat ja auch nicht funktioniert, weil wahrscheinlich noch andere Zeitserver laufen.
Wie bekomme ich denn jetzt mein System sauber, so daß z. Bsp. nur ntpd funktioniert ? Muss ich in irgendwelchen Systemdateienn erstmal nach einen anderen Zeitserver suchen ? Es ist ja nicht normal, daß meine Zeit, wenn ich "date" eingebe, jetzt nach 5 Stunden , schon 1/2 Tag nachgeht.
Holm Kapschitzki
Du solltest damit beginnen, deine Prozessliste durchzusehen (ps axuwww) und den von dir installierten "ntpd dienst" (O-Ton gestrige Mail) sauber entfernen. Dann schaust du dir die Konfiguration des ntpd von FC3 genau an und passt sie deinen Wünschen gemäß an.
Alexander
also mit "ps axuwww" kann ich leider überhaupt kein Prozess mehr entdecken, der mit Zeit zu tun hat:
Hier die Ausgabe:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.4 2572 532 ? S 13:50 0:02 init [5]
root 2 0.0 0.0 0 0 ? SN 13:50 0:00 [ksoftirqd/0] root 3 0.0 0.0 0 0 ? S< 1909 0:03 [events/0] root 4 0.0 0.0 0 0 ? S< 1909 0:00 [khelper] root 5 0.0 0.0 0 0 ? S< 1909 0:00 [kacpid] root 15 0.0 0.0 0 0 ? S< 1909 0:00 [kblockd/0] root 25 0.0 0.0 0 0 ? S 12:38 0:00 [pdflush] root 28 0.0 0.0 0 0 ? S< 12:38 0:00 [aio/0] root 16 0.0 0.0 0 0 ? S 1909 0:00 [khubd] root 27 0.1 0.0 0 0 ? S 12:38 0:17 [kswapd0] root 103 0.0 0.0 0 0 ? S 12:38 0:00 [kseriod] root 178 0.0 0.0 0 0 ? S< 12:38 0:00 [kmirrord/0] root 187 0.0 0.0 0 0 ? S 12:38 0:01 [kjournald] root 1124 0.0 0.3 2788 480 ? S<s 12:39 0:00 udevd root 1492 0.0 0.0 0 0 ? S 12:39 0:00 [kjournald] root 1841 0.0 0.7 3672 992 ? Ss 12:40 0:00 /sbin/dhclient -1 -q -cf /etc/dhclient-eth0.conf -lf /var/lib/dhcp/dhclient-eth0.leases -pf /var/ run/dhclient-eth0.pid eth0 root 1875 0.0 0.4 2596 548 ? Ss 12:40 0:00 syslogd -m 0 root 1879 0.0 0.3 1892 440 ? Ss 12:40 0:00 klogd -x rpc 1900 0.0 0.4 2692 564 ? Ss 12:40 0:00 portmap rpcuser 1920 0.0 0.5 1732 716 ? Ss 12:40 0:00 rpc.statd root 1953 0.0 0.4 2120 564 ? Ss 12:40 0:01 rpc.idmapd root 2016 0.1 0.4 3592 508 ? Ss 12:40 0:14 nifd -n nobody 2046 0.0 0.7 14052 988 ? Ssl 12:40 0:00 mDNSResponder root 2058 0.0 0.6 2896 804 ? S 12:40 0:00 /usr/sbin/smartd root 2068 0.0 0.4 2520 512 ? Ss 12:40 0:00 /usr/sbin/acpid root 2116 0.0 1.1 4424 1464 ? Ss 12:41 0:00 /usr/sbin/sshd root 2127 0.0 0.4 3452 612 ? Ss 12:41 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid root 2146 0.0 1.5 8432 2004 ? Ss 12:41 0:01 sendmail: accepti ng connections smmsp 2156 0.0 1.3 7364 1688 ? Ss 12:41 0:00 sendmail: Queue r unner@01:00:00 for /var/spool/clientmqueue root 2169 0.0 0.3 2888 396 ? Ss 12:41 0:00 gpm -m /dev/input /mice -t imps2 root 2179 0.0 0.5 4008 756 ? Ss 12:41 0:00 crond xfs 2205 0.0 0.7 4160 1000 ? Ss 12:41 0:00 xfs -droppriv -da emon daemon 2224 0.0 0.4 2960 564 ? Ss 12:41 0:00 /usr/sbin/atd dbus 2243 0.0 0.8 3104 1072 ? Ss 12:41 0:00 dbus-daemon-1 --s ystem root 2256 0.0 0.6 3444 760 ? Ss 12:41 0:00 cups-config-daemo n root 2267 0.0 2.1 6804 2724 ? Ss 12:41 0:04 hald root 2428 0.0 1.9 10928 2448 ? Ss 12:41 0:00 smbd -D root 2432 0.0 7.8 22088 9900 ? Ss 12:41 0:04 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 root 2438 0.0 1.3 7956 1768 ? Ss 12:41 0:00 nmbd -D root 2439 0.0 1.0 7812 1336 ? S 12:41 0:00 nmbd -D root 2456 0.0 0.9 5008 1208 ? S 12:41 0:00 /bin/sh /opt/lamp p/bin/mysqld_safe --datadir=/opt/lampp/var/mysql --pid-file=/opt/lampp/var/mysql /base.mnsu.local.pid nobody 2463 0.0 1.5 4764 2016 ? Ss 12:41 0:00 proftpd: (accepti ng connections) nobody 2484 0.0 0.4 2104 568 ? Ss 12:41 0:00 /usr/sbin/oidentd -u nobody -g nobody root 2486 0.0 1.8 10924 2344 ? S 12:41 0:00 smbd -D nobody 2495 0.0 4.0 25916 5156 ? Sl 12:41 0:00 /opt/lampp/sbin/m ysqld --basedir=/opt/lampp --datadir=/opt/lampp/var/mysql --user=nobody --pid-fi le=/opt/lampp/var/mysql/base.mnsu.local.pid --skip-locking --port=3306 --socket= /opt/lampp/var/mysql/mysql.sock nobody 2497 0.0 7.6 22032 9720 ? S 12:41 0:00 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 2498 0.0 10.2 23972 12908 ? S 12:41 0:06 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 2499 0.1 10.2 24084 12972 ? S 12:41 0:08 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 2500 0.1 10.3 24316 13108 ? S 12:41 0:11 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 2501 0.1 10.5 24328 13264 ? S 12:41 0:15 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 2502 0.0 10.2 24084 12928 ? S 12:41 0:06 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 root 2505 0.0 3.5 7448 4436 ? Ss 12:41 0:00 /usr/bin/perl /us r/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf root 2511 0.0 0.3 2288 384 tty1 Ss+ 12:41 0:00 /sbin/mingetty tt y1 root 2512 0.0 0.3 2544 384 tty2 Ss+ 12:41 0:00 /sbin/mingetty tt y2 root 2513 0.0 0.3 2516 388 tty3 Ss+ 12:41 0:00 /sbin/mingetty tt y3 root 2514 0.0 0.3 3136 384 tty4 Ss+ 12:41 0:00 /sbin/mingetty tt y4 root 2515 0.0 0.3 3020 388 tty5 Ss+ 12:41 0:00 /sbin/mingetty tt y5 root 2516 0.0 0.3 1476 388 tty6 Ss+ 12:41 0:00 /sbin/mingetty tt y6 root 2517 0.0 1.8 11024 2280 ? Ss 12:41 0:00 /usr/bin/gdm-bina ry -nodaemon root 2782 0.0 0.0 0 0 ? S 12:41 0:01 [pdflush] root 2943 0.0 2.2 11652 2832 ? S 12:41 0:00 /usr/bin/gdm-bina ry -nodaemon root 2948 0.6 6.8 53584 8708 ? S 12:41 0:55 /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 gdm 3017 0.3 6.6 20028 8448 ? Ss 12:42 0:32 /usr/bin/gdmgreet er antorox 3103 0.0 1.4 4128 1824 ? S 12:51 0:03 /home/antorox/Unr eal3.2/src/ircd root 3105 3.7 2.9 11736 3752 ? S 12:52 5:04 smbd -D nobody 3113 0.1 10.5 24364 13360 ? S 12:53 0:09 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 3173 0.0 10.1 24008 12860 ? S 12:56 0:06 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 3226 0.0 10.1 23784 12804 ? S 13:38 0:02 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 3227 0.0 10.2 24004 12956 ? S 13:38 0:03 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 nobody 3228 0.0 10.1 23820 12864 ? S 13:38 0:01 /opt/lampp/bin/ht tpd -k start -DSSL -DPHP5 root 3360 0.0 1.7 8852 2212 ? SNs 13:46 0:00 cupsd root 29203 0.0 2.7 11616 3440 ? S 14:56 0:00 smbd -D root 29208 0.1 2.7 11616 3520 ? S 15:03 0:00 smbd -D root 29209 3.8 1.6 6712 2056 ? Ss 15:08 0:00 sshd: root@pts/1 root 29211 5.5 1.1 5112 1416 pts/1 Ss 15:08 0:00 -bash root 29243 0.0 0.5 3152 744 pts/1 R+ 15:08 0:00 ps axuwww
------------
Mit date bekomme ich jetzt folgende Ausgabe: Fr Mai 27 15:09:58 CEST 2005
Mit "cat /etc/sysconfig/clock": ZONE="Europe/Berlin" UTC=false ARC=false
Mit "hwclock --show --utc": Fr 27 Mai 2005 22:19:18 CEST -0.135079 Sekunden
Da stellt sich also die Hardwareuhr vor und die Systemzeit geht nach, obwohl ich heute Mittag mit: hwclock --systohc
alles synchronisiert habe.
Wo ist denn die Konfiguration des ntpd von FC3 genau ? Es gab glaube ich auch einen Befehl sich alle Verzeichnisse, wo etwas installiert ist anzeigen zu lassen? Muss ich nicht in der init.d oder in irgendeiner anderen Datei suchen, ob irgendwo doch noch was gestartet wird ?
Meinen selbst installierten "ntpd dienst" werde ich mit yum apt2get deinstallieren, aber wie gesagt das Problem trat ja schon vorher auf.
Hallo Alexander,
sorry... aber ich glaube Du weisst nicht wirklich was Du da tust?! Bemuehe Dich doch bitte erstmal darum die Doku zu Deinem Betriebssystem zu lesen und befasse Dich mit den relevanten Dingen die Du benutzen willst. Zeitabgleich mit ntpd unter fc3 ist wirklich einfach...
Gruss,
Martin
Wo ist denn die Konfiguration des ntpd von FC3 genau ? Es gab glaube ich auch einen Befehl sich alle Verzeichnisse, wo etwas installiert ist anzeigen zu lassen? Muss ich nicht in der init.d oder in irgendeiner anderen Datei suchen, ob irgendwo doch noch was gestartet wird ?
Meinen selbst installierten "ntpd dienst" werde ich mit yum apt2get deinstallieren, aber wie gesagt das Problem trat ja schon vorher auf.
Am Fr, den 27.05.2005 schrieb Holm um 20:29:
Hallo Holm!
also mit "ps axuwww" kann ich leider überhaupt kein Prozess mehr entdecken, der mit Zeit zu tun hat:
Ja, sehe ich auch nicht. Allerdings sehe ich, dass X läuft, was du ja in deiner ersten Mail gestern noch so beschrieben hast: "Mein fc3 Server ist nur über remote mittels konsole zu bedienen. Eine grafische Oberfläche fehlt und will ich auch nicht ;-)"
Mit date bekomme ich jetzt folgende Ausgabe: Fr Mai 27 15:09:58 CEST 2005
Offenbar geht die Uhr nach dem Mond. Ist vielleicht ein Hardwareproblem.
Mit "cat /etc/sysconfig/clock": ZONE="Europe/Berlin" UTC=false ARC=false
Mit "hwclock --show --utc": Fr 27 Mai 2005 22:19:18 CEST -0.135079 Sekunden
Da stellt sich also die Hardwareuhr vor und die Systemzeit geht nach, obwohl ich heute Mittag mit: hwclock --systohc
alles synchronisiert habe.
Ist das ein echter Rechner oder "was Virtuelles"?
Wo ist denn die Konfiguration des ntpd von FC3 genau ? Es gab glaube ich auch einen Befehl sich alle Verzeichnisse, wo etwas installiert ist anzeigen zu lassen? Muss ich nicht in der init.d oder in irgendeiner anderen Datei suchen, ob irgendwo doch noch was gestartet wird ?
Du meinst sicher den Befehl "locate". Mit "chkconfig" kannst du Red Hat / Fedora konforme Dienste anzeigen und ihren Start/Stop kontrollieren.
Meinen selbst installierten "ntpd dienst" werde ich mit yum apt2get deinstallieren, aber wie gesagt das Problem trat ja schon vorher auf.
FC3 kommt mit dem "ntp" Paket, dessen Konfiguration befindet sich in /etc/ntp.conf und unterhalb /etc/ntp/. Ich würde pool.ntp.org verwenden
"nptq -p" zeigt dir auch die zeitlichen Abweichungen an und du solltest Probleme mit der Zeit und ntpd im syslog sehen.
Da du offenbar sowieso in runlevel 5 bootest und X zur Verfügung hast, rate ich, dass du dich per "ssh -Y holm@server" einloggst, gefolgt von "sudo system-config-date" die Zeit Konfiguration vorzunehmen. Wenn du kein X laufen lassen möchtest - was bei einem Server durchaus Sinn macht -, dann ändere in der /etc/inittab den default runlevel auf 3 (an Stelle von 5) und wechsle ohne reboot per "init 3" in den non-X Modus.
Alexander
Hallo Martin Schmiderer,
das schwierige an den vielen Informationen, die ich mir heraussuche per Internet, ist, das solche nicht immer im richtigen Zusammenhang stehen. Deshhalb ist es für einen Anfänger unter Linux, wie mich schon recht schwierig.
Hallo Alexander Dalloz,
erstmal wirklich Danke für Deine detallierten Erklärungen. Das muss ich erstmal alles abarbeiten. Ich werde das Ergebnis hier mitteilen.
Ich betreibe einen sogenannten "wollmilchserver" @home hinter einem ipcop (router/fw) per dynamischer ip Anbindung. Da laufen irc server /lampp/ bouncer, sendmail etc .. und samba als dc und ich stelle zu Testzwecken webzugänge und webspace zur Verfügung, rein privater Natur.
am Freitag, 27. Mai 2005 um 21:15 hast Du geschrieben:
Am Fr, den 27.05.2005 schrieb Holm um 20:29:
Hallo Holm!
also mit "ps axuwww" kann ich leider überhaupt kein Prozess mehr entdecken, der mit Zeit zu tun hat:
Ja, sehe ich auch nicht. Allerdings sehe ich, dass X läuft, was du ja in deiner ersten Mail gestern noch so beschrieben hast: "Mein fc3 Server ist nur über remote mittels konsole zu bedienen. Eine grafische Oberfläche fehlt und will ich auch nicht ;-)"
Mit date bekomme ich jetzt folgende Ausgabe: Fr Mai 27 15:09:58 CEST 2005
Offenbar geht die Uhr nach dem Mond. Ist vielleicht ein Hardwareproblem.
Mit "cat /etc/sysconfig/clock": ZONE="Europe/Berlin" UTC=false ARC=false
Mit "hwclock --show --utc": Fr 27 Mai 2005 22:19:18 CEST -0.135079 Sekunden
Da stellt sich also die Hardwareuhr vor und die Systemzeit geht nach, obwohl ich heute Mittag mit: hwclock --systohc
alles synchronisiert habe.
Ist das ein echter Rechner oder "was Virtuelles"?
Wo ist denn die Konfiguration des ntpd von FC3 genau ? Es gab glaube ich auch einen Befehl sich alle Verzeichnisse, wo etwas installiert ist anzeigen zu lassen? Muss ich nicht in der init.d oder in irgendeiner anderen Datei suchen, ob irgendwo doch noch was gestartet wird ?
Du meinst sicher den Befehl "locate". Mit "chkconfig" kannst du Red Hat / Fedora konforme Dienste anzeigen und ihren Start/Stop kontrollieren.
Meinen selbst installierten "ntpd dienst" werde ich mit yum apt2get deinstallieren, aber wie gesagt das Problem trat ja schon vorher auf.
FC3 kommt mit dem "ntp" Paket, dessen Konfiguration befindet sich in /etc/ntp.conf und unterhalb /etc/ntp/. Ich würde pool.ntp.org verwenden
"nptq -p" zeigt dir auch die zeitlichen Abweichungen an und du solltest Probleme mit der Zeit und ntpd im syslog sehen.
Da du offenbar sowieso in runlevel 5 bootest und X zur Verfügung hast, rate ich, dass du dich per "ssh -Y holm@server" einloggst, gefolgt von "sudo system-config-date" die Zeit Konfiguration vorzunehmen. Wenn du kein X laufen lassen möchtest - was bei einem Server durchaus Sinn macht -, dann ändere in der /etc/inittab den default runlevel auf 3 (an Stelle von 5) und wechsle ohne reboot per "init 3" in den non-X Modus.
Alexander
Hallo Alexander Dalloz,
also ich habe jetzt erstmal auf init 3 umgestellt und mit yum remove npd den npd entfernt, um eigentlich alles zu entfernen was mit Zeitserver zu tun hat, um es dann erneut und sauber zu installieren.
Dann bin ich so vorgegangen:
1. Stelle die richtige Zeitzone ein. 2. Setze die Systemzeit wie oben beschrieben. ('date -s "YYYY-MM-TT hh:mm:ss"') 3. Lösche die Datei '/etc/adjtime'. 4. Setze die RTC mit: 'hwclock --debug --systohc --utc'. (Läuft die RTC auf lokaler Zeit, verwende statt '--utc' die Option '--localtime'). 5. Wiederhole Punkt 3 und 4.
Dann habe ich locate npd und locate ntpd ausgeführt. Das ist das Ergebis:
[root@base ~]# locate ntpd /etc/rc.d/init.d/ntpd /etc/rc.d/rc2.d/K74ntpd /etc/rc.d/rc4.d/K74ntpd /etc/rc.d/rc5.d/K74ntpd /etc/rc.d/rc3.d/K74ntpd /etc/rc.d/rc6.d/K74ntpd /etc/rc.d/rc1.d/K74ntpd /etc/rc.d/rc0.d/K74ntpd /etc/sysconfig/ntpd /usr/share/man/man1/ntpdc.1.gz /usr/share/man/man1/ntpdate.1.gz /usr/share/man/man1/ntpd.1.gz /usr/share/doc/ntp-4.2.0.a.20040617/ntpd.html /usr/share/doc/ntp-4.2.0.a.20040617/ntpdate.html.droproot /usr/share/doc/ntp-4.2.0.a.20040617/ntpdc.html /usr/share/doc/ntp-4.2.0.a.20040617/ntpdsim.html /usr/share/doc/ntp-4.2.0.a.20040617/ntpdate.html /usr/share/doc/ntp-4.2.0.a.20040617/build/hints/solaris.xtra.S99ntpd /usr/sbin/ntpdate /usr/sbin/ntpdc /usr/sbin/ntpd
Bei locate ntp kommt ein langer Verzeichnisbaum.
..... ..... ..... /usr/share/doc/ntp-4.2.0.a.20040617/build/hints/parse /usr/share/doc/ntp-4.2.0.a.20040617/build/hints/solaris.xtra.4023118 /usr/share/doc/ntp-4.2.0.a.20040617/build/hints/linux /usr/share/doc/ntp-4.2.0.a.20040617/build/hints/solaris.xtra.patchfreq /usr/share/doc/ntp-4.2.0.a.20040617/build/hints/decosf2 /usr/share/doc/ntp-4.2.0.a.20040617/build/hints/sco.html /usr/share/doc/ntp-4.2.0.a.20040617/build/hints /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts/links11.txt /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts/links7.txt /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts/links8.txt /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts/links9.txt /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts/footer.txt /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts/style.css /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts/links12.txt /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts/links10.txt /usr/share/doc/ntp-4.2.0.a.20040617/build/scripts /usr/share/doc/ntp-4.2.0.a.20040617/build/patches.html /usr/share/doc/ntp-4.2.0.a.20040617/build /usr/share/doc/ntp-4.2.0.a.20040617 /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd/smbdes.c /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd/mkntpwd.c /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd/getopt.h /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd/getopt.c /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd/md4.c /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd/mkntpwd.h /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd/Makefile /usr/share/doc/samba-3.0.8/LDAP/smbldap-tools/mkntpwd /usr/share/emacs/21.3/lisp/gnus/nntp.elc /usr/sbin/chkfontpath /usr/sbin/ntpdate /usr/sbin/ntpdc /usr/sbin/ntptrace /usr/sbin/ntpq /usr/sbin/ntp-wait /usr/sbin/ntp-keygen /usr/sbin/ntpd /usr/sbin/ntptime /usr/bin/ntpstat
Wie entferne ich denn das alles, so daß ich einfach npd als rpm nochmal sauber draufziehen kann ? ich dachte ich hätte was gelöscht, aber mit locate ist ja noch alles da. Bloss unter /etc/ntp.conf und unterhalb /etc/ntp/ ist halt alles weg, weil ich ja auch npd deinstalliert habe.
Mit freundlichen Grüßen Holm Kapschitzki mailto:holm@oleco.net
On Sat, 28 May 2005 00:02:26 +0200, Holm Kapschitzki wrote:
Hallo Alexander Dalloz,
also ich habe jetzt erstmal auf init 3 umgestellt und mit yum remove npd den npd entfernt, um eigentlich alles zu entfernen was mit Zeitserver zu tun hat,
Das wäre "rpm --erase ntp" gewesen. Ein "rpm --query ntp" sollte das Paket danach nicht anzeigen.
Aber ein einfaches Abschalten (ohne reboot!) reicht doch bereits: chkconfig ntp off ; service ntp stop
Hallo Michael Schwendt,
am Samstag, 28. Mai 2005 um 00:23 schrieben Sie:
On Sat, 28 May 2005 00:02:26 +0200, Holm Kapschitzki wrote:
Hallo Alexander Dalloz,
also ich habe jetzt erstmal auf init 3 umgestellt und mit yum remove npd den npd entfernt, um eigentlich alles zu entfernen was mit Zeitserver zu tun hat,
Das wäre "rpm --erase ntp" gewesen. Ein "rpm --query ntp" sollte das Paket danach nicht anzeigen.
Aber ein einfaches Abschalten (ohne reboot!) reicht doch bereits: chkconfig ntp off ; service ntp stop
ok, das mit dem deinstallieren ist wohl eine Windows Krankheit.
Wenn date nach Einstellung der Systemzeit, 15 min später falsch läuft und ich mit "ps axuwww" auch kein Dienst angezeigt bekomme, dann kann also im Hintergrund keine automatische Zeiteinstellung mehr stattfinden, also auch kein Programm laufen ?
Dann muss es ja ein Hardwareproblem sein ?
Mit date lässt man sich doch die Sytemzeit anzeigen und die wird doch beim booten eigentlich aus der rtc ausgelesen. Ich kann das nicht verstehen, wie soll man da den Fehler finden, wenn es ein Hardwareproblem ist.
Kann ich denn das alles was ich mit locate npd / nptd finde alles löschen ? Ich will von vorne installieren, den npd ...
cya und thx
Am Sa, den 28.05.2005 schrieb Holm Kapschitzki um 0:02:
Hallo Alexander Dalloz,
Alexander reicht :)
also ich habe jetzt erstmal auf init 3 umgestellt und mit yum remove npd den npd entfernt, um eigentlich alles zu entfernen was mit Zeitserver zu tun hat, um es dann erneut und sauber zu installieren.
rpm -ql ntp
Dann mit "rpm -e" oder "yum remove" entfernen und anschließend kontrollieren, ob noch eine modifizierte Konfigurationsdatei übrig geblieben ist.
Dann bin ich so vorgegangen:
- Stelle die richtige Zeitzone ein.
- Setze die Systemzeit wie oben beschrieben. ('date -s "YYYY-MM-TT hh:mm:ss"')
- Lösche die Datei '/etc/adjtime'.
- Setze die RTC mit: 'hwclock --debug --systohc --utc'. (Läuft die RTC auf lokaler Zeit, verwende statt '--utc' die Option '--localtime').
- Wiederhole Punkt 3 und 4.
Ich verstehe insbesondere Punkt 3 und 5 nicht.
Dann habe ich locate npd und locate ntpd ausgeführt. Das ist das Ergebis:
[root@base ~]# locate ntpd
Bei locate ntp kommt ein langer Verzeichnisbaum.
Wie entferne ich denn das alles, so daß ich einfach npd als rpm nochmal sauber draufziehen kann ? ich dachte ich hätte was gelöscht, aber mit locate ist ja noch alles da. Bloss unter /etc/ntp.conf und unterhalb /etc/ntp/ ist halt alles weg, weil ich ja auch npd deinstalliert habe.
Holm Kapschitzki
"locate" führt keine Suche in Echtzeit aus, sondern schaut in einer Datenbank nach. Jene wird regelmäßig automatisch per cronjob mit Inhalt gefüttert. Du bekommst bei deinen Kommandos also nicht den Stand, der aktuell für dein System gilt. "/etc/cron.daily/slocate.cron" auszuführen würde die locate Datenbank auf aktuellen Stand bringen.
Alexander
Hallo Alexander,
am Samstag, 28. Mai 2005 um 00:26 hast Du geschrieben:
Dann bin ich so vorgegangen:
- Stelle die richtige Zeitzone ein.
- Setze die Systemzeit wie oben beschrieben. ('date -s "YYYY-MM-TT hh:mm:ss"')
- Lösche die Datei '/etc/adjtime'.
- Setze die RTC mit: 'hwclock --debug --systohc --utc'. (Läuft die RTC
auf lokaler Zeit, verwende statt '--utc' die Option '--localtime'). 5. Wiederhole Punkt 3 und 4.
Ich verstehe insbesondere Punkt 3 und 5 nicht.
Ich hab mich da durchgelesen, aber so richtig schlau werd ich leider auch nicht drauss. Muss mit der Berechnung der Abweichung für den nächsten Abgleich zu tun haben :) ..
http://www.linuxinfozentrum.ch/chrony.php
Danke, das mit locate hab ich verstanden.
Also ist kja echt nicht normal , dass man mit date die Systemzeit einstellt,kein Dienst läuft und dann 15 Minuten später die Systemzeit um 20 Minuten nachgeht. Wie soll ich das Hardwareproblem bloss finden ?
Holm Kapschitzki wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ganz andere Baustelle! Alexander hat dir doch beschrieben wie du vorgehen kannst. Gefiel dir die Antwort nicht oder warum fängst du was neues an?
Vielleicht ist dein Motherboard auch einfach Schrott, zu alt, Quarz defekt, Batterie am Ende oder was weiß ich. Entscheide dich erstmal was du willst. Wenn du ntp willst lese und verstehe www.ntp.org
Michael
Hallo Michael Kollender,
am Samstag, 28. Mai 2005 um 10:07 hast Du geschrieben:
ganz andere Baustelle! Alexander hat dir doch beschrieben wie du vorgehen kannst. Gefiel dir die Antwort nicht oder warum fängst du was neues an?
Vielleicht ist dein Motherboard auch einfach Schrott, zu alt, Quarz defekt, Batterie am Ende oder was weiß ich. Entscheide dich erstmal was du willst. Wenn du ntp willst lese und verstehe www.ntp.org
Michael
Ich habe mich jetzt die ganze Nacht hingesetzt und wahrscheinlich einiges verstanden und auch den ntp konfiguriert. Ist ja wirklich nicht schwer. Dann muss ich wohl aufgeben. Bloss ist es hart zu verstehen, daßmein Motherboard Schrott ist, wenn alles andere sauber drauf läuft.
Leider Gottes läuft meine Bios Zeit in 12 h 30 Minuten vor. Das ist ja noch zu ertragen. Aber das ich mit Date eine Zeit einstelle und die gesamte Systemzeit zu langsam läuft, daß es gleich wieder nach 5 Minuten um 10 Minuten zu langsam ist, ist mir leider das totale Rätsel, daja anscheinend keine weiteren Dienste laufen, hätte ja sein können die Zeit versucht sich irgendwie anzupassen, durch irgendeinen Dienst den ich übersehen habe.
Ich habe aber auf meinem router keinen Zeitserver laufen oder sowas.
Bleibt wohl nur ein cronjob jede Minute ?
Wie schalt ich eigentlich acpi ab, über remote mittels Konsole. Habe gelsen das acpi auch Probleme bereiten kann.
Ich gehe weiter davon aus, das ja kein andere Dienst, der die Zeit abgleicht läuft. auch. Wir haben doch hier alles auseinandergenommen.
Am Sa, den 28.05.2005 schrieb Holm Kapschitzki um 10:29:
Bleibt wohl nur ein cronjob jede Minute ?
Der ntpd schafft die Synchronisation nicht?
Wie schalt ich eigentlich acpi ab, über remote mittels Konsole. Habe gelsen das acpi auch Probleme bereiten kann.
Als Kernel Parameter in der /etc/grub.conf in der Kernel Zeile anhängen: acpi=off
Alexander
Hallo Alexander,
am Samstag, 28. Mai 2005 um 13:35 hast Du geschrieben:
Bleibt wohl nur ein cronjob jede Minute ?
Der ntpd schafft die Synchronisation nicht?
Nein, noch nicht mal wenn ich den Service stoppe, ntpdate ptbtime1.ptb.de ausführe und anschlißend ntp wieder starte.
Wie leider zu erkennen ist wird die offset Zeit nur gösser.
[root@base ~]# ntpq -c peers remote refid st t when poll reach delay offset jitter ============================================================================== 80-28-46-78.ads 130.206.3.166 2 u 26 64 377 45.881 1093133 548044.
[root@base ~]# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 80.28.46.78 130.206.3.166 2 u 13 64 377 44.898 2579674 669040. [root@base ~]# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== 80.28.46.78 130.206.3.166 2 u 54 64 377 45.887 2942202 555509.
Meine /var/log/messages bringt zum bsp. mal das:
May 28 11:49:16 base ntpd[3101]: ntpd 4.2.0a@1.1190-r Mon Oct 11 09:10:20 EDT 2004 (1) May 28 11:49:16 base ntpd[3101]: precision = 7.000 usec May 28 11:49:16 base ntpd[3101]: Listening on interface wildcard, 0.0.0.0#123 May 28 11:49:16 base ntpd[3101]: Listening on interface wildcard, ::#123 May 28 11:49:16 base ntpd[3101]: Listening on interface lo, 127.0.0.1#123 May 28 11:49:16 base ntpd[3101]: Listening on interface eth0, 192.168.0.151#123 May 28 11:49:16 base ntpd[3101]: kernel time sync status 0040 May 28 11:49:16 base ntpd: Starten von ntpd succeeded May 28 11:49:16 base kernel: audit(1117273756.356:0): avc: denied { read } for pid=3101 exe=/usr/sbin/ntpd name=mtab dev=dm-0 ino=524113 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:etc_runtime_t tclass=file May 28 11:49:16 base kernel: audit(1117273756.357:0): avc: denied { read } for pid=3101 exe=/usr/sbin/ntpd name=meminfo dev=proc ino=-268435454 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:proc_t tclass=file May 28 11:53:35 base ntpd[3101]: ntpd exiting on signal 15
Ich denke die Zeitspanne wird wohl zu gross sein, für ein funktionieren. In meiner Firewall hab ich Port 123 für udp freigeschaltet.
Wie schalt ich eigentlich acpi ab, über remote mittels Konsole. Habe gelsen das acpi auch Probleme bereiten kann.
Als Kernel Parameter in der /etc/grub.conf in der Kernel Zeile anhängen: acpi=off
Alexander
Danke.
Eine altersschwache Batterie auf dem Motherboard kann die Hardware (BIOS) Uhr beeinflussen. Dass der Quarz defekt ist, halte ich eher für recht unwahrscheinlich, eher ist ein Elko am Lebenszeitende (gewölbter oder gar an den Sollbruchstellen gerissener Deckel).
Ich kann das leider nicht überprüfen, glaubs aber auch, daß ein Bauteil defket ist.Das einzige, was ich noch machen kann ist mal ne andere distri probieren.
Gruss Holm
mailto:holm@oleco.net
Holm Kapschitzki wrote:
[root@base ~]# ntpq -c peers remote refid st t when poll reach delay offset jitter ============================================================================== 80-28-46-78.ads 130.206.3.166 2 u 26 64 377 45.881 1093133 548044.
Hm, spanischer Server, Stratum 2,
Wie sieht deine ntp.conf aus?
Michael
Hallo Michael,
am Samstag, 28. Mai 2005 um 14:34 hast Du geschrieben:
Holm Kapschitzki wrote:
[root@base ~]# ntpq -c peers remote refid st t when poll reach delay offset jitter ============================================================================== 80-28-46-78.ads 130.206.3.166 2 u 26 64 377 45.881 1093133 548044.
Hm, spanischer Server, Stratum 2,
Wie sieht deine ntp.conf aus?
Das ist der Inhalt, hab aber schon alles mögliche probiert. Du kannst ja mal eine auf jeden Fall funktionierende posten:
#------ server 0.pool.ntp.org driftfile /etc/ntp.drift #------
Minimal würd ich sagen.
Aber ein Portscann verrät mir leider auch nichts gutes. Warum ist denn der Port 123 nicht offen ?
Starting nmap 3.70 ( http://www.insecure.org/nmap/ ) at 2005-05-28 12:50 CEST Interesting ports on base.mnsu.local (127.0.0.1): (The 1642 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open rpcbind 113/tcp open auth 139/tcp open netbios-ssn 443/tcp open https 445/tcp open microsoft-ds 631/tcp open ipp 1024/tcp open kdm 3306/tcp open mysql 6666/tcp open irc-serv 6667/tcp open irc 6668/tcp open irc 7000/tcp open afs3-fileserver 7001/tcp open afs3-callback 10000/tcp open snet-sensor-mgmt
Wie gesagt ich hab hier ne Abweichung der Systemzeit von 3 h in 3 h. Da muss wohl n Hardwaredefekt sein oder ne kernel sache. Von der distri Seite her hab ich aber keine Ahnung.
Gruss Holm
mailto:holm@oleco.net
On Sat, 28 May 2005 13:52:21 +0200, Holm Kapschitzki wrote:
May 28 11:49:16 base kernel: audit(1117273756.356:0): avc: denied { read } for pid=3101 exe=/usr/sbin/ntpd name=mtab dev=dm-0 ino=524113 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:etc_runtime_t tclass=file May 28 11:49:16 base kernel: audit(1117273756.357:0): avc: denied { read } for pid=3101 exe=/usr/sbin/ntpd name=meminfo dev=proc ino=-268435454 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:proc_t tclass=file
SELinux!
May 28 11:53:35 base ntpd[3101]: ntpd exiting on signal 15
Und hier terminiert er bereits wieder nach SIGTERM.
Hallo Michael,
am Samstag, 28. Mai 2005 um 15:08 hast Du geschrieben:
On Sat, 28 May 2005 13:52:21 +0200, Holm Kapschitzki wrote:
May 28 11:49:16 base kernel: audit(1117273756.356:0): avc: denied { read } for pid=3101 exe=/usr/sbin/ntpd name=mtab dev=dm-0 ino=524113 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:etc_runtime_t tclass=file May 28 11:49:16 base kernel: audit(1117273756.357:0): avc: denied { read } for pid=3101 exe=/usr/sbin/ntpd name=meminfo dev=proc ino=-268435454 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:proc_t tclass=file
SELinux!
Ich habe mal gegoogelt. Fedora Core 3 und Red Hat Enterprise Linux 4 haben doch SELinux standardmäßig. Muss man hier was updaten ?
Gruss Holm
mailto:holm@oleco.net
Holm Kapschitzki wrote:
Ich habe mal gegoogelt. Fedora Core 3 und Red Hat Enterprise Linux 4 haben doch SELinux standardmäßig. Muss man hier was updaten ?
/usr/sbin/sestatus -v
verrät dir ob SELinux läuft und auf
http://fedora.redhat.com/docs/selinux-faq-fc3/index.html
erfährst du wie du es abschaltest und manch anderes wissenwertes.
Michael
Hallo Alexander, Michael und an all die anderen die hier geholfen haben,
am Samstag, 28. Mai 2005 um 13:35 hat Alexander geschrieben:
Wie schalt ich eigentlich acpi ab, über remote mittels Konsole. Habe gelsen das acpi auch Probleme bereiten kann.
Als Kernel Parameter in der /etc/grub.conf in der Kernel Zeile anhängen: acpi=off
Ich habe das Problem damit lösen können. Neustart und die Systemzeit bleibt sauber auf die Sekunde genau. Ich hab schon Kopfschmerzen nach 48 h. Durch einen glücklichen Zufall bin ich heute Nacht durch Google darauf aufmerksam gemacht worden und es leider vor 1 h erst ausprobiert, daß acpi auch so ein Problem sein kann.
Nochmals Danke an Alle, habe durch das ganze Problem suchen, ne Menge von Euch gelernt.
Ich glaub der ntp Server ist nur noch ne Kleinigkeit. Das Grundproblem mit der Systemzeit hat sich ja gelöst. Und das war verdammt wichtig für meine so genannte "wollmilchsau".
am Samstag, 28. Mai 2005 um 13:35 hat Michael geschrieben:
Ich habe mal gegoogelt. Fedora Core 3 und Red Hat Enterprise Linux 4 haben doch SELinux standardmäßig. Muss man hier was updaten ?
/usr/sbin/sestatus -v
verrät dir ob SELinux läuft und auf
erfährst du wie du es abschaltest und manch anderes wissenwertes.
[root@base ~]# /usr/sbin/sestatus -v SELinux status: enabled
, aber das Problem ist ja jetzt gelöst.
Gruß Holm
mailto:holm@oleco.net
Am Sa, den 28.05.2005 schrieb Holm Kapschitzki um 16:16:
Wie schalt ich eigentlich acpi ab, über remote mittels Konsole. Habe gelsen das acpi auch Probleme bereiten kann.
Als Kernel Parameter in der /etc/grub.conf in der Kernel Zeile anhängen: acpi=off
Ich habe das Problem damit lösen können. Neustart und die Systemzeit bleibt sauber auf die Sekunde genau. Ich hab schon Kopfschmerzen nach 48 h. Durch einen glücklichen Zufall bin ich heute Nacht durch Google darauf aufmerksam gemacht worden und es leider vor 1 h erst ausprobiert, daß acpi auch so ein Problem sein kann.
Na das ist doch mal eine erfreuliche Nachricht. Hast du denn vorher (mit aktivem ACPI) per dmesg Meldungen sehen können, dass auf Grund von ACPI etwas nicht stimmt?
Ich glaub der ntp Server ist nur noch ne Kleinigkeit. Das Grundproblem mit der Systemzeit hat sich ja gelöst. Und das war verdammt wichtig für meine so genannte "wollmilchsau".
Auf jeden Fall solltest du dafür sorgen, dass du mit den Updates auf dem aktuellen Stand bist. Insbesondere was SELinux anbetrifft gab es einige Updates, die Probleme beseitigt haben. Wenn du also mit "yum update" z.B. alles auf dem neuesten Stand hast, solltest du mit "touch /.autorelabel" und anschließendem Reboot einmal Korrekturen durchführen. Denn etwas passte ja mit SELinux und ntpd nicht (die audit / avc Meldungen im syslog sind von Bedeutung).
Gruß Holm
Alexander
Hallo Alexander,
am Samstag, 28. Mai 2005 um 18:36 hast Du geschrieben:
Hast du denn vorher (mit aktivem ACPI) per dmesg Meldungen sehen können, dass auf Grund von ACPI etwas nicht stimmt?
Ich habe vor dem Neubooten kein dmesg durchgeführt. Unter npd hab ich jetzt auch n Sternchen und die Systemzeit ist seit 4 h stabil auf die Sekunde.
[root@base ~]# ntpq -pn remote refid st t when poll reach delay offset jitter ============================================================================== *80.33.107.110 130.206.130.95 3 u 2 128 377 160.205 0.752 50.485
Aber mir ist etwas anderes aufgefallen, wenn ich jetzt dmesg ausführe:
SELinux: initialized (dev hdb1, type vfat), uses genfs_contexts SELinux: initialized (dev hdd1, type vfat), uses genfs_contexts audit(1117294785.616:0): avc: denied { read } for pid=3135 exe=/usr/sbin/ntpd name=mtab dev=dm-0 ino=524112 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:etc_runtime_t tclass=file audit(1117294785.634:0): avc: denied { read } for pid=3135 exe=/usr/sbin/ntpd name=meminfo dev=proc ino=-268435454 scontext=root:system_r:ntpd_t tcontext=system_u:object_r:proc_t tclass=file loop: loaded (max 8 devices)
und unter /var/log/messages/:
May 28 18:39:48 base ntpd[3135]: can't open /etc/ntp.drift.TEMP: Permission denied
Auf jeden Fall solltest du dafür sorgen, dass du mit den Updates auf dem aktuellen Stand bist. Insbesondere was SELinux anbetrifft gab es einige Updates, die Probleme beseitigt haben. Wenn du also mit "yum update" z.B. alles auf dem neuesten Stand hast, solltest du mit "touch /.autorelabel" und anschließendem Reboot einmal Korrekturen durchführen. Denn etwas passte ja mit SELinux und ntpd nicht (die audit / avc Meldungen im syslog sind von Bedeutung).
Ich führe gerade yum update aus und hätte mal noch eine Frage zu SELinux:
Muss ich nach yum update in der Konsole einfach nur "touch /.autorelabel" ausführen,odermich ich mich nach den Hinweisen richten:
http://fedora.jp/datapool/fedora-docs/selinux-faq-en/
How do I switch the policy I'm currently using?
Following is the manual procedure: 1. Edit /etc/selinux/config and change the type of policy to SELINUXTYPE=policyname. 2. To ensure that you can return from a reboot, set the mode to SELINUX=permissive. This way SELinux will be running under the correct policy, but will let you login if there is a problem such as incorrect file context labeling. 3. Tell the init scripts to relabel the system on reboot with the command touch /.autorelabel. 4. Reboot the system. A clean restart under the new policy allows all system processes to be started in the proper context, and reveals any problems in the policy change. 5. Confirm your changes took effect with the command sestatus -v. With the new system running in permissive mode, check /var/log/messages for avc: denied messages. These may indicate a problem that needs to be solved for the system to run without trouble under the new policy. 6. When you are satisfied that the system runs stable under the new policy, enable enforcing by changing SELINUX=enforcing. You can either reboot or run setenforce 1 to turn enforcing on in real time.
zu Punkt 1: SELINUXTYPE=policyname
Soll man hier wirklich policename reinschreiben ?
zu Punkt 2:
Wo setz ich denn den Mode ?
WEnn die Fragen geklärt wären, dann müsste ich doch nach yumupdate einfach rebooten und dann die Schritte ausführen ?
Am Sa, den 28.05.2005 schrieb Holm Kapschitzki um 20:19:
Ich führe gerade yum update aus und hätte mal noch eine Frage zu SELinux:
Muss ich nach yum update in der Konsole einfach nur "touch /.autorelabel" ausführen,odermich ich mich nach den Hinweisen richten:
http://fedora.jp/datapool/fedora-docs/selinux-faq-en/
How do I switch the policy I'm currently using?
Following is the manual procedure:
Edit /etc/selinux/config and change the type of policy to SELINUXTYPE=policyname. 2. To ensure that you can return from a reboot, set the mode to SELINUX=permissive. This way SELinux will be running under the correct policy, but will let you login if there is a problem such as incorrect file context labeling. 3. Tell the init scripts to relabel the system on reboot with the command touch /.autorelabel. 4. Reboot the system. A clean restart under the new policy allows all system processes to be started in the proper context, and reveals any problems in the policy change. 5. Confirm your changes took effect with the command sestatus -v. With the new system running in permissive mode, check /var/log/messages for avc: denied messages. These may indicate a problem that needs to be solved for the system to run without trouble under the new policy. 6. When you are satisfied that the system runs stable under the new policy, enable enforcing by changing SELINUX=enforcing. You can either reboot or run setenforce 1 to turn enforcing on in real time.
zu Punkt 1: SELINUXTYPE=policyname
Soll man hier wirklich policename reinschreiben ?
Nein, das soll einen Platzhalter in der Doku darstellen.
zu Punkt 2:
Wo setz ich denn den Mode ?
Schau mal in
/etc/sysconfig/selinux
WEnn die Fragen geklärt wären, dann müsste ich doch nach yumupdate einfach rebooten und dann die Schritte ausführen ?
Je nachdem, was das "yum update" bei dir alles updated, kann ein Reboot nicht schaden. Beachte bitte Meldungen während des Updates, wo neue Files als *.rpmnew angelegt werden und damit existente Dateien nicht einfach überschreiben. Gerade bei den SELinux policies solltest du mit den *.rpmnew die Gleichnamigen ohne Suffix ersetzen.
Alexander
Hallo Alexander,
am Samstag, 28. Mai 2005 um 20:38 hast Du geschrieben:
WEnn die Fragen geklärt wären, dann müsste ich doch nach yumupdate einfach rebooten und dann die Schritte ausführen ?
Je nachdem, was das "yum update" bei dir alles updated, kann ein Reboot nicht schaden. Beachte bitte Meldungen während des Updates, wo neue Files als *.rpmnew angelegt werden und damit existente Dateien nicht einfach überschreiben. Gerade bei den SELinux policies solltest du mit den *.rpmnew die Gleichnamigen ohne Suffix ersetzen.
Auf die Meldungen habe ich nicht geschaut während des Updates. Kann man sich die denn nochmal anschauen? Ich finde bloss /var/log/yum.log oder /var/log/messages.
Das heisst also ich muss die *.rpmnew in die gleichnamige Datei, die ja vorher schon auf dem System war, umbenennen und die alte löschen?
Ein locate selinux bringt mir leider keine *.rpmnew Datei zum umbenennen.
Gruß Holm
mailto:holm@oleco.net
Am Sa, den 28.05.2005 schrieb Holm Kapschitzki um 20:56:
Auf die Meldungen habe ich nicht geschaut während des Updates. Kann man sich die denn nochmal anschauen? Ich finde bloss /var/log/yum.log oder /var/log/messages.
Du kommst so an die Meldungen nicht mehr ran. Du wirst also nach *.rpmnew Dateien suchen müssen, z.B. per
find / -name "*.rpmnew"
Das heisst also ich muss die *.rpmnew in die gleichnamige Datei, die ja vorher schon auf dem System war, umbenennen und die alte löschen?
Zumindest bei den SELinux Policy Files solltest du die neuen benutzen
mv /pfad/zu/foo.rpmnew /pfad/zu/foo
Das überschreibt die existente Datei.
Ein locate selinux bringt mir leider keine *.rpmnew Datei zum umbenennen.
Die locate Datenbank ist auch aktuell mit dem Stand nach deinem Update?
Gruß Holm
Alexander
Hallo Alexander,
am Samstag, 28. Mai 2005 um 21:40 hast du geschrieben:
Ein locate selinux bringt mir leider keine *.rpmnew Datei zum umbenennen.
Die locate Datenbank ist auch aktuell mit dem Stand nach deinem Update?
Gruß Holm
Habe mit updatedb meine locate Datenbank auf den neuesten Stand gebracht und anschließend mit find / -name "*.rpmnew" gesucht.
Es wurde nur eine neue Datei gefunden:
/etc/vimrc.rpmnew
Hätte nochmal eine Frage zu SELinux. Meine conf sieht so aus:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=permissive #SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted
Ich habe mich nach der Anleitung gerichtet. Die durch mich veränderten Einträge nach dem Update von SELinux stehen oben in der conf.
How do I switch the policy I'm currently using?
Following is the manual procedure: 1. Edit /etc/selinux/config and change the type of policy to SELINUXTYPE=policyname. 2. To ensure that you can return from a reboot, set the mode to SELINUX=permissive. This way SELinux will be running under the correct policy, but will let you login if there is a problem such as incorrect file context labeling. 3. Tell the init scripts to relabel the system on reboot with the command touch /.autorelabel. 4. Reboot the system. A clean restart under the new policy allows all system processes to be started in the proper context, and reveals any problems in the policy change. 5. Confirm your changes took effect with the command sestatus -v. With the new system running in permissive mode, check /var/log/messages for avc: denied messages. These may indicate a problem that needs to be solved for the system to run without trouble under the new policy. 6. When you are satisfied that the system runs stable under the new policy, enable enforcing by changing SELINUX=enforcing. You can either reboot or run setenforce 1 to turn enforcing on in real time.
zu Punkt 1:
Ist denn das jetzt so richtig, daß ich unter "SELINUXTYPE=targeted" zu stehen habe nach dem SELinux Update ? Es heisst ja in der Anleitung "SELINUXTYPE=policyname". Ich verstehe das jetzt so, daß dort z. Bsp. "targeted" hineingehört nachdem ich das Update durchgeführt habe.
Ansonsten habe ich alle Schritte ausgeführt und das System rebootet. Anschließend habe ich überprüft, daß keine "denied-messages" auftreten und "SELINUX=" wieder auf "SELINUX=enforcing" gestellt.
Jetzt habe ich aber ein anderes Problem mit ntp. Er ist gestern sauber gelaufen und hat auch die "drift" Datei angelegt und einen Wert eingeschrieben. Dann habe ich den Dienst beendet, weil ich die Systemuhr mal alleine laufen lassen wollte. Heute morgen will ich mit "/etc/init.d/ntpd start" den Dienst starten und bekomme auch ein "ntpd starten: ....[ OK ]" in der Konsole angezeigt. Unter /var/log/messages steht das:
May 30 11:22:05 base ntpd[7143]: ntpd 4.2.0a@1.1190-r Mon Oct 11 09:10:20 EDT 2004 (1) May 30 11:22:05 base ntpd: Starten von ntpd succeeded May 30 11:22:06 base ntpd[7143]: precision = 1.000 usec May 30 11:22:06 base ntpd[7143]: Listening on interface wildcard, 0.0.0.0#123 May 30 11:22:06 base ntpd[7143]: Listening on interface wildcard, ::#123 May 30 11:22:06 base ntpd[7143]: Listening on interface lo, 127.0.0.1#123 May 30 11:22:06 base ntpd[7143]: Listening on interface eth0, 192.168.0.151#123 May 30 11:22:06 base ntpd[7143]: kernel time sync status 0040
Mache ich danach aber "ps ax" oder "ps axuwww" ein ist da kein Dienst gestartet. Auf ntp kann ich auch nicht zugreifen. Ich geh davon aus, der Dienst hat sich beendet.
[root@base ~]# ntpq -pn ntpq: read: Connection refused
Ich kann ja auch immer wieder "/etc/init.d/ntpd start" ausführen und bekomme immer ein "OK" angezeigt.
Also meine Bios Uhr und meine Systemuhr laufen sauber, daran kann es nicht liegen, daß ntp nicht arbeitet. Ich ba e allerdings eine dynamische IP, die sich 5.58 Uhr morgends ändert. Eigentlich sollte das für ntp kein Problem sein. Zumindest müsste er sich ja jetz starten lassen, bzw. ansprechbar sein.
Gruss Holm
mailto:holm@oleco.net
Am Mo, den 30.05.2005 schrieb Holm Kapschitzki um 11:31:
Habe mit updatedb meine locate Datenbank auf den neuesten Stand gebracht und anschließend mit find / -name "*.rpmnew" gesucht.
Wenn du die locate DB aktualisierst, dann kannst du ja auch deren gespeicherten Daten benutzen und musst nicht durch ein erneutes "find" noch mal suchen lassen :)
Es wurde nur eine neue Datei gefunden:
/etc/vimrc.rpmnew
Gut, dann hast du weniger Arbeit. Du kannst dann per
diff /etc/vimrc /etc/vimrc.rpmnew
schauen, was jeweils unterschiedlich ist. Wenn du - was ich mal annehme - nicht selber an der /etc/vimrc Anpassungen vorgenommen hast, dann kannst du einfach die bestehende vimrc mit der neuen überschreiben.
Hätte nochmal eine Frage zu SELinux. Meine conf sieht so aus:
# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=permissive
"permissive" ist eigentlich nur für den Zwecke des Debuggens und zur Analyse zum Schreiben angepasster policies da. Entweder "disabled" oder besser, weil SELinux ja ein Sicherheitsfeature ist, auf "enforcing" einstellen.
#SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted
Ich habe mich nach der Anleitung gerichtet. Die durch mich veränderten Einträge nach dem Update von SELinux stehen oben in der conf.
zu Punkt 1:
Ist denn das jetzt so richtig, daß ich unter "SELINUXTYPE=targeted" zu stehen habe nach dem SELinux Update? Es heisst ja in der Anleitung "SELINUXTYPE=policyname". Ich verstehe das jetzt so, daß dort z. Bsp. "targeted" hineingehört nachdem ich das Update durchgeführt habe.
Der "SELINUXTYPE" ist valide, ja. Es gibt die 2 policy Typen "targeted" (wirkt nur für bestimmte Netzwerk Dienste wie z.B. den Apache) und "strict" (greift systemweit).
Ansonsten habe ich alle Schritte ausgeführt und das System rebootet. Anschließend habe ich überprüft, daß keine "denied-messages" auftreten und "SELINUX=" wieder auf "SELINUX=enforcing" gestellt.
Das ist gut.
Jetzt habe ich aber ein anderes Problem mit ntp. Er ist gestern sauber gelaufen und hat auch die "drift" Datei angelegt und einen Wert eingeschrieben. Dann habe ich den Dienst beendet, weil ich die Systemuhr mal alleine laufen lassen wollte. Heute morgen will ich mit "/etc/init.d/ntpd start" den Dienst starten und bekomme auch ein "ntpd starten: ....[ OK ]" in der Konsole angezeigt. Unter /var/log/messages steht das:
May 30 11:22:05 base ntpd[7143]: ntpd 4.2.0a@1.1190-r Mon Oct 11 09:10:20 EDT 2004 (1) May 30 11:22:05 base ntpd: Starten von ntpd succeeded May 30 11:22:06 base ntpd[7143]: precision = 1.000 usec May 30 11:22:06 base ntpd[7143]: Listening on interface wildcard, 0.0.0.0#123 May 30 11:22:06 base ntpd[7143]: Listening on interface wildcard, ::#123 May 30 11:22:06 base ntpd[7143]: Listening on interface lo, 127.0.0.1#123 May 30 11:22:06 base ntpd[7143]: Listening on interface eth0, 192.168.0.151#123 May 30 11:22:06 base ntpd[7143]: kernel time sync status 0040
Sieht soweit korrekt aus.
Mache ich danach aber "ps ax" oder "ps axuwww" ein ist da kein Dienst gestartet. Auf ntp kann ich auch nicht zugreifen. Ich geh davon aus, der Dienst hat sich beendet.
Und keine Meldung dazu im syslog zu finden?
[root@base ~]# ntpq -pn ntpq: read: Connection refused
Ich kann ja auch immer wieder "/etc/init.d/ntpd start" ausführen und bekomme immer ein "OK" angezeigt.
Also meine Bios Uhr und meine Systemuhr laufen sauber, daran kann es nicht liegen, daß ntp nicht arbeitet. Ich ba e allerdings eine dynamische IP, die sich 5.58 Uhr morgends ändert. Eigentlich sollte das für ntp kein Problem sein. Zumindest müsste er sich ja jetz starten lassen, bzw. ansprechbar sein.
Möglicherweise betrifft dich:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154759
Gruss Holm
Alexander
Am Mo, den 30.05.2005 schrieb Alexander Dalloz um 16:42:
[root@base ~]# ntpq -pn ntpq: read: Connection refused
Ich kann ja auch immer wieder "/etc/init.d/ntpd start" ausführen und bekomme immer ein "OK" angezeigt.
Möglicherweise betrifft dich:
Alexander
Obiges Problem scheint Exec-shield verursacht zu sein. Ein neuer Kernel soll helfen:
%changelog * Wed Jun 1 2005 Dave Jones davej@redhat.com - Exec-shield improvements (Should fix #154759)
Alexander
Hallo Alexander,
am Mittwoch, 1. Juni 2005 um 21:59 hast Du geschrieben:
[root@base ~]# ntpq -pn ntpq: read: Connection refused
Ich kann ja auch immer wieder "/etc/init.d/ntpd start" ausführen und bekomme immer ein "OK" angezeigt.
Möglicherweise betrifft dich:
Alexander
Obiges Problem scheint Exec-shield verursacht zu sein. Ein neuer Kernel soll helfen:
%changelog
- Wed Jun 1 2005 Dave Jones davej@redhat.com
- Exec-shield improvements (Should fix #154759)
Alexander
Ich werd mal den Kernel updaten und dann berichten.
Tut er den Kernel nicht automatisch über yum updaten mit dem Befehl "yum update"? Das habe ich nämlich schon durchgeführt.
Gruss Holm
mailto:holm@oleco.net
Am Mi, den 01.06.2005 schrieb Holm Kapschitzki um 22:22:
Ich werd mal den Kernel updaten und dann berichten.
Tut er den Kernel nicht automatisch über yum updaten mit dem Befehl "yum update"? Das habe ich nämlich schon durchgeführt.
Gruss Holm
Der Kernel in Rede stehend ist noch in der "vor Test Phase":
http://people.redhat.com/davej/kernels/Fedora/FC3/
Alexander
Holm Kapschitzki schrieb:
Also meine Bios Uhr und meine Systemuhr laufen sauber, daran kann es nicht liegen, daß ntp nicht arbeitet. Ich ba e allerdings eine dynamische IP, die sich 5.58 Uhr morgends ändert. Eigentlich sollte das für ntp kein Problem sein. Zumindest müsste er sich ja jetz starten lassen, bzw. ansprechbar sein.
Wenn die IP sich ändert läuft der ntpd weiter, kann sich nur nicht mehr synchronisieren. Was passiert, wenn du "/etc/init.d/ntpd restart" eintippelst? Um zu sehen ob es an SElinux liegt kannst du es ja mal disablen.
Michael
Am Sa, den 28.05.2005 schrieb Michael Kollender um 10:07:
Holm Kapschitzki wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ganz andere Baustelle! Alexander hat dir doch beschrieben wie du vorgehen kannst. Gefiel dir die Antwort nicht oder warum fängst du was neues an?
Langsam, langsam :) Holm wollte ja nur dokumentieren, wo er die 5 Schritte her hat, zu denen ich geschrieben hatte, warum er sie so ausführe.
Vielleicht ist dein Motherboard auch einfach Schrott, zu alt, Quarz defekt, Batterie am Ende oder was weiß ich. Entscheide dich erstmal was du willst. Wenn du ntp willst lese und verstehe www.ntp.org
Michael
Eine altersschwache Batterie auf dem Motherboard kann die Hardware (BIOS) Uhr beeinflussen. Dass der Quarz defekt ist, halte ich eher für recht unwahrscheinlich, eher ist ein Elko am Lebenszeitende (gewölbter oder gar an den Sollbruchstellen gerissener Deckel).
Alexander
de-users@lists.fedoraproject.org
-
Alexander Dalloz -
fedoraliste＠web.de -
Holm Kapschitzki -
Martin Schmiderer -
Michael Schwendt