Ich hab schon lange nichts mehr hierüber geschrieben, die “einfachen” Themen sind ja auch schon durch. Eines der wohl nützlichsten Tools neben den coreutils ist für mich ssh, da man damit extrem flexibel ist. Von überall her ist man ohne grossen Aufwand auf einem beliebigen Rechner und arbeitet damit genau gleich, als wäre man lokal am Gerät. Ok, das wissen die meisten wohl bereits. Es gibt aber noch ein paar Dinge, die einem das Leben mit ssh noch einfacher machen, davon soll dieser Beitrag handeln.

Authentifizerung mit Public-Key (in 2 Schritten)

Als erstes braucht man natürlich ein Schlüsselpaar, dies erstellt man mit ssh-keygen Wer mutig ist kann das Passwort auch einfach leer lassen. Für jeden Rechner, an dem man sich nun damit anmelden will, ist nur noch folgendes zu tun: ssh $host "mkdir -p .ssh; cat >> .ssh/authorized_keys" < .ssh/id_rsa.pubDabei wird auf dem Server das entsprechende Verzeichnis erstellt, falls es noch nicht existiert und danach unseren Public-Key angehängt. Das wars schon! Wenn man das Passwort (für den Schlüssel) nicht jedes Mal eintippen will, dann lohnt es sich, den "ssh agent" einzusetzen. Da dessen Konfiguration jedoch Distributionsabhängig ist, verzichte ich auf eine Erläuterung.

Konfiguration pro Host

Leider kann man sich den Usernamen, den man auf einem Rechner hat, nicht immer aussuchen. Natürlich könnte man sich immer mit user@host verbinden, aber das ist eigentlich unnötig, viel eleganter ist es, die Host-Spezifische Konfiguration in .ssh/config einzutragen. Bei mir sieht die Beispielsweise so aus:
Host dnd
HostName dnd.ch
User mstocker

Host r2
HostName r2.ifs.hsr.ch

Sollte eigentlich selbsterklärend sein. Für die Verbindung reicht nun ein 'ssh dnd' oder 'ssh r2'.

Tunnels

Wenn man einen mühsamen Admin hat, der einem alle möglichen Ports zumacht, kann man dies ziemlich einfach umgehen, und zwar mit local port forwarding.

Nehmen wir an, wir haben einen Laptop im HSR-Netz und würden gerne auf server1:8080 verbinden. Zuhause haben wir einen Rechner stehen, den wir per ssh erreichen können, und welcher auch server1:8080 errreicht. Mit folgendem Befehl wird nun ein Tunnel über den Server zu Hause nach server1:8080 erstellt: ssh -L 80:server1:8080 server_zu_hauseIm Browser über localhost:80 ist server1 nun erreichbar. Ist doch eigentlich ganz einfach!

Mit ssh kann man noch viel wildere Dinge tun, wie z.B. Reverse-Tunnels, mit denen man beispielsweise von zu Hause aus auf den PC im Büro zugreifen kann. Und seit OpenSSH 4.3 sind sogar ganze VPNs möglich...

Jawohl, es ist so weit, KDE 4.0.0 wurde heute veröffentlicht, mit Paketen für die meisten Distributionen, wie man im offiziellen Release Announcement lesen kann. Man kann auch eine der Live-CDs ausprobieren, oder zumindest mal die Screenshots des Visual-Guides anschauen.

Wie das mit einer 0-Version so ist, sollte man etwas nachsichtig sein, vieles wird noch nicht so gut funktionieren wie im aktuellen 3er-Release. Es fehlen auch noch Module, wie beispielsweise die ganzen PIM-Applikationen. Der Mischbetrieb von 3er und 4er Versionen ist aber auch kein Problem.

Viel Spass!

mit Siedler 2. Ja, wirklich, Siedler 2. Und Nein, ich meine nicht “die nächste Generation”, sondern das gute, alte DOS-Spiel. Zum Beweis, ein Screenshot des letzten Tores, im Hintergrund sieht man noch meinen aktuellen Desktop, da ich das Spiel in 1024×768 in der Dosbox laufen habe:

Backups sind ein eher unbeliebtes Thema, genau so wie das bezahlen von Krankenkassenprämien und Versicherungen: Im Moment hat man nichts davon (ausser dass man vielleicht ruhiger schlafen kann), aber wenn mans mal braucht dann ist man ungemein froh darüber.

Im Gegensatz zur Krankenkassenversicherung wird man von niemanden dazu gezwungen, ein Backup auch zu machen. Bitte alle aufstehen, die irgendwo ein System haben, das nicht gebackupd wird. Und jetzt auch noch alle, die zwar ein Backup haben, aber noch nie einen Restore davon ausprobiert haben? Alle die jetzt stehen sollten den folgenden Beitrag lesen, und ich bin mir sicher, dass es einige sind

Ein Backup zu erstellen ist nicht besonders schwer, und man braucht auch bestimmt nicht selbst irgendwelche Skripts zu schreiben.

Ich nutze eigentlich auf allen System Dirvish. Es ist ziemlich einfach zu konfigurieren, und vor allem ist es sehr einfach nachzuvollziehen, was passiert, bzw. was gebackupd wird. Dirvish nutzt Hardlinks für die verschiedenen Versionen des Backups, gleiche Dateien belegen also nicht mehrfach Platz. Vielleicht noch zwei Begriffe: Dirvish legt die verschiedenen Backup-Ziele (sogenannte “Vaults”) in einem “Bank”-Verzeichnis ab.

Zuerst müssen wir Dirvish jedoch noch installieren:

sudo aptitude install dirvish ; sudo emerge dirvish

Wie gesagt, Dirvish braucht eine “Bank” für die Backups, sowie einen Vault pro Backupziel. Unsere Bank erstellen wir in /mnt und nennen sie “backup”. Ein Vault ist nichts anderes als ein Ordner mit einem Unterordner namens “dirvish”, nennen wir ihn “root”.

sudo mkdir -p /mnt/backup/root/dirvish

Danach editieren wir die Datei /etc/dirvish/master.conf, in der die globalen Einstellungen gemacht werden. So könnte es Beispielsweise aussehen:

bank:
        /mnt/backup

# Veranlässt Dirvish, beim Backup auf dem
# aktuellen Filesystem zu bleiben.
xdev: true

# Ein paar nützliche excludes:
exclude:
        lost+found/
        /proc
        /mnt
        /dev
        /sys
        /var/cache/apt/archives/*.deb

# Alle Backups werden grundsätzlich
# nur 30 Tage lang aufbewahrt
expire-default: +30 days

# bis auf das erste jedes Monats,
# das behalten wir ein ganzes Jahr lang:
expire-rule:
# MIN HR DOM MON DOW STRFTIME_FMT
   *   *  1   *   *   +1 year

# Welche Backups/Vaults standardmässig
# gesichert werden:
Runall:
        root

Diese Einstellungen sind für alle Vaults gültig. Danach brauchen wir nur noch eine Konfiguration für das Backup (/mnt/backup/root/dirvish/default.conf):

# Der lokale Name des Rechners
client: Debian-40-etch-64-LAMP

# Und den Pfad, ab dem wir sichern wollen
tree: /

Mehr brauchen wir nicht zu konfigurieren. Tatsächlich sind wir schon fast fertig, wir müssen nur noch den Vault initialisieren und abwarten, während das erste Backup gemacht wird.
dirvish --vault root --init

Per cronjob (/etc/cron.d/dirvish) wird das ganze nun jeden Abend angekickt. Das wars schon!

Ich glaube, es herrscht eine grosse Verwirrung wenn es um das Thema Cut/Copy-Paste unter X geht. Zumindest höre ich oft Dinge wie “es wurde nicht kopiert”, “das Kopierte ist verlorengegangen” und viele wissen auch nicht, dass es zwei verschiedene Buffer gibt.

Vielleicht das Verwirrendste ist, dass beim Kopieren eigentlich noch nichts kopiert wird, sondern das Programm sich beim X-Server meldet und mitteilt, dass es jetzt die Selektion “besitzt”. Wenn nun in einem anderen Programm eingefügt wird, dann holt sich das aktive Programm von Besitzer der Selektion den Inhalt. Dabei kann auch eine “Verhandlung” über den Inhalt geführt werden: Nehmen wir an, ich kopiere im Browser ein Bild. Wenn ich das nun in der Konsole einfüge, wird einfach die URL eingefügt, da die Konsole mit dem Bildinhalt nicht allzu viel anfangen kann.

Ok, was passiert jedoch, wenn das Programm, aus dem kopiert wurde, zum Zeitpunkt des Einfügens nicht mehr läuft? Dann geschieht nämlich nichts, und das verwirrt viele. Natürlich gibt es dafür auch Abhilfe, beispielsweise das KDE-Programm Klipper, welches immer gleich alles kopiert und ausserdem auch noch eine History bietet.

Wie bereits gesagt, gibt es zwei verschiedene Zwischenablagen:

• Immer wenn Text mit der Maus selektiert wird (implizit).
• Über Ctrl^C, bzw. über das Applikations- oder Kontextmenu (explizit).

Das Einfügen geschieht in der ersten Variante mit der mittleren Maustaste und ansonsten wie gewohnt über Ctrl^V.

Ok, ich hoffe damit etwas Klarheit geschafft zu haben

Im letzten Teil ging es ja bereits darum, möglichst einfach Befehle zu wiederholen. Sehr oft will man jedoch bloss ein Argument “wiederverwenden”, also beispielsweise einen Pfad.

Um das letzte Argument (wenns kein Argument hatte dann auch einfach den Befehl) zu wiederholen, tippt man stattdessen einfach das etwas kryptisch aussehende
!$ Es gibt noch einen ganzen Haufen von Möglichkeiten auf spezifische Elemente zuzugreifen, also etwa das 2. Argument des vorletzten Befehls, aber die Syntax dazu kann ich mir nie recht merken.

Wenn man auf die letzten Argumente von weiter zurückliegenden Befehlen zugreifen will, kann man sich auch mit Alt^. recht komfortabel durchwühlen.

Mir geschieht es häufig, dass ich vergesse, gewisse Optionen anzugeben (-r beim Kopieren beispielsweise, oder -rf beim Löschen). Dafür habe ich mir die folgende Funktion (einfach nach .zshrc kopieren) geschrieben, welche den vorherigen Befehl holt, an den Anfang der Zeile springt, ein Wort nach vorne geht und auch schon vorsorglich rechts einen Abstand einfügt:

previous_line_after_first_word () {
        zle up-line-or-history
        zle beginning-of-line
        zle vi-forward-word
        RBUFFER=" $RBUFFER"
}
zle -N previous_line_after_first_word
bindkey ^O previous_line_after_first_word

Das ganze habe ich auf Ctrl^O gelegt.

Im letzten Beitrag ging es um die Navigation auf der aktuellen Eingabezeile, heute weiten wir das aus auf die gesamte History.

Mit dem Befehl $ history lassen sich, je nach Konfiguration, die letzten x-hundert ausgeführten Befehle anzeigen, jeweils mit einer Nummer versehen:

Möchte man nun einen Befehl nochmals ausführen, beispielsweise “kcmshell style”, genügt es, folgendes zu schreiben:
$ !487

Wenn man die ZShell benützt, kann man mit Tab den Befehl auch schon mal vervollständigen.

Mal unter uns, ich nutze die History so eigentlich nicht sehr oft, denn viel einfacher ist es, einfach darin zu suchen. Mit Ctrl^R leitet man die Suche ein, dann einen Teil des Befehls den man sucht eintippen und mit Enter ausführen. Falls der Falsche, also ein neuerer Befehl, auch auf das Suchmuster zutrifft und man nicht noch mehr tippen möchte, kann man mit erneutem Ctrl^R durch die Suchresultate blättern (und mit Ctrl^S übrigens auch wieder noch vorne).

Wenn ich also Beispielsweise an meinem Webserver arbeite, ab und zu eine Konfigurationsdatei verändere und immer mal wieder den Apache neustarten muss, dann reicht es meistens, Ctrl^R res zu tippen und fertig.

Ich glaube, wenn ich jemanden von Linux abschrecken wollte, dann würde ich ihn an einen der PCs hier an der Schule setzen..

• Der Font sieht ziemlich übel aus, aber das kann man zum Glück umstellen, auch wenn ich es nicht sehr schön hinbringe.
• Weshalb ist nur Gnome installiert? Die Partition hat noch 30GB freien Speicher, das reicht für ca. 10 KDE Versionen
• Allgemein ist praktisch kaum Software installiert, z.B. kein IM-Programm, kein GVim, kein Flash-Player …
• Ausserdem hat der Firefox ein Problem mit dem Rendern des Cursors, irgendwie blinkt nur die Hälfte.

Ich nehme es also wirklich niemandem übel, wenn er hier Windows bootet .

Mal ein etwas anderer Beitrag hier, und zwar möchte ich wissen, ob es jemanden interessieren würde, wenn ich hier ab und zu ein paar Hinweise zur Shell-Benutzung geben würde? Also eine Art Mini-Workshop.

Shell-Benutzung? Gibt es nicht schon genügend Seiten im Netz die sich damit befassen? Und abgesehen davon, RTFM! Nun, das mag stimmen, allerdings möchte ich eher die Leute ansprechen, die solche Dinge nicht wirklich suchen und sich dann damit befassen, sondern diejenigen, die nichts gegen kleine (vielleicht wöchentliche) Häppchen haben die sie nach und nach anwenden und so lernen (und hoffentlich verinnerlichen) können.

Alte Hasen und schon mehr oder weniger Erfahrene werden wahrscheinlich gelangweilt sein, aber ich kenne genug Leute, die zwar regelmässig eine Shell benutzen, aber kaum mehr machen als Text eintippen, mit den Cursortasten von links nach rechts navigieren und wenns gut kommt mal mit Cursor-Up den letzten Befehl holen. Mich juckt es dann jeweils in den Fingern und ich muss mich hüten, dass ich nicht “dazwischenfunke” (ok, manchmal kann ich mich auch nicht beherrschen ).

Thematisch werden wohl alle möglichen Themen angeschnitten werden, es müssen auch nicht unbedingt nur shell built-in commands vorkommen, sondern auch andere Unix-Utilities (find und grep beispielsweise).

Da ich mir die Arbeit nicht gern umsonst mache (vielleicht interessiert es ja wirklich niemanden), möchte ich darum bitten, einen kurzen Kommentar zu hinterlassen wenn Interesse besteht. Ein einfaches “+1″ reicht mir schon . Wenn sich mindestens zwei Leute melden dann lohnt sich das schon für mich.

Vor ein paar Tagen ist die neueste Version von Virtualbox erschienen und bei meinem heutigen Update war sie auch schon in Portage. Witzigste Neuerung: Der sogenannte Seamless-Mode, mit dem man Fenster aus der Client-VM “befreien” kann, das sieht dann beispielsweise so aus:

Oder hier der ganze Desktop (man beachte die Startleiste unten im Bild):

Ist echt noch witzig, vor allem um Kollegen zu verblüffen. Leider gibt es noch keine Xinerama-Unterstützung, die Fenster sind also auf ein Display beschränkt, aber das werden die Jungs von Innotek bestimmt noch beheben.