/dev/blog/ID10T

Advertisement

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.

Windows: Uptime eines Geräts herausfinden

• Windows • Comments

Als Linuxuser ist man im Bezug auf Serveruptime ja ziemlich verwöhnt. Updates brauchen in der Regel keine Neustarts sodass Server locker auf eine Uptime jenseits der 200 Tage kommen könnten. Das ist sicherlich einer der Gründe, warum die Uptime grade in Linuxkreisen oftmals eine nahezu religiöse Bedeutung hat. ;-)

In Linux bekommt man die Zeit, die ein Server nicht mehr neugestartet oder heruntergefahren wurde mit dem simplen uptime-Befehl angezeigt. Doch wie ist das bei Windows?

Dafür gibt es zwei Wege, der Königsweg ist meiner Meinung nach die Kombination aus beiden.

  1. systeminfo: Mit dem Befehl systeminfo in der CMD kann man sich - wie der Name schon sagt, einen Haufen Informationen über sein System ausgeben lassen. Unter anderem gibt es dort einen Punkt, der sich auf Deutsch Systembetriebszeit nennt, der die bisherige Betriebsdauer angibt.
    2013-02-12-systeminfo
  2. net statistics server: Mit dem Befehl net statistics server werden Informationen zum Server-Dienst angezeigt. Für uns ist hier der Punkt "Statistik seit" wichtig. Dieser teilt uns den genauen Startzeitpunkt der Serverdienstes mit. Da dieser einer der ersten gestarteten Dienste überhaupt ist, entspricht dies dem Start des Betriebssystems selbst.
    2013-02-12-net-statistics-server
  3. Der Königsweg: Der Königsweg für die Uptime unter Windows ist in meinen Augen eine Kombination aus beiden Befehlen:
    net statistics server | find /i "Statistik seit" && systeminfo | find /i "Systembetriebszeit"

    Die Ausgabe ist ähnlich übersichtlich wie bei Linux und gibt doch alle notwendigen Informationen wieder.
    2013-02-12-uptime-windows
    Was genau machen wir hier? Eigentlich nichts anderes, als beide Befehle ausführen, nach der benötigten Zeile suchen und nur diese ausgeben lassen.

Dass man unter Windows XP überhaupt pipen kann, war mir bis dato nicht bewusst. Das hätte mir einige Batches sicherlich einfacher gemacht.

Advertisement