Einträge von Maddin

Letztens bin ich bei Telepolis auf einen Artikel gestoßen, der mich auf ein sehr interessantes Projekt verwies: MailMyWeb.com
Das Ziel des Projekt ist es, den Zugriff auf das Internet da zu ermöglichen, wo es aus politischen Gründen (seien es Firmenpolitische oder auch Landespolitische) nicht möglich ist, frei auf alle Inhalte des WWW zuzugreifen. Einfach halber und genialer Weise geschieht dies über das Medium E-Mail.
Eine gar nicht mal so schlechte Idee, bedenkt man die schon fast täglich aufkommenden Nachrichten von Websperren durch Provider oder den kompletten Webverboten in den etwas östlicher liegenden Ländern dieser Erde.

Auch die Bedienung des "MailWebBrowsers" ist gar nicht mal so schwer. Hat man sich erst einmal angemeldet und die korrekten Sender- und Empfangsadressen hinterlegt und dem tätigen eines virtuellem Einkaufs für 0 Euro, kann es auch sogleich mit dem browsen beginnen. Dazu schreibt man einfach eine E-Mail an robot@mailmyweb.com, mit der gewünschten Webseite im Betreff. Prompt erhält man nach etwa 1 Minute eine E-Mail mit der gewünschten Webseite im Body.
Eine tolle Sache daran ist: befindet sich im Content der angemailten Seite ein Link, wird dieser automatisch zu einem Mail-To Link umgebaut, d.h. klickt man in der E-Mail auf den Link, poppt eine neue E-Mail mit dem gewünschten Link im Betreff auf, welche dann nur noch versendet werden muss. Dies sollte es so ermöglichen, relativ komfortabel zu "mailbrowsen".
Sogar an heutige Videoportale wurde gedacht. Klickt man auf eines der Videos, wird dieses durch die Software auf die Server von MailMyWeb heruntergeladen, in ein wmv Video umgewandelt und dann an die E-Mail-Adresse verschickt. Leider funktionieren im Moment noch nicht alle Videoportale (dieses eine da, klingt so ähnlich wie YouTube, klappt leider nicht ). Um zu erfahren was noch alles mit MailMyWeb möglich ist, empfehle ich euch als erstes eine E-Mail an den robot mit dem Betreff "hilfe" zu senden. Danach bekommt man eine Anleitung zugesandt, in der eigentlich alles erklärt wird.

Es muss natürlich klar sein, das ein E-Mail-Client bei der Darstellung und Bedienung mit den heutigen Webbrowsern nicht mithalten kann. Ich denke aber das dies zu verschmerzen ist. Mein erster Test (heise.de --> News lesen --> das Forum durchsuchen und YouTube Musikvideos) war zumindest erfolgreich und angenehmer als gar kein Internet haben zu können. Für die Nutzer die so an Ihre gewünschten Informationen kommen, ist es vollkommen ausreichend.

Eventuell finden sich ja ein paar Tester, die mir via Kommentar von Ihren Erlebnissen von MailMyWeb berichten können.
Ich finde es auf jeden Fall eine gute Idee und ein Projekt, welches man im Auge behalten sollte.

Heute möchte ich ein Projekt vorstellen, welches sich zum Ziel gesetzt hat "eine einfach zu benutzende Umgebung für Open Source Software zur Verfügung zu stellen, mit der es möglich ist, Kommandozeilen-, X11- oder Aqua basierte Programme für MacOS X zu kompilieren, zu installieren und zu erneuern". MacPorts heißt das ganze und ist unter der URL macports.org zu erreichen.

Das Prinzip des Portumgebung ist schon etwas älter und wurde erstmals 1994 für FreeBSD von Jordan K. Hubbard entwickelt. Mittlerweile nutzen es mehrere BSD- und auch Linux Varianten als die bevorzugte Paketverwaltung. Das eigentliche Ziel ist es, die Installation von Softwarepaketen aus dem Quellcode so einfach wie möglich zu gestalten, ohne dass der Nutzer darüber Kenntnisse haben muss.

Um MacPorts auf dem Mac zu installieren, lädt man sich einfach das zu seiner Version (Leo, Snow Leo, Tiger) passende DMG und startet die Installation. Ein Tipp, denn ich habe die Installation 3 mal gestartet : schaut euch im Installations-Programm via Apfel+L das Installations-Logfile an, da der Installer als erstes via rsync eine Menge Dateien vom einem MacPort Mirror zieht und man leider keinen Status im Installations Programm sieht und man unter Umständen denken könnte, dass der Installer sich erhangen hat.
Nach der Installation kann man sich dann das eigentliche Paketverwaltungs-Tool ansehen, welches sich wie sollte es anders sein, port nennt. Über dieses kann der Nutzer dann Software suchen, installieren, updaten und auch wieder deinstallieren. Wie immer empfehle ich vor der Benutzung der Software das Lesen der manpage via man 1 port.

Das schöne an MacPorts ist, dass es durch die Vielzahl der verfügbaren Pakete (im Moment sind es etwa 6680) und die Einfachheit der Verwaltung, eine Paketverwaltung für MacOS X zur Verfügung stellt, die so gut wie keine (Software-)Wünsche offen lässt.

Ich kann es nur jedem Mac Nutzer empfehlen, vor allem wenn man wie ich aus der Linux Ecke kommt und es gewöhnt ist, seine Software via apt/yum zu installieren.

Ich hatte ja in meinem letzten Post von molly-guard erzählt. Leider gibt es das Paket im Moment ja nur für Debian-artige Systeme.

Jetzt nicht mehr

Ich habe ein RPM Paket für RedHat Enterprise Server/CentOS 5 gebaut. Getestet ist das Paket unter CentOS 5.0 - 5.3. Solltet Ihr Probleme mit dem Paket haben, könnt Ihr euch gerne via Kommentar/Twitter/E-Mail an uns wenden.

Ich hoffe das RPM Paket findet rege Nutzung. Denn es kann, wie in meinem Post erwähnt, Leben retten

Das RPM Paket zum herunterladen, findet Ihr hier: molly-guard-0.3-1.noarch.rpm

Der heutige Tipp resultiert wieder einmal aus dem täglichen Arbeitsleben eines Administrators und soll euch dabei helfen, die Fehler die ich begangen habe, wenn möglich zu vermeiden.

Wer kennt das nicht, nach einem 10h Tag, vor 20 Remote Konsolen hängend, tippt man in nächtlicher Umneblung reboot auf einem vermeintlichen Testserver ein. Soweit so gut. 5 Minuten später klingelt dann das Telefon, am andere Ende der Geschäftsführer mit der Frage: "Wieso kann ich unseren Web-, Datenbank- [wichtigen Server hier eintragen] Server nicht erreichen? Hast du was dran gemacht?". In folge der fotgeschrittenen Stunde, denn richtige Admins fangen ja auch erst um 12 Uhr Mittags an zu arbeiten, sagt man natürlich ohne darüber nachzudenken: "Nein, aber ich schau gleich mal drauf, bin eh noch via ssh *geistesblitz* ähh, ich ruf gleich zurück". Hmm ssh, 20 Remote Konsolen offen, da war doch was. Hab ich jetzt den Testserver rebootet oder vielleicht doch den [wichtigen] Server?

Aber auch darüber hat sich bereits ein findiger Entwickler gedanken gemacht und zumindest für Debian artige Systeme ein Paket dafür bereit gestellt.

Molly-Guard heißt das ganze und ist relativ einfach über

apt-get install molly-guard

zu installieren. Dieses kleine Paket macht im Endeffekt nichts anderes als unter /usr/sbin/ einen Symlink für die Programme halt,shutdown,reboot und poweroff anzulegen, welche auf das molly-guard Skript unter /usr/share/molly-guard/shutdown verweisen. Dieses wiederum erkennt anhand des aufgerufenen Programmnamens, bestimmer Umgebungsvariablen und abgefragter Parameter, ob man sich in einer SSH Session befindet, und fragt wenn das der Fall ist, nach dem Hostnamen des Servers den man herunter fahren möchte. Dies sieht dann in etwa so aus:

root@important_server:~# shutdown -n 60
W: molly-guard: SSH session detected!
Please type in hostname of the machine to shutdown: testserver
Good thing I asked; I won't shutdown important_server ...

Und wieder einmal eine kleine aber feine Erfindung, die das Admin-Leben erleichtert und vor allem Nerven spart.

Beim meinem letzten Post war ich ja auch auf das Thema geteilte Screen Session gekommen, in dem ich erklärt habe wie man via screen und einigen Optionen, wunderbar mit mehreren root-Nutzern zusammen in einer Screen Session arbeiten kann. Da Screen aber auch in der Lage ist, mit mehreren unterschiedlichen Nutzern eine geteilte Session zu machen, möchte ich euch dies anhand eines kleinen Beispiels erklären.

Mein Beispiel ist aus meinem Alltag gegriffen, in dem es immer mal wieder vorkommt, dass ein Kunde zum Beispiel eine Applikation installiert haben möchte, diese aber unter dem root Nutzer installiert werden muss. Dann empfiehlt sich einfach eine geteilte Screen Session zu machen, in der der normale Nutzer auf meinen root Screen einen lesenden Zugriff erhält und mich durch die Installation des Programmes leiten kann, ohne aber selbst mit meinen Rechten irgend etwas ausführen zu können. Ich kann mir auch vorstellen das dies zu Schulungszwecken sehr hilfreich sein kann, zum Beispiel um eine Konfiguration oder Installation erklären zu können.

Die erste Aktion, die ausgeführt werden muss, ist dem screen Programm, welches meist unter /usr/bin/screen liegt, setuid Rechte zu geben. Diese werden benötigt um im Multinutzer Betrieb von Screen Dateien zu öffnen, die sonst nur von root gelesen werden können.

Bitte beachtet aber, dass Programme die mit setuid Bit laufen und dem Nutzer root gehören, alles auf dem System machen können. D.h. sollte das Programm eine Schwachstelle haben (BufferOverflows etc. pp.), kann dadurch das System komprimitiert werden.

Deswegen solltet Ihr nach der Session dem Programm Screen das setuid Bit wieder entfernen.

Um das setuid Bit zu setzen, führt Ihr als root Nutzer folgenden Befehl aus:

chmod u+s /usr/bin/screen

Danach läuft Screen als setuid Programm. Um das setuid Bit nach der Screen Session wieder zu entfernen, führt Ihr wieder als root Nutzer folgenden Befehl aus:

chmod u-s /usr/bin/screen

Nach dem setzen der Rechte könnt Ihr, wie schon im letzten Artikle beschrieben, eine Screen Session mit eigenem Namen als root Nutzer aufrufen:

screen -S root_lese_session

Nachdem Ihr diese erstellt habt, müssen ein paar Optionen gesetzt werden, sodass ein normaler Nutzer lesenden Zugriff auf den Screen erhält. Dazu führt Ihr die folgenden Kommandos im Screen aus:

(strg+a) + :multiuser on
(strg+a) + :acladd nutzername
(strg+a) + :aclchg nutzername -rwx "#?"
(strg+a) + :aclchg nutzername +rx "0,detach"

Die Kommandos haben dabei folgende Bedeutung:

• (strg+a) + :multiuser on schaltet den Multinutzer Betrieb ein


• (strg+a) + :acladd nutzername fügt den Nutzer nutzername (also z.B. hans) der Zugriffsdatenbank von Screen hinzu, nachdem dieses Kommando ausgeführt wurde, hat der Nutzer alle Rechte in dieser Screen Session


• (strg+a) + :aclchg nutzername -rwx "#?" entfernt die Leserechte (-r), die Schreibrechte (-w) und die Screenkommando Rechte (-x) für alle offenen Screens und Kommandos in dieser Session ("#?")


• (strg+a) + :aclchg nutzername +rx "0,detach" fügt für den Nutzer auf Screen 0 die Lese- und Ausführrechte wieder hinzu, somit kann der Nutzer Screen 0 lesen und sich von diesem wieder abmelden ((strg+a)+(strg+d))

Nach dem die Optionen erfolgreich gesetzt wurden, kann sich der Nutzer mit dem folgendem Befehl anmelden:

screen -x root/root_lese_session

Und jetzt kann die freudige Session beginnen. Bei jedem Tastendruck leuchtet der Screen kurz weiß auf, sodass man als root Nutzer merkt wenn der normale Nutzer hätte etwas eingeben wollen. Das einzige was der normale Nutzer jetzt noch darf, ist sich vom Screen via (strg+a)+(strg+d) abzumelden.

Und schon kann man mit der Schulung, Installationen oder sonstigem beginnen. Wenn Ihr fertig mit eurem vorhaben seid, könnt Ihr die Berechtigungen des normalen Nutzers, ganz eichfach, via

(strg+a) + :acldel nutzername

wieder löschen.

Das Beispiel wurde auf einem Ubuntu 8.04 LTS erstellt. Bitte bedenkt das sich das unter Redhat/CentOS/MacOSX ein wenig anders darstellen kann (je nach Screen Version). Als Hilfe empfehlen sich immer die dazugehörigen man pages von screen. Und jetzt viel Spaß beim ausprobieren!

Heute möchten wir euch 3 kleine, aber wirkungsvolle Tipps für das tägliche Arbeiten an entfernten Computern geben.
In Zeiten wo Administratoren für immer mehr, und vor Allem, immer weiter entferntere Systeme zuständig sind, haben sich im Unix bereich 2 Tools heraus kristallisiert, die für die tägliche Arbeit unabdingbar sind: screen und ssh.

1. Shared SSH Sessions
   Des öfteren arbeitet man mit mehreren Remote Shells auf einem Server. Gerade wenn man am testen, konfigurieren oder debuggen auf einem Server ist, ist dies meist unabdingbar. Um dann auf dem Server durch die angehäuften Shells nicht zuviel Speicher zu nutzen (es kann ja auch mal sein, man arbeitet auf einer Appliance oder einem Router mit etwas weniger Speicher), bietet SSH die Möglichkeit sogenannte Master Verbindungen aufzubauen. Diese sind in der Lage, ihre Verbindung mit mehreren Slave Verbindungen zu teilen. Dazu wird auf dem lokalen System ein Master Socket angelegt, über den die Slave Verbindungen zugreifen können. Daraus resultieren 2 Vorteile:
   
   
   • auf dem entfernten System wird durch die "wiederverwendung" der schon bestehenden Verbindung, Speicher gespart
   • die Slave Verbindungen müssen sich am entfernten System nicht mehr authentifizieren (sehr hilfreich bei gescripteten Sachen)
   
   
   Wie legt man nun eine Master Verbindung an? Ganz einfach, nämlich so:

   ssh -M -o ControlPath=/Pfad/zum/Master/Socket user@host

   Dabei steht ide Option -M für Master und unter der Option -o ControlPath=/Pfad/zum/Master/Socket wird der Pfad zum Kontroll Socket für die Slave Verbindungen angegeben. Der Socket wird dabei unter den jeweiligen Benutzer mit Lese- und Schreibrechten angelegt (0600), ist also für andere Nutzer (ausser natürlich root) nicht les- und schreibbar. Die Slave Verbindungen startet man dann ganz einfach via

   ssh -S /Pfad/zum/Master/Socket user@host

2. Screen lock
   Ist man einmal via SSH auf einem entferntem System angemeldet, ist nichts schlimmer als wenn diese Session durch Verbindungsfehler, sei es die schlechte Verbindung (z.B. nach China) oder das versehentlich geschlossene Fenster, wieder beendet werden. Für solche (und noch viele andere) Zwecke gibt es screen. Screen erstellt einen virtuellen Terminal, der losgelöst vom SSH Prozess auch dann weiter existiert, wenn dieser durch irgendwelche Gründe beendet wird. Hat man jetzt via screen einen Screen gestartet, kann die Verbindung wegbrechen wie sie möchte. Nach einer Wiederverbindung auf das System kann man sich ganz einfach via screen -r den Screen zurück holen und da weiter machen wo man aufgehört hat. Was aber wenn man sensible Daten auf seinem Screen verfolgt (z.B. Log Ausgaben) oder dieser beim Verlassen des Arbeitsplatzes vor fremden Zugriff geschützt werden soll? Auch dafür gibt es eine Lösung: In der laufenden Sceen Session aktiviert man mit der Tastenkombination (strg+A) + (strg+x) (unter Debian, bei anderen Systemen hilft ein Blick in die Hilfe, zu erreichen via (strg+a) + :help + enter) den Screen Lock. Danach ist der Screen nur noch über das Login zu erreichen. Je nach dem was für ein Lock Programm oder eine Version von Screen verwendet, kann man den Screen mit dem Nutzer Passwort oder einem selbst gewählten Passwort entsperren.
   


3. Geteilte Screen Session
   Nun soll es ja auch vorkommen, dass mehr als ein Adminstrator für die Systempflege zuständig ist und man gemeinsam auf einem System an einer Konfiguration arbeitet oder einen Fehler debuged. Aber auch dafür gibt es mit Screen eine Lösung, die vor allem dann sehr toll ist, wenn man gemeinsam Dateien editieren möchte oder jemanden etwas erklären möchte. In diesem Post werde ich euch die geteilte Screen Session mit gleichen Nutzern erklären. Es gibt auch Möglichkeiten mit unterschiedlichen Nutzern eine geteilte Screen Session zu machen, z.B. root als ausführende Kraft und ein normaler Nutzer der nur einen Read-Only Zugriff auf den Screen hat. Nun aber zu ersterer Variante mit dem gleichen Nutzer. Als erstes startet man einen Screen mit einem angepassten Socketnamen via

   screen -S Socketname

   Um den Screen jetzt Multinutzer fähig zu machen, aktiviert man mit der Tastenkombination (strg+a) + :multiuser on diese Funktionalität. Mit dem zweiten Benutzer kann man jetzt via

   screen -x Socketname

   auf die Session zugreifen. Und simsalabim, schreibt der eine Nutzer sieht es der andere Nutzer sofort.
   

Ich hoffe diese Tipps erleichtern euch die tägliche Arbeit auf der Shell..