Man sollte nicht immer alles so hinnehmen, was Andere so schreiben — egal wie sehr man ihnen Profession anerkennt. Bestes Beispiel ist der Artikel von MacMacken zum Thema IPv6-Privatsphäre. Da verweist er auf einen Artikel der Zeitschrift c´t in dem es um die Privacy Extension für IPv6 geht und darum, das diese bei OSX nicht per Default aktiviert sind. Eine Aufklärung, wie man diese denoch bei OSX aktiviert wird aufgezeigt. Da dieses Aktivierung per sysctl (also per Befehlszeile) erfolgt, ist sie somit auch nicht Neustart-sicher. Die Lösung der c´t lautet daher ihren selbstgebauten LaunchDaemon herunterzuladen und zu installieren. Dabei gibt es, wie auch bei anderen *nix/BSD-Betriebssystemen, eine deutlich einfachere Lösung:

Man lege eine Datei /etc/sysctl.conf mit dem Inhalt

net.inet6.ip6.use_tempaddr=1

an und nach einem Reboot kann man mit dem Befehl

sudo sysctl net.inet6.ip6.use_tempaddr

herausfinden, das das Ergebnisist und somit die Einstellungen wirken.

Es hilft in Zukunft also durchaus mal nachzudenken und das auszuprobieren, was bei anderen *nix/BSD-Betriebssystemen auch funktioniert — auch eine mehr oder minder renomierte Zeitschrift wie die c´t kann sich irren. Übrigens verweist Apple in seinen man-Pages selbst auf sysctl.conf .

Wenn man öfter auf der Kommandozeile arbeitet lernt man die History-Funktion zu schätzen. Hier eine lose Aufstellung einiger Möglichkeiten, wie man die History-Funktion noch weiter aufbohren und an seine Bedürfnisse anpassen kann.
Update: Aufgrund von weiteren Recherchen und des Kommentars auf macfidelity habe ich diesen Artikel noch einmal überarbeitet und weitere Informationen hinzugefügt.

Einleitung

Die History ist eine eingebaute Funktion in dem Befehlsinterpreter bash — der Standardshell inzwischen vieler *nixe bzw. *BSDs, so auch von Mac OS X. Die History hat eingebaute Befehle, die man wunderbar im Handbuch von Bash nachlesen kann, oder in Kürze erklärt bei macfidelity findet. Das Grundverhalten der History kann man, wie auch ziemlich vieler anderer Funktionen, in den Profil-Dateien der bash definieren. Dazu möchte ich auf den Artikel Bash-Shell einrichten verweisen.

History von mehreren parallel laufenden Terminalsessions sichern

Oft genug hat man mehrere Terminalsessions zu einem Host offen um sich z.B. in der einen Session das Logfile anzuschauen, während man in anderen Session einen Befehl ausführt. Beim Beenden der Session wird aber nur eine History gespeichert. Um immer hinzuzufügen führt man folgenden Befehl aus

shopt -s histappend

History sofort speichern

Die History einer Sesion wird immer erst beim Beenden einer Session in die Datei .bash_history gespeichert. Um bei parallelen Terminalsessions auf die Befehle zuzugreifen, die gerade erst in einer anderen Session getätigt wurden, kann man mit der Umgebungsvariablen

export PROMPT_COMMAND='history -a'

die Shell dazu zwingen bei jedem Generieren eines neuen Prompts (als einer Befehlseingabezeile) die History zu schreiben.

History mit Timestamp

Um im Historyfile sich pro Befehl auch einen Timestamp hinzufügen zu lassen gibt man folgendes ein:

export HISTTIMEFORMAT='%a %T '

Die Variablen dafür kann man sich von strftime abschauen.

Größe des History-Speichers in der Datei

Wie viele Zeile die History-Datei speichern kann weiß ich zwar nicht genau (ich denke aber das es 500 Zeilen sind), aber vergrößern kann man ihn mit

export HISTFILESIZE=1000

oder aber man schaltet gleich die Größenbeschränkung aus:

unset HISTFILESIZE

Mit der Variable

export HISTSIZE=500

kann man definieren, wie viele Zeilen maximal beim Beenden einer Terminalsession in die History-Datei geschrieben werden.

Ignorieren von Befehlen

Alle eingegebenen Befehle werden in die History gespeichert. Dieses Verhalten kann man etwas einschränken, indem man Befehle, welche mit einem Leerzeichen anfangen nicht in die History aufnehmen läßt

export HISTCONTROL=ignorespace

So kann man auch bewußt Befehle nicht in die History schreiben lassen, wenn man z.B. statt »ls« einfach « ls« eingibt.

Keine Duplikate in die History

Wie oben schon beschrieben werden alle Befehle in die History aufgenommen, auch die, die mehrfach eingegeben wurden. Möchte man das nicht

export HISTCONTROL=ignoredups

Möchte man weder Duplikate, noch die mit einem Leerzeichen am Anfang, so gibt man folgendes ein

export HISTCONTROL=ignoreboth

Spezielle Zeilen von der History ausschließen

Wenn die Variable HISTCONTROL nicht gesetzt ist, kann man auch selbst entscheiden, welche Zeilen nicht in die History aufgenommen werden sollen. Dies geschieht durch die Variable HISTIGNORE, welche mit Doppelpunkten getrennt

export HISTIGNORE='cat*:cd*:vi*:ls*'

Damit werden alle Zeilen, die mit cat, cd oder vi oder ls beginnen, nicht in der History gespeichert. Es bietet sich auch an hier alle selbst definierten Aliase anzugeben. Da theoretisch hier mit regulären Ausdrücken gearbeitet werden kann, stehen der Phantasie alle Möglichkeiten offen.

Fragen über Fragen

Kennt Ihr noch mehr Befehle um die History zu »pimpen«? Ich kann mich daran erinnern, das es einen Befehl gab, mit dem man automatisch gleich nach jedem Return den Befehl in die History schreiben lassen kann — aber wie hies der nur?

Gerade bei OSX kommt man ja meist drumherum mit der Kommandozeile zu arbeiten — dabei kann man in der Shell einiges schneller bzw. einfacher machen und um gewisse Einstellungen von OSX (wie zum Beispiel hier und hier beschrieben) zu ändern kommt man nicht umher das Terminal zu öffnen.

Vorgeplänkel

Wie man im Finder oder in jedem anderen Programm zuerst seine Benutzeroberfläche einrichtet, so macht man das auch in der Kommandozeile. Nur wird das hier nicht über eine Preference File gemacht sondern über (in OSX) versteckte Systemdateien. Da OSX diese Schreiben bzw. Erstellen dieser Dateien zum Teil für den normalen Benutzer verboten hat, muss man daran denken, das man sich root–Rechte holt. Das geht einmal mit dem Account root (Zur Aktivierung des root–Accounts verweise ich auf Apple), zu dem ich mit dem Shell-Befehl

su -

oder

sudo -s

wechsle. Oder aber zukünftig jedem Befehl ein

sudo

voransetze.

Für die Individualisierung der Shell sind verschiedene Dateien und Verzeichnisse wichtig. Zuerst wird zwischen den Benutzereinstellungen und den Einstellungen für den ganzen Rechner unterschieden. Die Benutzereinstellungen liegen im Userverzeichnis, also /Users/BENUTZERNAME (Ausnahme hier ist der Benutzer root, der sein Homeverzeichnis in /root findet) und die Systemeinstellungen im Verzeichnis /etc. Wie die Namen schon sagen, sind die ersteren nur für den angemeldeten Benutzer gültig, die Systemeinstellungen für jeden Benutzer.

Individuelle Anpassungen kann man einmal für das Tastaturmapping machen — hier sind die Dateien /etc/inputrc bzw. ~/.inputrc verantwortlich und für  das Aussehen bzw. das definieren von Umgebungsvariablen — dafür sind die Dateien /etc/profile und /etc/bash.bashrc bzw. ~/.bash_profile, ~/.profile, ~/.bashrc und ~/bash_login. Eine gute Zusammenfassung der Reihenfolge der Abarbeitung der Dateien findet man hier. Der Einfachheit halber benutze ich in diesem Artikel die Datei profile.

Farben für den tristen Alltag

Mit Farben kann man sich die Shell übersichtlicher machen. Dazu hat fidel schon mal was geschrieben. Definiert werden diese in der Profil-Datei. Man kann den Prompt bearbeiten (Farbe und Aussehen).  Standard ist folgendes Aussehen

In meinem Fall brauche ich die Angabe des Rechner-Namens nicht und ein nettes Gelb kann auch nicht schaden

export PS1="\[\e[33;1;40m\][\u] \w>\[\e[0m\] "

Das Gleiche kann man auch für den Prompt definieren, wenn man mit sudo sich temporäre root–Rechte gibt. In meinem Fall möchte ich gelbe Schrift auf einem rotem Untergrund.

export SUDO_PS1="\[\e[33;1;41m\][\u] \w>\[\e[0m\] "

Das sieht jetzt alles recht kryptisch aus, was daran liegt, das die Programmierung des Prompts in Escape-Sequenzen erfolgen muss. Wenn man etwas tiefer in die Materie einsteigen will, seinen ganz persönlichen Prompt bauen möchte oder schlicht einfach verstehen will, was hier gemacht wird, dem sein pimp my shell ans Herz gelegt. Es gibt dann auch noch Informationen von IBM und Ring of saturn.

Ein oft benutzter Befehl in der Kommandozeile lautet ls zum Anzeigen eine Verzeichnisinhalts. Um die verschiedenen Inhalte wie Verzeichnisse, Dateien, Symlinks und Co. auseinanderzuhalten ist eine farbige Darstellung sehr nützlich. Dies kann man entwerder durch das Aufrufen des Befehls ls mit dem Schalter –G erreichen, oder aber, wenn man die Farben selber definieren will, mit folgenden Umgebungsvariablen

export CLICOLOR=1
export LSCOLORS=dxfxcxbxegedabagacad

Die Bedeutung der jeweiligen Optionen kann man sich hier anschauen. Für ganz Faule gibt es einen Generator.

Um dem Befehl grep etwas Farbe zu geben, muss folgende Umgebungsvariable gesetzt werden

export GREP_OPTIONS='--color=auto' GREP_COLOR='1;32'

Einfacher Zugriff auf die History

Ich hatte hier schon mal was über die Einstellungen der bash history geschrieben. Die Einstellungen dort werden in der Profil-Datei gemacht. Wie in den Kommentaren hinzugefügt benutze ich folgendes Tastaturmapping in /etc/inputrc

"e[5~": history-search-backward
"e[6~": history-search-forward

Damit kann ich mit den Tasten Bild rauf/Page up bzw. Bild runter/Page down durch die History scrollen. Das funktioniert sogar basierend auf dem, was schon auf der Kommandozeile steht. Gebe ich zum Beispiel less ein, dann werden mir mit den genannten Tasten nur die History-Einträge angezeigt, die mit dieser Buchstabenfolge anfangen.

Damit die history gleich geschrieben wird und nicht erst beim Beenden der shell session kann in der Profil-Datei mit

# Append commands to the history every time a prompt is shown,
# instead of after closing the session.
PROMPT_COMMAND='history -a'

erzwungen werden, dass mit jedem Erzeugen eines neuen Prompts die history geschrieben wird.

Leichteres Admin-Leben mit Aliasen

Standardmäßig wird dem normalen Benutzer beim Aufrufen von ls die Ansicht auf dotfiles verwehrt. Mit dem Eintrag

alias "ls=ls -a"

wird das korrigiert. Ansonsten kann man hier Programmaufrufen feste Parameter mitgeben und auch langen Befehlszeilen Kürzel vergeben.

Zusätzliches

Möchte man zusätzliche Pfad als Standardpfad einzurichten, damit man beim Aufrufen nicht den gesamten Pfad angeben muss, dann gibt man diesen wie folgt an:

export PATH=$PATH:/usr/local/src/bin

Wenn man Änderungen an den Profil-Dateien macht, dann werden diese Änderungen erst gültig, wenn die Profil-Datei erneut eingelesen wird. Das erreicht man entweder mit dem Öffnen einer neuen Terminal-Session oder aber mit dem Befehl

source ~/.profile

Fragen über Fragen

Wie sieht Eure Individualisierung der Kommandzeile aus? Welche Möglichkeiten habe ich vergessen zu erklären? Kanntet Ihr schon alle Möglichkeiten?

Backup von bestimmten Dateien

Häufiger möchte man, wenn man mal schnell etwas in einer Config-Datei etwas ändert, davon fix ein Backup anlegen. Klassisch habe ich das meist schnell mit

cp DATEI.conf DATEI.conf.orig

gelöst. Was aber passiert, wenn man dann später nochmal was ändern will respektive ein neues Backup angelegt werden soll?! Wie man dieses Problem erschlägt, habe ich schon mal in diesem Artikel erklärt — das war aber nur ein Schnellschuß. Das Problem dabei ist nämlich, das man ja jeweils die alten Backups nochmal mitsichert und dadurch die Backups immer größer werden. Dies kann man durch einen Exclude-Parameter von tar auschließen. Der Befehl um in einem Verzeichnis alle Dateien zu sichern lautet also

tar -cz --no-recursion --exclude=backup-*.tar.gz -f backup-$(date +%F-%H-%M).tar.gz *

Backup von ganzen Pfaden inkl. der Unterverzeichnisse

In einigen Fällen will man nicht nur die Dateien in einem Verzeichnis sichern sondern lieber gleich den Inhalt gesamte Verzeichnis inklusive aller Unterverzeichnisse

tar -cz --exclude=backup-*.tar.gz -f backup-$(date +%F-%H-%M).tar.gz .

Backup von Dateien bzw. Pfaden, die im gesamten System verteilt sind

Und schließlich hat man den Fall, das man alle wichtigen Dateien eines Systems sichern will, die aber über das gesamte System verteilt sind. Dies erreicht man mit einer Include-Datei

tar cvzf /backup-$(date +%F-%T).tar.gz -T /etc/backup-include-dir.conf

wobei man in die Datei /etc/backup-include-dir.conf alle Pfade bzw. alle Dateien reinschreibt, die gesichert werden sollen. Wichtig ist dabei nur: Pro Datei/Pfad jeweils eine Zeile.

Und denkt daran: Solche Befehlszeilen eignen sich wunderbar dazu als alias definiert zu werden, damit man schnell drauf zugreifen kann, wenn man es mal braucht.

Wie in dem Artikel SSH mit Tunnel nutzen geschrieben, habe ich mich damit beschäftigt, wie ich mir beliebige Dienste meine Heimnetzwerkes über einen SSH-Tunnel auf meinen entfernten PC holen kann. Aktuell wollte ich ein Debian in einer Virtuelle Maschine auf meinem iMac hochfahren und an dieser etwas ausprobieren. Wie ich bei VMware Fusion eine VM per Kommandozeile starte/steuere, habe ich schon in VMware Fusion über die Kommandozeile steuern gezeigt. Ich habe mir also einen Tunnel zum SSH-Zugang des iMacs aufgebaut

ssh -L 2222:192.168.1.10:22 root@test.dyndns.org

und mich mit

ssh -D 2222 localhost

auf den iMac eingewählt. Dann fix mit

/Library/Application\ Support/VMware\ Fusion/vmrun start /Users/imac/Documents/Virtual\ Machines.localized/Debian\ Lenny\ 5.01.vmwarevm/Debian\ Lenny\ 5.01.vmx

die Debian VM gestartet.

Dabei habe ich gemerkt, das ich nicht mehr die IP der VM wußte, da diese auf DHCP konfiguriert ist. Also fix die VM wieder runtergefahren und mit

vi /Users/imac/Documents/Virtual\ Machines.localized/Debian\ Lenny\ 5.01.vmwarevm/Debian\ Lenny\ 5.01.vmx

die Einstellungsdatei der VM bearbeitet.

Mit den zusätzlichen Parametern

RemoteDisplay.vnc.enabled = »TRUE»
RemoteDisplay.vnc.port = »5901«

habe ich für genau diese VM nun einen zusätzlichen VNC-Server angeschaltet, auf den ich mich dann explizit einwählen kann.

Mit der Befehlszeile

ssh -L 2901:192.168.1.10:5901 root@test.dyndns.org

kann ich nun also per VNC auf die Debian VM zugreifen

und die IP-Adresse herausfinden. Mit dieser kann ich dann wiederrum einen weiteren Tunnel zum SSH-Server der VM aufbauen.

Kanntet Ihr die Funktion schon?

Zuerst aber muß man wissen, wo man den Befehl vmrun finden kann — in /Library/Application Support/VMware Fusion/

Um den Befehl global ausführen zu können muß man den Pfad zur PATH-Variablen hinzufügen

export PATH="$PATH:/Library/Application Support/VMware Fusion"

Allgemeines

Zuerst man vmrun sagen mit welchem Typ er sich verbinden soll.

vmrun -T fusion

Als nächstes kommt die Authentifizierung am Gastsystem

vmrun -T fusion -gu USERNAME -gp USERPW

Nun kommen wir zu den einzelnen Kommandos, welche man absetzen kann. Als Parameter fast jeden Kommandos muß man das VMX-File der entsprechenden virtuellen Maschine angeben. Bei VMware Fusion befinden sich diese im Unterordner in /Users/USERNAME/Documents/Virtual\ Machines.localized/ Um sich alle bekannten VMs anzeigen zu lassen nutzt man am besten

vmrun -T fusion list

Ausführen von Programmen im Gastsystem

Am Interessantesten für mich ist die Möglichkeit Befehle direkt in der virtuellen Maschine absetzen zu können. Dafür gibt es das Kommando runProgramInGuest. Der komplette Syntax lautet:

vmrun -T fusion -gu USERNAME -gp USERPW runProgramInGuest ~/Documents/Virtual\ Machines.localized/XP/xp.vmx BEFEHL

Sollte die Befehlszeile etwas länger sein und mehrere Parameter enthalten, so muß der Befehl in Hochkommas gesetzt werden. Enthält wiederrum ein Parameter auch schon ein Hochkomma, so muß dem gesamten Befehl ebenso ein weiteres Hochkomma gegeben werden. Faustregel: Für jedes Hochkomma-Paar im Befehl selber muß dem gesamten Parameter selber ein extra Hochkomma hinzugegeben werden.

Um, wie in diesem Beitrag geschrieben, dem Active Directory meines Windows-Servers alle zur Zeit gültigen EMail-Adressen zu entlocken nutze ich folgende Befehlszeile

./vmrun -T fusion -gu ADMIN@DOMAIN.DE -gp GANZGEHEIM runProgramInGuest ~/Documents/Virtual\ Machines.localized/Windows\ Server\ 2003\ Small\ Business.vmwarevm/Windows\ Server\ 2003\ Small\ Business.vmx ""ldifde.exe -m -n -g -f "C:\Mailgw\recipient.txt" -r "(mailnickname=*)" -l proxyAddresses""

Wenn ich gleich den Upload noch hinzufügen will, lege ich in den Pfad c:\mailgw auf dem Windows-Server eine Batch-Datei, die mir nach und nach alles ausführt (also Extract der Emailadressen und Kopieren per pscp).

./vmrun -T fusion -gu ADMIN@DOMAIN.DE -gp GANZGEHEIM runProgramInGuest ~/Documents/Virtual\ Machines.localized/Windows\ Server\ 2003\ Small\ Business.vmwarevm/Windows\ Server\ 2003\ Small\ Business.vmx "c:\mailgw\userextract.cmd"

Backup einer virtuellen Maschine

Um meinen virtuelle Windows-Server zu sichern nutze ich zur Zeit Acronis Trueimage innerhalb der VM und sichere auf eine externe Platte, welche per Shared Folder in die VM eingebunden ist. Das ist natürlich »von hinten durch die Brust ins Auge«, war aber auf die Schnelle das Naheliegendste. Wie in mac | Einrichtung eines Backups geschrieben ist es ein Wunsch von mir das Backup direkt aus OSX heraus zu starten. Dies könnte ich jetzt mit dem Absetzen eines Befehls erreichen (ob Trueimage das untersützt wäre noch zu recherchieren) oder aber ich erstelle ein Snapshot per vmrun

./vmrun -T fusion snapshot ~/Documents/Virtual\ Machines.localized/Windows\ Server\ 2003\ Small\ Business.vmwarevm/Windows\ Server\ 2003\ Small\ Business.vmx MySnapshot

Zu Testen wäre jetzt, wie groß die Snapshots sind und ob die VM während der Erstellung erreichbar ist oder aber gestoppt bzw. heruntergefahren werden muß.

Nutzt Ihr vmrun und wenn ja, wie?

server:~# host gmx.de
gmx.de has address 213.165.65.50
gmx.de mail is handled by 10 mx0.gmx.net.
gmx.de mail is handled by 10 mx1.gmx.net.

Möchte man diesen Email-Server anfunken, dann macht man das mit
telnet mx0.gmx.net 25

Der Server antwortet:
Trying 213.165.64.100...
Connected to mx0.gmx.net.
Escape character is '^]'.
220 mx0.gmx.net GMX Mailservices ESMTP {mx023}

Wir stellen uns vor:
ehlo mail.domain.de

Der Server antwortet:
250-mx0.gmx.net GMX Mailservices
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 SIZE

Darauf hin fangen wir an die Mail zu schreiben. Zuerst kommt der Absender:
mail from:  absender@domain.de


Der Server gibt sein ok
250 2.1.0 ok {mx023}

dann der Empfänger:
rcpt to: irgendwer@gmx.de

wieder der Server
250 2.1.5 ok {mx023}

Dann kommen wir zum eigentlichen Text
data

Der Server wieder
354 mx0.gmx.net Go ahead {mx023}

wir vergeben einen Betreff
subject: testmail

anschließend kommt der eigentliche Text
Dies ist eine Testmail

Abschließend ein einzelner Punkt gefolgt von einem RETURN zum Abschließen der Mail
.

Der Server bestätigt die Annahme
250 2.6.0 Message accepted {mx023}

Wir sagen brav Auf Wiedersehen
quit

der Server antwortet
221 2.0.0 GMX Mailservices {mx023}

und weg sind wir
Connection closed by foreign host.

Das kann man nicht nur mit fremden, sondern natürlich auch mit dem eigenen Mail-Server machen. Besonders wenn man diesen gerade frisch aufsetzt, sollte man folgendes probieren:

1. Verbindungsaufbau von eigenem DSL-Anschluß zu mailserver.domain.de mit fremder Emailadresse als Absender und gültigem Empfänger der eigenen Domain.
2. Verbindungsaufbau von eigenem DSL-Anschluß zu mailserver.domain.de mit fremder Emailadresse als Absender und ungültigem Empfänger der eigenen Domain.
3. Verbindungsaufbau von eigenem DSL-Anschluß zu mailserver.domain.de mit fremder Emailadresse als Absender und fremden Empfänger.
4. Verbindungsaufbau von eigenem DSL-Anschluß zu mailserver.domain.de mit eigener Emailadresse der Domain als Absender und gültigem Empfänger der eigenen Domain.
5. Verbindungsaufbau vom Server zu localhost mit obigen vier Optionen.

So sollte man alle Varianten durchhaben, wie Mails eingeliefert werden könnten. Das Ergebnis eines jeden Tests sollte man genau untersuchen und hinterfragen, ob das genau so erwünscht war.

Manchmal möchte man entweder das Verhalten prüfen, wie ein lokaler Dienst EMails einliefert. Das wird nicht immer über den SMTP-Dienst des Servers getan sondern wird direkt in den EMail-Server injiziert. Bei postfix als MTA wird der Prozeß pickup dafür genutzt. Am Einfachsten ist es den Inhalt der Email in ein Textfile mit folgendem Muster zu schreiben.

From: <absender@domain.de>
To: <empfänger@domain.de>


Subject: This is a Postfix Sendmail Test

Dieses Textfile wird anschließend mit dem Befehl:
# cat testfile | /usr/sbin/sendmail -t -bm -v
abgeschickt.