Vorgeplänkel:

• Wenn Du Things auf mehr als einem Mac nutzen möchtest, dann kaufe bitte eine entsprechende Anzahl von Lizenzen.
• Ja, ich meine das ernst – die Buben aus Stuttgart haben wahnsinnig gute Arbeit geleistet, sowas muß man einfach würdigen.
• Ich gehe davon aus, daß Du ein lauffähiges git auf Deinem Mac hast, Anleitungen hierzu gibt es genug im Netz.
• Ich habe vor langer Zeit den symlink /Volumes/iDisk erstellt, um einen generischen Zugriffspfad zu haben. In den kompletten Zeilen weiter unten referenziere ich diesen Pfad. Der Name Deiner iDisk ist Dein Benutzername, ersetze also entsprechend iDisk mit $Du.

Let’s get dirty!
Auf dem Mac mit installiertem und genutztem Things erstellen wir ein git-Repository. Things legt seine Datenbank als XML in ~/Library/Application Support/Cultured Code/Things ab, und damit das Setup einfach bleibt, nutzen wir auch genau diesen Pfad für das Repository.
cd ~/Library/Application\ Support/Cultured\ Code/Things
git init
git add .
git commit -a -m "initial commit"

Sobald das neu erstellte Repository existiert und mit den bisherigen Daten gefüllt ist, erstellen wir erst ein neues Repository auf der iDisk (--bare weil wir in diesem Repository nicht arbeiten wollen, sondern es nur als “Server” benutzt wird) und pushen die Daten dort hin.
git clone --bare . /Volumes/iDisk/Repository/things.git
git remote add idisk /Volumes/iDisk/Repository/things.git
git push idisk master
Der Name “iDisk” für das remote-Repository ist hierbei frei gewählt.

Das folgende Shell-Script wird in Zukunft die oben angesprochene Magie™ für uns übernehmen, daher bitte einmal copy&paste, chmod +x und mit dem gewünschten Zeitpunkt in die crontab des eigenen Users eintragen.

1
2
3
4
5
6

#!/bin/bash
DATE=`date`
cd ~/Library/Application\ Support/Cultured\ Code/Things
git pull idisk master
git commit -a -m "Auto Sync - $DATE"
git push idisk master

Bis hier haben wir ein Backup-System mit Versionshistorie, aber von einem zweiten Mac war bisher noch nicht die Rede, oder? Also…

Schickt die Clone herrein!

Auf dem zweiten oder siebzenten Mac Things installieren und mit der leeren Datenbank beenden.

cd ~/Library/Application\ Support/Cultured\ Code
mv Things Things.dist
git clone /Volumes/iDisk/Repository/things.git


Und auch auf diesem Apfel lassen wir das obige Shell-Script per cron laufen. Ich empfehle hier die Zeitpunkte nicht zu nah aneinander zu legen, so daß Kollisionen bestmöglich vermieden werden.

Kollisionen:
Auch wenn git mit Kollisionen umgehen kann, dieser Weg sollte nur so weit als Sicher bezeichnet werden, als das nur ein Mensch an einem Mac parallel arbeitet. Mit etwas mehr Magie™ läßt sich sicherlich ein Weg finden, die Things Datenbank bei Änderungen aus mehreren Quellen entsprechend zu mergen, aber diese Anforderung stellte sich bei der Motivation dieser Anleitung nicht. Für Vorschläge bin ich immer offen.

Egal was Du tust, sichere Deine Daten! Ich bin zwar kein Fießling, und absichtlich werden hier niemals Fehler zu finden sein, aber wer blind ein rm -rf / abtippt, dem ist nicht mehr zu helfen. Sichere Deine Daten, denke nach was Du tust, teste was man testen kann.

Inspiriert von:

• Syncing Things with git and Launchd
• Git, iDisk und so

git clone git://git.kernel.org/pub/scm/git/git.git
cd git
make quick-install-html
pfexec mkdir -p /usr/share/doc/git-doc
cd /usr/share/doc/git-doc
pfexec mv ~/share/doc/git-doc/* .

Nun funktioniert z.B. git help --web init wie erwartet, und der Browser wird geoeffent um die Hilfe-Seite anzuzeigen.
Wenn das git-Repository sonst nicht mehr benoetigt wird kann es natuerlich anschliessend wieder geloescht werden. Ebenso ~/share, sofern keine anderen Daten dort gelagert werden.

• die Daten eines auf MacOS X erstellten ZPools sollen auf eine OpenSolaris-Maschine uebertragen werden.

Gedankengang #1:
Es war schon spaet abends, wirklich nachgedacht wurde nicht, klein Sebastian startet ein rsync und denkt “so lang wird das schon nicht dauern”. Problematik dabei ist bzw. war allerdings, dass auf dem Pool u.A. auch diverse OpenSource-Projekte und -Sammlungen im Quelltext vorlagen, so z.B. pkgsrc, was ohne mit der Wimper zu zucken zu mehreren Millionen kleinen Files fuehrt. Ebenfalls kam der kleine Sebastian nicht auf die Idee fuer das rsync ein LAN-Kabel anzuschliessen und schickte den kompletten Datenstrom ueber WLAN durch die Luft. (Immerhin zwar n, aber im Vergleich zu Gigabit-Ethernet immernoch langsam.) Einigen wir uns auf keine so gute Idee, auch wenn sie zum Ziel gefuehrt hat.

rsync -avzP -e "ssh -p 22" /Volumes/tank/* shl@<ziel>:/tank/transfer

Gedankengang #2: (ein paar Tage spaeter)
Die Daten sind auf dem neuen Pool angekommen – so weit so gut. Und damit es noch einen Lern-Erfolg gibt, machen wir das jetzt nochmal in richtig. Damit ich den – in diesem Falle – ueberfluessigen Layer Netzwerk los werde, schliesse ich die USB-Platten vom Mac direkt an die OpenSolaris-Box an. Hierfuer muss der Pool allerdings erst umbenannt werden, da eine Maschine nicht zwei Pools des gleichen Namens mounten kann.

sudo zpool export tank
sudo zpool import oldtank tank
sudo zpool export oldtank

Die Schritte im Detail: wir exportieren den Pool, damit wir ihn per import <neu> <alt> umbenennen koennen und exportieren ihn nochmals, damit wir ihn an die andere Kiste anschliessen koennen. Hier noch ein

pfexec zpool import oldtank

und zumindest das erste Problem ist gegessen.

ZFS bietet von Haus aus eine durchdachte Moeglichkeit an um Daten von A nach B zu schieben, naemlich zfs send | zfs receive. Durch die Pipe (|) kann man hier auch prima z.B. ssh als Transport-Medium nutzen. Allerdings kann zfs send nur Snapshots uebertragen – aber bei einem Filesystem was effektiv still steht (hier oldtank) tut das ja nun wirklich nicht weh.

Das folgende Script habe ich die letzten Monate auf meinem Mac zum snapshot’en benutzt. In groben Zuegen basiert es auf Jeff’s Snapshot-Script, allerdings erstellen wir hier keinen Timestamp sondern einen hoffentlich eindeutigen String fuer die Snapshots die wir kopieren moechten, in diesem Falle “NOWITSTHETIME“.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#!/bin/bash
 
FS=`zfs list -t filesystem | grep oldtank | awk '/^[a-z0-9]+\//{ print $1}'`
#NOW=`date +%Y-%m-%d`
NOW=NOWITSTHETIME
 
for I in $FS; do
 echo "Snapshot'ing ${I}@$NOW ..."
 zfs snapshot ${I}@$NOW
 if [ $? = 0 ]; then
  echo "success!"
 else
  echo "failed ($?)!"
 fi
done

Im naechsten Script – ich entschuldige mich im Vorfeld fuer die massive und z.T. unnoetige Nutzung von grep, aber mir gefaellt das halt so – schicken wir die eben erstellten Snapshots nach tank/transfer2 (vorher natuerlich anlegen, sonst wird das nix…):

1
2
3
4
5
6
7

#!/bin/bash
 
for i in `zfs list -rH -t snapshot | awk '{print $1}' | grep oldtank | grep -v tank/transfer2/oldtank | grep NOWITSTHETIME`
do
echo "sending Snapshot" $i "to transfer2"
pfexec zfs send $i | pfexec zfs receive tank/transfer2/$i
done

Fragt sich nun natuerlich: was haben wir gewonnen?
zfs send serialisiert den Datenstrom, was z.B. dazu fuehrt, dass es vollkommen egal ist, ob wir mit Millionen von kleinen Dateien oder drei grossen 1TB-Files arbeiten. Ebenfalls koennen wir uns den kompletten Weg der Daten sicher ueber deren Zustand sein, denn wir vertrauen durchweg auf die Integritaetschecks von ZFS. Wenn gewuenscht (ich habe nicht wirklich einen Sinn darin gesehen) kann man durch die Pipes noch z.B. gzip einbauen, oder eben Transport-Mechanismen wir ssh oder sonstwas nutzen. Konstrukte wie

zfs send tank@BRIEFTAUBE > file
Benutze file mit Brieftaube
cat file | zfs receive tank@BRIEFTAUBE

sind genauso moeglich. Und auch die Nutzung als Backup ist durchaus eine Ueberlegung wert.
Um zur urspruenglichen Problemstellung zurueck zu kommen: im Vergleich zur Methode #1 ist die Loesung mit zfs send eindeutig schneller. Und – zumindest ich – habe damit ein besseres Gefuehl.

Beide Scripte sind per git auf github verfuegbar.
(git clone git://github.com/shl/zfssnapsend.git)

Was bedeutet das nun:
Hier wird nicht der User bzw. Kerberos-Prinzipal mit ACLs versehen, sondern die Quell-IP des anfragenden Systems.

Anstatt

pts createuser JohnDoe
pts adduser JohnDoe Marketing
fs setacl $foo $bar $baz

wird für eine einzelne IP (z.B. einen dedizierten Server für einen Dienst, der sich nicht wirklich kerberisieren lässt)

pts creategroup HardToKerberize
pts createuser 172.23.42.666
pts adduser 172.23.42.666 HardToKerberize
fs setacl $foo $bar $baz

Um die Übersicht zu behalten bietet es sich an, neben exzessiver Dokumentation der eigenen Zelle (ja, das war ein Zaunpfahl), für IPs Gruppen zu erstellen, allein schon weil OpenAFS nicht mit der CIDR-Notation klar kommt.

Und bevor nun jemand ganze IP-Ranges von Hand eintippt:

1
2
3
4
5
6
7
8
9
10
11
12

#!/usr/bin/env python
# encoding: utf-8
 
def main():
  print "pts creategroup LAN-172.31"
  for i in range(0, 256):
    for j in range(0, 256):
      print "pts createuser 172.31." + str(i) + "." + str(j)
      print "pts adduser 172.31." + str(i) + "." + str(j) + " LAN-172.31"
 
if __name__ == '__main__':
	main()

Natürlich – wie immer – erst denken, dann anpassen, dann abtippen, dann ausführen.

autoload -U tetris
zle -N tetris
bindkey "^Xt" tetris

Ein beherzter Druck auf [CTRL]-[X]-[T] und los geht der Spaß!

Danke Stefan.

Ich kann das gar nicht oft genug betonen.

Mit diesem Patch (Download vom lokaler Mirror) wird bei einer definierbaren Gruppe von Befehlen eine Growl-Notification versendet, sobald die Ausführung abgeschlossen ist.

In der Zeile 2011 wird die Liste der growlifizierten Kommandos definiert.

GROWL_COMMANDS=(rsync scp cp sleep svn git)

Diese Zeile entsprechend erweitern oder kürzen, ganz nach eigenem Geschmack. sleep ist praktisch zum testen.

Danke, Andreas!

I’m wondering for quite some time now, why there is no simple method the check whether the sum of the volume quotas exceeds the available disk space for each paritition on an AFS fileserver.

Und das Ergebnis (zu finden in seinem Blog) funktioniert prima.
Danke Jakob.

Hinweis: der nachfolgende Weg ist absolut unsupported (weder von VMWare noch von mir oder sonst irgendjemandem) und sollte nur dann gewaehlt werden wenn man an einem potentiellem Desaster schuld sein moechte. Ich hab Euch gewarnt!

Als ersten Schritt muessen wir dem ESXi einen SSH-Zugang beibringen. Dazu bitte ins Rechenzentrum fahren oder in den Server-Raum gehen und lokal an die Maschine setzen. Was huepsche gelb/schwarz eines VMWare-Hosts kann durch CTRL-ALT-F1 in eine Linux-Konsole verwandelt werden (naja, fast zumindest). Was man jetzt nicht sieht, ist der Login-Dialog. Bitte blind unsupported eintippen, gefolgt vom gewaehlten root-Passwort, sobald der ESXi dazu auffordert. Falls es nicht sofort klappt, einfach ein paar mal die Enter-Taste druecken und von vorne anfangen.
In der Datei /etc/inetd.conf das “#”-Zeichen vor dem SSH-Eintrag entfernen und speichern. Jetzt kommt Murphy in’s Spiel. Bei einigen meiner ESXi’s hat es gereicht die relevanten Dienste mittels /sbin/services.sh restart neu zu starten um den SSHd zu aktivieren, andere ESXi’s wollten komplett gebootet werden. Versucht einfach schlimmstenfalls beides.

Naechster Schritt: man nehme einen SSH-Client (schlimmstenfalls PuTTY) und versuche einen Connect als “root” auf Port 22 der Management-IP.

Im Verzeichnis /vmfs/volumes/datastore findet man nun das VMFS der virtuellen Maschinen, und kann sie per SCP auf andere ESX- und ESXi-Hosts uebertragen.

Interessant sind die VMDK-Files, denn hier sind die Konfigurationen sowie die virtuellen Platten versteckt. Die VMDK-Files einfach auf einen anderen Host kopieren und notfalls in der Maschinenname.VMDK die Pfade anpassen. Die restlichen Dateien sind fuer das Clonen nicht relevant und koennen getrost ignoriert werden. Sie werden bei Import der virtuellen Festplatte im Infrastructure Client neu angelegt.

That’s it.

Useful command-line secrets for increasing productivity in the office

Fühlt sich zwar seltsam an, aber man kann durchaus damit arbeiten.

Ein schöner Vorteil der “freien” Betriebssysteme ist an dieser Stelle, daß man sie nahezu alle auch aus dem Netzwerk booten kann – Stichwort PXE – und somit zumindest das Erstellen von Installationsmedien entfällt.

Mit einem PXE-fähigen Rechner ist man in der Lage, anstelle von lokalen Medien (Festplatte, Diskette, CD etc.) über ein Netzwerk (Ethernet) von einem entfernten Rechner zu booten. Dies kann dazu dienen, auf einem Rechner ohne Zufügen von Medien (CDs, DVDs etc.) ein Betriebssystem zu installieren oder auch ein Thinclient-System aufzubauen, in dem die Client-Rechner gar keine Laufwerke benötigen, und dem Nutzer dennoch ein komplett nutzbares Betriebssystem zur Verfügung gestellt wird.

[nach wikipedia]

Wie baut man denn jetzt ein solches PXE-Environment auf? Naja – eigenlich recht einfach. Man benötigt nur den Dienst DHCP, eine Portion TFTP und später etwas NFS – schon fertig. In der Realität ist’s natürlich ein kleines bisselchen mehr Aufwand…

Zuerst suchen wir uns eine Maschine im Netz, auf der das PXE-System laufen soll. In meinem Falle ist das eine Debian Maschine, konzeptionell funktioniert das aber auch wunderbar mit anderen Distributionen oder den BSD-Geschmacksrichtungen. Ich habe mir vor einiger Zeit mal angewöhnt solche Installationen getrennt vom restlichen Betriebssystem zu verwalten, daher wähle ich einen Pfad unterhalb von /opt – das steht natürlich jedem frei.

# mkdir /opt/pxeboot/tftp

Was wir auf jeden Fall brauchen, ist eine aktuelle Version von syslinux – runterladen und in diesem neuen Verzeichnis entpacken.

Den Debian-Installer laden wir als nächstes. Heute gibt es durchaus Sinn sowohl den i386- als auch den AMD64-Zweig anzubieten, daher laden wir beide nacheinander runter und entpacken die Files ebenfalls nach /opt/pxeboot/tftp.


# wget http://ftp.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/netboot.tar.gz
# tar xzf netboot.tar.gz
# rm netboot.tar.gz
# wget http://ftp.debian.org/debian/dists/etch/main/installer-amd64/current/images/netboot/netboot.tar.gz
# tar xzf netboot.tar.gz
# rm netboot.tar.gz


Beide Dateien heißen netboot.tar.gz, also nicht aus Versehen gegenseitig überschreiben. Ein paar Dateien sind in beiden Archiven enthalten – einfach ignorieren, die dürfen ruhig überschrieben werden. Ebenfalls brauchen wir zwei Symlinks nicht mehr – pxelinux.0 und pxelinux.cfg sollten auch gleich gelöscht werden – wir legen sie später neu an.

Aus dem syslinux-Paket stibitzen wir noch die Datei com32/modules/menu.c32 und kopieren sie nach /opt/pxeboot/tftp.

Dem DHCP-Server in unserem Netz muß noch erklärt werden, daß er den Clients auf PXE-Anfragen antwortet. Beim ISC DHCPd3 geht das sehr schmerzfrei, auch bei anderen DHCP-Servern sollte das kein Problem sein. (moemoe beschreibt das mit dnsmasq)


subnet 172.30.4.0 netmask 255.255.252.0 {
 range 172.30.6.1 172.30.6.254;
 range dynamic-bootp 172.30.5.240 172.30.5.255;
 option routers 172.30.7.254;
 filename "pxelinux.0";
 next-server 172.30.4.1;
}


Die beiden hervorgehobenen Zeilen teilen dem Client mit welche Datei er von welchem Server per TFTP anfordern soll. Installieren wir noch einen TFTP-Server! Wer Debian einsetzt kann sich jetzt glücklich schätzen, denn was gibt es schon schöneres als apt-get?


# apt-get install atftpd


Bei mir wird der atftpd per inetd gestartet, also muß eine entsprechende Zeile in die /etc/inetd.conf

tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /opt/pxeboot/tftp Einfach ganz unten anhängen – sofern da noch nix von tftp steht – und darauf achten, daß es wirklich alles eine Zeile ist.

Jetzt noch das Boot-Menü anpassen.

In /opt/pxeboot/tftp ein neues Verzeichnis namens pxelinux.cfg erstellen und darin eine Datei namens default in den Editor laden.


DEFAULT menu.c32
PROMPT 0
MENU TITLE Automagisches Netzwerk-Booten
TIMEOUT 300
LABEL d
 MENU DEFAULT
 MENU LABEL Boot from ^disk
 localboot 0x80
LABEL di-i386
 MENU LABEL Debian Installer ^i386 - submenu
 KERNEL menu.c32
 APPEND debian-installer/i386/pxelinux.cfg/default
LABEL di-amd64
 MENU LABEL Debian Installer ^amd64 - submenu
 KERNEL menu.c32
 APPEND debian-installer/amd64/pxelinux.cfg/default
LABEL n
 MENU LABEL Try ^next bootdevice
 localboot -1


Aus dem Debian-Installer i386 (/opt/pxeboot/tftp/debian-installer/i386) noch die Datei pxelinux.0 nach /opt/pxeboot/tftp kopieren und fertig sind wir – für den ersten Schritt. Den DHCP-Server und den inetd noch kurz mit der neuen Konfiguration vertraut machen (also known as durchstarten) und schon sollten die Maschinen per PXE den Debian Installer booten können.

Allerdings – zumindest mir – reicht das noch nicht. Für’s Debugging eignet sich noch ein Live-System, außerdem muß noch der Installer von FreeBSD mit in’s Boot-Menü.

Grade für Debugging hat sich bei mir grml bewährt.

grml is a bootable CD (Live-CD) originally based on Knoppix and nowadays based on Debian. grml includes a collection of GNU/Linux software especially for system administrator and users of texttools. grml provides automatic hardware detection. You can use grml (for example) as a rescue system, for analyzing systems/networks or as a working environment. It is not necessary to install anything to a harddisk; you don’t even need a harddisk to run it. Due to on-the-fly decompression grml includes about 2.1GB of software and documentation on the CD.

[grml]

Aus dem grml-ISO basteln wir eine NFS-Freigabe und laden zusätzlich noch die speziellen Files für den grml-Netboot.


# mkdir /opt/pxeboot/tftp/grml
# wget ftp://ftp.uni-erlangen.de/pub/mirrors/grml/grml_1.1.iso
# mount -o loop grml_1.0.iso /mnt/tmp/
# cp -r /mnt/tmp/* /opt/pxeboot/tftp/grml
# cp /mnt/tmp/boot/isolinux/minirt26.gz /opt/pxeboot/tftp/grml/boot/
# umount /mnt/tmp
# wget http://grml.org/terminalserver/grml_netboot_package_1.1.tar.bz2
# tar xvjpf grml_netboot_package_1.1.tar.bz2
# cp grml_netboot_package_grml_1.1/tftpboot/linux26 /opt/pxeboot/tftp/grml/boot/
# cp grml_netboot_package_grml_1.1/tftpboot/minirt26.gz /opt/pxeboot/tftp/grml/boot/
# cp grml_netboot_package_grml_1.1/tftpboot/memtest /opt/pxeboot/tftp/grml/boot/


Sowohl das ISO als auch den Inhalt von grml_netboot_package_1.1.tar.bz2 benötigen wir danach nicht mehr.

Die Datei /opt/pxeboot/tftp/pxelinux.cfg/default noch um den grml-Eintrag anpassen:

LABEL grml
 MENU LABEL ^GRML
 kernel grml/boot/linux26
 append ramdisk_size=24000 root=/dev/ram0 rw init=/etc/init nfsdir=Server-IP-oder-Name:/opt/pxeboot/tftp/grml/ nodhcp noprompt noeject apm=power-off nomce initrd=grml/boot/minirt26.gz vga=normal

Was jetzt noch fehlt, ist der NFS-Export von /opt/pxeboot/tftp/grml – aber auch das ist kein größeres Problem. Die Datei /etc/exports um die entsprechenden Einträge ergänzen und den NFS-Dienst ebenfalls neu starten.


/opt/pxeboot/tftp/grml/ * (ro,no_root_squash,no_subtree_check)
/opt/pxeboot/tftp/ * (ro,no_root_squash,no_subtree_check)


That’s it – jetzt ist auch grml über das Netzwerk startbar. Fehlt noch FreeBSD.

Leider ist der Aufwand bei FreeBSD etwas größer als bei Linux, denn für das Erstellen eines PXE-Images benötigt man ein funktionierendes FreeBSD-System und ein bootonly.iso.


# mdconfig -a -t vnode -f 7.0-RELEASE-i386-bootonly.iso -u1 ; mount -t cd9660 /dev/md1 /mnt/cdrom
# dd if=/dev/zero of=fbsd7R_i386.img bs=1k count=32k
# mdconfig -a -t vnode -f fbsd7R_i386.img -u0
# bsdlabel -w -B md0 auto; bsdlabel -A md0
# newfs -b 8192 -f 1024 /dev/md0a
# mount /dev/md0a /mnt/disk
# cp -R /mnt/cdrom/boot /mnt/disk/
# umount /mnt/disk
# umount /mnt/cdrom ; mdconfig -d -u0 ; mdconfig -d -u1
[nach /dev/rant]

Das entstandende Image fbsd7R_i386.img auf den PXE-Server kopieren, gzipen und in pxelinux.cfg/default mit eintragen.


LABEL fbsd7-i386
 MENU LABEL FreeBSD 7-RELEASE i386
 kernel memdisk
 append initrd=freebsd/fbsd7R_i386.img.gz harddisk noedd


Die Datei memdisk ebenfalls noch aus syslinux ins Verzeichnis /opt/pxeboot/tftp kopieren, denn die benötigt der FreeBSD Start-Vorgang. Auch FreeBSD hat einen AMD64-Zweig. Der wird entsprechend der Anleitung oben für i386 gebaut.

Das war’s – das Gröbste ist erledigt. Wem die Menüs noch nicht gefallen kann sich an syslinux noch ein bisselchen verkünsteln – Stichwort: vesamenu.c32.
Ich habe das ganze vor einer Weile für unser Büro-Netzwerk gebaut, und bin bisher sehr zufrieden. Wirklich geholfen haben mir die folgenden Postings, danke an die Autoren!

• PXE-Bootmenü für Debian-Installer und GRML
• Convert FreeBSD ISO image for PXE bootstrap
• pxelinux BSD installs

Ebenfalls ganz interessant ist ein Eintag von RoudyBob.NET, für alle, die versuchen Microsoft Virtual PC 2004 per PXE zu booten. Ohne ein spezielles Floppy-Image funktioniert das nämlich nicht.

Why stick with the standard boring shell prompt when you can easily make it colorful and more informative? In this tip, Daniel Robbins will show you how to get your shell prompt just the way you like it, as well as how to dynamically update your X terminal’s title bar.

IBM Developerworks – Prompt Magic [via netzhure]

export LESS_TERMCAP_mb=$’\E[01;31m’
export LESS_TERMCAP_md=$’\E[01;31m’
export LESS_TERMCAP_me=$’\E[0m’
export LESS_TERMCAP_se=$’\E[0m’
export LESS_TERMCAP_so=$’\E[01;44;33m’
export LESS_TERMCAP_ue=$’\E[0m’
export LESS_TERMCAP_us=$’\E[01;32m’

Sehr praktisch! Funktioniert auch wunderbar mit der Z-Shell.
Gefunden u.a. bei moemoe.

Das Wiki des UUGRN e.V. schreibt zur Z-Shell:

Die zsh – Kurzform fuer Z-Shell wurde zur Erweiterung der bash, der csh und der tcsh entwickelt. Sie ist fast komplett zur bash und zur TENEX-C Shell kompatibel, bietet aber einige Erweiterungen:

• frei programmierbare TAB-Completion
• eine History fuer alle laufenden Instanzen
• Rechtschreibpruefung waehrend der Eingabe
• extrem themebares Prompt (auch auf der rechten Seite des Terminals moeglich)

Die zsh wurde 1989 entwicklelt und steht unter der BSD-Lizenz. Sie war lange die Standard-Shell auf MacOS X. In nahezu jeder Unix/Linux-Distrubution existieren binaer-Pakete zur Z-Shell.

Wer die Z-Shell einfach mal ausprobieren moechte, sollte sich grml ansehen:

grml is a bootable CD (Live-CD) originally based on Knoppix and nowadays based on Debian. grml includes a collection of GNU/Linux software especially for users of texttools and system administrators. grml provides automatic hardware detection. You can use grml (for example) as a rescue system, for analyzing systems/networks or as a working environment.

grml beinhaltet die Z-Shell bereits als default-Shell und bringt sehr nützliche Konfigurationen mit. Diese Configs kann man recht problemlos auf FreeBSD, Solaris oder OS X portieren, und die Z-Shell mit wenig Aufwand zur Standard-Shell auf seinem System machen.

Aber Achtung! Suchtgefahr.