The three most painfull IP protocolls

Während meiner IT Laufbahn, die nun immerhin bereits ca. 13 Jahre währt, gab es immer wieder Anwendungsfälle, die einem fast in den Wahnsinn treiben. Ein beliebtes Problem was uns ITlern wohl bis zur flächendeckenden Einführung von IPV6 immer wieder begegnen wird, ist das eine oder andere Internet Protokoll ordentlich über eine NAT Firewall zu bekommen. Gerade verzweifele ich mal wieder an einem hierzu prädestiniertem Kandidaten. Wer designed eigentlich diese Protokolle? Leben die in einer anderen Welt? Vermutlich kommen die Informatiker, denen wir das zu verdanken haben von irgendwelchen Unis die aus historischen Gründen noch ein /8 Netz mit öffentlichen IPs haben und jeden Uni Rechner mit einer public IP versorgen. Wie auch immer hier nun meine persönlichen Top 3 der nervigsten Internet Protokolle:

  1. SIP – Wer käme auch schon auf Idee sein IP Telefon zu Hause nicht als einziges Gerät an seinem Internetanschluss zu verwenden, damit man kein NAT verwenden muss.
  2. IPSEC – Vielen Dank für dieses unnötig komplizierte Protokoll. Natürlich nicht hinter NAT Firewalls zu verwenden. Gott sei Dank gibt es OpenVPN
  3. FTP – Dank der prima Idee zwei verschiedene Ports zu verwenden und diese in entgegengesetzter Richtung kommunizieren zu lassen

Falls Ihr eine andere Top 3 Liste habt: Schreibt doch nen Kommentar.

VDR Shutdown Shortcut

Aktuell bin ich mal wieder dabei den stromfressenden Homeserver im Keller loszuwerden. Bisher sieht der gefühlt 27. Versuch ganz gut aus. Dank pfsense und siproxd muss die FritzBox nicht mehr Router spielen, damit SIP funktioniert. OpenVPN hat ebenfalls dank pfsense und der eingebauten AES-128 Hardware Beschleunigung meines Alix Boards gute Performance bei minimalem Stromverbrauch. Jetzt fehlte nur noch eine passende Lösung für VDR. Die Lösung: yaVDR. Diese Ubuntu basierte VDR Distribution hat direkt alles eingebaut, was ich so brauche (XBMC, mcli plugin für Netceiver,…) und ACPI Wakeup funktioniert out of the box. Nun kann ich meine VDR Kiste gepflegt per WakeOnLan per pfsense Webinterface von überall aufwecken. Der passende Link für ein Lesezeichen im Browser sieht wie folgt aus:
http://[pfSense IP]/services_wol.php?mac=[MAC Adresse des Rechners]&if=lan

Um den VDR nun wieder herunterzufahren, ohne SSH bemühen zu müssen, nutze ich vdradmin-am. Der passende Link:
http://[IP des VDR Rechners]:8001/vdradmin.pl?vdr_cmd=5&run_vdrcmd=Ausf%C3%BChren&aktion=vdr_cmds

Schöne bunte Graphen

Gesucht war eine Möglichkeit die Daten aus der Temperaturüberwachung geeignet in einem schönen bunten Graphen darzustellen.
Bisher habe ich cacti mit einem eigenen Template verwendet. Allerdings ist mir das Tool etwas zu überladen und ich benötige die SNMP Funktionen (außer für die Temperaturüberwachung) nicht, da ich ansonsten collectd verwende. In Cacti ist es leider nicht vorgesehen fremd erzeugte RRD Graphen einfach nur anzuzeigen. Es gibt zwar ein python script welches die collectd Graphen in Cacti einbindet, aber das ist am Ende doch wieder nur Gefrickel.
Drraw ist eine schlanke Alternative, die genau das tut was ich möchte: Einfach nur bunte Graphen aus RRD Files bauen. Am Ende wurden es einige Stunden Gebastel, aber das Ergebniss kann sich sehen lassen:

Anbei noch der passende Aufruf von rrdtool:

rrdtool graph -
--start=end - 1 day
--end=now
--title=Temperatur Außen
--vertical-label=C
--imgformat=PNG
--width=500
--base=1000
--height=240
--interlaced
DEF:b=file1.rrd:eddn_temp:AVERAGE
DEF:w=file2.rrd:eddn_temp:AVERAGE
CDEF:D=b,23,GE,b,24,LT,b,24,IF,0,IF
CDEF:C=b,24,GE,b,0,IF
CDEF:E=b,22,GE,b,23,LT,b,23,IF,0,IF
CDEF:F=b,21,GE,b,22,LT,b,22,IF,0,IF
CDEF:G=b,20,GE,b,21,LT,b,21,IF,0,IF
CDEF:H=b,19,GE,b,20,LT,b,20,IF,0,IF
CDEF:I=b,18,GE,b,19,LT,b,19,IF,0,IF
CDEF:J=b,17,GE,b,18,LT,b,18,IF,0,IF
CDEF:K=b,16,GE,b,17,LT,b,17,IF,0,IF
CDEF:L=b,11,GE,b,16,LT,b,16,IF,0,IF
CDEF:M=b,10,GE,b,12,LT,b,11,IF,0,IF
CDEF:N=b,9,GE,b,10,LT,b,10,IF,0,IF
CDEF:O=b,8,GE,b,9,LT,b,9,IF,0,IF
CDEF:P=b,7,GE,b,8,LT,b,8,IF,0,IF
CDEF:Q=b,6,GE,b,7,LT,b,7,IF,0,IF
CDEF:R=b,5,GE,b,6,LT,b,6,IF,0,IF
CDEF:S=b,4,GE,b,5,LT,b,5,IF,0,IF
CDEF:T=b,3,GE,b,4,LT,b,4,IF,0,IF
CDEF:U=b,3,LT,b,5,IF
CDEF:A=b
VDEF:V=b,AVERAGE
LINE1:b:
AREA:D#FF3300:
AREA:C#FF0000:
AREA:E#FF6600:
AREA:F#FF9900:
AREA:G#FFCC00:
AREA:H#CCFF00:
AREA:I#99FF00:
AREA:J#66FF00:
AREA:K#33FF00:
AREA:L#00FF00:
AREA:M#00FF33:
AREA:N#00FF66:
AREA:O#00FF99:
AREA:P#00FFCC:
AREA:Q#00CCFF:
AREA:R#0099FF:
AREA:S#0066FF:
AREA:T#0033FF:
AREA:U#0000FF:
LINE1:A#000000:Außen
VDEF:A_MIN=A,MINIMUM
GPRINT:A_MIN:Min: %8.2lf%s
VDEF:A_AVERAGE=A,AVERAGE
GPRINT:A_AVERAGE:Avg: %8.2lf%s
VDEF:A_MAX=A,MAXIMUM
GPRINT:A_MAX:Max: %8.2lf%s
VDEF:A_LAST=A,LAST
GPRINT:A_LAST:Last: %8.2lf%sn
LINE1:w#808080:Innen
LINE1:V#008000:Durchschnitt

floek goes OpenSolaris: xVM tuning

Hier noch einige Tuning-Tips für xVM und ZFS:
Damit ZFS nicht zu viel RAM frisst sollte man in /etc/system die Zeile

set zfs:zfs_arc_max = 0x10000000

hinzufügen.

Wenn eine VM abstürzt wird ein Dump unter /var/xen/dump geschrieben. Da hierdurch ggf. das root Filesystem vollgeschrieben werden kann, sollte man dieses Verzeichnis in ein eigenes Dateisystem legen:

zfs create -o mountpoint=/var/xen/dump,quota=2G rpool/xendumps

Die CPU und RAM Ressourcen der Dom0 möchte man ggf. ebenfalls beschränken. Hierzu übergibt man geeignete Parameter an den Hypervisor, indem man in /rpool/boot/grub/menu.lst den Aufruf des Xen Hypervisors z.B. wie folgt anpasst:

kernel$ /boot/$ISADIR/xen.gz console=com1 com1=auto dom0_mem=1024M dom0_max_vcpus=1

Weiterhin sollte man noch folgende Option setzen und den xend neu starten:

svccfg -s svc:/system/xvm/xend setprop config/dom0-min-mem = 2334
svcadm refresh svc:/system/xvm/xend:default
svcadm restart svc:/system/xvm/xend:default

Schlussendlich sollte man noch den gdm deaktivieren:

svcadm disable gdm

Quelle: http://hub.opensolaris.org/bin/view/Community+Group+xen/configuring-dom0

floek goes OpenSolaris: xVM

Die Xen Implementierung in OpenSolaris nennt sich aus markenrechtlichen Gründen xVM und wird standardmäßig mitgeliefert. Die Installation erfolgt über das Paketmanagement:

pkg install SUNWxvm SUNWxvmdom SUNWxvmhvm SUNWxvmipa SUNWxvmpv xvm xvm-gui SUNWlibvirt SUNWvirt-manager SUNWvirtinst


Nach Abschluss der Installation sollte man folgende Dienste aktivieren (svcadm enable dienst):

online 11:10:27 svc:/system/xvm/vnc-config:default
online 11:39:10 svc:/system/xvm/store:default
online 11:39:11 svc:/system/xvm/xend:default
online 11:39:12 svc:/system/xvm/console:default
online 11:39:12 svc:/system/xvm/domains:default
online 11:55:04 svc:/system/xvm/virtd:default


Jetzt noch einen zusätzlichen Eintrag im grub Menü erstellen, damit der Hypevisor auch vor dem OpenSolaris Kernel geladen wird. Hier zu sollte folgender Eintrag zu /rpool/boot/grub/menu.lst hinzugefügt werden (In meinem Beispiel liegt das System auf dem zpool rpool):

title OpenSolaris 2009.06 xVM
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/opensolaris
splashimage /boot/solaris.xpm
foreground d25f00
background 115d93
kernel$ /boot/$ISADIR/xen.gz
module$ /platform/i86xpv/kernel/$ISADIR/unix /platform/i86xpv/kernel/$ISADIR/unix -B $ZFS-BOOTFS,console=graphics
module$ /platform/i86pc/$ISADIR/boot_archive


Nach einem Reboot in OpenSolaris 2009.06 xVM sollte nun die Virtualisierungsumgebung bereit sein. Dies sieht man am schnellsten über virsh list. Hier sollte zumindestens so etwas zurückgegeben werden:

Id Name State
----------------------------------
0 Domain-0 running

Andernfalls ist wahrscheinlich etwas schief gelaufen. Debugging Informationen gibt es in

  • /var/svc/log/*xvm*
  • /var/log/xen/
  • Jetzt kann man sich einen ZFS Poo erstellen, wenn gewünscht, (zpool create xvmpool raidz2 c7t0d0 c7t1d0 c7t2d0 c7t3d0 c7t4d0) und darin Volumes für die VMs einrichten (zfs create -V 10G xvmpool/domain). Diese stehen dann unter /dev/zvol/dsk/xvmpool/domain zur Verfügung. VMs lassen sich jetzt z.B. per virt-manager oder virt-install installieren. Hierbei ist das jeweilige zvol als file anzugeben. Falls man bereits vorhandene (Xen) VMs hat, kann man diese z.B. per cat domainimage > /dev/zvol/rdsk/xvmpool/domain importieren. Auch das ggf. vorhandene Xen Configfile lässt sich per xm create domainconfig importieren. Da allerdings einige Anpassungen notwendig sind und man xVM lieber über virsh steuern möchte, empfiehlt es sich gleich das XML Format von virsh zu nutzen. Ich poste hier mal eine Config für ein paravirtualisiertes Ubuntu, welches als Vorlage genutzt werden kann:

    <domain type='xen'>
    <name>ubuntu</name>
    <bootloader>/usr/lib/xen/bin/pygrub</bootloader>
    <os>
    <type>linux</type>
    </os>
    <memory>262144</memory>
    <vcpu>1</vcpu>
    <on_poweroff>destroy</on_poweroff>
    <on_reboot>restart</on_reboot>
    <on_crash>restart</on_crash>
    <clock offset='utc'/>
    <devices>
    <interface type='bridge'>
    <source bridge='rge0'/>
    <script path='vif-vnic'/>
    </interface>
    <disk type='block' device='disk'>
    <driver name='phy'/>
    <source dev='/dev/zvol/dsk/xvmpool/ubuntu'/>
    <target dev='hda'/>
    </disk>
    <console tty='/dev/pts/7'/>
    </devices>
    </domain>

    Das ganze als z.B. ubuntu.xml speichern, via virsh define ubuntu.xml importieren, mit virsh start ubuntu starten und über virt-console ubuntu beim booten zuschauen.
    Neue VMs habe ich einfach voll virtualisiert installiert und dann innerhalb der VM einen Xen Kernel installiert. Bei ubuntu muss man aufpassen, dass ein update-grub in der Vollvirtualisierung keinen Grub Eintrag für den Xen Kernel erzeugt. Diesen muss man händisch zur /boot/grub/menu.lst hinzufügen und als default Kernel einrichten. Anschließend kann man die Config per virsh dumpxml domain > domain.xml exportieren, anhand obiger Beispielconfig anpassen und per virsh define domain.xml wieder importieren.

    floek goes OpenSolaris: nrpe

    Glücklicherweise gibt es Nagios Plugins und den nrpe Daemon für das Monitoring im contrib Repository. Hier gibt es Pakete die von der Community bereitgestellt werden und einen Prüfprozess durchlaufen haben. Das contrib Repository lässt sich wie folgt zusätzlich zum normalen Repository nutzen:
    pkg set-authority -O http://pkg.opensolaris.org/contrib/ contrib
    Nun installiert pkg install nrpe nagios-plugins die binaries des nrpe daemon und der Nagios Plugins. Die Files liegen unter /usr/nagios/. Jetzt noch /usr/nagios/etc/nrpe.cfg anpassen und ggf. noch einen User und eine Gruppe für den nrpe daemon anlegen und wir sind fasst fertig. Ich habe einen Blog Eintrag gefunden, der beschreibt, wie man den nrpe daemon unter SMF zum laufen bekommt. Hierzu http://blogs.digitar.com/media/2/nrpe_smf.zip runterladen, entpacken, in das neue Verzeichniss wechseln und noch etwas die Pfade in ./manifest/nagios-nrpe.xml und ./method/nagios-nrpe anpassen. Jetzt kann man via

    # cp ./manifest/nagios-nrpe.xml /var/svc/manifest/network/
    # cp ./method/nagios-nrpe /lib/svc/method/
    # svccfg import /var/svc/manifest/network/nagios-nrpe.xml
    # chmod +x /lib/svc/method/nagios-nrpe

    den SMF Dienst installieren. Ist alles gut gegangen startet ein svcadm enable nrpe den nrpe Dienst. Falls was schief gegangen ist kann man in /var/svc/log/network-nagios-nrpe:default.log nachschauen welche Fehlermeldung ausgegeben wird.

    floek goes OpenSolaris: OpenSolaris Minimalinstallation auf USB Stick

    Die Standardinstallation von OpenSolaris benötigt ca. 3 GB Platz und bringt viel Zeug mit was kein Mensch auf einem Server braucht. Unter anderem Gnome, Firefox, Evolution uvm. Leider kann man mit dem GUI Installer auf der Live CD nicht auswählen was man denn installieren möchte. Allerdings gibt es ein Script von Mark Johnson, welches hier hilft. Man bootet den Rechner von der Live CD. Hier reicht es in die Text Konsole zu booten (Login: jack/jack, root/opensolaris) und das Script per wget http://blogs.sun.com/mrj/resource/slim-guest-installer;chmod +x slim-guest-installer runterzuladen. Falls man auf USB Sticks installieren möchte muss man das Script noch etwas anpassen, damit diese auch für die Installation zur Verfügung stehen: vi slim-guest-installer +74. Ersetze ['/usr/sbin/format'] durch ['/usr/sbin/format', '-e'], nun werden vom Script auch USB Sticks gefunden. Jetzt kann man per ./slim-guest-installer die Installation starten. Festplatte oder USB Stick auswählen und los gehts. Allerdings wird OpenSolaris tatsächlich sehr sliminstalliert. So fehlen in der Installation ggf. Treiber für Netzwerk und SATA Platten. SSH oder nen vi gibt es auch erst mal nicht. Daher sollte man Nach Abschluss des Scripts gleich die notwendigen Pakete nachinstallieren. Zuerst muss man das Verzeichnis herausfinden, wo die neue Installation gemountet wurde. Hier hilft ein einfaches mount. Anschließend kann man die Pakete per

    /bin/pkg -R install
    SUNWrge
    SUNWsshd
    SUNWssh
    SUNWsshcu
    SUNWvim
    SUNWahc

    nach installieren. Nun noch ein reboot und schon kann man sich in seinem Minimal-OpenSolaris einloggen. Die Netzwerkkonfiguration muss nun noch manuell erledigt werden. Ich empfehle erst mal SSH an den Start zu bekommen und dann den Rest remote zu machen. Erst mal braucht es eine IP: ifconfig rge0 plumb 192.168.1.2/24 up. In meinem Fall fehlten noch die SSH-Keys für den Host. Diese habe ich per

    ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N "" -C ""
    ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N "" -C ""

    nachinstalliert. Danach svcadm enable ssh und einloggen per ssh sollte möglich sein. Jetzt muss man noch die Netzwerkkonfiguration nach der alten Methode gemacht werden. Ich gehe hier nicht weiter darauf ein. Nur ein paar Files die angepasst werden müssen gebe ich hier an:

  • /etc/hostname.rge0
  • /etc/netmasks
  • /etc/hosts
  • /etc/nsswitch.conf
  • /etc/resolv.conf
  • /etc/defaultrouter
  • floek goes OpenSolaris: Boot from USB mirror

    Booten von Festplatten? Warum eigentlich? Wenn ich meine 5x 500GB Platten zu einem großen Array zusammenbauen möchte, kann ich nicht davon booten. Außerdem braucht es für ein Betriebssystem ja nicht so viel Platz. Also: Zwei 8 GB USB Sticks gekauft, einen Mirror (RAID-1) drüber gemacht und davon gebootet. Los gehts:
    Continue reading