Monat: März 2011

Musik, oder so

2011-03-31 / ports

Es ist viele Jahre her. Das Thema war Musik, bzw. Lieder, die mit „Musik“ kaum korrekt umschrieben werden koennen, bzw. wo sich einem durchaus auch „Akustischer Umweltschmutz“ als Umschreibung aufdraengt. Da meinte ein guter Freund, der Nils, dass wir irgendwann vielleicht alle nur noch „Lieder“ hoeren, die im Grunde nur noch ein langer 1kHz-Ton sind. Naja, da sind wir noch nicht…
Wer mich kennt weiss, dass ich manchmal auch Musik hoere, die man mit „ruppig“ beschreiben kann. Aber das was ich eben zufaellig gefunden habe, ist sogar mir ein Stueck weit zu hart.

Also dann doch lieber, im Vergleich mit obigem, eine entspannte Runde Iniquity 🙂 Und ich liebe ja die Kommentare auf Youtube. Einer, der mir im Zusammenhang mit obigem „Lied“ besonders gefaellt ist „Do they have a dinosaur as their vocalist?“ 😉

Danke

2011-03-30 / ports

Ein weitere Abschnitt in meinem Leben neigt sich dem Ende. Dafuer schliesst sich ein neuer Abschnitt an. Ab dem 01.07.2011 bin ich Mitarbeiter des TUEV Rheinland. Ich bin sicher da werden viele tolle und spannende Aufgaben auf mich zu kommen.

Warum ich aber eigentlich den Beitrag schreibe. Im Rahmen einer solchen Aenderung gibt es natuerlich auch vieles zu beachten. Ein echtes Highlight war, man mag es kaum glauben, der geplante Urlaub. Eigentlich wollten wir im Mai zwei Wochen nach Kroatien fahren. Als klar war, dass ich Wechseln wuerde kam natuerlich die Frage, wie sinnvoll es ist, nach dem Urlaub noch vier Wochen „arbeiten“ zu gehen. Vor allem im Hinblick darauf, dass man dann auch ohne einen freien Tag von einem zum naechsten Arbeitgeber wechselt.

Problem… Alles war geplant, gebucht und organisiert. Da muss man dann mit dem Arbeitgeber, insbesondere mit dem Kollegen, der anschliessend Urlaub hat, sprechen. Da muss der Reiseveranstaler angesprochen werden, ob eine Umbuchung moeglich ist. Und *natuerlich* muss man das Thema auch mit der Familie, vor allem der Frau, besprechen. Da die Umbuchung Geld kostet, der Urlaub, weil spaeter, teuerer wird und man zeitweise komplettes Chaos hat, ist das alles in allem nicht lustig oder leicht.

Im Moment schaut alles so aus, als waere es moeglich, dass ich meinen Urlaub im Juni und nicht im Mai mache. Das wuerde mir natuerlich total entgegen kommen, da ich dann Ende Mai meinen letzten Arbeitstag habe, dann einen Monat frei und dann erholt meinen neuen Job beginnen kann. Dafuer, dass ich verschieben kann, muss ich auf jeden Fall mal meinem Kollegen Uwe danken! Du hast dir da echt mal ein Bier verdient.

Und wir alle haben ja manchmal Phasen in denen wir nicht zu geniessen sind, oder in denen der Umgang mit uns nicht ganz leicht ist. Deshalb muss ich auch meiner Frau danken, dass Sie mich, trotz ihrer ganzen Planung, bis jetzt nicht aus dem Haus geworfen hat! 🙂 Denn leicht war es die Tage mit mir sicher auch nicht. Danke! Ich liebe dich!

Datei != Datei

2011-03-25 / ports

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Vor einigen Tage wollte ich, wie auch mal in Arbeit auf vielen Servern beschrieben, einige Server auf einen aktuellen Stand bringen. Also eine neue lokale Konsole auf und ein beherztes ramon@zak:~$ for i in $(< server); do ssh $i „sudo aptitude update && sudo aptitude safe-upgrade“; done abgesetzt. Was erhalte ich als Meldung?

: Name or service not knownname srv-cgn-01

Ich gebe zu, ich war etwas verwundert, da in meiner ~/.ssh/config ein Eintrag fuer eben diesen und acht andere Server zu finden ist. Um sicher zu gehen, dass alles klappt, versuche ich mich haendisch mit dem Server zu verbinden.

ramon@zak ~ $ ssh srv-cgn-01
Linux srv-cgn-01 2.6.32-30-server #59-Ubuntu SMP Tue Mar 1 22:46:09 UTC 2011 x86_64 GNU/Linux
Ubuntu 10.04.2 LTS

Welcome to the Ubuntu Server!
* Documentation: http://www.ubuntu.com/server/doc

System information as of Wed Mar 23 10:14:58 CET 2011

System load: 0.21 Processes: 143
Usage of /: 2.4% of 128.80GB Users logged in: 0
Memory usage: 7% IP address for eth0: 87.79.26.35
Swap usage: 0% IP address for eth1: 192.168.100.1
Temperature: 8 C

Graph this data and manage this system at https://landscape.canonical.com/

0 packages can be updated.
0 updates are security updates.

Last login: Tue Mar 22 07:54:16 2011 from foo.ptlx.de
ramon@zak

Klappte soweit. Jetzt wollte ich doch mal schauen, was mir hier mit einem echo angezeigt wird.

ramon@zak ~ $ for i in $(cat server_ptlx); do echo ssh $i ls; done
ls srv-cgn-01
ls srv-cgn-02
ls srv-cgn-03
ls srv-cgn-04
ls srv-cgn-05
ls srv-cgn-06
ls srv-cgn-07
ls srv-cgn-08
ls srv-cgn-09
ramon@zak

Das war definitiv nicht die Ausgabe, die ich erwartet hatte. Viel mehr waere etwas wie ssh srv-cgn-01 ls zu erwarten gewesen. Ich werde es nicht zu Spannend machen, moechte aber sagen, dass ich bei dem Problem sogar angefangen hatte strace in die Loesungssuche mit einzubeziehen. Nach einigen Mails zwischen Dirk und mir kam dann die entscheidende Frage „Deine .ssh/config ist eine Unix-Datei, oder?“.

ramon@zak:~$ file .ssh/config
.ssh/config: ASCII text

Ja, offensichtlich war die Datei „in Ordnung“. Aber was war mit meiner Datei, in der alle Server eingetragen sind?

ramon@zak ~ $ file server
server: ASCII text, with CRLF line terminators

Ja, da muss man erst mal drauf kommen. In der Datei war nicht, wie bei Linux-Dateien typisch, nur ein Line Feed, sondern ein Carriage Return mit anschliessendem Line Feed zu finden. In der Regel kommen Dateien mit einem CRLF aus dem Windows-Umfeld.

Als ich die Datei bereinigt hatte, hat auch mein oben genannte Aufruf endlich funktioniert. Viele Beispiele, wie so eine Bereinigung aussehen kann, finden sich unter HowTo: UNIX / Linux Convert DOS Newlines CR-LF to Unix/Linux Format. Unklar ist mir weiterhin, wieso die Datei bei mir auf einmal mit einem CRLF auftaucht 🙂

Debug SSH

2011-03-04 / ports

Hinweis on: Das ist ein Beitrag aus dem ehemaligen Projekt „adminstories.de“. Bitte hier fuer weitere Informationen schauen.Hinweis off

Aus gegebenem Anlass etwas „Wiederverwertung“ :). Die Tage wurde ich angesprochen, da ein Kollege ein Problem hatte. Es ging darum, dass eine SSH-Verbindung mit Authentifizierung via SSH-Key nicht funktionieren wollte. Im Detail stellte es sich so dar, dass der Client eine Kennwortabfrage brachte. Frage war nun, was hier der Grund fuer den Effekt war. Also haben wir uns erst mal an den Client gesetzt und die loebliche, aber nur selten verwendete Option -v, genutzt.

ramon@client ~/.ssh $ ssh -vvv ramon@server
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ramon/.ssh/identity
debug3: no such identity: /home/ramon/.ssh/identity
debug1: Trying private key: /home/ramon/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug3: sign_and_send_pubkey
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 640 bytes for a total of 1767
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/ramon/.ssh/id_dsa
debug3: no such identity: /home/ramon/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
ramon@server’s password:

Hier kann man prima sehen, dass versucht wird mit id_dsa sich gegenueber dem Server zu authentifizieren. Allerdings schlaegt das fehl. Das sieht man daran, dass nach einem Kennwort gefragt wird. Schauen wir also mal wie es sich auf dem Server darstellt. Um den laufenden Betrieb nicht zu stoeren starten wir einen weiteren SSH-Daemon inklusive Debug-Option der auf Port 24 lauscht.

root@server:/# /usr/sbin/sshd -p 24 -ddd

Nun versuchen wir uns noch einmal via ssh -p 24 user@server am Server anzumelden und schauen, was der Server ausgibt.

debug1: trying public key file /home/ramon/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for file /home/ramon/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1000/1000 (e=0/0)
debug1: trying public key file /home/ramon/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for ramon from 10.0.0.194 port 41962 ssh2

Hier kann man nun prima sehen warum der Zugriff nicht wie geplant funktioniert. Der Ausloeser ist die falsch gesetzte Berechtigung auf der authorized_keys. Entweder setzt man nun also die Rechte „korrekt“, ausser dem Owner darf niemand W(rite) haben, oder man setzt StrictMode no. Letzteres ist allerdings nicht zu empfehlen. Wer interessiert ist findet die Pruefung auch im Quellcode von OpenSSH in der auth.c. Die Funktion nennt sich da secure_filename.