Archive for the 'Betriebssysteme' Category

TACACS unter CentOS 6

Dienstag, August 28th, 2012

Informationen über TACACS gibt es in der Wikipedia (http://de.wikipedia.org/wiki/TACACS). Dieser Artikel zeigt nur, wie man einen TACACS-Server auf CentOS 6 64bit installiert.

Installation

  • Die Quelltexte gibt es unter: ftp://ftp.shrubbery.net/pub/tac_plus
  • Herunterladen mittels:
    • wget ftp://ftp.shrubbery.net/pub/tac_plus/tacacs+-F4.0.4.26.tar.gz
  • Quellen entpacken:
    • tar xzf tacacs+-F4.0.4.26.tar.gz
  • Standardmaessig sind nicht alle notwendigen Pakete installiert um den Tacacs-Daemon zu kompilieren – die werden jetzt nachinstalliert:
    • yum install -y make gcc-c++ flex bison tcp_wrappers-devel.x86_64 man xinetd
  • Configure, make, make install durchfuehren – vorher aber noch in Ordner mit den Quellen wechseln:
    • cd tacacs+-F4.0.4.26
    • ./configure --prefix=/usr
    • make
    • make install
  • Der Tacacs-Dienst ist jetzt installiert. Bevor er das erste mal gestartet werden kann, muss ein ldconfig aufgerufen werden, damit die installierten libraries erkannt werden:
    • ldconfig
  • Es fehlt noch der Ordner mit der Konfigurationsdatei. Dieser wird in /etc/ angelegt und darin die Konfigurationsdatei.
    • mkdir /etc/tac_plus
    • touch /etc/tac_plus/tacacs.conf
  • Der Tacacs-Dienst wird ueber xinetd gestartet und muss dort mit einer Konfigurationsdatei versehen werden, damit xinetd den Dienst ueberhaupt kennt. Ausserdem muss xinetd noch aktiviert und gestartet werden:
    • touch /etc/xinetd.d/tacacs
    • Moeglicher Inhalt der Konfigurationsdatei ist:
      • service tacacs
        {
        socket_type = stream
        protocol = tcp
        wait = no
        disable = no
        user = root
        server = /usr/bin/tac_plus
        server_args = -C /etc/tac_plus/tac_plus.conf -L -p 49 -i -d 16
        cps = 50 10
        flags = IPv4
        }
      • chkconfig xinetd on
      • service xinetd restart

Konfiguration des Tacacs-Dienstes

Nachdem die notwendigen Dateien installiert sind und auch der xinetd den Tacacs-Dienst kennt um ihn zu starten, kann jetzt die eigentliche Tacacs-Konfiguration eingespielt werden. Eine minimale Konfiguration in /etc/tac_plus/tac_plus.conf koennte etwa so aussehen:


accounting file = /var/log/tac-plus/account
key = 85bc054457f1d43c15de234813b4856b66d474ebde7fd6258beb532fc7
group = all {
default service = permit
service = exec {
priv-lvl = 15
}
}

user = lando {
member = all
login = des $1$0T$Ntl2SGIAxzGnEjdpjLFi00
}

Passworte, wie hier eins in der login-Zeile zu sehen ist, koennen mit tac_pwd generiert werden. Standardmaessig werden crypt-Passworte erzeugt. Es gibt mit dem Paramter -m auch die Moeglichkeit, MD5-Passworte zu nutzen. Mehr Informationen ueber die Konfiguration gibts in der Manpage: man tac_plus.conf.

VM exportieren und importieren über SSH

Sonntag, Juli 1st, 2012

Der herkömmliche Weg

Eine XenServer-VM exportieren und importieren über das CLI ist simpel. Man mountet auf beiden XenServern (auf dem ex- und importierenden) einen NFS-Server (z.B. nach /mnt):

mount 10.10.10.10:/nfs /mnt

und startet dann den Export der virtuellen Maschine BLUBB:

xe vm-export vm=BLUBB filename=/mnt/BLUBB.xva

Das dauert dann eine Weile, bis alle Daten in diese Datei geschrieben worden sind. Wenn das fertig ist, startet man den Import auf dem zweiten XenServer:

xe vm-import filename=/mnt/BLUBB.xva

und wartet wieder, bis auch das abgeschlossen ist. Diese ganze Geschichte hat nur einen Haken: man braucht im Idealfall soviel Festplattenplatz, wie in der VM an Festplattenplatz genutzt wird (also gerade aktive Daten auf der VM-Platte) – im schlimmsten Fall aber soviel Platz, wie die virtuelle Festplatte gross ist. Ein Beispiel:

  • ein CentOS wird auf einer 100GB virtuellen Festplatte installiert
  • bei der Installation werden 2GB an Daten auf diese Festplatte geschrieben
  • wird die VM jetzt exportiert, wird die Exportdatei etwa 2GB groß
  • jetzt schreibt man zusätzlich 98GB an Daten in der VM auf die virtuelle Festplatte und löscht diese Daten dann wieder
  • wird die VM jetzt exportiert, wird die Exportdatei etwa 100GB groß, man braucht also 100GB auf dem NFS-Server.

Das zeigt, dass beim Löschen von Dateien nicht der Inhalt selbst gelöscht wird (und ausgenullt oder überschrieben wird), sondern nur entsprechende Verweise in der Dateisystemstruktur gelöscht werden. Um diese Dateien wirklich zu Löschen müsste man den freien Speicher der Festplatte mit Nullen oder Zufall überschreiben. Sollte man sich für ersteres entscheiden, hat dies auch beim Export wieder den Vorteil, dass die Datei kleiner wird.

Der SSH-Weg

Es gibt aber auch einen Weg den Import und Export einer VM gleichzeitig zu erledigen:

ssh SERVER-A-IP „xe vm-export vm=BLUBB filename=“ | xe vm-import filename=/dev/stdin

Nochmal zur Erläuterung, was passieren soll: Man will eine VM von Server A nach Server B verschieben, ohne sie temporär irgendwo abzulegen. Um dies zu erreichen, meldet man sich auf Server B an und startet eine SSH-Sitzung zu Server A. Das Kommando, welches durch SSH auf A ausgeführt wird, exportiert die VM, schreibt sie aber nicht in eine Datei. Wenn beim xe vm-export der filename leer bleibt, geht die Ausgabe nach stdout und das wird durch SSH zum Server B transportiert. Nun muss nur noch die Ausgabe an vm-import gegeben werden. Leider funktioniert hier der Parameter filename etwas anders und holt sich die Eingabe nicht von stdin. Aber das ist insofern kein Problem, als dass stdin auch über eine Datei angesprochen werden kann (/dev/stdin).

Auch hier gilt: sollte viel auf der Festplatte der VM herumgeschrieben worden sein, dauert der Export mitunter sehr lange. Aber man erspart sich das Speichern auf einem NFS-Server oder einem anderen Medium.

 

Ubuntu 10.04 HVM to PV

Freitag, Februar 24th, 2012

Wenn man ein Ubuntu als vollvirtualiserte Maschine hat (z.B. wenn man eine physikalische Maschine virtualisiert hat), dann kann man es nachträglich recht einfach in eine paravirtualisierte VM umbauen. Dazu muss der Kernel passen und die Konsoleneinstellungen müssen in der VM angepasst werden. Danach werden ein paar HVM-Einstellungen geleert und der PV-Bootloader festgelegt.

  1. Ubuntu Gast-Einstellungen:
    1. # apt-get update && apt-get install linux-image-generic-pae
      (oder  entsprechenden amd64-Kernel)
    2. # cp /etc/init/tty1.conf /etc/init/hvc0.conf
      Mit beliebigem Editor /etc/init/hvc0.conf editieren und alle vorkommenden tty1 durch hvc0 ersetzen und die Datei speichern.
    3. # shutdown -P now
      Die VM herunterfahren.
  2. XenServer-Einstellungen
    Auf der Konsole des XenServers müssen einige Einstellungen der VM angepasst werden
    1. # xe vm-list power-state=halted
      Zeigt alle abgeschalteten VMs an. Hier die gewünschte VM heraussuchen und die UUID notieren
    2. # xe vm-param-set uuid=UUID HVM-boot-policy=
      UUID durch die vorher ermittelte ersetzen. HVM-boot-policy wird ein leerer Wert zugewiesen
    3. # xe vm-param-set uuid=UUID PV-bootloader=pygrub
      Der Bootloader für die VM wird auf pygrub geändert.
    4. # xe vm-disk-list uuid=UUID
      Zeigt alle der Festplatte zugeordneten Festplatten an. Hier wird die UUID der VBD mit der ID 0 gesucht.
    5. # xe vbd-param-set uuid=VBD_UUID bootable=true
      Diese VBD wird als bootfähig markiert
    6. # xe vm-start uuid=UUID
      VM starten
  3. Gasterweiterungen in der VM installieren
    1. xs-tools.iso bei der VM einlegen
    2. # mount /dev/xvdd /mnt
      In der VM die CD mounten (ggf. die Device- und Ordnernamen anpassen)
    3. # cd /mnt/Linux; ./install.sh
      Gasterweiterungen installieren
      # dpkg -i /mnt/Linux/xe-guest-utils*i386.deb
      (oder statt i386.deb amd64.deb fuer 64bit-Systeme)
    4. # sudo reboot
      VM neustarten

Nach dem Starten der VM muss man meist das XenCenter neustarten, da er sonst keine Eingabe in der Konsole der VM erlaubt.

Diese Prozedur funktioniert sowohl bei Ubuntu 10.04 als auch bei 8.04 und 8.10. Die Namen der Kernel-Images unterscheiden sich zwar hier und da, der grobe Ablauf ist aber der selbe.

 

VMs beenden

Freitag, Februar 24th, 2012

Es gibt mehrere Möglichkeiten um VMs zu beenden. Der einfachste: im XenCenter ein Shut Down auslösen. Das hilft aber nicht immer, dann funktioniert meist ein Force Shut Down.

Heute hatte ich es, dass alle vollvirtualisierte VM keine Konsole mehr angezeigt hat – keinerlei Bild kam, noch nichteinmal irgendwas schwarzes. Auch auf der Konsole haben sich die VMs nicht beenden lassen. Ich bekam lediglich die Meldung, dass noch eine Operation ausgeführt wird. Auch ein xe task-list und xe task-cancel haben das nicht behoben.

Hier hat dann folgender Thread geholfen: http://forums.citrix.com/thread.jspa?threadID=274697&start=15&tstart=0. Der Thread ist zwar fuer XenServer 5.6, es trifft aber auch auf XenServer 6.0.0 zu.

Um es hier nochmal kurz zusammenzufassen:

  1. VM-UUID herausfinden:
    # xe vm-list name-label=XYZ_VM params=uuid
    uuid ( RO)    : ddf7adee-13ff-85d8-d631-8287359f84dc
  2. Domain-ID mittels der UUID der VM herausfinden:
    #  list_domains |grep ddf7adee-13ff-85d8-d631-8287359f84dc
    44 | ddf7adee-13ff-85d8-d631-8287359f84dc |    B H
  3. Die ID 44 dann zum zerstören der Domain verwenden:
    # /opt/xensource/debug/destroy_domain -domid 8
  4. Nun die VM neustarten:
    # xe vm-reboot uuid=ddf7adee-13ff-85d8-d631-8287359f84dc force=true
Danach sollte die VM neustarten und auch wieder verfügbar sein. Um zu testen, ob wirklich wieder alles in Ordnung ist, empfiehlt es sich, die VM nochmal herunterzufahren und dann neuzustarten (kein reboot, ein richtiger Shutdown). Ich hatte hier das Problem, dass ich eine Meldung bekommen habe: 24.02.2012 23:15:33 Error: Starting VM ‚XYZ_VM‘ – The VDI is not available. Das lässt sich am einfachsten durch ein Kopieren der VM beheben (Fastcopy reicht). Die Kopie sollte problemlos starten. Das Original kann dann einfach gelöscht werden.

OnlineTVRecorder-Decoder

Mittwoch, Mai 11th, 2011

Wer einen Account bei OnlineTVRecorder.com hat, wird feststellen, dass der Decoder bei weitem nicht fuer alle Betriebssysteme verfuegbar ist. Eine Datei herunterladen und direkt auf dem Server dekodieren ist also nicht ganz so einfach, wenn man ein FreeBSD hat. Wie unschoen das zunaechst auch erscheint, es gibt eine Moeglichkeit den Decoder trotzdem zu nutzen: den Linux-Kompatibilitaets-Layer.

Vorbereitungen

Installation

Statisches Binary

Nun, da das FreeBSD installiert ist, kann man das Linux-Binary des Decoders herunterladen. Den gibt es auf den Seiten des OTR im Linux-Bereich (Link zu den OTR-Downloadseiten). Dort gibt es diverse Linux-Versionen. Zunächst habe ich es mit der einfach statisch gelinkten Version ausprobiert. Das ging soweit auch, allerdings konnte er nie zum Server verbinden um die OTR-Datei zu dekodieren. Ich habe immer den selben Fehler erhalten, wie er auch im OTRForum zu finden war: „No Connection to Server“. Kein warum oder wieso… es geht schlicht nicht.

Statisch gelinktes Binary funktioniert also gar nicht.

Dynamisch gelinktes Ubuntu-Binary

Nächster Versuch erschien mir eigentlich unnötig, aber weil das ausprobieren ja schnell gemacht ist, habe ich dann doch noch das Ubuntu-Binary geladen und ausprobiert. Damit lief das Dekodieren der OTR-Datei problemlos. Wirklich installieren muss man den Decoder auch nicht. Es reicht das tar.bz2 auszupacken und die Datei otrdecoder auszufuehren (natuerlch mit den entsprechenden Parametern).

Welche der dort angebotenen Versionen funktionieren denn schlussendlich? Probiert habe ich insgesamt drei Versionen:

  1. Dekoder (Statisch gelinkt): funktioniert nicht
  2. Dekoder (Dynamisch gelinkt (Ubuntu Gutsy)): funktioniert
  3. EasyDecoder (Konsolenversion, 32bit – Ubuntu 8.04): funktioniert.

Die 64bit Varianten habe ich nicht weiter getestet, nachdem die 32bit Versionen liefen.

Partitionen und Volumes vergroessern

Montag, Oktober 18th, 2010

Heute stand ich mal wieder vor einem interessanten Problem. Ich habe in einer virtuellen Umgebung (in diesem Falle XenServer) ein Template, dass nach dem Ausrollen in eine VM, eine 10GB Platte hat. Ich kann diese dann einfach im XenCenter vergroessern, was allerdings nur dazu fuehrt, dass das Betriebssystem in der VM, eine groessere Festplatte anzeigt. Eingebunden wird von diesem zusaetzlichen Speicherplatz nichts. Dazu bedarf es ein bisschen Abhilfe. Meine Festplatte ist im folgenden /dev/xvda, diese hat 2 Partitionen:

  1. /dev/xvda1 – 512MB Partition fuer /boot, ext2 als Dateisystem
  2. /dev/xvda2 – etwa 8.5GB grosse Partition fuer LVM (enthaelt root und swap)

Um das ganze nun umzubauen, damit /dev/xvda3 mehr als nur diese 8.5GB hat, sondern auch den restlichen freien Platz nutzt, sind folgende Schritte notwendig:

Notwendige Software

Auf einem debian brauche ich dazu: gpart (enthaelt sfdisk) und lvm2:

aptitude install gpart lvm2

Werte bestimmen

Bestimmen der Start- und Endwerte der zu aendernden Partition:

fdisk -u -l /dev/xvda

Das gibt folgende Ausgabe:

Disk /dev/xvda: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders, total 41943040 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000b41d0

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1   *        2048      999423      498688   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/xvda2          999424    23066623    11033600   8e  Linux LVM

Werte berechnen

Die Ausgabe von dem fdisk-Aufruf eben enthaelt alle notwendigen Angaben. Sowohl den Anfangs- als auch den Endwert. Der Anfangswert ist die 999424 (siehe auch das Device xvda2) und der Endwert ist die Sektor der Platte 41943040. Die Groesse der Partition muss berechnet werden: Sektorzahl der Platte minus Anfangswert – in meinem Bespiel also 41943040 – 999424 = 40943616

Partition vergroessern

Das eigentliche Vergroessern erfolgt mit sfdisk:

sfdisk --force -uS -N2 /dev/xvda

An der Kommandozeile von dem Programm dann erst den Startwert (999424) und die Groesse (40943616) angeben, mit Enter bestaetigen und dann noch die Aenderung mit y bestaetigen.

Die Partitionsgrenzen sind damit verschoben und um diese Aenderungen vollstaendig zu uebernehmen, muss die Maschine neugestartet werden.

PV und LV vergroessern

Die Partition ist jetzt auf volle Groesse gebracht, nun erfolgt das Vergroessern der ganzen LVM-Geschichten:

  1. Physical Volume vergroessern:
    pvresize /dev/xvda2

    Mit pvdisplay kann man die Aenderung kontrollieren.

  2. Die Volume Group sollte jetzt ebenfalls vergroessert sein. Kontrolle erfolgt ueber: vgdisplay. Hier kann man dann ebenfalls sehen, wieviel Speicherplatz jetzt auf dem Volume frei ist.
  3. Logical Volume vergroessern:
    sudo lvextend -l +100%FREE data/root

Dateisystem vergroessern

Als letztes wird dann noch das Dateisystem angepasst und auf die maximale Groesse aufgeblasen. In meinem Beispiel ist es ein ext3. Das Vergroessern dauert… je nach Groesse eine ganze Weile:

resize2fs /dev/data/root

Fertig. Kontrolle erfolgt ueber df -h. Wenn hier jetzt die neue Festplattengroesse erscheint, ist alles glatt gelaufen. Am besten aber nochmal die Maschine neustarten, damit man sicher ist, dass nicht irgendwo ein kleiner Fehler ist. Gegebenenfalls ist sogar ein Filesystemcheck sinnvoll. Dieser sollte nicht auf einem gemounteten Dateisystem durchgefuehrt werden, sondern beim naechsten Neustart ablaufen. Dazu muss die Datei /forcefsck angelegt werden:

touch /forcefsck

Unixeinführung 2010

Sonntag, Mai 30th, 2010

Dieses Jahr wurde von der Fachschaft Informatik mal wieder eine Unixeinfuehrung in die Projektwoche aufgenommen, die ich letzten Freitag gehalten habe. Die Vortragsfolien finden sich im Anhang zum Download. Viel Spass damit.

Download: unixeinfuehrung2010.zip

NetBSD5-Netzwerkinstallation

Montag, Juli 20th, 2009

So ab und an kommt es doch mal vor, dass ich mich von FreeBSD zu Open- oder NetBSD verirre. Dann stehe ich jedes mal vor der Frage: Verbrenne ich einen Rohling fuer die Installation oder installiere ich den Kram via Netzwerk? Meist entscheide ich mich dann fuer letzteres. Die Infrastruktur (TFTP- und DHCP-Server) ist sowieso vorhanden.

Gestern war wieder so ein Versuch ein NetBSD5 auf eine Kiste zu buegeln. Es war bei NetBSD mal so, dass es einen extra Installations-Kernel gab. Da brauchte man lediglich die pxeboot-Datei, die dem DHCP-Server hingeworfen wurde und eben diesen Installation-Kern. Mitlerweile hat sich aber eine Kleinigkeit geaendert, denn es wird nur noch der GENERIC-Kern und eine Ramdisk (miniroot.kmod) benoetigt um ins NetBSD-Setup zu gelangen. Um diese Veraenderung zu verstehen bzw. um herauszubekommen, wie es nun tatsaechlich geht, habe ich eine ganze Weile gebraucht. Das NetBSD-Handbuch schweigt sich darueber aus.

Schritt 1: TFTP-Server

Der Anfang dieser Installation ist wie gehabt. Man startet einen TFTP-Server, der die Dateien pxeboot_ia32.bin (fuer NetBSD5 zum Beispiel hier herunterladbar) und kern-GENERIC.tgz (Download hier) ausliefert. Darueber hinaus braucht man mitlerweile noch die entsprechende Ramdisk: miniroot.kmod (gibts hier zum herunterladen)
Unter FreeBSD wuerde das etwa so aussehen: Zunaechst werden die Dateien heruntergeladen und in /tftpboot abgelegt.

cd /tftpboot
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/installation/misc/pxeboot_ia32.bin
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/binary/sets/kern-GENERIC.tgz
fetch ftp://ftp.de.netbsd.org/pub/NetBSD/NetBSD-5.0/i386/installation/miniroot/miniroot.kmod

Nun muss noch der TFTP-Server in /etc/inetd.conf aktiviert werden. Dazu wird das Kommentarzeichen vor der Zeile

#tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -s /tftpboot

entfernt. Danach kann man dann entweder ein inetd_enable=“YES“ in /etc/rc.conf unterbringen und mittels /etc/rc.d/inetd starten, oder aber man fuehrt einfach ein /etc/rc.d/inetd forcestart aus. Beides fuehrt auf jeden Fall dazu, dass der inetd gestartet wird.

Schritt 2: DHCP-Server

Einen laufenden DHCP-Server vorausgesetzt, sollte ein kleiner Eintrag reichen. Ich selber habe einen isc-dhcpd am laufen, den ich um folgende Zeile im Subnet-Bereich der dhcpd.conf ergaenzt habe:

filename "pxeboot_ia32.bin";

Danach noch den DHCP-Server neustarten (/usr/local/etc/rc.d/isc-dhcpd restart) und alles sollte soweit funktionieren.
Sicher koennte man auch der Einfachheit halber einen Eintrag fuer die entsprechende MAC-Adresse machen, aber ich hatte diese gerade nicht zur Hand, als ich den DHCP konfiguriert habe. Sie stand schlichtweg nicht auf dem Device drauf. Also habe ich einfach als globale Einstellung das pxeboot eingetragen. Da sollte man vielleicht noch dran denken das wieder zu deaktivieren. Ansonsten koennte es irgendwann mal komische Ueberraschungen geben, wenn ploetzlich einige Rechner versuchen ein NetBSD aus dem Netz zu booten. 🙂

Schritt 3: Rechner installieren

Nun fehlt eigentlich nur noch eine Sache, die da waere, den Zielrechner zu installieren. Dazu wird er ganz normal angeschlossen und gestartet. Sofern er pxeboot-faehig ist und dies auch aktiviert ist (das ist rechnerabhaengig), sollte der NetBSD-pxeboot kommen. Dort hat man 5 Sekunden lang Zeit die Leertaste zu druecken. Nachdem das erfolgt ist, braucht man eigentlich nur noch zwei Befehle:

load tftp:miniroot.kmod
boot tftp:kern-GENERIC.tgz

Falls man noch Einstellungen mittels userconf machen will, kann man hier noch ein -c anfuegen: boot tftp:kern-GENERIC.tgz -c.

Soweit so gut, sollte eigentlich funktionieren und den Rechner ins Setup booten lassen.

Fedora 11 – Leonidas

Dienstag, Juni 9th, 2009

Auch bei diesem Release gibt es die finalen Fedora-Images mal wieder ein kleines Stückchen früher als gewöhnlich zum downloaden: ftp://public.lando.cc/pub/linux/fedora11/.

CentOS 5.3 und Plesk 9.2.1

Dienstag, Mai 5th, 2009

Ich habe am Wochenende meinen CentOS-Server auf Version 5.3 gehievt, was erstaunlich problemlos funktioniert hat. Nach ein paar Empfehlungen aus einigen Foren, habe ich folgende Updatebefehle gewählt:

yum -y update yum
yum clean all
yum -y update glibc
yum -y update

Nun noch das Plesk-Update durchwuergen – das gabs dann gestern Nacht. Sonst hatte ich ja bei jedem groesseren Plesk-Update eher mit Problemen zu kaempfen. Aber diesmal hat auch das erfreulicher Weise funktioniert. Man sollte sich lediglich die Updateanweisung einmal genauer anschauen. Diese ist auf den Parallels-Seiten zu finden. Das Greylisting funktioniert wunderbar und spart auf meinem Server einiges an Ressourcen an. DNS-Blacklisting ist zwar gut und schoen, bringt aber nicht immer sonderlich viel. Ich denke, dass die Kombination aus DNSBL und Greylisting sehr lange und gut funktionieren wird.