linux
Die Google Lüge
Nur weil es in letzter Zeit schon öfter vorgekommen ist, vermute ich, dass es kein Zufall mehr sein kann.
Gibt man im Google Suchbegriffe ein, schmuggeln sich laufend Seiten in die ersten 10 Treffer, in denen zumindest einer der Suchbegriffe nicht vorkommt.
Beispiel:
zypper puppet downgrade – Link Nr. 3 bei mir, über google.at gesucht, geht überhaupt nicht auf Puppet ein.
[Update] So rächt sich google – jetzt bin ich für diese Keywords "zypper, puppet und downgrade" selber auf dem Spitzenplatz gelandet – und das ohne eine Lösung für das ursprüngliche Problem parat zu haben.
LUG Krems
Da es nächste Woche schon wieder Zeit für das Treffen der Linux User Group Krems ist, hier meine Notizen zum letzten Treffen. …
Immer am ersten Mittwoch im Monat findet ein Treffen der LUG statt. Die Treffen finden im Seminarraum der ASINOE statt. Der Hinweis auf der Mailingliste sagt, dass man über die "verboten aussehende Wiese" gehen muss – auch wenn man glaubt, hier gehts nicht mehr weiter.
Die LUG wird von der Mailingliste unter lug.krems.cc mit etwa 100 Abonnenten zusammengehalten.
Es treffen sich Techniker – d.h. Menschen die alle recht ähnlich ticken und eine gemeinsame "Sprache" sprechen.
Was wurde gemacht?
Diagnose eines Hardware Problems an einem Laptop. Diskussion von E-book-readern fürs pdf-lesen. Ein Vergleich von MySQL und Postgres, Samba-Konfigurations-Fragen. Pizza essen und weitere Diskussionen.
Wie man sich aus einer iptables Firewall aussperrt
Für Firewall-Spielereien auf einer Remote-Maschine ist es ja eine gute Idee, einen cronjob anzulegen, der sicherstellt, dass alle paar Minuten die Möglichkeit zum Verbinden neu geöffnet wird. Was aber passiert mit folgender Zeile in der Crontab:
iptables -P ACCEPT; iptables -F
Auf den ersten Blick sieht das gut aus – aber in Wahrheit führt der Cronjob dazu, dass man sich aus der Remote-Maschine aussperrt.
Der Grund ist einfach – die Syntax beim setzen der Policy ist falsch, wie die Man-Page zeigt:
-P, --policy chain target
Auch der Vor-Ort-Admin hilft nicht weiter, so lange der Cronjob regelmäßig wieder die Blockade verursacht!
Richtig wäre für diesen Anwendungszweck:
#!/bin/bash /sbin/iptables -P INPUT ACCEPT /sbin/iptables -P OUTPUT ACCEPT /sbin/iptables -F
Zitat des Tages
Alle reden von Backup, aber jeder will eigentlich Restore!
– Linux Magazin 3/11, S. 91
Logging und Netzwerkverbindungen in der Bash
Inspiriert vom Artikel Bash Bashing aus dem Linux Magazin 12/2010 hab ich mich etwas näher mit den Fähigkeiten der Bash beschäftigt.
Zwei interessante Punkte habe ich dabei entdeckt: …
- Mit dem Shell-Builtin „exec“ lassen sich ganz einfach Filedescriptoren verbiegen. Das Beispiel dazu im Artikel schreibt dazu:
exec 77>&1
, das heißt es wird der Deskriptor 1 – die Standardausgabe – mit dem Deskriptor 77 verbunden. Das dient eigentlich dazu, dass die Standardausgabe gesichert wird, um diese später wiederherstellen zu können. Dabei stellt sich mir allerdings die Frage warum gerade der Deskriptor 77 verwendet wird. Es kann dann mit
exec > /tmp/logfile
die gesamte Ausgabe aller folgenden Befehle in eine Datei umgelenkt werden, ohne diese extra angeben zu müssen. Wiederhergestellt wird die Standardausgabe dann über den Befehl
exec 1>&77
- Der zweite wichtige Punkt ist der, dass die Bash bereits alles wichtige mitbringt um eine Netzwerkverbindung aufzubauen. Das sollte sich auch problemlos mit Punkt 1 kombinieren lassen. Um etwa eine Datei von einem Webserver herunterzuladen wird kein zusätzliches Werkzeug wie wget benötigt.
Das Ergebnis war dieses Beispielscript mit dem z.B. eine Webseite heruntergeladen werden kann:#!/bin/bash # exec: bash builtin # exec 5<> filedescriptor 5 mit netzwerksocket verbinden # host www.orf.at; port 80 exec 5<> /dev/tcp/www.orf.at/80 # etwas an den socket schicken echo -e "GET / HTTP/1.0\n" >&5 # antwort vom socket abholen (und in ein Datei outputfile schreiben) cat <&5 > outputfile
Eine Anleitung zu dem Ganzen findet sich auch unter „/dev/tcp“ im „Advanced Bash Scripting Guide“.
chmod -x chmod
Vor einiger Zeit schon gesehen, aber jetzt wieder gefunden.
Sollte man dem chmod-Befehl das Recht nehmen, gestartet zu werden – wie kann man es wieder herstellen. Einige mehr oder weniger kreative Ideen zeigt diese Präsentation: …
Sicheres NFS
NFS in Version 3 kann heutzutage als deutlich unsicher eingestuft werden. Eine Authentifizierung erfolgt, wenn überhaupt, nur über IP Adressen. Aus diesem Grund sind den "Erfindern" von NFS so schöne Sachen wie root_squash eingefallen – das soll verhindern, dass jemand, der auf einem Rechner root-Rechte hat, diese nicht automatisch über NFS auch auf einem anderen Rechner ausnutzen kann.
So weit so gut – doch in der Praxis ergeben sich dadurch leider Probleme. So darf der Superuser weniger mit den Dateien machen, wie ein anderer User und er darf den Usern nicht helfen, die Berechtigungen "richtig" zu setzen. Irgendwie habe ich mich kürzlich gefragt, was die Geschichte wirklich bringen soll. Sobald ein User root Rechte auf einem System hat, kann er doch ohnehin jede beliebige User ID an den NFS Server schicken und damit den Schutz umgehen!
Zitat des Tages
Kids, don't try this at home. Writing a book takes personal sacrifice, including many hours staring at your monitor while just knowing htat noboday will actually read this, execpt your relatives. And even then it becomes obvious that they'll nod their heads with a vacuous look on their faces and say, "Clustering what? Does that include Nougat in some fashion?"
Zitiert aus
Linux Clustering: Building and Maintaining Linux Clusters