Einträge von Maddin

Wie Ihr ja sicherlich schon mitbekommen habt, sind wir relativ große Apple Fanbois (ich mehr, der Rob weniger) und somit war es für uns auch selbstverständlich, dass wir uns die neu Magic-Mouse bestellen. Doch leider schafft es Apple in letzter Zeit uns immer wieder, uns zu enttäuschen. Das erste Problem sind die akuten Lieferprobleme der neuen Magic-Mouse. Muss man denn ein Produkt releasen, welches erst 3 Monate später überhaupt käuflich zu erwerben ist. Ich weiß ja nicht wie es in euren Städten aussieht, aber weder über Amazon, noch über den Cyberport-Store in Dresden oder beim anderen Apple-Resellern waren die Mäuse erhältlich. So kam es, dass wir sage und schreibe 4 Monate auf unsere Mäuse warten mussten

Wir freuten uns also, als letzte Woche eine Mail im Briefkasten lag in der stand, dass unsere Magic-Mäuse abholbereit wären. Also hin zum Händler des Vertrauens und abgeholt die Ware. Aber schon nach dem auspacken gab es die erste Entäuschung. Keine Ladeschale oder Ladekabel, die Maus funktioniert mit herausnehmbaren AA Batterien. Wieviel kam die Maus gleich nochmal? 70€? Da hätte man Mehr erwartet. Also ausgepackt die Ware und mit den MacBookPro's gepeert. Hier gab es Apple-typisch keine Überraschungen, alles klappte First-Try ohne Probleme.

Wer das Trackpad der aktuellen MacBook (Pro) Reihe gewöhnt ist, wird sich relativ schnell an die Gesten der Magic-Mouse gewöhnen und diese auch lieben. Was allerdings stört, ist die für uns zu langsame Zeigergeschwindigkeit (auf Maximum gestellt aber IOHO immer noch zu langsam). Wie das bei der Auflösung der CinemaDisplay's wird (sind ja leider immer noch in Reperatur, siehe hier und hier), können wir uns im Moment noch nicht so recht vorstellen. Auch treten komische Nebeneffekte bei der Verwendung mit der Magic-Mouse auf, die vorher mit einer kabelgebundenen Maus nicht aufgetreten sind. Bei mir zum Beispiel, fängt die Maus bei CPU-lastigen App's (z.B. FF mit viel Flash oder JS) an zu "stocken". Warum das so ist und ob das an der Bluetooth-Verarbeitung liegt, konnten wir noch nicht festellen.

Im Endeffekt lässt sich sagen, dass die Magic-Mouse eine optisch sehr anprechende, aber leider überteuerte Maus ohne Magie ist. Leider ein Apple-Produkt mehr, welches uns nicht überzeugen konnte.

Seit langen hatte ich mir vorgenommen die Richtlinien für Passwörter auf meinem Macbook zu ändern. Als ich heute endlich dazu kam und mir Linux-like die manpage des von Darwin verwendeten passwd Programms anschaute, merkte ich schnell, dass die Konfiguration der Richtlinien unter Mac OS X ein wenig anders zu sein scheint, als ich es gewohnt war.

Um es vorweg zu nehmen, es gibt 2 Varianten um die Richtlinien anzupassen - eine Nerdige via Konsole und eine Windows-like grafische mit einem Tool. Die einfachere von beiden ist sicher das GUI-Tool von Apple, welches sich in den Server Admin Tools versteckt und auf dem Namen Arbeitsgruppenmanager hört. Über dieses Tool könnt Ihr euch lokal auf euren Mac verbinden (auch wenn eine Warnmeldung kommt, dass man nur mit einer lokalen Konfigurationsdatenbank arbeitet) und in diesem Änderungen vornehmen. Hier empfiehlt es sich auf den gewünschten User zu klicken um dann unter Erweitert --> Optionen die gewünschten Richtlinien vorzunehmen.

Die zweite und imho etwas mächtigere Variante (ich habe in der GUI z.B. keine Einstellung für passwordCannotBeName, requiresAlpha oder requiresNumeric gefunden), ist das Tool pwpolicy. Dieses sollte per default auf euren Mac's installiert sein. Um euch einigen Ärger und Logs durchwühlen zu ersparen, nutzt das Tool nur als root bzw. Systemverwalter + sudo. Ich würde euch auch empfehlen als erstes die manpage des Programmes zu lesen und erst danach die gewünschten Einstellungen vorzunehmen. Ich z.B. habe mein Ablaufdatum der Passwörter für meinen User auf 90 Tage gestellt sowie die Passwort-Länge auf mindestens 8 Zeichen gesetzt. Dies erfolgt mit dem Befehl

pwpolicy -u ich -setpolicy "maxMinutesUntilChangePassword=129600 minChars=8"

Danach kann man sich via

pwpolicy -u ich -getpolicy

die geänderten Einstellungen ansehen.

Viel Spass beim ausprobieren.

Wie Rob in einem unserer letzten Einträge schon berichtete, wiesen unsere beiden Cinema Display's schwarze Flecken im unteren linken Bereich des Bildschirms auf. Meiner wurde also nun als erstes in die Reperatur gegeben. Da dies über Weihnachten eingeschickt wurde, ist die Reperaturdauer von 3 Wochen in Ordnung.

Also freute ich mich schon heute endlich wieder mein Cinema Display beim Händler unseres Vertrauens abzuholen und es wieder an meinem MacBookPro zu betreiben. Also das Display abgeholt, ausgepackt, angeschlossen und gewartet. Das erste Gute was auffiel, die Flecken waren weg und das Display tat auf den ersten Blick seinen Dienst.

Nach einigen Sekunden fiel mir aber auf, dass das Display sehr hell eingestellt war. Logischerweise drückte ich auf meiner Tastatur F1 bzw. F2, welche normalerweise die Helligkeitsregelung für das Display sind. Aber es tat sich Nix . Auch nach mehrmaligen drücken der Taste erschien keine Helligkeitsanzeige auf dem Display. Im zweite Versuch öffnete ich die Systemeinstellungen --> Monitore, aber auch da gab es keinen Schieberegler für die Helligkeit. Unter dem Punkt "Farben" meldete sich mein CinemaDisplay aber kommischer Weise als iMac an??! Nach etwas googlen und der Suche im Apple-Forum, ring ich mich dann durch, doch einmal die Apple-Support-Hotline zu belasten. Nach jedoch 30 Minuten ohne Lösung (zum "günstigen" Apple Preis von 4,50€) kam der Support Mitarbeiter zu dem Punkt, dass das Display sich wahrscheinlich als iMac im Display-Modus ausgibt (obwohl keine Elektronik bei der Reparatur getauscht wurde) und es doch noch einmal zur Reparatur geschafft werden muss. Ja und das ist irgendwie suboptimal.

Wir werden uns jetzt wahrscheinlich nach anderen Monitoren umsehen. Falls es Neuigkeiten gibt, geben wir natürlich Bescheid.

Heute möchte ich euch die Chemnitzer Linux Tage etwas näher bringen. Wie jedes Jahr findet dieser wieder im März (diesmal am 13. und 14. - dick im Kalender einkreisen) in den Hörsaal- und Seminar-Gebäuden der Technischen Universität Chemnitz statt.

Eines der Themengebiete des diesjährigen CLT lautet Dienste und Dämonen und soll die Protokolle und ihre Implementierungen, sowie die Anwendungsgebiete und Geschäftsmodelle dem interessierten Linux-Nutzer etwas näher bringen. Andere Themengebiete sind zum Beispiel der Desktops und der Embedded-Bereich. Erstmalig wird es dieses Jahr einen Kernel-Track geben, in dem sich interessierte Nutzer über die Entwicklungen im, sowie das eigentliche Programmieren am Kernel informieren können. Das gesamte Programm (leider noch nicht komplett Fertig) findet Ihr auf dieser Webseite.

Auch werden dieses Jahr wieder einige Herrsteller (u.a. AMD, Zarafa, Debian) ihre Produkte vorstellen und mit einem Stand vertreten sein. Für das leibliche Wohl wird ebenfalls gesorgt, denn im oberen Stockwerk wird es wieder eine Cafetaria geben in der man zum kleinen Preis Snacks und Getränke kaufen kann.

Die letzten 2 Jahre waren auf jedenfall sehr interessant und einige der Vorträge sehr sehenswert. Als Geheimtipp kann ich euch den Vortrag von Hans-Jürgen Schönig über PostgreSQL empfehlen. Dieser war die letzten 2 Jahre, wenn auch nicht der informationsreicheste, jedoch vom Humor und der Durchführung der beste Vortrag der ganzen CLT (Hans-Jürgen FTW ).

Auch die Eintrittspreise sind sehr Human gehalten. Das Wochenendticket kostet 5 EUR, sowie ermäßigt 3 EUR. Es würde mich freuen wenn sich ein paar von euch durch den Artikel anmimieren lassen, die Chemitzer Linux Tage einmal zu besuchen. Bis dahin und eventuell sieht man sich ja auch da.

Einen fleißigen Weihnachtsmann sowie einen guten Rutsch und erholsame Tage wünschen euch das Admin-Blog-Team a.k.a Rob, Maddin und Frank.

Wie Ihr sicherlich schon auf den gängigen IT-News Seiten gelesen habt, betreibt Google jetzt einen eigenen DNS Service. Das Ziel dessen ist es das Internet sicherer und performanter zu machen. Der Service selbst ist nur ein Resolver Dienst, d.h. er gibt die eigentlichen Anfragen an die authorisierten DNS Server der angefragten Domain (DNS SOA) weiter und merkt sich dann die Antwort. Somit ist es nicht möglich, sich bei Google eine eigenen DNS Zone anzulegen, wie das zum Beispiel bei DynDNS der Fall ist.

Unsere ersten Test's ergaben, dass die Antwortzeiten vor allem bei ausländischen Seiten um etwa 20%-40% schneller sind. Dies scheint aus dem guten Netzwerk zu resultieren, das sich Google mittlerweile aufgebaut hat. Einem Testbetrieb der Google DNS Server steht somit erst einmal nichts im Weg.

Vielleicht könnt Ihr uns eure ersten Erfahrungen der Google DNS Server mitteilen?!

Das Skript, welches ich zum testen gebaut habe, findet Ihr hier: dns_test.sh
Es macht nicht's anderes, als eine paar Domains mehrmals hintereinander erst auf den Google DNS und dann auf den eigenen DNS Server aufzulösen. Die daraus resultierenden Durchschnittswerte werden dann ausgegegben.

Heute mal ein etwas kürzerer Beitrag von mir. Ich stand vor kurzem vor dem Problem die default resource limit Werte meiner Linux-Box auslesen zu müssen, um zu wissen ob ein Programm mit der zu testenden Konfiguration auch wirklich sauber läuft (im speziellen ging es um die Möglichkeit den virtuellen Speicher des Prozesses komplett im Hauptspeicher zu behalten, welches mit mlock() möglich ist, es gibt aber ein resource limit, nämlich RLIMIT_MEMLOCK welches die größe beschränkt). Da ich weder ein Tool, noch sonst irgend etwas gefunden habe, was dies möglich macht, habe ich es einfach selber gecoded .

Eventuell benötigt einer von euch das ja irgenwann einmal. Das Tool, welches ein quickhack in C ist , gibt es hier: getrlimits.c
Kompiliert bekommt Ihr das ganze via gcc -o getrlimits getrlimits.c.

Ich bin letztens auf eine Webseite der NSA (National Security Agency - Nachrichtendienst der USA) gestossen, in der Sicherheitstipps für verschiedene Software und Systeme zur Verfügung gestellt werden. Unter anderem befinden sich da auch Tipps für das absichern und härten von Mac OS X (Panther, Tiger und Leopard).

Ich möchte euch ein paar Tipps davon beschreiben und erklären. Einige der Tipps können ohne Probleme von allen Mac Usern durchgeführt werden. Andere wiederum sollte man nur konfigurieren, wenn man ein wenig Hintergrundwissen zum Thema hat. Ich werde diese gegebenenfalls kennzeichnen, denn wir wollen ja nicht das Ihr euch euer System zer-sichert-schießt.

Bitte beachtet auch, dass ein System was hochsicher ist, nicht unbedingt Benutzerfreundlich ist. Eine hochsicheres System, welches Benutzerfreundlich ist, gibt es leider nicht (zumindest habe ich dieses noch nicht gefunden, ich bin aber auch eher der Sicherheitsfreak und lebe gern mit dem höheren Aufwand). Die folgenden Tipps sind auf (Snow) Leopard ausgelegt.

1. arbeiten als normaler Nutzer
Der erste Tipp ist zugleich auch der einfachste und gilt quasi für alle Betriebssysteme. Normale arbeiten (E-Mails lesen, Web browsen, Office arbeiten) sollte man als normaler Nutzer ohne Administrator-Rechte ausführen. Wahrscheinlich könnte der großteil aller Angriffe auf Computer-Systeme verhindert werden, wenn die Nutzer mit normalen Rechten arbeiten würden. Denn sobald es eine Schadsoftware auf den Computer geschafft hat, stehen dieser Tür und Angel offen, denn als Benutzer mit Admin-Rechten darf diese alles machen. Als erstes sollte man unter Systemeinstellungen --> Benutzer einen Adminstrator-Account einrichten. Als Tipp kann ich euch bei der Kennwortvergabe das kleine Schlüsselsymbol geben. Einmal geklickt erscheint ein weiteres kleines Fenster, bei dem Ihr Hilfe bei der Kennwortgenerierung erhaltet.

2. Software Updates
Auch der 2. Tipp könnte nicht einfacher sein. Haltet euer System auf einem aktuellen Stand und nutzt die zur Verfügung stehenden Updatemechanismen (Systemeinstellungen --> Sofwareaktualisierungen oder bei Apple).

3. Benutzerkonto Einstellungen
Deaktivieren des automatischen Logins und des Anzeigen der Nutzer Liste (Systemeinstellungen --> Benutzer --> Anmeldeoption). Somit wird es einem Angreifer der sich physikalischen Zugriff zum System verschafft hat, zumindest erst einmal schwerer gemacht sich am System anzumelden bzw. herauszufinden welche Nutzer überhaupt im System existieren.
Deaktivieren des Gast-Benutzerkontos und des Sharings (Systemeinstellungen --> Benutzer --> Gast Konto). Deaktiviert das Gast-Benutzerkonto sowie das Anmelden an Freigaben als Gast.

4. Sicherheits Einstellungen
Kennwort erforderlich nach Ruhezustand oder der aktivierung des Bildschirmschoners Systemeinstellungen --> Sicherheit --> Kennwort erforderlich --> Sofort. Eigentlich können im Allgemein Tab alle Häkchen gesetzt werden. Diese sollten alle selbsterklärend sein. Sicheren virtuellen Speicher verwenden bedeutet, dass geswappter Speicher also Speicherbereiche die aus dem RAM auf die Festplatte geschrieben werden, verschlüsselt abgelegt werden. FileVault bietet sich für diejenigen an, die ein mobilen Mac besitzen. Bei der aktivierung von FileVault wird der "Inhalt" der Festplatte verschlüsselt. Bitte bedenkt, dass nach dem verschlüsseln das TimeMachine Backup nicht mehr wie im gewohnten Umfang funktioniert (es kann nur noch die komplette Festplatte sichern, da die Daten verschlüsselt abgelegt sind und somit kein Diff des Filesystems möglich ist). Auch sollte Ihr bei FileVault nicht das Hauptkennwort vergessen, da sonst alle Daten verloren sind. Im Firewall Tab empfiehlt es sich natürlich die Firewall zu aktivieren und unter den Weiteren Optionen den Tarn-Modus zu aktivieren und nur bekannte Programme zuzulassen (in meinem Fall z.B. ssh).

5. Netzwerk Konfiguration
Deaktivieren von IPv6 wenn nicht benötigt. Systemeinstellung --> Netzwerk --> Weitere Optionen --> TCP/IP Tab --> IPv6 konfigurieren: Aus. Solange IPv6 nicht benötigt wird, kann dies auch deaktiviert werden. Solltet Ihr zudem eurer AirPort Netzwerk nicht benötigen, deaktiviert es.

6. suid und sgid Programme finden (advanced)
Sucht euch alle suid und sgid Programme auf euren Mac und ändert diese zu normalen Programmen ab, solange dies möglich ist. Sollten suid Programme dem Root Nutzer gehören (User <-> suid oder Gruppe <-> sgid) werden diese auch als Root Nutzer ausgeführt. Meistens benötigen diese Programme diese Rechte gar nicht. Um alle suid Programme zu finden, führt Ihr find / -perm -4000 -ls aus und um alle sgid zu finden, nehmt Ihr find / -perm -2000 -ls. Solche Tools wie rsh und rlogin benötigen sicher keine Root Rechte. Um die gefunden Programme anzupassen, nehmt Ihr am besten chmod (z.B. chmod u-s Programm für das enfernen des suid Bits)

7. Benutzerordner restriktieren
Damit andere Benutzer nicht in eurer "Heimatverzeichnis" per default hinein sehen können, empfielt es sich diese via chmod og-rx /Users/Nutzername abzusichern.

Beachtet Ihr diese Hinweise, sollte euer Mac schon ein bisschen sicherer sein . Natürlich kommen zum Thema Sicherheit noch viele andere Faktoren hinzu (Nutzer, Software, Umgebung), aber der Anfang sollte damit getan sein. Diese und noch viele weitere Tipps findet Ihr in den besagten PDF's der NSA, welche ich sehr empfehle zu lesen.

Heute vor 5 Jahren erblickte ein neuer Browser das Licht der Welt: Mozilla Firefox. Firefox enstand damals aus der Mozilla-Browser-Suite, die einen Browser, einen E-Mail-Client sowie einen RSS-Reader enthielt. Dies schien den damaligen Entwicklern ein zu aufgeblähtes Produkt, weshalb man sich entschied einen eigenständigen Browser zu entwickeln. Und war heraus kam, ist meiner Meinung nach, der beste Browser der Welt

Hier noch einmal einen herzlichen Glückwunsch an die Mozilla-Foundation für dieses tolle Produkt und ein Happy Birthday an Firefox!

Firefox ist unter anderem dafür bekannt, durch seine Add-ons beliebig erweiterbar zu sein. Und das nicht zu unrecht. Im Moment gibt es sage und schreibe etwa 38.682 Add-on Sammlungen und etwa 163.819.085 Add-ons sind derzeit in Benutzung. Eine statistische Übersicht dazu findet man bei Mozilla selbst.

Heute möchte ich euch meine für mich wichtigsten und beliebtesten Add-ons vorstellen (alphabetisch geordnet):

• Adblock Plus
  
  
  
  • eins der wichtigsten Plugins, denn ich hasse Werbeeinblendungen auf Webseiten, hilfreich für jeden der sich im Web bewegt
  
  
  
  


• ColorZilla
  
  
  
  • ist ein Add-on um Farbbestimmungen durchzuführen, zum Beispiel mit dem ColorPicker, sehr zu empfehlen für Webentwickler
  
  
  
  


• DomainDetails
  
  
  
  • zeigt in der unteren Statusleiste Informationen über den Domainnamen, gelieferte Server-Header, IP-Adressen und Geo-Lokalisierungen an, hilfreich für die Admin's unter uns
  
  
  
  


• FireGestures
  
  
  
  • nachdem es die MouseGestures für den Firefox 3.x leider nicht mehr gab, habe ich diese installiert, dient der Navigation im Browser mit der Maus, hilfreich für Geeks
  
  
  
  


• Flashblock
  
  
  
  • blockt Flash, ich mag kein Flash
  
  
  
  


• LiveHTTPHeaders
  
  
  
  • ein sehr gutes Add-on zum debuggen von HTTP-Request's, zeigt alle Request's vom und zum Browser, hilfreich für Admin's
  
  
  
  


• Lori
  
  
  
  • Life of request info, ein sehr geniales Add-on, zeigt in der unteren Statusleiste Statistiken zum Aufbau (Sekunden zum ersten Byte, Sekunden zum vollständigen Laden, Summe KB) von Webseiten an, sehr hilfreich für Admin's
  
  
  
  


• ModifyHeaders
  
  
  
  • ein Add-on zum editieren der zu sendenden HTTP-Header, hilfreich für das debuggen von Webanwendungen
  
  
  
  


• NagiosChecker
  
  
  
  • wahrscheinlich das wichtigste Add-on überhaupt, zeigt den Nagios-Status in der unteren Statusleiste, unverzichtbar für Admin's die Nagios nutzen
  
  
  
  


• ShortenURL
  
  
  
  • dieses Add-on nutze ich, seitdem mich der Rob dazu gezwungen hat diesen ganzen Web 2.5-3.0 Stuff mitzumachen , kürzt URL's mit einem beliebiegen Dienst sofort im Browser
  
  

Eventuell findet Ihr hier ein tolles Add-on für Euch. Über gute Add-on Tipps in den Kommentarten würde ich mich natürlich sehr freuen!

Heute wieder ein Trick aus der Linux-Admin-Ecke an euch. Es kommt ja öfters vor, dass bei einem Update nur einige System-Bibliotheken geupdatet werden und man das System deswegen ja nicht unbedingt neu starten muss.
Allerdings werden von gestarteten Programmen immer noch die Bibliotheken verwendet, die vor dem Update aktuell waren, solange diese Programme nicht neu gestartet werden. Dies kann dazu führen, dass die Systeme, obwohl man sie aktuell hält, dennoch verwundbar sind.

Um alle gelöschten oder veränderten und dennoch verwendeten Bilbiotheken heraus zu finden, führt man nach dem Update auf seinen Systemen folgendes Kommando aus:

lsof -n | egrep -i "(DEL|inode)"

Danach sollte man eine Augabe ähnlich dieser erhalten:

server:~# lsof -n | egrep -i "(del|node)"
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
nrpe 1111 nagios mem REG 9,1 22637092 /usr/lib/libssl.so.0.9.8 (path inode=22638819)
dbus-daem 2222 messagebus mem REG 9,1 22635753 /usr/lib/libexpat.so.1.5.2 (path inode=22638405)
apache2 3333 www-data mem REG 9,1 22635753 /usr/lib/libexpat.so.1.5.2 (path inode=22638405)

Dabei wird über das del nach gelöschten Dateien und Dateien die zwar noch im Speicher gemapped sind, aber auf der Festplatte nicht mehr existieren, gesucht. Das node sucht nach der Ausgabe path inode=, also nach inodes die sich verändert haben. Bei meiner Ausgabe sieht man das die Programme nrpe, dbus und apache2 also einmal neugestartet werden müssten, da diese alte Versionen der Bibliotheken verwenden.

Wie ich bei meiner Recherche gerade herausfand, gibt es für Debian das Paket debian-goodies, welches das Tool checkrestart enthält. Dieses übernimmt genau diese Aufgabe und teilt euch mit, welche Init-Scripte ausgeführt werden müssen :

server:~# checkrestart
Found 7 processes using old versions of upgraded files
(2 distinct programs)
(2 distinct packages)

Of these, 2 seem to contain init scripts which can be used to restart them:
The following packages seem to have init scripts that could be used
to restart them:
dbus:
1111 /usr/bin/dbus-daemon
apache2-mpm-prefork:
22222 /usr/sbin/apache2
2222 /usr/sbin/apache2
23232 /usr/sbin/apache2
32323 /usr/sbin/apache2
22322 /usr/sbin/apache2
33233 /usr/sbin/apache2

These are the init scripts:
/etc/init.d/dbus restart
/etc/init.d/apache2 restart

Eine von beiden Möglichkeiten wird euch sicher helfen

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!