/dev/blog/ID10T

Advertisement

NTP-Client in Debian einrichten

• Linux • Comments

Eine der ersten Aktionen auf einem frisch installierten Linux Server ist sicherlich das Einrichten von NTP. Dass eine synchronisierte Systemzeit extrem wichtig ist, sollte den meisten Usern und Admins einleuchten. Jeder, der deswegen schonmal mit Datenbankinkonsistenzen zu kämpfen hatte, weiß wovon ich rede. Da ich die Schritte immer wieder vergesse, werde ich sie hier für die Nachwelt dokumentieren.

  1. Falls gewünscht sollte die Zeitzone eingestellt werden. Das geht auf zwei Arten. Mit manueller Eingabe:
    dpkg-reconfigure tzdata

    oder indem man die entsprechende zonedate kopiert:

    cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime

    Europe und Berlin solltet ihr dann natürlich durch eure entsprechenden Pendants ersetzen.

  2. Den ntp-Dienst installieren, falls noch nicht vorhanden.
    aptitude -y install ntp
  3. Anschließend ersetzen wir die Poolserver in der ntp.conf noch mit denen des jeweiligen regionalen ntp-Pools.
    sed -i 's/debian.pool.ntp.org/de.pool.ntp.org/g' /etc/ntp.conf
  4. Dann noch den NTP-Dienst neustarten und alles ist fein.
    service ntp restart

Ein Oneliner für Copy & Paste oder Skripte würde dann so aussehen:

cp /usr/share/zoneinfo/Europe/Berlin /etc/localtime && aptitude -y install ntp && sed -i 's/debian.pool.ntp.org/de.pool.ntp.org/g' /etc/ntp.conf && service ntp restart

Die ganze Chose kann man dann entweder testen, indem man mal ein

ntpq -p

eingibt, um die NTP-Server des Systems herauszubekommen oder - wenn man ein bisschen paranoid ist, so wie ich - indem man den NTP-Dienst beendet, die Zeit ändert und ihn dann mit dem -gq Parameter startet.

service ntp stop && date -s 12:00 && ntpd -gq && service ntp start && date

Wenn die Ausgabe dann etwa so aussieht:
2013-03-15-ntp-client und der Eintrag "ntpd: time set" erscheint, läuft alles korrekt.
Falls ihr auf eurem Server iptables einsetzt und standardmäßig alle ausgehenden Verbindungen dropt, solltet ihr noch zwei Regeln in euer iptables-Skript aufnehmen:

iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A INPUT -p udp --sport 123 -j ACCEPT

Damit sollte dann wirklich alles laufen.

OT: Notiz an mich zu iptables

• Offtopic • Comments

Notiz an mich:

Bevor du den Server rebootest, stelle sicher, dass alle iptables-Regeln auch in deiner Wiederherstellungsdatei gespeichert sind.

Hintergrund:

Ich habe gestern an einem meiner vServer gebastelt und die Maschine im Zuge dessen auch neugestartet. Alles lief hinterher wie gewollt, also beendete ich irgendwann meine Arbeiten daran und loggte mich aus. Heute morgen habe ich durch Zufall auf die Bewertungsskala meines seit Kurzem auf dieser Kiste laufenden NTP-Servers geschaut und war etwas überrascht.

2013-03-19-ntp-server

Verdammt, da hatte ich doch glatt vergessen die Regel, die einkommende NTP-Verbindungen erlaubt, in die Datei zu übernehmen, die nach Systemstart die iptables-Regeln wieder automatisch einrichtet. Das gefiel dem NTP-Pool natürlich gar nicht. Jetzt wird es sicherlich einige Zeit dauern, bis meine Maschine wieder Anfragen zugeteilt bekommt. :-?

Ironie der Sache: Ich hatte den Server neugestartet, um die Funktion eines anderen Skripts nach dem Systemstart zu testen.

PS: Zu NTP-Clients und Servern werde ich demnächst mal zwei Beiträge schreiben.

Selbst gehostete Google Reader Alternativen

• Online • Comments

Google hat gestern angekündigt, dass der Google Reader zum 1. Juli abgeschaltet werden soll. Das finde ich sehr schade, bisher war dieser Dienst einer der wenigen, die ich auch dauerhaft weiter bei Google belassen hätte. Während mein mittelfristiger Plan vorsieht, die meisten der jetzt genutzten Google Dienste wie GMail, GTasks, die Kontakte und noch ein paar weitere auf ein selbst gehostetes System umzuziehen, war das beim Google Reader eigentlich erst langfristig geplant. Nun bin ich aber alarmiert und mache mir entsprechende Gedanken. Deswegen habe ich mal angefangen eine Übersicht von RSS Readern zu erstellen, die man auf eigenem Webspace oder einem eigenen Server nutzen kann. Bisher habe ich noch keines dieser Angebote getestet, das wird sich aber mit Sicherheit in den nächsten Wochen ändern. Meine Anforderungen sind:

Weniger Wert lege ich auf:

Dann schauen wir mal, was ich bisher finden konnte:

SSH: "Failed public key file"-Fehler beheben

• Linux • Comments

Jeder der etwas mit SSH arbeitet weiß, dass bei Fehlern immer eine Devise gilt: Berechtigungen checken, Berechtigungen checken, Berechtigungen checken! Damit kann man i.d.R. auch 98% aller Fehler beheben.
Ebenso der heute bei mir aufgetretene Fehler in einer Appliance. Der Root-User kann sich hervorragend per SSH in die Maschine einloggen, der neu erstellte User kann es nicht. Die Keys werden durch einen Eintrag in der sshd_config zentral verwaltet.

AuthorizedKeysFile /usr/local/etc/sshd/.authorized_keys/%u

Setzt man das LogLevel in der sshd_config auf DEBUG3, bekommt man Logeinträge die etwa so aussehen:

Feb 16 11:08:54 testserver sshd[16398]: debug1: userauth-request for user testuser service ssh-connection method publickey
[...]
Feb 16 11:08:54 testserver sshd[16397]: debug3: mm_answer_keyallowed entering
Feb 16 11:08:54 testserver sshd[16397]: debug3: mm_answer_keyallowed: key_from_blob: 0x406da540
Feb 16 11:08:54 testserver sshd[16397]: debug1: temporarily_use_uid: 1002/100 (e=0/0)
Feb 16 11:08:54 testserver sshd[16397]: debug1: trying public key file /usr/local/etc/sshd/.authorized_keys/testuser
Feb 16 11:08:54 testserver sshd[16397]: debug1: restore_uid: 0/0
Feb 16 11:08:54 testserver sshd[16397]: debug1: temporarily_use_uid: 1002/100 (e=0/0)
Feb 16 11:08:54 testserver sshd[16397]: debug1: trying public key file /usr/local/etc/sshd/.authorized_keys/testuser
Feb 16 11:08:54 testserver sshd[16397]: debug1: restore_uid: 0/0
Feb 16 11:08:54 testserver sshd[16397]: Failed publickey for testuser from 10.0.0.1 port 42784 ssh2
Feb 16 11:08:54 testserver sshd[16397]: debug3: mm_answer_keyallowed: key 0x406da540 is disallowed

Die 3 hervorgehobenen Zeilen sind hier die wichtigen. SSHD versucht, auf das entsprechende AuthorizedKeyFile mit der User- und Group-ID des gewünschten Benutzers zuzugreifen. In diesem Falle versucht also der User testuser auf die Datei /usr/local/etc/sshd/.authorized_keys/testuser zuzugreifen. Dies muss ihm auch erlaubt sein. In meinem Fall konnte er das nicht, da das .authorized_keys-Verzeichnis eine 700er-Berechtigung hatte. Warum man die Berechtigung für einen Public Keys Ordner so restriktiv gesetzt war und warum OpenSSH selbst auf der höchsten Logstufe keine vielsagendere Fehlermeldung gibt, wird mir auf immer schleierhaft bleiben.
Da ich nicht wusste, dass der SSHD den Zugriff mit dem jeweiligen User versucht, hatte ich diese Problemquelle auch gar nicht ausgemacht und war schon mitten in der Fehlersuche in PAM- und SeLinux-Einstellungen. :-P

Blog: Haufenweise Probleme

• Blogging • Comments

Ich fürchte, meine Wordpress Instanz löst sich langsam auf. Die letzten Wochen habe ich fleißig Beiträge geschrieben, doch keiner tauchte im RSS-Feed auf. Dass der RSS-Feed seit längerer Zeit Beiträge erst verzögert ausliefert, ist mir bewusst. Dass es gar nicht ging, hat mich dann doch gewundert. Es stellte sich heraus, dass lediglich ICH als eingeloggter Admin die neuen Beiträge sehen konnte, jedem anderen Besucher blieben sie verwehrt. Auslöser dafür war wohl ein fehlkonfiguriertes Caching-Plugin. Ich denke, das ist jetzt abgestellt, trotzdem werde ich meinen für Mitte des Jahres geplanten Blogumzug vermutlich noch diesen Monat angehen. Im Zuge dessen werde ich dann auch wahrscheinlich ein neues Design einstellen, selbst wenn es nur temporär sein wird.
2013-03-05-wordpress-logo
Bild: Chesi - Fotos CC, CC BY-SA 2.0

Update 07.03.2013: Dieser Beitrag war der erste Beitrag seit Monaten, der wieder pünktlich im RSS-Feed ausgeliefert wird. Als wollte sich die Technik jetzt nochmal von ihrer besten Seite zeigen wollen.

Advertisement