/dev/blog/ID10T

Advertisement

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.

Geforce GTX570: Abstürze beiDirectX11 Spielen beheben

• Hardware • Comments

Irgendwie ziehe ich Probleme an. Ich habe mir vorletztes Jahr einen PC gekauft, Bestandteil war eine ASUS Geforce GTX570. Eigentlich bin ich sehr zufrieden mit dieser Grafikkarte. Sie glänzte damals mit einem hervorragendem Preis-Leistungsverhältnis, hat bisher jedes Spiel, dass ich gespielt habe flüssig und in vollen Details darstellen können und ist dabei nicht zu laut.

Doch bis vor Kurzem gab es da ein Problem: Einige DirectX11-Spiele stürzten regelmäßig ab. Der Sound war oft noch zu hören, aber ansonsten wurde ich zurück auf den Desktop geworfen. Da es sich ausnahmslos um Konsolenportierungen handelte, hatte ich es zuerst auf die Spiele geschoben. Doch nachdem neben Just Cause 2 und Saints Row the Third jetzt auch noch Assassin's Creed III nicht richtig laufen wollte, habe ich mir doch mal etwas mehr Gedanken gemacht und die Grafikkarte und DirectX11 als Problembereiche identifiziert. Und es stellte sich raus, ich bin nicht der einzige mit diesem Problem.

Das Problem selbst ist bizarr: Asus und einige andere Grafikkartenhersteller haben die Karte minimalst übertaktet (bei mir waren um die 10 Mhz, wenn ich mich recht erinnere), das reicht aber offensichtlich völlig, um DX11 ins Stottern zu bekommen.

Die Lösung dazu ist simpel, ein Firmware Update für die Grafikkarte. Im Falle meiner ASUS GTX570 wäre dieses auf ASUS Downloadsseite zu finden, bei anderen Herstellern gibt es garantiert ähnliche Updates.

Im oben verlinkten Thread sind noch ein paar Workarounds, aber als IT-Mensch sage ich: Das Problem immer an der Wurzel packen, nicht die Wirkung bekämpfen.

Nach dem Update kann ich endlich auch wieder schön Assassins Creed 3 spielen.

20130209-assassins-creed-3-dx10

Dass der Thread von 2011 ist und ich bis ins Jahr 2013 mit diesem Problem zu kämpfen hatte, weil ich die Problemquelle an der falschen Stelle vermutet habe, finde ich allerdings ziemlich deprimierend. :cry:

Advertisement