Erik`s Blog

Heute durfte ich etwas neues lernen. Statt dem Üblichen Aufruf von find mit -exec {} \; kann auch ein + als Abschluss des -exec Kommandos benutzt werden. Dies hat den Vorteil, dass z.B. bei einem Aufruf von

find ./ -type f -exec rm {} +

das rm nicht für jedes Vorkommen gestartet wird, sondern (ähnlich der Verwendung von xargs) das rm auf eine Liste mit Treffern angewandt wird. Bei einer grösseren List spart man sich da einiges an Zeit und ggf. Ressourcen. Leider geht dies aus der deutschen man page nicht hervor. In der Englischen ist es hingegen zu finden:

-exec command {} + This variant of the -exec action runs the specified command on the selected files, but the command line is built by appending each selected file name at the end; the total number of invoca‐ tions of the command will be much less than the number of matched files. The command line is built in much the same way that xargs builds its command lines. Only one instance of `{}' is allowed within the command. The command is executed in the starting directory.

Nachdem Bitcoins zurzeit gerade wild durch sämtliche Medien geistern, möchte ich doch auch meine Meinung dazu äussern.

Ich meine, die ersten Bitcoins die ich kaufte waren so um die 5 Euro. Leider habe ich diese nicht durchgehend behalten, da mir der Kursanstieg viel zu rasant war. Dass der Kurs eingebrochen ist, kam viel später, als ich es erwartet hätte.

So wie es aussieht, sind im Moment vor allem Spekulanten auf den Bitcoin aufmerksam geworden. Zusätzlich denke ich auch, dass viele ihr Geld "in Sicherheit" bringen wollten. Wie es damals auch mit der Aktie der deutschen Telekom war, dürfte es auch hier schon einige Kleinanleger erwischt haben, die unbedingt auch noch auf diesen Zug aufspringen wollten und den Spekulanten damit wahrscheinlich erlaubten, mit satten Gewinnen wieder zu verkaufen.

"Bitcoin als Währung nutzen" vollständig lesen »

Das schöne an CentOS ist, dass man sich recht einfach ein eigenes Repository, bzw. einen eigenen Mirror bauen kann. Das ist vor allem gut, wenn man Updates vor dem Einspielen in die Produktivumgebung testen will. Jetzt kam es dazu, dass wir einen frisch aufgesetzten CentOS Server an unser Repository anschlossen und damit leider ein paar Pakete auf dem System neuer waren, als in unserem Repository. Das sorgte dann auch dafür, dass einige zusätzliche Pakete wegen nicht erfüllter Abhängigkeiten nicht installiert werden konnten.

Ich nehme CentOS auch gar nicht übel, dass es Schwierigkeiten hat, solche Abhängigkeiten zu lösen, bzw. zu identifizieren. Nachdem es nicht das erste Mal war, dass ich "zu neue" Pakete auf dem System hatte, wusste ich schon, wie ich die verantwortlichen Pakete finden kann. Dank der "downgrade" Funktion von yum lassen sich die zu neuen Pakete auch gut auf die richtige Version downgraden.

Was ich CentOS ziemlich übel nehme ist jedoch, dass es beim Downgrade von 3 Paketen die Abhängigkeiten irgendwie nicht richtig auflösen konnte und in der Folge ca. 50 Pakete zur Deinstallation markierte. Hätte ich mich voll darauf konzentriert und mir die Paketliste angesehen, hätte ich das natürlich abgebrochen, doch ich war etwas abgelenkt..... Unter den 50 Paketen, die wegen nicht erfüllter Abhängigkeiten deinstalliert wurden, befanden sich unter anderem "yum" und "rpm".

Wenn ich beispielsweise unter Gentoo auch nur ein Paket aus der "system" Gruppe deinstallieren will, werde ich darauf hingewiesen, dass ich damit mein System kaputt machen kann. Stoppe ich einen boot-Service, erhalte ich ebenfalls einen Hinweis...

CentOS hat es geschafft, ohne Nachfrage, sämtliche Möglichkeiten, Pakete zu installieren, zu entfernen. Damit hatte ich es jetzt geschafft, das System unbrauchbar zu machen. Versuche ein rpm-binary und die notwendigen dynamisch gelinkten libraries zu kopieren führten auch nicht zum Erfolg. Damit blieb nur noch neu Aufsetzen.

Ich will nicht sagen, dass es nicht meine Schuld war, doch ein kleiner Hinweis wäre schon nett gewesen ;-)

Heute wollte ein Arbeitskollege zusätzliche Schreib- und Leserechte auf alle Dateien in einem Homeverzeichnis vergeben. Mir ist immer noch nicht klar, warum der Besitzer des Homeverzeichnisses einen Symlink auf / hatte, der Effekt war aber natürlich spannend. An dieser Stelle sei erwähnt, dass die Rechte rekursiv angepasst werden sollten.

Angefangen hat es damit, dass andere Benutzer sich nicht mehr per ssh (mit Keyfile-Authentifizierung) einloggen konnten. Sudo ging auch nicht mehr. Wie gut, dass wir das root-Kennwort kennen!

Zur Erläuterung für die, die es nicht wissen: Die Anpassung der Rechte folgte dem Symlink und hat somit zusätzliche Rechte auf alle Dateien/Verzeichnisse des Servers vergeben. Sicherheitskritische Funktionen prüfen oft, ob nicht zu viele Rechte vergeben sind und verweigern die Ausführung. ssh prüft bei der Authentifizierung per Keyfile beispielsweise die rechte der Datei ~/.ssh/authorized_keys. Kann hier jeder ändern, wird die Datei nicht mehr berücksichtigt, ein Login per Keyfile ist also nicht mehr möglich. Ähnlich verhält es sich bei der Datei /etc/sudoers.

In solchen Situationen lobt man sich ein Backup. Nur wollten wir nicht den ganzen Stand des Servers zurückspielen. Deshalb haben wir im Backup die Dateirechte ausgelesen und auf den Server zurück gespielt:

find . -exec stat -c "%a %n" {} \;|while read mod file;do file=${file##.};echo "chmod $mod $file" >>chmod.sh;done;ssh $server sh - <chmod.sh

Damit wurden zumindest alle Dateien, die im Backup vorhanden waren, wieder auf die ursprünglichen Rechte zurück gesetzt.

Eigentlich weiss man es ja, doch wissen und darauf achten ist leider manchmal zweierlei.

Ich habe mir ein bash script gebaut, das mir einen IRC-Channel überwachen und ggf. ein E-Mail senden sollte. Dazu habe ich 2 Funktionen gemacht. Die eine, die sich mit einem IRC-Server verbindet und im entsprechenden Kanal einloggt und die 2. Funktion, die dann das E-Mail versendet. "Natürlich" hiess die Funktion mail. Genau so heisst auch das Programm, mit dem ich die Mails versenden wollte.

Mein Problem äusserte sich in einer Endlosschleife. Sobald ein Mail versandt werden sollte. Alle Tests mit echo und Ähnlichem funktionierten natürlich.

Nachdem die Kommunikation mit dem IRC-Server in einer while-Schleife läuft und daher ständig von STDIN liesst, hatte ich immer einen Zusammenhang damit vermutet. Wenigstens habe ich dadurch viel über Datei Descriptoren und FIFOs gelernt. Nach Stunden habe auch ich verstanden, dass ich nicht das Programm "mail" rief, sondern jedes Mal wieder meine eigene Funktion "mail", die dann "mail" rief.

Ich werde mir wohl ein anderes Namensschema für Funktionen angewöhnen (müssen).

Da schauten wir heute nicht schlecht, als nach einem yum update des CentOS 6 plötzlich der Mailserver meinte, er könne wegen einer Misskonfiguration keine E-Mails annehmen. Wussten wir doch sicher, dass wir an der Konfiguration nichts verändert hatten. Auch die Fehlermeldung brachte uns da nicht wirklich weiter:

NOQUEUE: reject: RCPT from mailout-de.gmx.net[213.165.64.22]: 451 4.3.5 Server configuration problem

Einer Intuition folgend schaute ich nach, ob postgrey überhaupt läuft und auf dem gewünschten Port hört. Da wusste ich nämlich schon aus schmerzlicher Erfahrung, dass postfix keine E-Mails annimmt, wenn es konfiguriert ist, postgrey zu benutzen, diesen jedoch nicht erreichen kann. Und so war es dann auch. Postgrey lief zwar, lauschte aber nicht auf den in postfix konfigurierten Port (100232).

Ein Blick in /etc/sysconfig/postgrey zeigte jedoch:

OPTIONS="--inet=10023"

Ein Neustart mit Blick ins Log zeigte, dass postgrey auf den Unix Socket statt auf den TCP/IP Port hört. Jetzt konnte es eigentlich nur noch am init-Skript liegen. Volltreffer:

options="--unix=/var/spool/postfix/postgrey/socket"

Da hat wohl jemand vergessen, dass linux case-sensitiv ist. Die Theorie schnell getestet und in /etc/sysconfig/postgrey aus

OPTIONS="--inet=10023"

ein

options="--inet=10023"

gemacht, neu gestartet, fertig :)

Das init-Skript zu ändern wäre mir hier zu heiss gewesen, da dieses, wie man hier gut sehen kann, leicht durch ein update geändert wird (wobei wir das nicht mehr verifiziert haben, doch viel mehr Möglichkeiten bleiben nicht). Das File unter /etc/sysconfig sollte die Distribution höchstens ausliefern, wenn es nicht da ist, doch nie ändern...

BTW: Gentoo hätte auch das Init-Skript nicht einfach angepasst, sondern die Änderung angezeigt und es dem Admin überlassen, die Änderungen (falls nicht trivial) zu mergen/verwerfen....
Schön, dass Mailserver nicht so schnell aufgeben und die Mails erneut einliefern. Damit haben wir jetzt nur ein paar nächtlich versandte E-Mails etwas aus gebremst. Warum sollen die auch früher ankommen als wir.

Merke: Nach einem Update des Betriebssystems oder von wichtigen Komponenten lohnt sich immer ein Blick ins Logfile!

Auch ich wurde auf bitcoins aufmerksam. Leider oder vielleicht auch zum Glück erst nach dem grossen Hype/Verfall. Ich hatte zwar auch schon davon gehört, aber mich erst jetzt dafür interessiert, als ich für meinen Server hier etwas zu tun suchte. Leider ist ja heute nichts mehr mit dem so genannten Minen zu verdienen, zumindest nicht, wenn man es mit einer CPU versucht. Dann bleibt eigentlich nur noch das Tauschen von staatlicher Währung in Bitcoins. Doch was mache ich dann mit den Bitcoins.... Wenn jemand vor hat mir Bitcoins zukommen zu lassen bin ich natürlich sehr dankbar. Hier jedenfalls meine Adresse: 1QComoQdRqg464VDEmeWaU9x6fenpMtmZf Vielleicht biete ich ja mal Services gegen BTC an :)

Programmieren ist ja jetzt nicht so mein Ding, bei Bedarf eben etwas Bash-scripting, vielleicht auch mal perl. Aber bei LOLCODE könnte ich mir das nochmals überlegen :)

So, geschafft. Der Server ist endlich aufgesetzt und die Blog-Software ist auch installiert. Jetzt fehlen nur noch sinnvolle Einträge.