Zugschlusbeobachtungen - Debian-Packages

help needed for ATM support in ifupdown-scripts-zg2

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 16 Apr 2009 22:49:28 +0200

I haven’t been using ATM on Linux for some six years now. I neither have access to an ATM network any more nor do I have ATM hardware any more. Therefore, I plan to remove ATM support from ifupdown-scripts-zg2 in the next release which will be done in the next few weeks.

If anybody does still use ATM on Linux in conjunction with my scripts, you might want to offer help with the package if you want to have continued ATM support in ifdown-scripts-zg2. I cannot test the code any more and therefore cannot maintain it in the future.

DPotW: swaks

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 06 Mar 2007 13:20:00 +0100

Description: SMTP command-line test tool
 swaks (Swiss Army Knife SMTP) is a command-line tool written in Perl
 for testing SMTP setups; it supports STARTTLS and SMTP AUTH (PLAIN,
 LOGIN, CRAM-MD5, SPA, and DIGEST-MD5). swaks allows to stop the SMTP
 dialog at any stage, e.g to check RCPT TO: without actually sending a
 mail.
 .
 If you are spending too much time iterating “telnet foo.example 25”
 swaks is for you.

A very important tool which makes debugging e-mail a breeze. A must for every mail admin.

listadmin

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 11 Feb 2006 11:04:03 +0100

Die Kategorie “Debian-Package of the Week” habe ich umbenannt in “Ausgesuchte Debian-Packages”, weil ich den angestrebten wöchentlichen Rhythmus drastisch verfehle.

Heute empfehle ich listadmin.

Wer sich um Mailinglisten kümmert, die mit mailman

bedient werden, weiß, was es für eine Sysiphus-Arbeit es ist, sich um die Mails zu kümmern, die in der Moderatorenqueue auflaufen. Bei Listen, die es schon etwas länger gibt, ist das hauptsächlich Spam, und mit vertretbarem Aufwand ist das nicht zu managen.

listadmin bringt das Management der Mailqueue auf die Kommandozeile. Man hinterlegt in einer ~/.listadmin.ini die Information über und die Zugangsdaten zu den Listen. So konfiguriert zum Beispiel

adminurl http://mailman.{domain}/cgi-bin/mailman/admindb/{list}

username mh+straba-selbst-fahren@zugschlus.de
password <snip>
straba-selbst-fahren@lists.zugschlus.de

username mh+bofh-users@zugschlus.de
password <snip>
bofh-users@lists.bofh.de

zwei Listen auf unterschiedlichen Hosts in listadmins Verantwortung. Dann reicht ein Aufruf von listadmin aus der Shell, und listadmin holt

Den Inhalt der Moderatorenqueue aus dem Webinterface
Fragt Dich für jede Mail in der Queue, was es damit machen soll (Accept, Drop, View Body, View Headers, und noch ein paar Optionen) und
führt schließlich Deine Kommandos aus

und das für alle Listen mit einem einzigen Aufruf. Zusätzlich kann man Defaults vorgeben und den Spamassassin-Score mit in die Bewertung aufnehmen, so dass man z.B. alle Mails mit einem Score über 10 automatisch droppen kann, oder auch einfach nur aus dem cron alle nicht approvten Mails regelmäßg aus der Queue kicken kann.

Das ganze ist natürlich mit geparsten Webseiten und “getürkten” POST-Requests ein übler Hack, der bei jedem Mailman-Update königlich auf die Nase fallen kann, wenn sich das Webinterface ändert, aber es hilft, den Moderatorenaufwand auf ein paar Sekunden pro Tag und Liste zu drücken was früher echt lästig war.

Schön wäre es natürlich, wenn Mailman (endlich) ein brauchbares maschinenkompatibles Interface bieten würde, aber so lange Mailman das noch nicht selbst kann, ist listadmin eine große HIlfe.

DPotW: grub

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 19 Jun 2005 23:59:00 +0200

grub ist ein Bootmanager für Linux und andere Betriebssysteme mit durchaus bemerkenswerten Features

Bootmanager haben ein unauffälliges Leben. Man nimmt sie normalerweise nur dann wahr, wenn irgendwas schief läuft. Für Linux auf x86-Systemen gibt es zwei, die Linux direkt booten können und die nennenswerte Verbreitung erlangt haben: grub und das ältere lilo. lilo habe ich immer gehaßt - und wenn es auch nur deswegen war, dass ich ständig vergessen habe, nach einem Kernelupdate lilo aufzurufen und deswegen das System nicht mehr startfähig war.

Grub macht das alles viel besser. Grub kann interaktiv sein, hat eine Kommandozeile, und kann Dateisysteme verstehen. Das bedeutet, dass der Blocklisten-Hack bei Grub nur noch zum Tragen kommt, damit er seinen eigenen Code finden und nachladen kann: Der schliesslich zu ladende Kernel kommt schon aus dem Dateisystem, und somit braucht man den Bootmanager nicht mehr anzufassen, wenn man den Kernel getauscht hat. Für Hirnartisten ist das sehr praktisch: Ein Schritt, den man weniger falsch machen kann.

Von einem entfernbaren Medium wie einer Diskette gestartet, wirft grub einen auf eine Kommandozeile, auf der man die wichtigsten Dinge direkt erledigen kann: Man kann grub auf einer Festplatte lauffähig installieren, oder ein Betriebssystem booten. Sehr praktisch. Von einer Festplatte gebootet, liest grub eine Datei mit Kommandos, die z.B. ein Menü verschiedener Optionen aufbauen und präsentieren kann. Per Leuchtbalken kann man dann auswählen, was man booten möchte.

Selbstverständlich kann man auch hier eingreifen, und den konkreten Bootvorgang auf Wunsch sehr komfortabel durch Bearbeiten der in der Menüdatei hinterlegten Kommandos customizen. Besonders in Paniksituationen ist man damit sehr flexibel; dieses Feature hat mir schon mehr als einmal den Arsch gerettet.

Die Debian-Package von grub geht noch einen Schritt weiter: Über Hooks in den Kernel-Paketen wird bei der Installation eines kernel-image.deb sofort ein zum Kernel passender Eintrag im grub-Menü erzeugt, so dass man auch mehr als nur zwei Kernels booten kann.

Grub kann natürlich auch andere Betriebssysteme starten, muss bei den Systemen aus Redmond mangels Standardkonformität dieser Systeme allerdings den Umweg über den eigenen Bootloader der Redmondware gehen.

Unterstützung für serielle Konsole ist natürlich vorhanden und sehr komfortabel: Beim Booten wird zuerst parallel auf “richtiger” und serieller Konsole ein Tastendruck (mit Timeout, versteht sich) erwartet, und dort wo die erste Bedienhandlung erfolgt wird dann auch das grub-Menü gezeigt.

stow - Packagemanagement für Arme

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 12 Jun 2005 23:59:00 +0200

GNU stow erlaubt die Installation von Software, die nicht aus einer “richtigen” Package kommt, ohne die unsäglichen Schmerzen, die bei der Installation direkt nach /usr/local entstehen.

Auf Systemen, die dem FHS gehorchen, landet aus Distributionspackages installierte Software üblicherweise in /usr. Lokal gebaute Software wird nach /usr/local installiert. Dabei entsteht innerhalb /usr/local leicht das Problem, dass man die Übersicht darüber verliert, welche Datei zu welcher Package gehört. Das Ergebnis ist ein schwer wartbares System, das einen Update-Albtraum darstellt.

GNU stow versucht dieses Problem dadurch zu lösen, dass jede lokal gebaute Software in einen eigenen Tree unterhalb von /usr/local/stow/[packagename] installiert wird. Das Programm stow legt dann Symlinks nach /usr/local an, damit die Files in den “normalen” Pfaden gefunden werden können.

Über die Symlinks ist einfache Identifikation des Softwarepakets möglich, das für eine Datei “verantwortlich” ist. Ebenso einfach ist die Deinstallation der Symlinks, so dass man eine Software rückstandslos entsorgen kann. Insbesondere der Wechsel zwischen Versionen ist somit ohne Aufwand möglich, da einzelne Versionen unter /usr/local/stow/[packagename] installiert bleiben können, auch wenn sie gerade nicht nach /usr/local verlinked sind.

Am besten geeignet für die Installation in einem stow-Directory sind Packages, die sich für die Ausführung aus anderen Verzeichnissen kompilieren lassen als die, in die installiert wird. Packages, die autoconf/automake verwenden, erfüllen diese Anforderung im allgemeinen.


./configure --prefix /usr/local
make
make install prefix=/usr/local/stow/[packagename]
cd /usr/local/stow
stow [packagename]

Packages, deren Makefile keinen Prefix unterstützt, sollte man für die Ausführung aus /usr/local/stow/[packagename] übersetzen. Das ist zwar nicht schön, erfüllt aber in aller Regel ebenfalls den Zweck. make install sollte man mit einem Account ausführen, der nur in /usr/local/stow, nicht aber in den anderen Verzeichnissen unterhalb von /usr/local schreiben darf - oder man prüft vor der “richtigen” Installation mit make -n install, ob der Installationscode auch das beabsichtigte tut.

GNU stow eignet sich insbesondere für die “quick-and-dirty” Installation von Software, für die es sich nicht lohnt, eine “richtige” Package zu schnüren.

In /usr/local/stow/[packagename] installierte Packages kann man durch tar recht einfach von einer Maschine auf eine
andere verschieben, wenn man sich der fehlenden Features:

Kein Dependency-Handling
kein conffile-Handling
keine Maintainer-Scripts

bewusst ist.

DPotW: dpatch

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 07 Jun 2005 16:51:00 +0200

Dpatch ist ein Tool, das einem Debian-Maintainer die Arbeit kolossal einfach macht.

Patchsets können zusammen gehörend verwaltet werden
Die Upstream-Sourcen bleiben unverändert, auch wenn sie verändert werden
Man braucht nur noch debian/ in einem Versionskontrollsystem haben
Die Anwendung von Patches kann zur Bauzeit kontrolliert werden

Beim Bau von debian-Packages ist das Unterverzeichnis debian/ die Domäne des Maintainers. Manchmal aber muss er auch ausserhalb des Verzeichnisses Änderungen vornehmen. Klassisch tut er dies direkt, und die Änderungen landen dann auch direkt im Debian-.diff.gz. Funktioniert, und verletzt nicht das Prinzip der “Pristine Sources”, da das .tar.gz des Upstreams unangetastet bleibt.

Wenn man aber nun - z.B. bei einem besonders unkooperativen Upstream - viele Änderungen an der Software vornehmen muss, wird das Verfahren schnell unübersichtlich. Man wird also die gesamte Package in ein Versionskontrollsystem einchecken, und hat dann nur noch bei Upstream-Updates ungefähr unendliche Schmerzen. Jedenfalls, wenn man mit CVS nur über eine lange Geschichte der Abneigung verbunden ist und beim mergen von Changes immer nur Zerstörung erzeugt. Auch ist es bei diesem Ansatz schwer, zusammengehörige Änderungen auch zusammen zu verwalten, und für Änderungen, die nur unter gewissen Umständen (z.B. auf gewissen Architekturen) notwendig sind, scriptet man sich einen Wolf.

Dpatch löst einige dieser Probleme. Dpatch ist ein System, das es möglich macht, beim Packagebau automatisch Patches auf die Package anzuwenden. Die Patches liegen dabei im Verzeichnis debian/patches. Über eine Steuerdatei kann ausgewählt werden, welcher Patch angewendet werden soll, und die die Patches selbst ein Shellscript enthalten, kann auch der Patch selbst entscheiden, ob er angewendet werden will oder nicht.

Dadurch, dass die Patches innerhalb des debian/-Verzeichnisses liegen, reicht es völlig aus, dieses Verzeichnis unter eigener Versionskontrolle zu haben, was Upstream-Updates drastisch erleichtert. Man muss zwar immer noch aufpassen, dass die eigenen Patches auch auf die neue Upstream-Version anwendbar sind, der ganze Prozess ist aber um Längen übersichtlicher. Geeignete Build-Scripts (svn-buildpackage kann das zum Beispiel) können das Upstream .tar.gz automatisch auspacken, so dass man auch diese Arbeit nicht manuell tun muss.

Auch die Erstellung und Pflege der Patches wird durch dpatch erleichtert. dpatch-edit-patch macht Dir eine Arbeitskopie des aktuellen Verzeichnisses und gibt Dir eine Shell innerhalb dieser Arbeitskopie. Nachdem Du Deine Änderungen gemacht hast und diese Shell beendest, werden die von Dir an der Arbeitskopie durchgeführten Änderungen zu einem Patch zusammengeschnürt und an die richtige Stelle ins debian/-Verzeichnis geworfen. Auch hier kann optional ein Upstream-.tar.gz ausgepackt werden. Feine Sache das, die obendrein auch noch dafür sorgt, dass thematisch zusammengehörige Änderungen zusammen in einem Patchfile landen, das man dann auch benutzen kann, um die Änderung an den Upstream weiterzureichen.

Dieser Artikel ist nicht so ganz uneigennützig: Ich bin Member des Dpatch Maintainer Teams, und eine neue, erheblich erweiterte Version von Dpatch ist ab heute abend in Debian unstable. Please test!

DPotW: cdbs

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 29 May 2005 17:00:00 +0200

Eine durchaus umstrittene Debian-Package ist cdbs, das Common Debian Build System, was die Erstellung von Packages deutlich erleichtert.

Wenn man sich die Debian-Policy genauer anguckt, sieht man, wie hoch die Anforderungen an das main package building script,debian/rules, sind. Selbst das debian/rules aus hello-debhelper ist über 50 Zeilen lang. Das ist nicht nur bei der Erstellung viel Arbeit, sondern sorgt bei Änderungen an der Debian-Policy für graue Haare, weil man als Maintainer die Änderungen manuell in jeder Package nachziehen muss.

cdbs erleichtert dies erheblich. Die Package enthält eine Sammlung von make-Include-Files, die für “normale” Packages die debian/rules-Datei zusammenschnurren lassen.

Für eine Package, die sich straghtforward mit dem üblichen “Dreikampf” configure; make; make installdebian/rules mit cdbs nur noch aus drei Zeilen:


#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/autotools.mk

Der Vorteil an der Geschichte ist, dass bei Policy-Änderungen keine lokale Arbeit notwendig ist. Der Nachteil an der Geschichte ist, dass man nicht mehr so detailliert eingreifen kann, wie man es manchmal will. Man kann zwar an vielen Stellen mit Variablen in den Bau der Package eingreifen, aber was die cdbs-Macher nicht vorgesehen haben, geht auch nicht. Somit ist cdbs sicher nicht das Tool der Wahl für komplexe Packages wie exim4, aber so simple Dinge wie rageircd, apg oder ser2net lassen sich mit cdbs einfachst bauen.

Einen typischen Debian-Nachteil hat cdbs ebenfalls: Es ist verhältnismäßig zurückhaltend dokumentiert. Ohne Beispielcode ist man aufgeschmissen. Die Dokumisere hat sich allerdings deutlich gebessert, seit das CDBS-Wiki online gegangen ist. Lektüre, die sich unbedingt lohnt.

DPotW: guessnet-ifupdown

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 22 May 2005 15:41:00 +0200

guessnet-ifupdown ist die von mir präferierte Lösung für das Problem eines mobilen Hosts, der mal dort und mal dort ans Netz angeschlossen wird, und die DHCP-Server in den verschiedenen Netzen einem zwar IP und Defaultgateway geben mögen, aber andere Einstellungen trotzdem lokal geregelt werden müssen.

Ich mag guessnet-ifupdown aus der guessnet-Package deswegen, deswegen, weil es sich schön in die Debian-Philosophie der Netzkonfiguration einfügt: Es wird über /etc/network/interfaces konfiguriert:


mapping eth0
        script /usr/sbin/guessnet-ifupdown
        map default: default
        map timeout: 3
        map verbose: true

iface l21 inet dhcp
        scheme l21
        route_silo silo unreachable
        route_lilo lilo unreachable
        exim4_smarthost smtp 25
        web_proxy web.proxy 8080
        ntp ntp
        cron_apt yes
        cups yes
        test-peer address 192.168.130.1

iface expensive inet manual
        scheme expensive
        route_silo silo unreachable
        route_lilo lilo unreachable
        exim4_smarthost q.bofh.de 25
        web_proxy none
        cron_apt refrain

iface disconnected inet manual
        scheme disconnected
        route_unreach 0.0.0.0/0 unreachable
        up ip link set dev eth0 down
        exim4_smarthost defer_always
        web_proxy none
        test missing-cable

Zusätzlich verwende ich ifplugd, um das Interface beim Einstecken des Netzwerkkabels “up” zu setzen. In der Folge wird guessnet-ifupdown aufgerufen, das einige Prüfungen durchführt (das sind die test-Klauseln in der /e/n/i). Als Tests stehen zur Verfügung:

Wird ein System mit bestimmter IP/MAC-Adresse gefunden?
Ist ein Kabel gesteckt?
Welchen Wert liefert ein Kommando zurück?
Ist ein PPPoE?-Server im Netz?

Abhängig von den Tests wird das Interface dann so initialisiert, wie in der entsprechenden Stanza genannt. In meinem Beispiel L21 ist das DHCP, wobei es auch möglich ist, bei Abwesenheit eines DHCP-Servers nach einem System mit bestimmter IP-Adresse zu suchen, um dann eine zum Gegenstück passende statische IP-Adresse zu konfigurieren.

Die anderen Zeilen in den Stanzas steuern Scripte, die in /etc/network/if-up.d und /etc/network/if-down.d dafür sorgen, dass die Einstellungen bei der Interfaceinitialisierung ins System geprügelt werden. Hier ein Beispiel:


$ cat web-proxy
#!/bin/bash

# Environment:
#  MODE = { start | stop }
#  IF_WEB_PROXY = hostname port
# TODO: Exceptions

USEFILE=“/etc/use-proxy”
PACFILE=“/etc/proxy.pac”

if [ -z “$IF_WEB_PROXY” ]; then
  exit 0
fi

if [ “$MODE” = “stop” ]; then
  rm -f $USEFILE
  rm -f $PACFILE
  exit 0
fi

if [ “$IF_WEB_PROXY” = “none” ]; then
  rm -f $USEFILE
  rm -f $PACFILE
  exit 0
fi

PORT=“${IF_WEB_PROXY#* }”
HOST=“${IF_WEB_PROXY% *}”

cat < $USEFILE
#!/bin/bash

export http_proxy=http://$HOST:$PORT/
export
ftp_proxy=$http_proxy
export no_proxy=127.0.0.1,localhost
# the following is a local fix for #255742
export NO_PROXY=“$no_proxy”
EOF

cat < $PACFILE
function FindProxyForURL(url,
host) {
  if( isInNet(host, “127.0.0.1”, “255.0.0.0”)) {
    return
“DIRECT”;
  } else {
    return “PROXY $HOST:$PORT”;
  }
}
EOF

Das Script steht sowohl in if-up.d als auch in if-down.d und setzt abhängig von den aus /e/n/i übergebenen Werten die entsprechenden Daten in die Dateien /etc/use-proxy und /etc/proxy.pac. Das eine wird von den User-Init-Scripts gesourced, das andere steht als file://-URL in den Proxyeinstellungen der Browser.

Die anderen Scripts sind auf Anfrage verfügbar, und werden von mir vielleicht irgendwann mal zur guessnet-Package als examples veröffentlicht.

Das Interface “expensive” wird nicht von guessnet bedient, sondern steht manuell als “ifup expensive” in /etc/ppp/ip-up.d für “Provider”, die “teuer” sind, also z.B. die GPRS-Verbindung. Ich verhindere somit, dass trafficintensive Dinge wie cron-apt gerade dann loslaufen, wenn IP richtig teuer ist. Da die Methode “manual” verwendet wird und keine Änderungen an der direkten Netzkonfiguration durchgeführt werden, ist der “ifup”-Aufruf aus der PPP-Initialisierungsphase unschädlich.

Noch nicht angegangen bin ich die Automatik für wireless LAN, die wegen der notwendigen Verschlüsselungsmechanismen nicht 1:1 wie ein Ethernetinterface abbildbar ist. Dafür gibt es mit waproamd auch einen gut integrierenden Helfer, den ich allerdings bisher noch nicht ausprobiert habe: Wireless ist für mich nach wie vor kein Vorrangthema.

DPotW: cron-apt

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 15 May 2005 11:57:00 +0200

Die dieswöchige Debian-Package of the Week ist cron-apt, ein Tool, mit dessen Hilfe unter anderem das automatische Ausrollen von Security-Updates auf eine große Zahl von Systemen drastisch vereinfacht wird.

Eigentlich ist das, was cron-apt tut, denkbar einfach: Es ruft aus dem cron regelmäßig die Kombination apt-get update; apt-get --download-only dist-upgrade auf und stellt dem Systemverwalter das Ergebnis per Mail zu.

Was so einfach klingt, ist in der Praxis sehr hilfreich, weil auf diese Weise jedes einzelne System ständig überprüft, ob es aktuell ist. Sprich, man kann beim Update ruhig einzelne Systeme vergessen, sie brüllen Dich beim nächsten cron-Zyklus selbsttätig wieder an, und das so lange, bis Du sie mit dem Update versorgt hast.

Obwohl cron-apt natürlich die Updates auch gleich installieren könnte, habe ich mich zu diesem Schritt bisher noch nicht getraut: Meine cron-apts laden die Updates sofort nach Verfügbarkeit auf das Zielsystem; die eigentliche Installation mache ich aber noch manuell. Dabei kann ich mir gut vorstellen, dass die Konfigurationsfähigkeit es hergeben müsste, das unkritische Packages wie das stündliche Virenpatternupdate sofort auch installiert werden. Probiert habe ich das freilich bisher genausowenig wie die Verwendung von aptitude anstelle des klassischen apt-get, was ab sarge aktuell werden könnte.

Um die Last auf den Mirrors besser zu verteilen, wartet ein aufgerufenes cron-apt erstmal eine zufällige Zeit, bevor es mit dem Download beginnt.

Was ich auch sehr nett finde, ist die Möglichkeit, nur dann eine Mail zu schicken, wenn sich die Ausgabe des Installationstools gegenüber dem letzten Aufruf geändert hat. Das ermöglicht häufigen Aufruf, ohne die Mailbox zu bombardieren.

cron-apt nützt sowohl auf stable- als auch auf unstable-Systemen. Auf stable-Systemen erhält man von cron-apt Informationen, wenn neue Security-Updates bzw. Point Releases verfügbar sind. Oft sind die Mails von cron-apt schon da, bevor überhaupt das Advisory erschienen ist. Auf unstable-Systemen kommen natürlich mehr Mails, die einen daran erinnern, dass das lokale unstable nicht mehr bleeding edge ist.

Zum Abschluss hier noch meine cron-apt-Konfiguration, die stündlich nach Updates guckt, diese auch sofort herunterlädt (aber nicht installiert), aber nur bei Veränderungen eine Mail schickt. Für den Fall, dass das Update nicht sofort ausgeführt wurde, gibt es einmal nächtlich eine Erinnerung. Bedingt durch das automatische Herunterladen und den Diff-Check gibt es bei neu erschienenen Packages zwei Mails im Stundenabstand - die erste zeigt, dass neue Packages da sind und dass sie heruntergeladen wurden, die zweite zeigt dann nur noch, dass neue Packages auf Installation warten - und nach erfolgter Installation auch eine “Bestätigung”, dass nix neues mehr auf Installation wartet. Damit wird Teamwork unterstützt, weil man sieht, dass jemand anders schon aktiv war - und das ganz automatisch.

/etc/cron.d/cron-apt


0 4     root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt
0    *  root    test -x /usr/sbin/cron-apt && /usr/sbin/cron-apt /etc/cron-apt/config
/etc/cron-apt/config-hourly

/etc/cron-apt/config


MAILTO=“mh+$(hostname --fqdn)-cron-apt@zugschlus.de”
MAILON=“upgrade”
DIFFONCHANGES=prepend

/etc/cron-apt/config-hourly


MAILON=“changes”

DPotW: file-rc

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 09 May 2005 12:34:25 +0200

file-rc ist ein Ersatz für die unter SysV-Derivaten und Linux üblichen Linkfarmen, die sich inzwischen halbwegs einheitlich unter /etc/rcx.d angesammelt haben. Statt Linkfarm gibt es ein einziges Konfigurationsfile, /etc/runlevel.conf

Ein Ausschnitt aus meiner /etc/runlevel.conf sieht so aus:


# This file was automatically generated by /usr/share/file-rc/rclink2file.sh.
# You can use your favourite editor or update-rc.d(8) to modify it.
# Read runlevel.conf(5) man page for more information about this file.
#
# Format:
# <sort> <off-> <on-levels>     <command>
01      0,1,6   -               /etc/init.d/kdm
02      -       S               /etc/init.d/mountvirtfs
05      -       1               /etc/init.d/single
05      -       S               /etc/init.d/bootlogd
05      -       S               /etc/init.d/initrd-tools.sh
05      -       S               /etc/init.d/keymap.sh
20      0,1,6   2,3,4,5         /etc/init.d/console-log
20      0,1,6   2,3,4,5         /etc/init.d/exim4
20      0,1,6   2,3,4,5         /etc/init.d/ifplugd
20      0,1,6   2,3,4,5         /etc/init.d/inetd
20      0,1,6   2,3,4,5         /etc/init.d/makedev
20      0,1,6   2,3,4,5         /etc/init.d/pcmcia
20      0,1,6   2,3,4,5         /etc/init.d/ssh
20      0,1,2,3,4,5,6   -       /etc/init.d/inn2
20      0,1,6   2,3,4,5         /etc/init.d/xinetd
20      0,1,2,3,4,5,6   -       /etc/init.d/snmpd
20      0,1,2,3,4,5,6   -       /etc/init.d/smokeping
20      0,1,6   -               /etc/init.d/munin-node
20      0,1,2,3,4,5,6   -       /etc/init.d/torrus-common
23      0,1,2,3,4,5,6   -       /etc/init.d/ntp-server

Ich denke, man sieht schön deutlich, wie das Ding gemacht ist. Jede Ziffer in den Spalten zwei und drei ersetzt einen
Link in der Linkfarm.

file-rc hat volle Unterstüzung des Debian-Abstraktionslayers, d.h. Packages, die update-rc.d und invoke-rc.d verwenden, merken nicht einmal, dass sie keine Symlinks verarbeiten. Leider hat das Debian-Abstraktionslayer die bekannte, lästige Lücke, die einen dazu zwingt, manchmal doch auf die Symlinks zuzugreifen.

Bei der Installation von file-rc wird die vorgefundene Linkfarm 1:1 in eine runlevel.conf umgesetzt, und andersrum, wobei ich das “andersrum” mangels Deinstallation noch nie wirklich ausprobiert habe.

Wie ich zu file-rc gekommen bin? Bei meiner ersten Debian-Installation (hamm, wenn sich noch jemand erinnert) habe ich noch die Liste der Packages vollständig durchgeschaut, und fand die Description interessant - ohne zu wissen, dass ich mir gleich mein ganzes System umstelle. Später hielt ich file-rc für den Default, und war ganz entsetzt, als ich auf meiner zweiten Debian-Installation (slink, falls sich, Ihr wisst schon) wieder die althergebrachte Link-Farm fand.