Kategorie-Archiv: Linux

Ubuntu 9.04 und TrekStor Vibez MP3 Player

Mein TrekStor Vibez MP3-Player wurde unter früheren Linux-Distributionen immer als USB Massenspeicher erkannt. Daten liessen sich ohne Probleme wie bei einem USB Stick kopieren. Unter Ubuntu 9.04 wird das Gerät als Vibez MP3 Player erkannt, es lassen sich aber keine Daten kopieren. Die Ursachen dieses Fehlers und seine Behebung sind folgendermassen zu beschreiben:

Der Fehler

Für die Erkennung von USB Geräten und die Einbindung in das System ist u.a. HAL (hardware abstraction layer) zuständig. Bei Anschluss eines USB Geräts scannt HAL dieses und entscheidet über die Einbindungsart. Für den TrekStor Vibez ist in /var/log/messages zu sehen:


[1] usb 2-1.2: new high speed USB device using ehci_hcd and address 7
[2] usb 2-1.2: configuration #1 chosen from 1 choice
[3] scsi12 : SCSI emulation for USB Mass Storage devices
[4] gvfsd-gphoto2[22362]: segfault at c ip b7d629e0 sp bfbf4c24 error 4 in libpthread-2.9.so[b7d5b000+15000]

In Zeile 1 wird das Gerät erkannt, in Zeile 4 wird das für dieses Gerät zuständige GVFS Modul gestartet. GVFS ist die GNOME Implementierung eines virtuellen Dateisystems auf Benutzerebene. Es abstrahiert reale Dateisysteme und bietet eine einheitliche Schnittstelle für Anwenderprogramme, z.B. für Nautilus. Das Problem hier ist nur: Das gvfsd-gphoto2 Modul stürzt nach dem Laden mit einem Segmentation Fault ab ! Dies ist ein bekannter Bug (ua. https://bugs.launchpad.net/ubuntu/+bug/345916).

Die Lösung

In diesem Artikel fand sich ein Lösungsansatz:

  1. Aus einem Terminal heraus als Systemverwalter nach /usr/share/hal/fdi/preprobe/10osvendor/ wechseln
  2. Eine Sicherheitskopie der Datei 20-libgphoto2.fdi machen
  3. Die Originaldatei in einen Editor laden und nach „TrekStor“ suchen
  4. Der Eintrag findet sich in einem Konfigurationsblock, der mit

    <match key="usb.vendor_id" int="1647">

    beginnt.
  5. Dieser Block (11 Zeilen) wird gelöscht. Dadurch wird die Zuordnung des Moduls gvfsd-gphoto2 entfernt.

Wenn man danach das Gerät wieder anschliesst, wird es korrekt als Massenspeicher erkannt. Das zeigt sich auch im Protokoll:


usb 2-1.2: new high speed USB device using ehci_hcd and address 10
usb 2-1.2: configuration #1 chosen from 1 choice
scsi15 : SCSI emulation for USB Mass Storage devices
usb 2-1.2: reset high speed USB device using ehci_hcd and address 10
scsi 15:0:0:0: Direct-Access TrekStor vibez 2 PQ: 0 ANSI: 4
sd 15:0:0:0: [sdg] 23429729 512-byte hardware sectors: (11.9 GB/11.1 GiB)
sd 15:0:0:0: [sdg] Write Protect is off
sd 15:0:0:0: [sdg] 23429729 512-byte hardware sectors: (11.9 GB/11.1 GiB)
sd 15:0:0:0: [sdg] Write Protect is off
sd 15:0:0:0: [sdg] Attached SCSI removable disk
sd 15:0:0:0: Attached scsi generic sg8 type 0

Mit dieser Änderung lassen sich wieder Dateien kopieren. Zuständig ist jetzt das usb-storage Modul, das den USB Massenspeicher als SCSI Gerät einbindet.

Tipps zur Ubuntu 9.05 Installation

Nach dem Wechsel auf Ubuntu 9.04 „Jaunty Jackalope“ als Desktop-Betriebssystem sind für einen Fedora Core- Umsteiger einige Dinge anders als gewohnt. Hier ein paar Praxis-Tipps:

Problem:

Ein am Parallelport angeschlossener Drucker funktioniert nicht

Lösung:

Wahrscheinlich sind nicht alle erforderlichen Module für die parallele Schnittstelle nicht vollständig geladen. Nach der Installation sind zwei Module aktiv (Ausgabe von lsmod):

lp 17156 0
parport 42220 3 ppdev,lp

Es fehlt das PC-spezifische Parport-Modul; das lässt sich auch aus dem Systemlog (/var/log/messages) nachvollziehen:

lp: driver loaded but no devices found

Das Nachladen des Moduls behebt das Problem:

sudo modprobe parport_pc

Im Systemlog wird gemeldet:

parport0: PC-style at 0x278 (0x678), irq 5, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]

Damit das Modul beim Boot automatisch geladen wird, ist ein Eintrag in /etc/modules erforderlich; einfach den Modulnamen in einer einzelnen Zeile eintragen.

Problem:

Beim Aktivieren des Netzwerks soll ein bestimmtes Kommando ausgeführt bzw. ein Daemon gestartet werden

Lösung:

Wenn die Netzinterfaces über das GUI-Tool „Netzverbindungen“ konfiguriert wurde, ist der beste Weg, in /etc/network/ip-up.d das passende Startscript zu hinterlegen. Die dort vorhandenen Scripts können als Muster dienen.

Problem:


Die Installation soll auf einem System mit einem On-Board RAID Controller erfolgen. Der Ubuntu-Installer sieht aber die einzelnen Platten und ignoriert anscheinend die RAID Einstellungen.

Lösung:

Die auf Mainboards im Consumer-Bereich verbauten Chips/Chipsätze bieten oft kein wirkliches Hardware-RAID. Vielmehr stellen sie Multikanal-Diskcontroller mit einer besonderen BIOS Unterstützung zur Konfiguration dar. Die Realisierung der RAID Level muss mehr oder weniger umfangreich der jeweilige Treiber (und damit die Host-CPU) zum Chip/Chipsatz übernehmen. Vielfach spricht man hier von einem „Fake RAID“.

Der auf meinem ASUS Board verbaute Intel ICH8R Chipsatz stellt ein derartiges RAID bereit. Ubuntu 9.04 erkennt bei der regulären Installation nur normale SATA Kanäle. Um dennoch eine erfolgreiche Installation unter Nutzung der RAID Funktionen hinzubekommen, muss anders vorgegangen werden:

  1. Zunächst wird das Installationsmedium als LiveCD gebootet
  2. Dann wird das Modul „dmraid“ zur Unterstützung installiert
  3. Nach einer normalen Installation ohneGrub-Einrichtung wird Grub manuell aus einem chroot-Environment installiert und das „dmraid“ Modul in die Init-RAM-Disk übernommen

Das ist das Prinzip des Vorgehens, die Details stehen im

Ubuntu Fake RAID Howto

Zu beachten ist hierbei (Abschnitt zu Ubuntu 9.04):

  • Schritt 9, Absatz l, Satz ii ist nur nötig, wenn bereits ein anderes Betriebssystem auf den Platten liegt. Auf einer frischen Neuinstallation wird das find Kommando keinen Bootloader finden.
  • Schritt 9, Absatz n ist ebenfalls obsolet, wenn kein weiteres System vorhanden ist.

Das Vorgehen ist im übrigen hervorragend beschrieben und zeigt sehr beeindruckend, welche Vorteile die Installation von einem vollständigen Live System bietet.

Problem:


Beim Booten sollen CIFS (Windows) Shares gemoutet werden, die beim Herunterfahren auch wieder unmountet werden sollen.

Lösung:

Zunächst muss das Paket smbfs installiert sein. Dann reicht für das automatische Mounten ist ein Eintrag in /etc/fstab:


//server/share /meinmountpoint smbfs credentials=/etc/geheim,auto,port=139,ip=1.2.3.4 0 0

Hierbei ist zu beachten:

  1. /etc/geheim ist eine Datei mit dem Benutzernamen und dem Passwort des Windows-Logins, über das der Share gemountet werden soll. Das steht in zwei Zeilen:

    username=windowuser
    password=seinpassword

  2. port=139 erzwingt die Benutzung des klassischen SMB Ports für die Freigabe. smbfs benutzt in der aktuellen Version erst Port 445/tcp und erst bei Misserfolg den Port 139/tcp. Wenn aber der Windows-Server nur 139/tcp kennt, entsteht dadurch eine überflüssige Verzögerung.

Eigentlich würde das auch für das Unmounten reichen, aber hier wird es schwierig:
Weil beim Shutdown erst das Netzwerk gestoppt wird und dann alle Mounts entfernt werden, hängt der Shutdown. Abhilfe schafft ein Verlinken des Scripts /etc/init.d/umountnfs.sh in die passenden SysV Initverzeichnisse:

ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K17umountnfs
ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K17umountnfs

 

Dieses Script übernimmt das Abhängen nicht nur von NFS-, sondern auch von allen anderen Netzuwerkmounts.

Linuxinstallation auf andere Maschinen übertragen

Ich stehe oft vor der Aufgabe, bestehende Linux-Installationen mit installierten Anwendungen auf andere Maschinen (Zielsystem) zu kopieren, die bestehende Maschine (Quellsystem) also sozusagen zu klonieren. Unter Linux ist das mit Bordmitteln und den jeweiligen Installationsmedien nicht schwierig.

Die nachfolgenden Pfade beziehen sich auf Red Hat / CentOS / Fedora, bei anderen Distributionen können Änderungen nötig sein

  1. Auf dem Quellsystem mittels tar ein Vollbackup erzeugen. Ich erzeuge immer eine Backup-Datei pro Verzeichnis in der Wurzel (also /). Hierbei dürfen die Verzeichnisse /proc, /sys, /boot und /mnt nicht gesichert werden, auf /tmp verzichte ich auch meistens. Am besten geht das so:tar -cvzpSlf archiv.tgz /verzeichnis

    Die so erzeugten Dateien brenne ich auf CDROM oder schiebe sie auf ein System im Netz, z.B. per FTP.
    Beachten sollte man aber:

    • Alle Anwendungen bzw. Daemons sollten beendet sein (stop über die Init-Scripts)
    • Es sollten keine Benutzer auf dem Quellsystem arbeiten.
  2. Das Zielsystem erhält mittels der Installationsmedien ersteinmal eine Minimalinstallation. Dabei verzichte ich i.d.R. auch auf eine grafische Oberfläche; meist klone ich so Applikationsserver ohne direkte Benutzer-Logins auf dem System. Die Partitionierung kann aber vom Quellsystem abweichen, auch andere Hardware-Ausstattung ist meist kein Problem.
  3. Unter /root lege ich ein Verzeichnis „orig“ an, dort hinein kopiere ich die Dateien:
    • /etc/fstab
    • /etc/mtab
    • /etc/modprobe.conf oder modules.conf
    • /etc/modprobe.d (mit cp-a)
    • /boot (als tar-Archiv)
  4. Dann entpacke ich nacheinander die Archive aus dem Backup des Quellsystems
  5. Anschliessend kopiere ich aus /ect gesicherten Dateien zurück.
  6. Hat man versehentlich doch /boot kopiert, muss man jetzt die oben erstellte Sicherung wieder entpacken
  7. Jetzt ist ein Neustart fällig, der eigentlich klappen sollte.
    Oft beschwert sich die Hardware-Erkennung (Red Hat kudzu) über veränderte Hardware, die Meldungen muss man eben abarbeiten. Sofern beim Backup des Quellsystems nicht alle Anwendungen gestoppt waren, können ebenfalls Fehlermeldungen auftreten. Bei 2.Reboot sollten diese aber nicht mehr erscheinen.

Wichtig ist: Diese Methode funktioniert nur, wenn man für die Minimalinstallation die gleiche Distribution und die gleiche Version benutzt, wie sie das Zielsystem besitzt.

Probleme kann es geben, wenn auch dem Quellsystem durch Anwendungsinstallationen Binaries oder Bibliotheken durch andere Versionen überschrieben wurden, die auf dem Zielsystem aufgrund anderer Hardware nicht „passen“. Meist klappt das Vorgehen aber ohne Probleme.

Auf diese Weise können auch Installationen in eine virtuelle Maschine umziehen.

Apple IIGS und Linux verbinden

Im Internet existieren viele Sites mit Software-Images für den Apple II. Doch wie wandern diese Images vom PC auf den Apple ? Im folgenden meine Erfahrungen: Der einfachste Weg für den Datentransfer zwischen PC und Apple ist eine serielle Verbindung. Voraussetzung ist:

  • eine serielle Schnittstelle im Applez.B. die Super Serial Card oder die eingebaute Schnittstelle im Apple II GS
  • ein passendes Kabel
    Achtung: Die nachfolgende Anleitung ist sollte richtig sein, die Nutzung geschieht aber auf eigene Gefahr. Für Schäden wird also nicht gehaftet !

Während die Super Serial Card Standard-Sub-D Buchsen benutzt, ist es beim GS schon schwieriger. Die Apple-seitige Buchse ist eine Mini-DIN 8 Buchse (MD8). Die Pins sind wie folgt nummeriert:

MD8 Buchse Aufsicht   MD8 Stecker Aufsicht
  6 7 8                    8 7 6
 3  4  5                  5  4  3
   1 2                      2 1

Folgende Signale liegen an:

  1. Handshake Out (DTR)
  2. Handshake In (DSR)
  3. Transmit Data Minus
  4. Masse
  5. Recieve Data Minus
  6. Transmit Data Plus
  7. DCD
  8. Recieve Data Plus

Ein Nullmodem Kabel mit 9 poliger Sub-D Buchse ist wie folgt verdrahtet (MD8 auf Sub-D):

3   + 2
5   + 3
4,8 + 5
2   + 7
1   + 1,6,8
7   + 4

Einen entsprechenden Stecker erhält man z.B. bei CONRAD für etwa EUR 1,- Damit lässt sich ein passendes Kabel basteln, sofern man eine ruhige Hand und einen feinen Lötkolben hat; die Pins des MD8 Steckers liegen dicht beieinander.

Mit etwas Glück erhält man bei GRAVIS ein passendes Kabel Sub-D 9 Polig auf MD8; diese Kabel sind als Modem-Kabel auch bei älteren Macintosh Modellen verwendet worden. Auch ein MD8-MD8 Kabel könnte einiges erleichtern, da man nach Durchtrennen
des Kabels nur an einer Seite eine Sub-D Buchse anlöten muss.

Übertragungssoftware

Hier liegt ein „Henne-Ei“ Problem vor: Wie bekommt man mit serieller Übertragung ein Programm für serielle Übertragung auf den Apple ? Dank der IN#x und PR#x Befehle des Apple geht das glückerlicherweise ganz einfach. Das Programm Apple Disk Transfer übertragt sich mit diesem Mechanismus sehr einfach. ADT kann dann Disk-Images von einem der Apple-FTP Server über den PC übertragen.Der Complete Guide on using ADT beschreibt dies ausführlich.

Links zum Thema

Analoge Audioquellen in MP3 umwandeln

WAV Dateien in MP3 umwandeln

Hierzu ist der Lame das Mittel der Wahl:


lame -h --scale 1 datei.wav datei.mp3

wandelt die WAV Datei in eine MP3 Datei um, dabei hohe Qualität (-h) verwenden und die Laustärke um den angegebenen Faktor erhöhen (1 bedeutet also keine Erhöhung).

UPnP Mediaserver für Linux

Wenn ein UPnP Media Server auf einem Linux-Server installiert ist und dieser mittels iptables eine lokale Firewall besitzt, wird es schwierig. Zunächst sind folgende Ports für den Zugriff durch die Streaming Clients zu öffen:

  • 1900 udp und tcp
  • UDP 1030, 1900, 9080
  • Eine breite Port-Range ab 9000/tcp (sofern diese als Startadresse konfiguriert ist), der Server inkrementiert im Betrieb seinen Port gelegentlich !

(ich benutze TwonkyMedia, vielleicht brauchen andere Server andere Adressen)

Dann muss zusätzlich zur eigentlichen IP Adresse des Servers auch die Multicast Adresse 239.255.255.250/255.0.0.0 als Serveradresse (also Zieladresse) in den Firewall-regeln eingetragen sein. Ohne den Eintrag erreichen Suchmeldungen von UPnP Clients den Server nicht und können
diesen nicht benutzen.

Gigaset M740AV DVB-T Aufzeichnungen auf DVD brennen

Für den DVB-T Empfang verwende ich eine Settop-Box von Siemens, das Gigaset M740-AV. Diese Box besitzt einen Ethernet-Port und kann auf SMB-Shares im Netzwerk direkt aufzeichnen. Die erzeugten Dateien enthalten die DVB Tranport Streams (MPEG), allerdings wird ein eigenes Format verwendet. Dies zerlegt die aufgezeichneten Sendungen in einzelne, jeweils max. 250 MB grosse Dateien.
Um daraus Video-DVD’s zu machen, sind mehrere Schritte nötig:

  1. Die einzelnen, zu einer Aufzeichnung gehörenden Dateien werden zu einem Transport Stream (TS-Format) zusammengefügt. Dazu benutze ich das Java-Programm Cridmanager unter Linux. Da meine Aufnahmen sowieso auf einem Netzwerk-Server liegen, mounte ich den entsprechenden Share auf meiner Workstation und benenne den Mountpoint als Verzeichnis im Cridmanager.
  2. Anschliessend entferne ich Vor- und Nachlauf sowie die Werbeeinblendungen
    in den Aufnahmen. Hierzu dient das Programm ProjectX Beim Schneiden zerlegt ProjectX den TS-Stream in eine Audio- und eine Video-Datei (Demultiplexing, „demux“).
  3. Vor der weiteren Bearbeitung müssen die Demux-Dateien wieder zusammengefügt werden (Multiplexing). Dazu verwende ich das Tool „mplex“ aus den MJpeg Tools.mplex -f8 -v1 -o output.mpg input.m2v input.m2a

    wobei .m2v die Video- und .m2a die Audio Datei ist, die Dateiendungen können abweichen.

    Am Ende liegt eine MPEG2-Datei (.mpg) vor, die sich bereits mit gägigen Video-Abspielern unter Linux (xine, VLC, MPlayer) abspielen lässt. Auf meinem Server habe ich einen weiteren Share eingerichtet, auf dem ich diese Dateien sammle. Dieser Share ist auf dem Gigaset M740-AV als weiterer PC angemeldet, über die Funktion „Media Locator“ kann ich die Aufnahmen der Sammlung direkt abspielen.

  4. Zur Langzeit-Archivierung besonders beliebter Aufnahmen sinnvoll, aus den Aufnahmen Video-DVD’s zu brennen. Dazu sind unter Linux einige Tools verfügbar; als Frontend bietet sich das GUI (GTK/Gnome Anwendung) DeVeDe an. Diese erzeugt ISO-Images von Video-DVDs, die ich mit K3B auf einen DVD Rohling brenne.

Tipps und Probleme

  1. Cridmanager und ProjectX brauchen das richtige Java Runtime Environment (JRE)Das unter Fedora Core 6 normalerweise installierte JRE ist nicht brauchbar für den Cridmanager. Es gibt Fehlermeldungen beim Start und die Fensterbereiche lassen sich nicht zoomen, die Baumstruktur des crid-Verzeichnisses beim Cridmanager ist nicht erkennbar, ProjectX zeigt kein Bild usw. Zur Problemlösung ist das aktuelle Java Runtime Environment (JRE) (derzeit Version 6 Update 4) von SUN zu installieren. Danach ist es allerdings noch nicht als verwendete „Default“ Umgebung aktiv, sondern muss durch den „Alternatives“ Mechanismus aktiviert werden (root-Rechte nötig):

    /usr/sbin/alternatives --install /usr/bin/java java /usr/java/j2re6u3/bin/java 2
    /usr/sbin/alternatives --config java

    (der Pfad zu bin/java kann abweichen, also prüfen !)

    Der letzte Befehl bringt ein Auswahlmen¨ zur Wahl der Java-Umgebung, hier muss die eben installierte Umgebung gewählt werden.

  2. Video-DVDs flackern/ruckeln beim Abspielen auf einem Hardware DVD Player am FernseherBewegungsunschärfen bei Video-DVDs im PAL Format sind i.d.R durch Probleme beim Interlacing (Zeilensprungverfahren) begründet. Ein normales PAL Bild mit 720 Spalten und 576 Zeilen wird zwei Halbbildern mit jeweils halber Zeilenanzahl gesendet (gerade/ungerade Zeilen). Diese müssen natürlich in der richtigen (ursprünglichen) Reihenfolge in der PAL- MPEG-Datei (interlaced) liegen. Ist diese Reihenfolge durcheinander, sind unbewegte Bildteile scharf, bewegte Teile flackern jedoch.

    Abhilfe schafft bei mir ein Deinterlacing des Videos (in DeVeDe einstellbar, FFMGPEG-Deinterlacing). Dann werden die Halbbilder zu Vollbildern synchron vereinigt.

    Ein paar Hintergründe (mein derzeitiger Wissensstand):

    • Software-Videoplayer am PC oder LCD/Plasma-Fernseher zeigen deinterlaced Videos direkt an. Werden sie mit interlaced MPEG gefüttert, wird das Bild vor der Anzeige deinterlaced- ein digitales System kennt keine Zeilsprünge, sondern nur Pixel.
    • Hardware-DVD Player erzeugen am analogen Ausgang (PAL, SCART) immer ein interlaced Bild, auch wenn sie mit deinterlaced MPEGS gefüttert werden (also Progressive Scan kennen). An einem Digital-Ausgang liegt immer ein deinterlaced Signal an (eben digital)
    • Ist ein LCD-Display per PAL Scart an einen DVD Player angeschlossen und spielt der ein deinterlaced MPEG ab, findet also erst ein Interlacing (DVD Player) und dann ein Deinterlacing (LCD) statt- die Qualität ist also entsprechend… besonders, wenn das PAL Bild auf die Pixel des Displays skaliert /interpoliert werden.
    • Auch 100Hz Röhrenfernseher machen Deinterlacing und senden dann mit 100Hz das Bild ohne Zeilensprung an die Röhre.
  3. Richtige Sampling-Raten für Video-DVDsDas Audio-Sampling sollte nicht über 192 Kbps liegen, sonst kriegen Hardware-DVD Player Probleme, eine Video-Rate von 5011 Kbps ist für die Gigaset-MPEGs ideal (Originalrate). Kauf-DVDs kennen oft eine variable Bitrate, die je nach Bildinhalt (Grossaufnahmen vs. Panoramaansichten) angepasst ist.

Scanner unter Linux

Scanner unter Linux zu verwenden ist noch immer ein reizvolles Thema:

  • Kaum ein Hersteller unterstützt Linux direkt
  • Es gibt viele verschiedene Scanner mit sehr unterschiedlichem Hardware-Aufbau
  • Informationen zur Hardware werden oft vom Hersteller geheimgehalten
  • Es existieren verschiedene Anschlussarten (USB, SCSI, Parallelport, eigene Interfaces,…)

Auf dieser Seite sind einige Hintergründe und Tipps zusammengefaßt, wie Sie trotzdem Spass mit einem Scanner unter Linux haben können.

Ansteuerung

Das Ansteuern eines Scanners unter Linux geschieht nur auf Ebene des Anschlusses durch Kernelfunktionen (also z.B. usb- Module). Die Kommunikation über diesen Anschluss geschieht durch Programme auf Anwenderebene. Mittlerweile wird fast ausschliesslich SANE verwendet. Diese Software ist modular aufgebaut und unterscheidet einen Backend-Bereich mit den eigentlichen Scanner-Treibern und einen Frontend- Bereich mit den Benutzerprogrammen zum Scannen.
SANE ist netzwerktransparent, es können also auch mehrere Rechner über das Netz auf einen Scanner zugreifen.

SANE benutzen

  • InstallationSANE ist Bestandteil jeder grossen Distribution und wird über die jeweilige Paketverwaltung installiert. Wichtig ist: Es müssen sowohl das Frontend- als auch das Backend-Paket installiert werden.
  • KonfigurationSANE stützt sich auf folgende Konfigurationsdateien (Pfadangaben für Redhat-Linux):
    1. /etc/sane.d/dll.conf: Aktive Backends (Treiber) für die jeweiligen Scanner. Auf der SANE Homepage befindet sich eine Übersicht, welcher Scanner welchen Treiber benötigt. Um gegenseitige Beeinflussungen der Treiber zu vermeiden, sollten hier alle nicht benötigten Treiber auskommentiert werden.
    2. /etc/sane.d/xyz.conf: Konfiguration für Backend xyz. Hier können je nach Backend verschiedene Optimierungseinstellungen vorgenommen werden
  • ScannererkennungMit dem Befehl sane-find-scanner gibt SANE eine Liste der erkannten Scanner aus. Ist der angeschlossene Scanner enthalten, funktioniert alles weitere. Anderenfalls ist Störungssuche gefordert:
    1. Wird der Scanner überhaupt unterstützt
      (Liste auf der SANE Homepage) ?
    2. Ist der Anschluss korrekt konfiguriert und wird der Scanner hardwareseitig erkannt ?
      • USB: cat /proc/bus/usb/devices
      • SCSI: cat /proc/scsi/scsi
      • Parallelport: Unter /proc/sys/dev/parport finden sich Angaben zu den jeweiligen ParallelportsHinweis:SANE unterstützt nur wenige Parallelport-Scanner. Die Konfiguration eines bidirektionalen Parallelports ist unter Linux u.U. schwierig, ausserdem sind manche Parallelschnittstellen in den Chipsätzen der Rechner fehlerhaft und funktionieren nicht korrekt.
  • Scanner testenEin erster Test kann direkt von der Kommandozeile mit scanimage -d plustek:/dev/usb/scanner0 –format pnm > outfile.pnm

    geschehen, wobei plustek ausgewählte Backend darstellt und /dev/usb/scanner0
    den über sane-find-scanner ermittelten Device. Hier müssen die Angaben zum jeweiligen Modell verwendet werden.

    Die erhaltene Datei outfile.pnm lässt sich mit GIMP direkt betrachten.

  • FrontendsFür alle weiteren Scan-Versuche ist ein Frontend wie xsane die richtige Wahl; es ist im Frontend-Paket zu SANE enthalten.

SANE optimieren

  • FarbbalanceWenn die erhaltenen Scans fehlerhafte Farben aufweisen, ist meist eine Optimierung der Farbbalance in der Backend-Konfiguration erforderlich. Bei umax und plustek geschieht dies über die „gain“ Werte (red-gain, green-gain, blue-gain).Hinweise stehen in den Manual-Pages zu den Backends, die mit
    man sane-xyz einzusehen sind.

Probleme und Lösungen

  • Sane meldet plötzlich nach erfolgreichem Betrieb „Cant’t find scanner“Dieser Fehler tritt gelegentlich bei USB-Scannern auf, wenn ein anderes
    Anwenderprogramm den USB Bus nach Geräten durchsucht und diese benutzen
    will. Ein Beispiel ist der Konquerer von KDE mit der URI devices:/. Meist
    hilft dann nur ein Entladen und Neuladen der usb-uhci Kernelmodule
  • Scans mit Canon Lide 20 weisen einen starken Rotstich auf
    1. Dieser Fehler tritt auch mit dem aktuellen Release von Sane auf. Ein
      Workaround ist über passende „gain“ Werte möglich.

      /etc/sane.d/plustek.conf (Ausschnitt)

      option red_gain 8

      option green_gain 41

      option blue_gain 38

    2. Der Fehler ist im aktuellen Sane Snapshot behoben. Die Farbkalibrierung
      der älteren Versionen wurde zu früh beendet, wodurch der Scanner einen Rotstich bewirkte. Dies ist auch sichtbar während des Scan-Vorgangs: Die Snapshot-Version scannt mit fast weissem Licht, die Release-Version von Sane mit rötlichem Licht.Der verwendete Snapshot (sane-backends-1.0.13-gja-090104.tgz) ist auf der Sane Plustek Backend als Quellcode zu bekommen (Stand 15.04.2004).

Links zum Thema

  • SANE
    Scanner Access Now Easy- die Softwarekollektion für die Scanner-Anbindung mit Linux
  • Sane Plustek Backend
    Ein SANE Backend für Plustek-Scanner, das auch Canon LiDE Scanner versorgt

Linux Paketverwaltung

von Georg Basse, Mai 2004

In den Frühzeiten der Linux-Geschichte wurde die Software auf Bändern oder Disketten ausgeliefert. Mit zunehmender Komplexität der Distributionen wurden deren Komponenten in Form von Paketen gebündelt, die sich einzeln und nach Vorauswahl durch den Benutzer installieren liessen. Verschiedene Ansätze für das Paketmanagement wurden im Laufe der Jahre ersonnen, fanden Verbreitung und gerieten wieder in Vergessenheit. Übriggeblieben sind einige, wenige Formate wie das Debian Paketformat , das Redhat Packet Management und auch die noch sehr urtümliche Slackware Paketverwaltung. Daneben hat Gentoo mit seinem Portage-System einige Ideen aus der *BSD Welt in das Reich des Pinguins übertragen.

Dieses Dokument beschreibt vergleichend die grundliegenden Eigenschaften der genannten Paketverwaltungen. Dies geschieht sowohl aus Anwender- und Adminstratorensicht als auch aus Sicht des Entwicklers, der Pakete selbst schnüren möchte. Aufgrund der hohen Komplexität des Themas können natürlich nicht alle Aspekte der jeweiligen Mechanismen und Tools behandelt werden. Weiterführende Literatur zu den einzelnen Werkzeugen ist am Ende des Artikels genannt.

Anforderungen heute

Eine Paketverwaltung muss eine Reihe von Anforderungen erfüllen. Aus Sicht des Adminstrators ist hier in erster Linie der Umgang mit Abhängigkeiten zwischen Paketen zu nennen. Jedes Paket muss vollständig über seine Erfordernisse an die Laufzeitumgebung Auskunft geben und ebenso vollständig die von ihm bereitgestellten Komponenten nennen. Mit diesen Informationen versorgt können dann entsprechende Softwaretools automatisch alle für die Installation eines Paketes notwendigen weiteren Pakete prüfen und wenn nötig installieren. Dies ist nicht trivial: Aus der Installation einer für ein Paket erforderlichen Bibliothek beispielsweise können sich weitere Abhängigkeiten ergeben. Auch sind Abhängigkeiten nicht immer eindeutig zu definieren; manche Komponenten werden nur unter bestimmten Voraussetzungen benötigt (sind also optional), an anderer Stelle sind nur bestimmte Funktionalitäten (wie z.B. ein SMTP Mail Transfer Programm) erforderlich, die sich auf ähnliche Weise von mehreren Programmen (z.B. sendmail, postfix, qmail) bereitstellen lassen.Eine Hauptaufgabe von Tools zur Paketverwaltung ist es, die unterschiedlichen Quellen Pakete zu verwalten. Neben Wechseldatenträgern wie CDROMs und DVDs der jeweiligen Distribution sind auch Internetressourcen und idealerweise fremde, nicht zur Distribution gehörige Datenträger als Lieferanten von Softwarepaketen heranzuziehen. Dabei will der Administrator möglichst einfach die gewünschte Software ungeachtet der unterschiedlichen Quellen finden können. Eine moderne Paketverwaltung muss auch einmal installierte Software wieder eindeutig den Ursprungspaketen zuordnen können. Für jede installierte Datei ist ein Eintrag in einer Datenbank erforderlich, die das Ursprungspaket benennt. Wie diese Datenbank realisiert ist, spielt hierbei eine untergeordnete Rolle. Neben der Erstinstallation eines Pakets ist das Update von Paketen und das Upgrade einer Distribution das Hauptarbeitsfeld des Paketmanagements. Wichtig hierbei ist ein reibungsloser Wechsel von einem Versionsstand zum nächsten unter Beibehaltung der Konfigurationen an der jeweilgen Software. Je weiter eine Software zu konfigurieren ist, desto schwieriger kann die Abbildung dieser Anforderung bei der Paketerstellung sein. Ein „bootless“ Upgrade einer gesamten Distribution ohne spürbaren Ausfall von bereitgestellten Diensten ist der Extremfall in diesem Bereich.

Neben Binärpaketen spielen Quellcodes in der Paketverwaltung ebenfalls eine wichtige Rolle, reden wir hier doch über die Verwaltung von Open Source Systemen. Das Paketmanagement muss eine klare Zuordnung von erstellten Binärdateien zum zugrunde liegenden Quellcode erlauben. Dabei müssen sich die während des Buildprozesses gemachten Konfigurationen des Quellcodes eindeutig nachvollziehen lassen. Nur dann ist es möglich, anhand des Quellcodes bei Bedarf ein neues, verändertes oder verbessertes Paket für die jeweilige Distribution zu erzeugen, das sich in den übrigen Eigenschaften genauso verhält wie das alte Paket.

In dieses Problemfeld fällt auch die Anforderung nach einem integrierten Patch-Management, obwohl hier Entwickler und Software-Maintainer eher betroffen sind als der Administrator und Anwender eines Systems. Linux Distrbutoren hauptsächlich damit beschäftigt, aus dem jedem zur Verfügung stehenden Pool an freier Software ein Produkt mit charakteristischen Eigenschaften und einem entsprechenden Branding zur erstellen. Diese Maintainance für einzelne freie Softwareprojekte fällt umso schwerer, je mehr individuelle und manuelle Arbeiten bei Versionswechsel des jeweilgen Projekts erforderlich sind. Die Integration distributions- und plattformabhängiger Patches und die Durchführung des Buildprozesses solte durch die Paketverwaltung soweit wie möglich automatisch ablaufen. Ein solches automatisches Verfahren garantiert auch eine hohe Nachvollzeihbarkeit und ist dann mehr oder weniger selbst dokumentierend. Ein weiterer Aspekt ist der Bedarf nach einer wirklich plattformübergreifenden Funktion der Paketverwaltung. Wird in anderen Betriebssystemwelten hierunter nur die Funktion einer Software mit verschiedenen Jahrgängen eines Betriebssystems auf derselben Hardware verstanden, so bietet Linux hier eine bei weitem grössere Abdeckung. Hier wollen neben 32-Bit x86 Architekturen auch die abgeleiteten 64-Bit Architekturen ebenso bedient werden wie PowerPC- und Sparc-Plattformen, IBMs zSeries und eine Fülle weiterer Plattformen mit geringer werdender Relevanz (wie HP PA Risc, Motorola 68K, Acorn Risc Prozessor). Ein Paketmanagement muss helfen, die plattformabhängigen Spezifitäten des Buildprozesses und des Patchen des Ausgangsquellcodes im Griff zu behalten.

Features im Vergleich

Um möglichst einfach einen Überblick zu Paketformaten, -managern und zur Verfügung stehenden Features zu erhalten, wurden diese in Tabelle 1 vergleichend gegenübergestellt. Diese Darstellung orientiert sich an der Alien-Homepage [5]. Um diese Gegenüberstellung verständlich zu machen, bedarf es einer Beschreibung der genannten Features:

  • Sicherheit und Authentizität:Die Installation von Softwarepaketen stellt nicht zu unterschätzende Sicherheitsanforderungen. Durch die Verwendung einer digitalen Signatur vorzugsweise auf Basis des freien GPG ist die Herkunft des Pakets aus einer bestimmten Quelle sicherzustellen. Hierzu muss der Maintainer eines Pakets ein Schlüsselpaar erstellen und seinen öffentlichen Schlüssel bereitstellen. Bei der Paketerstellung signiert der Maintainer das Paket mit seinem privaten und nur ihm zugänglichen Schlüssel. Nach dem Download eines Pakets kann der Benutzer dann mittels des öffentlichen Schlüssels die korrekte Signatur des Pakets nachweisen. Besonders bedeutsam ist dies für Mirror-Server, die Pakete einer Originalquelle (z.B. dem Stammserver einer Distribution) spiegeln. Durch die Signatur lässt sich prüfen, ob es sich auf dem Mirror wirklich um Originale des Stammservers handelt oder um möglicherweise in böswilliger Absicht manipulierte Pakete von Dritten. In der RPM-Welt ist die Verwendung von Signaturen einigen Jahren üblich, auch für Debian Pakete bürgert sich dieses Vorgehen ein. Slackware Pakete kennen diesen Mechanismus leider nicht. Prüfsummen stellen zusätzlich die Integrität von Paketen sicher. Fedora Core nutzt diese Summen, um bei CDROM Images vor einer Installation auf Wunsch einen Integritätstest der gesamten Distribution durchzuführen, wodurch sich download-bedingte Fehler ausschliessen lassen.
  • Paket-Metadaten:Innerhalb der Paket-Metadaten, also der Gesamtheit aller Verwaltungsdaten und -informationen sollten neben dem Namen und der Versionsinformation der Software auch eine Beschreibung des Paketinhalts enthalten sein. Ein Paket kann dabei neben seinem eigentlichen Paketnamen (z.B. apache) auch den Namen eines virtuellen Pakets (z.B. Webserver) tragen. Einen grossen Stellenwert nehmen wie oben angeführt die Benennung von Beziehungen unterschiedlicher echter oder virtueller Pakete untereinander ein. Abhängigkeiten auf Paket- oder Dateiebene sind hierbei ebenso zu nennen wie Konflikte, also Ausschlusskriterien für ein neues Paket aufgrund des Vorhandenseins eines anderen. Als Anforderungen (recommendations) werden in Abgrenzung dazu Paketbeziehungen verstanden, die eine Installation eines Pakets zwar nicht unmöglich machen, in den meisten Fällen aber einen Betrieb der jeweiligen Software erschweren oder verhindern. Alle diese Beziehungen können ausserdem versionsabhängig sein. Eine logische Verknüpfung von Abhängigkeiten im Sinne von „Paket A benötigt Paket B und (Paket C oder D)“ bietet in beliebiger Schachtelungstiefe derzeit nur Debian. RPM erfordert hier aufwendige Konstrukte, da hier nur reine Und-verknüpfte Listen möglich sind. Auch ist hier ebenso wie bei Slackware keine Priorisierung bekannt, für das System essentielle Pakete (z.B. binutils) können nicht von entbehrlichen Paketen (z.B. emacs) getrennt differenziert werden. Fedora Core nimmt eine solche Trennung ausserhalb von RPM im Software-Installationstool vor, Suse tut in YaST ähnliches.
  • Besondere DateienRPM bietet besondere Mechanismen für die Installation und das Löschen von Dokumentationen und Konfigurationsdateien an. Dies spiegelt sich im Verzeichnisbaum unterhalb von /usr/share/doc wieder, wo RPM einheitlich formatierte Verzeichnisnamen für die Paketdokumentationen generiert. Auch die bei Installation und Deinstallation auftretenden Dateien /etc/xyz.rpmsave und rpmnew erzeugt RPM für deklarierte Konfigurationsdateien automatisch. Von besonderer Bedeutung für die Zuordnung von Dateien zu Paketen in einem installierten System können „ghost“ Dateien wie z.B. Logfiles sein. Diese sind nicht im Paket enthalten, werden aber von der enthaltenen Software erzeugt und sind daher dem Paket zuzuordnen.
  • Paketmanager-ProgrammeBei der Installation und Deinstallation können unter Umständen aufwendige Massnahmen erforderlich sein, die weit über das einfache Kopieren und Löschen von Dateien hinausgehen. Diese Massnahmen sind hochgradig spezifisch für das jeweilige Programm und daher nicht vollautomatisch vom Paketmanagement durchzuführen. Stattdessen muss der Paket Maintainer durch vor oder nach einem Installations- oder Deinstallationsprozess ablaufende Scripts die erforderlichen Dinge erledigen lassen. Die Qualität dieser Scripts macht einen wesentlichen Anteil des Komforts im Umgang mit Softwarepaketen aus und an dieser Stelle zeigen sich die meisten Qualitätsunterschiede zwischen verschiedenen Distributionen, auch wenn sie wie bei RPM ein und dasselbe Paketformat verwenden.Neben Pre- und Postinstallations- und Deinstallationsprogrammen sind Triggerscripts [6] ein interessantes und nur bei RPM vorkommenden Feature. Durch einen Trigger ist ein installiertes Paket imstande, auf Veränderungen im Paketpool zu reagieren und z.B. bei Austausch eines Mail Transfer Agents die erforderlichen Änderungen an der eigenen Konfiguration automatisch vorzunehmen. Dieses Feature wird leider trotz seines hohen Nutzens nicht oft verwendet.

RPM

Das RPM Paket stellt neben einer Reihe weiterer Tools mit dem Programm /bin/rpm das wichtigste Programm für das Paketmanagement bereit. Es dient zum Installieren, Löschen und Aktualisieren von Paketen und verfügt über viele Funktionen zum Anzeigen von Paketeigenschaften. Die Manual-Seite zu „rpm“ (man rpm) ist ausgesprochen ausführlich und sollte die Benutzung hinreichend erklären. Daher sollen hier nur anhand einiger, auf die Vergleichstabelle bezogene Tips im Umgang mit „rpm“ beschrieben werden.Zur Arbeit mit digitalen Signaturen stellt „rpm“ einige Kommandos bereit. Neue öffentliche Schlüssel lassen sich mit rpm –import key.txt aus einer ASCII Datei (hier key.txt) einspielen. Bei Installation oder Update eines Pakets prüft „rpm“ dann die Paketsignatur mit diesem öffentlichen Schlüssel und warnt gegebenenfalls. rpm -K paket.rpm prüft ein Paket (hier paket.rpm) hinsichtlich seiner Signatur und gibt den Schlüsseltyp aus. Eine Übersicht über die installierten Schlüssel liefert der Aufruf rpm -qi gpg-pubkey.

Eine weitere wichtige Eigenschaft der RPM Pakete ist das Vorhandensein einer Prüfsumme, über die sich die Integrität des Pakets nachweisen läßt. Dies funktioniert auch mit Dateien aus installierten Paketen. Der Befehl rpm -Va listet alle Dateien, die sich seit der Installation der vorhandenen Pakete verändert haben. Einerseits kann diese Funktion zum Erstellen eines in Bezug auf die Installations-CDs einer Distribution inkementellen Backups herangezogen werden. Andererseits bietet sich so eine Kontrollmöglichkeit, ob Binärdateien einer Änderung unterzogen wurden. Solche Änderungen sind zunächst einmal verdächtig und können Hinweise auf unerwünschte Benutzeraktivitäten oder sogar auf ungebetete Gäste auf dem System liefern, da u.U. Originaldateien durch kompromittierte Kopien ausgetauscht wurden.

Mit der Option -q werden bei „rpm“ alle Abfragen von Paketdaten und RPM Datenbankinformationen eingeleitet. Viele Paket-Metadaten lassen sich mit dem Aufruf rpm -qip paket.rpm für nicht installierte Pakete bzw. mit rpm -qi paketname für installierte anzeigen. Eine Liste der installierten Pakete liefert rpm -qa, wobei der Aufruf in der Form rpm -qa -last | less diese Liste nach Installationszeitpunkt sortiert auflistet. Eine Liste der Abhängigkeiten eines Pakets zeigt das Kommando rpm -qpR paket.rpm bzw. rpm -qR paketname (s.o) an. Weitere oft benötigte Optionen sind rpm -qpl paket.rpm für die Anzeige der Dateien innerhalb eines Pakets und rpm -qf dateiname, um die Zugehörigkeit einer Datei zu einem Paket zu ermitteln.

Bei Updates eines Pakets kann es sinnvoll sein, den ursprünglichen Versionsstand inklusive der durchgeführten Konfigurationen zu sichern, um bei Problemen eine „fall back“ Möglichkeit zu haben. Dafür stellt „rpm“ die Option –repackage zur Verfügung. Mit rpm -U –repackage paket.rpm wird ein Update des Pakets durchgeführt, die alte Version landet als RPM-Paket unter /var/spool/repackage/altpaket.rpm. Für ein „fall back“ genügt dann ein rpm -U –oldpackage altpaket.rpm. Dies kann auch als elegante Möglichkeit dienen, um Pakete mit komplexen Konfigurationen sicher von einer Maschine auf eine andere zu transportieren.

APT

EntwicklungMit Debian 0.93 erschien das bis heute eingesetzte .deb Paketformat und der Paketmanager „dpkg“ auf der Bildfläche. Seine weitreichenden Fähigkeiten besonders im Bereich der Behandlung von Abhängigkeiten zwischen einzelnen Paketen wurden aus dem Anspruch des Debian-Projekts heraus geschaffen, ein integriertes und stabiles Gesamtsystem zu schaffen. Für dpkg existieren mit dselect und apt-get verschiedene Frontends.

Das ursprünglich für Debian entwickelt stellt das „advanced packaging tool“ APT ein universelles Frontend für die Paketmanager dpkg und RPM dar. Die RPM Portierung stammt vom Linux-Distributor Connectiva, steht aber für alle RPM basierten Distributionen bereit [1]. Das APT Paket besteht aus einer Sammlung von Tools, von denen apt-get das am meisten verwendete Programm sein dürfte. Es erledigt die Installation neuer Pakete, das Update vorhandener Pakete und bei Bedarf auch das Upgrade einer Linux-Installation in seiner Gesamtheit.

Damit dies funktioniert, benötigt apt-get die Metadaten aller bereitstehender Pakete in einer lokalen Caching-Datenbank, der Paket-Cache unter /var/cache/apt/pkgcache.bin. Diese lokale Datenbank wird anhand der zur Verfügung stehenden Paketquellen gefüllt. Hierbei kann es sich um Wechseldatenträger oder Netzwerkressourcen handeln. Benannt werden diese Quellen in der Datei /etc/apt/sources.list, die sich manuell oder (im Falle von CDROMs und DVDs) mit dem Befehl apt-cdrom pflegen lässt. Der Befehl apt-get update aktualisiert und ergänzt die Cache anhand dieser Quellinformationen. Jede Datenquelle muss die Metadaten der durch sie bereitgestellten Pakete in einem Verzeichnis apt/ bereitstellen. Bei Online-Repositories egal ob für Debian oder RPM Distributionen [3] ist dies Aufgabe des jeweiligen Betreibers, bei CDROMs muss dies bei der Erstellung des Master-Images vorgenommen werden. Das Debian-Projekt übernimmt dies bei seiner Distribution, bei RPM-basierten Distributionen wie Fedora Core oder Suse Linux ist dies nicht der Fall. Sollen auch die Installations-CDs einer solchen Distribution durch APT verwaltet werden, steht ein Remastering an. Für RedHat Linux und Fedora Core 1 ist unter [2] eine passende Anleitung zu finden.

Der Mühen Lohn liegt in einer sehr bequemen Art der Paketverwaltung, wie das Beispiel in Listing #1 zeigt. Das zusätzlich erforderliche Paket Neon wurde automatisch identifiziert, in einem der konfigurierten Repositories lokalisiert und nach dem Herunterladen installiert. Soll das Paket entfernt werden, genügt ein apt-get remove cadaver. Allerdings verbleibt das als Abhängigkeit installierte Paket Neon in diesem Fall im System- APT kann schliesslich nicht „wissen“, ob der Administrator diese Software nicht doch noch benötigt und tut hier lieber nichts als zuviel des Guten.

Wie aus dem Beispiel zu erkennen ist, prüft APT vorhandene GPG-Signaturen von RPM Paketen und versucht so, die Authentizität der Software sicherzustellen. Dieses Feature wird durch den Schalter GPG-Check „true“; im Block RPM {}; der Datei /etc/apt/apt.conf kontrolliert und sollte immer aktiv sein. Ein Einschleusen von maligner Software in ein Linux-System kann bei heutiger Sicherheitslage am leichtesten über kompromittierte Server und Repositories geschehen. Das Signieren von Paketen, wie es RPM seit längerem und Debian dpkg seit dem Release 3 (Woody) kennt, bietet hier einen recht zuverlässigen Schutz vor Manipulationen. Anhand der Signatur eines Pakets und dem öffentlichen Schlüssel der Quelle (Repository), von der das Paket zu stammen vorgibt, kann die Herkunft desselben geprüft werden. Dies setzt natürlich voraus, daß die öffentliche Schlüssel der konfigurierten Repositories auch dem lokalen APT bekannt sind. Bei einem RPM System muss dazu der öffentliche Schlüssel vom jeweiligen Server heruntergeladen und mit rpm –import schlüsseldateiname im RPM System bekanntgemacht werden. Ohne diese Vorbereitung lädt apt-get zwar die angeforderten Pakete herunter, verweigert aber die Installation.

Wem auch dieser Umgang mit APT noch zu unbequem ist und lieber mit einem grafischen Frontend arbeiten möchte, findet in Synaptic [4] das richtige Werkzeug. Ein einmaliges apt-get install synaptic lädt und installiert das Programm, das sich bei KDE 3.2 und Fedora Core 2 unter „Systemeinstellungen, Weitere Systemeinstellungen, Synaptic Paketverwaltung“ wiederfindet. Unter einer übersichtlichen Oberfläche finden sich dort die Namen und Beschreibungen der zur Verfügung stehenden Pakete (Abbildung #1). Synaptic steht für Debian und RPM Distributionen (RedHat Linux, Fedora Core, Suse) bereit. Ein zumindest von der Oberfläche her homogenes Paketmanagement ist bei diesem „Mainstream“ Distributionen also möglich.

yum

Neben APT ist Yum das derzeit am meisten diskutierte Frontend zu RPM. Es basiert auf dem Programm YUP („Yellowdog Updater“) der Linux RPM-Distribution Yellowdog für PowerPC. Die Entwicklung von Yum („yellowdog updater modified“) begann an der Duke University in Durham (USA) durch Seth Vidal, einem der dortigen Systemadminstratoren. Ursprünglich als Motivation zum Erlernen der Scriptsprache Phyton gedacht, entwickelte sich Yum zu einem mittlerweile recht verbreiteten Tool für die Paketverwaltung bei RPM-basierten Distributionen. Vor allem Fedora Core setzt neuerdings auf diese Entwicklung und will das Redhat-eigene „up2date“ früher oder später durch Yum ablösen.Ähnlich wie APT stützt sich Yum auf Online-Repositories als Quelle von RPM-Paketen. Als Informationsbasis nutzt es die Header der RPM Pakete, die auf dem Repository im Verzeichnis headers/ als Dateien mit dem Namen paket.hdr liegen müssen. Die Datei header.info im gleichen Verzeichnis enthält zusätzlich eine Liste aller Pakete und Pfade zu diesen im Repository. Der Erstellung eines Yum-Repositories dient das Programm „yum-arch“. Im Gegensatz zu APT, das als Paket-unabhängiges Tool ein eigenes Format für die Speicherung dieser Paketinformationen benutzt beschränkt sich Yum auf den Umgang mit RPM Paketen und kommt so mit einer deutlich kompakteren Datenbasis aus.

Für den Zugriff auf die Repositories und die Installation von Paketen ist das Programm „yum“ vorgesehen. Es nutzt dafür die Protokolle HTTP oder FTP und stützt sich auf die zentrale Konfigurationsdatei /etc/yum.conf. Diese definiert neben zahlreichen Rahmenparametern auch die verfügbaren Yum-Server. Ein Blick auf die Homepage des Projekts [9] ist schon wegen der Liste der verfügbaren Repository-Server lohnend. Auch auf den Seiten von Freshrpms [10] finden sich lohnende Hinweise.

Beim ersten Aufruf von „yum“ lädt es die RPM Header von den Servern und speichert diese lokal in /var/cache/yum. Dieser Vorgang kann ohne weitere Folgen für das System mit dem Kommando yum list updates erzwungen werden; allerdings sind wegen der Rechtevergabe für das Caching-Verzeichnis hier Rootrechte erforderlich. Als Ausgabe des Kommandos erscheint eine Liste von aktualisierbaren Paketen im System. Ähnlich dem bereits beschriebenen „apt-get“ genügt dann der Aufruf von yum install paket.rpm für den Download, die Auflösung von Abhängigkeiten und die Installation eines neuen Pakets. Die Manpage zu „yum“ und die Homepage des Projekts [9] erläutert die zur Verfügung stehenden Optionen in kompakter Form, weshalb auf eine Wiederholung hier verzichtet wird.

Neben serverlokalisierten Repositories kann „yum“ durchaus auch lokale Verzeichnisse als Paketquellen benutzen. Hierzu genügt es, im Basisverzeichnis der Sammlung von RPM Paketen mit dem Kommando yum-arch . (bzw. yum-arch pfadname) den Extraktionsvorgang für die RPM Header zu starten. Die Header finden sich dann wie erwähnt im Verzeichnis headers/ wieder. In /etc/yum.conf kann dann dieses Verzeichnis wie in Listing 1 gezeigt eingebunden werden. Ebenso einfach ist es auch, dieses Repository netzwerkweit bereitzustellen. Das Verzeichnis muss lediglich z.B. durch einen passenden Eintrag in der Apache-Konfiguration als Dokumentenquelle für den Webserver bekanntgemacht werden. Das funktioniert auf einem Server im lokalen Netz genauso wie auf angemietetem Webspace- für eigene Entwicklungen ein eleganter Weg der Publikation.

Mandrake URPM

URPM ist ähnlich wie der Yellow Dog Updater ein distributionsspezifisches Tool, das bisher nur unter Linux Mandrake zum Einsatz kommt. Es setzt ausschliesslich auf RPM auf und dient im wesentlichen zum automatischen Auflösen von Abhängigkeiten zwischen Paketen. Dazu verwendet URPM eine lokale Liste mit Headerinformationen der RPM Pakete, die von der jeweiligen Paketlokation (Datenträger, Serversysteme, lokale Verzeichnisse), im URPM-Jargon Sources genannt bereitgestellt werden muss. In der Regel liegt diese Liste als komprimierte Datei Mandrake/RPMS/synthesis.hdlist.cz auf einer CDROM oder einem FTP Server. Für die zum Zeitpunkt der Drucklegung aktuelle Mandrake-Version 10.0 ist diese Datei nur 263 kBytes gross.Das URPM Paket besteht aus einer Reihe von Kommandozeilen-Programmen, die jeweils einem bestimmten Zweck bei der Paketverwaltung dienen. Zur Installation neuer Pakete dient das Programm „urpmi“. Der Aufruf urpmi paket.rpm ermittelt zunächst, ob das gewünschte Paket in den angemeldeten Sources verfügbar ist. Ist dies der Fall, werden die Abhängigkeiten des Pakets aufgelöst, die benötigten Pakete beschafft und installiert. Verwendet man hier nicht die Option –auto beim Aufruf von „urpmi“, fragt das Tool beim Administrator nach, ob wirklich die ermittelten Pakte installiert werden sollen. Je nach Paketquelle fordert das Tool benötigte CDROMs an oder listet mögliche Alternativen (z.B. mehrere Server) für Installationsquellen auf.

Auf ähnliche Weise kann auch das Update aller installierten Pakete geschehen; urpmi –auto-select –auto –update sucht alle aktualisieren Versionen der installierten Pakete von den Sources zusammen und installiert diese ohne Nachfrage. Diese Funktion ermöglicht auch das Upgrade der gesamten Distribution. Allerdings sind hier vorher die Sources auf die Quellen der neuen Distribution einzustellen. Unter [8] findet sich eine kurze Anleitung, wie der Distributionsupgrade am besten zu bewerkstelligen ist.

Der Befehl „urpmi.addmedia“ aus dem URPM Paket fügt Paketlokationen zur lokalen „sources“ Liste hinzu und liest die Headerliste aus dieser Quelle ein. Der Befehl urpmi.addmedia gwdg ftp://ftp.gwdg.de/pub/linux/mandrake/10.0/i586/Mandrake/RPMS with . fügt der Quellliste den FTP Server der GWDG hinzu und benennt das RPM Verzeichnis auf diesem Server als Quelle für die Datei synthesis.hdlist.cz. CDROMs oder lokale Verzeichnisse mit RPM Paketen sind in ähnlicher Weise in die Paketverwaltung zu integrieren. Auserdem ist es sinnvoll, mit dem Befehl urpmi.update gwdg die Paketliste des og. Servers regelmässig zu aktualisieren, um bei Änderungen auf den neusten Stand zu kommen. Für CDROMs und DVDs ist dies natürlich nicht erforderlich.

Alle Daten aus hinzugefügten Sources sind unterhalb des Verzeichnisse /var/lib/urpmi abgelegt. In den mit „list“ beginnenden Dateien sind die Lokationen der Sources gespeichert, „synthesis“ Dateien enthalten die Headerinformationen usw. Ein manueller Eingriff ist hier nicht erforderlich, da URPM für alle Manipulationen entsprechende Befehle bereitstellt. Einzig im Fehlerfall kann es nötig werden, in diesem Verzeichnis zu arbeiten. Es lohnt sich eher, regelmässig den Inhalt des Verzeichnisses /var/cache/urpmi zu prüfen. Hier landen nämlich alle von Servern heruntergeladene Pakete. Gerade bei grossen Dateien kann sich die Sicherung dieser auf eine CDR lohnen, um ggf. nicht erneut einen bandbreitenhungrigen Download zu starten.

Novell Suse YaST

YaST („Yet another setup tool“) ist seit 1994 das Administrationstool von Suse Linux, das damals noch statt einer Versionsnummer das Erscheinungsdatum auf dem CD-Cover trug und von der S.u.S.E GmbH in Fürth bereitgestellt wurde. Im Gegensatz zu den bisher vorgestellten Tools ist das aktuelle YaST2 heute mehr eine Middleware zur Linux Systemadminstration als ein Paketmanagementtool. Es gräbt sich mittels verschachtelter Startscripts und Konfigurationsdateien tief in den Bootmechanismus und die Konfiguration von Daemons ein und erhebt den Anspruch, durch GUI-Elemente die Linuxadminstration besonders anfängerfreundlich zu gestalten. Ob dies dem Tool gelingt, ist immer wieder Gegenstand hitziger Diskussionen in der Linux-Szene. Hier sollen diese Streitereien nicht interessieren, vielmehr sei der Wert von YaST2 bei der Paketverwaltung hinterfragt.In jedem Fall bemerkenswert ist die Tatsache, daß ein automatisches Auflösen von Abhängigkeiten zwischen Paketen bei YaST2 und Suse Linux schon von je her und sogar vor Einführung von RPM als Paketformat zum guten Ton gehörte. Anfangs beschränkte sich diese Fähigkeit auf den Umgang mit Paketen der distributionseigenen Datenträger. Heute vermag YaST2 auch Internetressourcen, eigene CDROMs und Verzeichnisse zu integrieren.

Webmin

Webmin ist ein beliebtes, webbasiertes Tool zur Administration nicht nur für Linux, sondern für nahezu alle unixoiden Systeme, MacOS X eingeschlossen. Neben vielen anderen hilfreichen Modulen verfügt es auch über Funktionen für das Paketmanagement. Eigentlich ist dieses Modul eher spartanisch ausgestattet. Es bietet gerade einmal die Basisfunktionen für die Installation und das Upgrade von Paketen.Dennoch hat es seinen Reiz, denn es stellt hier für den Reigen der Paketformate der UNIX Welt eine einheitliche Oberfläche bereit. Free- und OpenBSD- Pakete, System-V Pakete, HP-UX Softwaredepots, Debian-, Redhat- und Slackwarepakete können mit einer konsistenten Oberfläche installiert werden. In einer Baumansicht sind alle installierten Pakete inklusive ihrer Paketbeschreibungen einsehbar. Die Installation neuer Pakete kann entweder von einer Datei auf der jeweiligen Maschine oder von einem FTP-oder HTTP Server ausgehen. Auch der Upload einer Datei per HTTP ist möglich. Spezielle Optionen einzelner Paketformate sind dabei in der Regel leider nicht zugänglich, hier verlangt die Universalität einige Abstriche. Je nach verwendetem Paketmanager stellt Webmin einige Zusatzfunktionen bereit, so ist z.B. der Zugriff auf APT Repositories und die Durchführung eines Systemupgrades mit apt-get möglich.

Links zum Thema

  • APT Paketverwaltung
    Eigentlich für Debian entwickeltes Frontend für Paketmanager
  • Paketformate Vergleichstabellle
    Eine Vergleichstabelle mit Eigenschaften von Paketmanagern
  • APT Red Hat CDROMs
    Anleitung, um Red Hat CDROMs durch APT verwaltbar zu machen
  • Synaptic GUI Frontend zu apt
    GUI für apt, egal ob mit rpm oder deb im Hintergrund
  • URPMI Howto
    Ein Howto für das User RPM Interface
  • YUM Homepage
    YellowDog Updater Modified ist ein weiteres rpm-Metafrontend