In bester Unix-Tradition stützt sich die Linux-Administration stark auf den geschickten Einsatz zahlreicher kleiner Werkzeuge, die erst im Zusammenspiel ihre volle Leistungsfähigkeit offenbaren. Die LPI-Prüfung 101 legt darum großen Wert auf sichere Kenntnisse der Gnu-Tools.

Welche LPI-Prüfung ist die anspruchsvollste? Selbst Linux-Routiniers stöhnen über die Detailfragen beim LPIC-1. Wer sich das Administrieren durch Learning by Doing erarbeitet hat, dem fehlen plötzlich viele Details und Grundlagen. So mancher Profi findet Prüfung 101 (erste Teilprüfung zum LPIC-1) schwieriger als das Level-2-Examen.

Probleme bei der LPIC-1-Zertifizierung bereitet vor allem die Sektion 103 mit ihren unzähligen Details, Aufrufparametern und Anwendungsproblemen zu Gnu-Tools, zur Shellprogrammierung, der Bash und der Prozessverwaltung. Die vorliegende Folge der LPI-Vorbereitung ist daher ganz diesem Themenkomplex gewidmet.

Die Objectives nennen die abgefragten Programme lückenlos, sodass eine gezielte Vorbereitung mit allen Tools (Tabelle 1) möglich ist. Zu den dort genannten Tools sollten nicht nur die Aufgaben bekannt sein, sondern auch die gebräuchlichen Aufrufparameter. (“Bei welcher Option ignoriert »sort« Groß- und Kleinschreibung?”)

Letzteres ist dank der Fülle von Tools und Parametern nicht gerade leicht. LPI-Prüflinge sollten darum die Manpages aller genannten Kommandos gründlich studieren und sich aufmerksam die sinnvollen Parameter dieser Tools anschauen. Es geht nicht darum, Parameter stupide auswendig zu lernen – das LPI will die vorhandene Erfahrung testen.

Gnu-Tools: Theorie allein reicht nicht

Folgerichtig enthalten die Fragen vorzugsweise Parameter, die ein Vollzeit-Linux-Administrator mit einem guten Jahr Routine sowieso beherrscht. Lesen sollte er zur Vorbereitung nicht nur die Parameter – die geraten bis zur Prüfung größtenteils wieder in Vergessenheit. Wichtiger ist, mit den Tools zu arbeiten, beispielsweise Shellskripte zu programmieren, die die Tools verwenden. Durch aktives Verwenden lernen die meisten Menschen am besten.

Es geht darum, ein Gefühl dafür zu bekommen, wie die Parameter eines Tools typischerweise aussehen, damit später in der Prüfung nach dem Ausschlussverfahren offensichtlich falsche Antworten identifizierbar und im Zweifelsfall wenigstens nach Bauchgefühl erratbar sind. Häufig wird die Antwort nicht exakt bekannt sein, dank Erfahrung ist aber rund die Hälfte der gegebenen Antworten als offensichtlich falsch auszuschließen. Dann bleiben zum Beispiel nur noch zwei mögliche Antworten. Diese Taktik ist legitim: Wer besser rät, hat auch mehr Erfahrung.

Standardtools

Die grundlegenden Funktionen der üblichen Datei-Tools »cp«, »mv«, »mkdir«, »rm« oder »rmdir« dürften bekannt sein, einige besondere Aufrufparameter sind aber wichtig. So kopiert etwa der Befehl »cp -Rpd Quelle Ziel« einen ganzen Dateibaum eins zu eins: rekursiv (»-R«) und unter Beibehaltung der Datei-Attribute (»-p«, preserve,schützen), auch Symlinks löst der Aufruf nicht auf, sondern kopiert sie als Symlink (»-d«, no dereference). Für diese Kombination gibt es die Kurzform »cp -a Quelle Ziel« (»-a«, archiv), aber LPI-Tests fragen die Parameter auch einzeln ab.

Auf das Find-Kommando legt das LPI sehr großen Wert: Es taucht in vielen Fragen auf, da es hervorragend mit vielen anderen Themengebieten kombinierbar ist. Find hat eine lange, aber gut lesbare Manpage (Abbildung 1).

Abbildung 1: Find kann weit mehr als nur nach Dateinamen suchen, wie ein Blick in die ausführliche Manpage verrät.

Gefallen an Find gefunden

Die Suche nach einem Dateinamen mit »find / -type f -name “*.txt”« ist einfach. Sie zeigt, dass der Ausgangspfad des Suchkommandos (hier »/«) keinen besonderen Parameternamen hat und an erster Stelle stehen muss. Danach folgen alle Suchkriterien, auch der Name genießt keine Privilegien, wenn er zusammen mit anderen Suchkriterien benutzt wird. Er muss dann ganz normal mit »-name« angekündigt werden.

Auch die letzten Zugriffe auf eine Datei sind ein Suchkriterium: Die Ausgabe von »ls« enthält diese Werte normalerweise nicht, aber Linux speichert pro Datei nicht nur einen, sondern drei Zeitstempel:

• »atime« (access time) ist der Zeitpunkt des letzten
  Zugriffs.
• »mtime« (modification time) zeigt, wann der
  Datei-Inhalt zuletzt geändert wurde.
• »ctime« (change time) zeigt, wann der Dateistatus
  zuletzt geändert wurde.

Abbildung 2 zeigt Beispiele für Veränderungen der Werte »atime« und »ctime«.

Abbildung 2: Normalerweise nicht zu sehen: Das Dateisystem pflegt für jede Datei mehrere Zeitstempel. Die Zeilen mit geänderten Zeiten sind rot umrahmt.

Nach Zeitstempel suchen

Der Befehl »find . -atime -3« sucht, ausgehend vom aktuellen Verzeichnis, nach allen Dateien, die in den letzten 72 Stunden angefasst wurden, zum Beispiel lesend. »find . -mtime 3« findet Dateien, die vor dreimal 24 Stunden (schreibend) verändert wurden.

Dabei orientiert sich Find nicht an durch Mitternacht getrennten Tagen, sondern denkt in 24-Stunden-Rhythmen. Akzeptiert werden damit alle Zugriffe innerhalb der 24-Stunden-Periode, also Veränderungen vor 49 bis 72 Stunden. Tipp: Die Manpage erklärt den Unterschied zwischen »+3«, »-3« und »3«.

Auch Dateirechte akzeptiert Find als Suchkriterium: »find / -perm 755« sucht Dateien mit den Rechten »rwxrw-rw«, während »find / -perm +111« Dateien ausfindig macht, die mindestens 111 (also die x-Bits) gesetzt haben.

Set-UID-Binaries

Besondere Aufmerksamkeit verdienen Programmdateien mit Set-UID-Bit. Es führt dazu, dass ein Prozess nicht mit den Rechten des aufrufenden Nutzers, sondern mit denen des Dateibesitzers startet. Das Set-UID-Bit nutzen oft Systemprogramme, die zum Erledigen einer bestimmten Aufgabe Root-Rechte benötigen. Passwd ist ein solches Set-UID-Programm, denn ein normaler Anwender könnte sonst mangels Schreibrecht kein Passwort in »/etc/shadow« ändern. Berücksichtigt man Set-UID-Bits, sind Dateirechte eigentlich vierstellig:

• »0755«: Datei/Ordner mit
  »rwxr-xr-x«.
• »4755«: Datei/Ordner mit »rwsr-xr-x«,
  also gesetztem Set-UID- und x-Bit.
• »2755«: Datei/Ordner mit »rwxr-sr-x«,
  also gesetztem Set-GID- und x-Bit.
• »6644«: Datei/Ordner mit »rwSr-Sr–«,
  also Set-UID- und Set-GID-Bit, aber kein x-Bit. Das fehlende x-Bit
  führt zum versal geschriebenen »S«.

Ein Set-UID-Bit ohne x-Bit, wie im letzten Beispiel, hat zwar wenig Sinn, ist aber dennoch möglich und besitzt darum eine spezielle Darstellung in der »ls«-Ausgabe.

Zur Wartung eines Linux-PC gehört auch die gelegentliche Suche nach Dateien, die ein Set-UID- oder Set-GID-Bit gesetzt haben. Das leistet »find / -perm +6000«. Das führende »+« sorgt wieder dafür, dass Dateien gefunden werden, die mindestens eines dieser Rechte gesetzt haben. Für jeden Treffer startet Find auf Wunsch ein Kommando:

find / -perm +6000 -exec cp {} /root/tmp/ ;

Die geschweiften Klammern stehen dabei für den Suchtreffer, das abschließende »;« benötigt einen Backslash als Escape-Zeichen, da es sonst von der Shell interpretiert und nicht an »find« durchgereicht würde.

Exec oder Xargs?

Anwender stoßen bei der Arbeit mit Dateisystem-Tools häufig auf das Problem, dass sie diesen keine Liste von Dateien per Pipe übergeben können, da die Tools die Dateinamen als Parameter, nicht aber an der Standardeingabe erwarten. Kommt ein Aufruf von »find […] -exec« nicht in Frage (weil etwa die Dateinamen schon in einer anderen Datei vorliegen), ist eine Alternative gefragt. Das gilt auch dann, wenn der Find-Aufruf zu viel Zeit benötigt, weil das Kommando für jeden Treffer einen neuen Prozess erzeugt.

Die Alternative heißt Xargs. Das Programm hat trotz des führenden X im Namen nichts mit dem X-Window-System zu tun. Es liest die Standardeingabe und ruft dann das angegebene Kommando auf, dabei übergibt es dem Befehl eine Liste von Argumenten. Die Argumente erzeugt Xargs aus den Daten, die es via Standardeingabe erhält. Normalerweise dienen Leerzeichen, Tabulatoren und Zeilenumbrüche (also alle so genannten Whitespace-Zeichen) als Trenner. Ein einfaches Beispiel ist »find . -name “*.bak” | xargs rm -i«. Der Befehl sucht ab dem aktuellen Verzeichnis nach Backupdateien und löscht sie mit Rückfrage.

Lästige Leerzeichen

Schwierigkeiten verursacht dies, wenn Dateinamen mit Leerzeichen auftauchen. Ein Ausweg besteht darin, sowohl Find als auch Xargs darauf umzustellen, die Dateinamen mit einem Nullzeichen (Ascii-Wert 0) abzuschließen beziehungsweise die Argumente in diesem Format zu erwarten:

find / Parameter -print0 | xargs -0 Befehl

Abbildung 3 zeigt, wie die Zusammenarbeit über Nullbytes funktioniert. Für komplexere Befehle (die etwa die Xargs übergebenen Dateinamen mehrfach enthalten sollen) bietet Xargs die Option »-i«, die einen Platzhalter definiert, der in dem folgenden Befehl wieder auftaucht. Dann ändert sich aber das Verhalten von Xargs: Nur noch Leerzeilen gelten als Trennzeichen, das Programm ruft das Kommando für jedes Argument einzeln auf. Damit ist es beispielsweise möglich, Dateien umzubenennen, zu kopieren und so weiter:

cat dateiliste.txt | xargs -I XXX mv XXX /tmp/test-XXX

Abbildung 3: Über spezielle Optionen arbeiten Find und Xargs optimal zusammen. Statt wie üblich per Leerzeichen, trennt Find die gefunden Filenamen dank der Option »-print0« mit einem Nullbyte. Im Unterschied zu Leerzeichen kann ein Nullbyte nie als Teil eines Dateinamens auftauchen. Xargs passt sich an und interpretiert dank »-0« nur noch das Nullbyte als Trennsymbol. Der »rm«-Befehl weiß daher, dass er die Datei »Mit Blanks.bak« löschen soll.

Oder besser gleich ohne den überflüssigen Cat-Aufruf, der preisverdächtig für den “Useless Use of Cat Award” [3] wäre: »xargs -I XXX mv XXX /tmp/test-XXX < dateiliste.txt«. Dank der Eingabeumlenkung liest Xargs wieder den Inhalt der Datei »dateiliste.txt«.

Prozesse und Prioritäten

Die Verwaltung von Prozessen behandelt der LPI-Test schon deutlich entspannter. Der Befehl »ps axu« zeigt zu den Prozessen auch Informationen über CPU- und Speicherverbrauch (Usage). Einen mit [Strg]+[Z] angehaltenen Prozess zeigt »jobs« als gestoppten Prozess an, »fg Job-ID« oder »bg Job-ID« setzen ihn fort – im Vorder- oder Hintergrund. Wichtig: »fg« und »bg« erwarten die Job-ID, nicht die Prozess-ID.

Prozesse, die im Hintergrund laufen, geben dennoch ihre Ausgaben auf das Terminal aus. Wer dies vermeiden will, leitet die Ausgabe in eine Datei oder nach »/dev/null« um, zum Beispiel mit »Kommando > /tmp/bla.txt«. Linux unterscheidet dabei zwischen der Standardausgabe (Stdout, »Kommando 1> /dev/null«) und der Standardfehlerausgabe (Stderr, »Kommando 2> /dev/null«). Um beide gemeinsam umzuleiten, sind zwei Methoden möglich, wobei die zweite Variante einfacher ausfällt:

Kommando  1> /dev/null  2>&1
Kommando  &> /dev/null

Manchmal sollen Prozesse im Hintergrund weiterlaufen, obwohl sich der Administrator mit seiner Login- oder SSH-Shell wieder verabschieden möchte. Dies führt normalerweise zum Abbruch aller darin gestarteten Prozesse, sofern er sie nicht explizit mit »nohup Kommando &« abgekoppelt hat. Damit die Ausgaben des Kommandos nicht im Nirwana verschwinden, schreibt Nohup sie in die Datei »nohup.out«.

Ebenfalls zur Jobverwaltung gehören die Tools »nice« und »renice«, welche die Prozesspriorität beeinflussen. Die Skala reicht von -20 (nicht nett, hohe Priorität) bis +19 (sehr nett, niedrige Priorität), Abbildung 4 zeigt eine Prozessliste mit verschiedenen Nice-Werten. Einen Nice-Level +20 gibt es nicht. Anwender können lediglich positive Nice-Werte vergeben, nur Root darf die nicht netten negativen Nice-Level vergeben.

Abbildung 4: Es muss nicht immer »top« sein: Auch »ps« zeigt Nice-Werte (in der rot umrahmten Spalte) an.

Vorsicht: Parameterstrich und Minuszeichen sind schnell verwechselt. Über »nice -19 Kommando« startet das Kommando mit positivem Nice-Wert, also geringer Priorität. Es ist gleichbedeutend mit »nice -n 19 Kommando«. Erst ein »nice –19 Kommando« oder – besser lesbar – »nice -n -19 Kommando« verleiht dem Kommando eine höhere Priorität.

Skript-Programmierung

Auch Shellskripting ist ein LPI-Prüfungsthema. Shellvariablen gelten zunächst nur in der Shell, in der sie gesetzt werden. Programme, die aus einer Shell heraus starten, haben keinen Zugriff auf diese Variablen. Erst durch Exportieren werden sie an Subshells oder Programme “vererbt”. Zum Exportieren stellt man der Wertzuweisung den Befehl »export« voran (»export MAIL=/var/spool/mail/tux«) oder exportiert eine bereits zugewiesene Variable nachträglich:

MAIL=/var/spool/mail/tux
export MAIL

Wenn die später gestarteten Programme eine exportierte Variable verändern, bleiben diese Änderungen lokal, in der Vater-Shell behalten sie ihren alten Wert:

$ export A=5
$ bash
$ A=3
$ echo $A
3
$ exit
$ echo $A
5

Sehr praktisch sind die Here-Dokumente: Ein Skript darf mehrzeilige Eingaben direkt im Text enthalten und kann sie per Pipe an ein Kommando weiterleiten. Die Shell liest den Here-Dokumentenblock bis zum definierten End-Codewort und übergibt ihn als Standardeingabe an das Programm (Listing 1).

01 $ cat <<EOM  | mail root@localhost
02 Subject: Test
03 
04 Ich bin ein HERE-Dokument.
05 EOM steht für end-of-mail, EOT für
06 end-of-text. Aber jedes andere
07 Wort wäre auch ok.
08 
09 EOM

Datenströme verändern

Es bleibt noch ein Blick auf die sehr unterschiedlichen Texteditoren Sed und Vi. Beide gelten zu Recht als komplex und kompliziert, aber auch als sehr mächtig. Der Name Sed ist die Abkürzung für Stream Editor, weil er nicht mit Dateien, sondern einem Datenstrom arbeitet. Er manipuliert Daten in einer Pipe-Kette, was ihn für viele Administrationsaufgaben empfiehlt. Bei der Skriptprogrammierung ist Sed wichtig, weil er dabei hilft, bestimmte Aufgaben automatisiert über Aufrufparameter abzuarbeiten, wo sonst Handarbeit angesagt wäre.

Der wichtigste Einsatzzweck von Sed ist die Suchen-und-Ersetzen-Operation. Sed folgt dabei der Syntax »sed s/Suche/Ersetze/«. Das »s« (substitute, ersetzen) stößt das Kommando an – in Schrägstriche eingeschlossen steht das Suche-Ersetze-Muster (Listing 2).

01 $ echo Sonne | sed s/S/W/
02 Wonne
03 $ echo Wonne | sed s/n/l/
04 Wolne
05 $ echo Wonne | sed s/n/l/g
06 Wolle
07 $ echo tux@tux.de | sed "s/[a-zA-Z]*.[a-zA-Z]*/example.com/"
08 tux@example.com

Der zweite Aufruf zeigt, dass Sed zunächst nur den jeweils ersten Treffer ersetzt: aus “Wonne” wird “Wolne”, nicht “Wolle”. Erst der Parameter »g« (global) hinter dem letzten Schrägstrich sorgt dafür, dass Sed alle Treffer ersetzt. Das letzte Beispiel benutzt reguläre Ausdrücke (Kasten “Reguläre Ausdrücke”) und entschärft das Sonderzeichen ».« daher per Backslash.

Sed kann noch deutlich mehr, es ist auch jenseits der LPI-Prüfungsvorbereitung sehr nützlich. LPI-Kandidaten benötigen grundlegende Kenntnisse zu regulären Ausdrücken; Profi-Wissen ist nicht erforderlich. Der Kasten enthält die wesentlichen Informationen.

Vi, der Klassiker

Auch der klassische Unix-Editor Vi spielt im LPI-Test eine Rolle. Die Objectives listen ein Dutzend Vi-Befehle. Die Fragen beschränken sich auf grundlegende Kommandos (Suchen und Ersetzen; Block lesen, speichern oder löschen) und einfache Bewegungsaktionen (fünf Zeilen hoch, zwei Wörter nach rechts, an den Zeilenanfang). Prüfungsfragen sind sowohl, aus einem vorgegeben Vi-Kommando die Aktion herauszulesen, als umgekehrt, zu einer Aufgabe das Kurzkommando zu erkennen.

Für viele Kandidaten entscheidet sich im Bereich 103 der Erfolg oder Misserfolg ihrer Prüfung, wobei viele den nötigen Aufwand zum Einarbeiten in die zahlreichen Tools und ihre Parameter unterschätzen – allen Warnungen zum Trotz. Dabei ist gerade dieser Bereich sehr systematisch und strukturiert erlernbar und macht sogar viel Spaß. Tabelle 1 listet alle Tools auf, die die LPI-Unterlagen als prüfungsrelevant erwähnen.

Gute Kenntnisse sind darüber hinaus auch für die eigene tägliche Arbeit ein echter Zeitgewinn. Für die Prüfungsvorbereitung gilt es also, den Spieltrieb zu wecken und zu basteln, zu basteln und nochmal zu basteln. (hge)