Und siehe da, die Lösung lag, wie so oft bei Linux Themen die ganze Zeit direkt vor meinen Füßen:

rm -f $(repomanage --old -k 2 myrepodir)

… behalte zu jedem RPM die zwei neuesten und lösche alle alten raus.

repomanage ist Bestandteil vom yum-utils RPM.

Ob das nun an der von mir genutzten Version liegt oder – und diese Vermutung habe ich – daran dass ein Nutzer irgendetwas “drückt” was dem Prozess das Genick bricht – es gibt hier und da einen Absturz des Asterisk Prozesses (meist Segfaults). Ich setze zur Zeit die Version 1.8.7 ein, plane jedoch auf 1.8.20 zu gehen. Möglicherweise ist das Problem dann auch behoben.

Und bis dahin?

Ja, bis dahin muss das System irgendwie so konfiguriert sein, dass die Schäden bzw. die Außenwirkung recht klein gehalten wird. Nun könnte man ein Script schreiben, welches den Prozess prüft und ggf. neu startet. Oder das ganze an das Monitoring übergeben und über ein Event den Dienst vom Monitoring neu starten lassen. Alles möglich … aber meiner Meinung nach zu kompliziert und auch nicht Zielführend. Warum? Ich möchte, dass der Dienst SOFORT wieder gestartet wird. Das ganze über Monitoring zu machen (egal ob lokal oder remote) bedeutet, dass ich immer maximal eine Minute habe, bis dass das System den Ausfall bemerkt.

So ähnlich wie …

Es gibt bereits ein fertiges Script, welches so was in der Richtung macht wie ich es mir vorgestellt habe. Das ganze ist ein Wrapper um den Asterisk Prozess herum. Wrapper? Naja, ein einfaches Bash Script welches den Asterisk Prozess innerhalb eines Loops startet. Wird der Prozess beendet, startet er über den Bash Loop sofort wieder.

Das Problem dabei ist, dass – bei einem Problem – der Prozess immer und immer wieder gestartet wird. Fällt er beim Start auf die Nase, so wird er trotzdem immer und immer wieder gestartet. Am Ende kann das fatal sein.

So hab ich das gemacht …

Warum sich nicht vorhanden Mechanismen bedienen. Es gibt da was, das ist seit gefühlten 100 Jahren im Einsatz und macht seinen Dienst perfekt – ok, es wird zur Zeit so langsam abgelöst, aber das ist jetzt mal egal. Wovon ich spreche? Der Init Prozess.

Mit Hilfe der inittab ist es möglich Prozesse in definierten runlevel zu starten und – was uns interessiert – quasi zu überwachen. Der Init Prozess startet den Prozess und sobald dieser beendet wird, startet er ihn sofort wieder. Genau das brauchen wir, damit der Asterisk bei einem Crash sofort wieder zur Verfügung steht. Dabei sind dann natürlich die aktuellen Gespräche weg, jedoch kann sofort wieder telefoniert werden ohne dass jemand erst etwas tun muss oder ein Monitoring Prozess das ganze prüft.

Wie sieht das nun in der inittab aus?

Ganz einfach:

as:2:respawn:/usr/sbin/asterisk -f -U asterisk

Aber Vorsicht! Der Asterisk darf bei der Umstellung auf die Inittab nicht laufen. Ansonsten versucht der Init Prozess Asterisk zu starten, was nicht möglich ist. Er wird das ein paar Mal versuchen und dann eine Karenzzeit warten, bis er das ganze wieder versucht.

Nach der Änderung der inittab mit “init q” die inittab neu einlesen. Dabei wird dann der Prozess ggf. gestartet. Vorsicht ist auch geboten bei Wartungsarbeiten – man sollte daran denken, dass der Asterisk Prozess nicht einfach so gestoppt werden kann Vorher die Zeile auskommentieren und über “init q” die inittab neu einlesen.

Vor langer Zeit habe ich mir ein kleines Tool namens rsr gestrickt, das ich vor kurzem mit weiteren Features (inspiriert von mussh) erweitert habe. Nun möchte ich es auch anderen zur Verfügung stellen und hoffe natürlich auf bugfixes und Verbesserungsvorschläge.
Es gibt zwar auch andere parallel ssh Tools, aber die haben mich nie wirklich glücklich gemacht. Immer hat etwas gefehlt.

Das kann rsr

• Skript oder einzelne Kommandos auf einer Liste von Hosts ausführen
• Parallelität der Bearbeitung einstallbar (bis hin zu alle gleichzeitig)
• Sortierte Ausgaben der entfernten Hosts anzeigen und/oder speichern sowie autoamtisches ausräumen
• Zusammenfassung aufgetretener Fehler
• Short- und Option mode
• SSH Optionen als defaults mitgeben

Ein Beispiel

pinky:/tmp/rsr # cat myhosts.txt
brain
snowball
billie
pharfignewton
pinky:/tmp/rsr # cat myscript.sh
#!/bin/sh
grep acl /etc/fstab
pinky:/tmp/rsr # rsr myscript.sh myhosts.txt
brain: /dev/system/root     /           ext3      acl               1 1
brain: LABEL=boot           /boot       ext2      acl,user_xattr    1 2
snowball: /dev/system/tmp     /tmp        ext3      acl              1 2
snowball: LABEL=boot          /boot       ext3      acl,user_xattr   1 2
billie: /dev/system/root     /           ext3      acl               1 1
billie: LABEL=boot           /boot       ext2      acl,user_xattr    1 2
billie: /dev/system/tmp      /tmp        ext3      acl               1 2
billie: /dev/system/usr      /usr        ext3      acl               1 2
billie: /dev/system/var      /var        ext3      acl               1 2

Errors occured on hosts:
pharfignewton.error_255:ssh: Could not resolve hostname pharfignewton: Name or service not known
pinky:/tmp/rsr #

In diesem Beispiel möchte ich einfach prüfen welche Server acls in der fstab enthalten (OK, ich gebs zu, reichlich sinnlos). Bei Host “pharfignewton” ist ein Fehler aufgetreten, was am Ende des Laufes ausgegeben wird.
Alle anderen Ausgaben die das Skript auf den entfernten Servern erzeugt, werden auf der Console sortiert ausgegeben.

Hier habe ich den “short mode”, in dem nur der Skriptname und optional die Serverlistendatei angeben werden muss verwendet. Möchte man rsr nicht mit den default Werten ausführen versteht es auch im “Option mode” eine Menge Parameter.

Die wichtigsten Paramenter

-C <script>: Skript, das ausgeführt werden soll.
-c <command>: einzelnes Kommando für den remote Host (kann mehrfach angegeben werden).
-H <hostlistfile>: Hostliste.
-h <hostname>: einzelner host (kann mehrfach angegeben werden).
-m [n]: Anzahl der parallelen SSH Sitzungen. Wird [n] nicht angegeben werden alle Hosts gleichzeitig bearbeitet.
-k [n]: Die Ausgaben werden in einem Verzeichnis, sortiert in “Host”-Ausgabedateien gespeichert. [n] gibt an, wieviele Läufe aufbewahrt werden. Wird für [n] nichts angegeben, werden Ausgaben älterer Läufe nicht gelöscht.

Hier die ganze Usage

Usage:
   rsr [OPTIONS]  [-c cmd] [-C scriptfile]
   rsr <script> [<hostfile>]
            Short mode: run <script> on <hostfile> hosts.
            If <hostfile> not given use file "allhosts.txt".
   rsr --help
            for full help text

Send a command or a script to multiple hosts.

OPTIONS:
   --help          This text.
   -m [n]          Run concurrently on 'n' hosts at a time.
                   Use '0' (zero) for infinite. (Default if -m)
                   If option is not set then default is 10
   -i <identity> [identity ..]
                   Load an identity file.  May be used
                   more than once.
   -o <ssh-args>   Args to pass to ssh with -o option.
   -a              Force loading ssh-agent.
   -A              Do NOT load ssh-agent.
   -u              Unique.  Eliminate duplicate hosts. (Default)
   -U              Do NOT make host list unique.
   -P              Do NOT fall back to passwords on any host. This
                   will skip hosts where keys fail.
   -l <login>      Use 'login' when no other is specified with
                   hostname.
   -L <login>      Force use of 'login' name on all hosts.
   -s <shell>      Path to shell on remote host. (Default: bash)
   -t <secs>       Timeout setting for each session.
                   (requires openssh 3.8 or newer)
   -V              Print version info and exit.
OUTPUT ARGS:
   -d [n]          Verbose debug.  Prints each action, all hosts
                   and commands to be executed to STDERR. 'n' can
                   be from 0 to 2.
   -v [n]          Ssh debug levels.  Can be from 0 to 3.
   -q              No output unless necessary.
   -k [n]          Keep last 'n' host output directories (If set
                   without argument then all output dirs kept. If
                   this option is not set no output will be kept)
   -O <dir>        Use <dir> for host output directory
                   with timestamp
PROXY ARGS:
   -p [user@]<host>
                   Host to use as proxy.  (Must have rsr installed)
   -po <ssh-args>  Args to pass to ssh on proxy with -o option.
HOST ARGS:
   -h [user@]<host> [[user@]<host> ..]
                   Add a host to list of hosts.  May be
                   used more than once.
   -H <file> [file ..]
                   Add contents of file(s) to list of hosts.
                   Files should have one host per line.  Use
                   "#" for comments.
COMMAND ARGS:
If neither is specified, commands will be read from standard input.
   -c <command>    Add a command or quoted list of commands and
                   args to list of commands to be executed on
                   each host.  May be used more than once.
   -C <file> [file ..]
                   Add file contents to list of commands to be
                   executed on each host.  May be used more
                   than once.

Download

rsr-2.0.tar.gz

Bei Bedarf kann ich auch gerne ein SLES/RHEL RPM schnüren.

Installation

Da rsr lediglich ein Bash Skript ist, kann man es einfach irgendwo, am Besten aber in den $PATH legen.
Achtung: Wird die -O Option nicht angegeben wird temporär ein Arbeitsverzeichnis im aktuellen Pfad angelegt. Man muss daher im aktuellen Verzeichnis Schreibrechte besitzen.

Tipps:

Sinnvoll wäre der ssh-agent, das Verteilen seines public keys und das Füllen der SSH known_hosts mit den Fingerprints aller Server. Wenn einem die Sicherheit und Fingerprints egal ist, kann auch eine entsprechende SSH Optionen für das Nichtbeachten der Fingerprints in den Defaults (im Skript) eingetragen werden. Anderfalls gibts viele, viele Fehlermeldungen!

Ich würde mich freuen, wenn rsr auch anderen Admins so viel Zeit und Stumpfsinnarbeit erspahren würde wie uns…

Vorschläge und Bugfixes gerne an mich!

TFTP ist relativ dämlich – was ihn für diverse Anwendungsfälle attraktiv macht. Ohne viel hin&her mit Benutzerkonten oder ähnlichem kann man Dateien zur Verfügung stellen oder auch ablegen. Aus dem Grund wird TFTP gerne von Hardwareherstellern für Updates oder Bootkonfigurationen eingesetzt.

Diverse Geräte lassen sich auch über diesen Mechanismus sichern. So die von uns für die Telefonanlage eingesetzten Patton Geräte als auch die Aastra DECT Basisstationen.

“file exists”

Ein Problem bei TFTP – wenigstens bei einem der sich an die RFC hält – ist, dass es quasi kein überschreiben gibt. Liegt eine Datei auf dem Server, so kann sie nicht überschrieben werden. Entweder muss also das schreibende oder sichernde Gerät den Namen für die Datei ändern oder das ganze schlägt fehl. Was nun, wenn ich den Dateinamen nicht beeinflussen kann und dazu auch den Sicherungszeitpunkt nicht beeinflussen kann?

Genau das Problem hatte ich. Die Aastra DECT Sender sichern ihre Datenbank (Konfigurationsdatenbank) per TFTP. Die Datei hat im Namen zwar das Datum, jedoch keine Uhrzeit o.ä. . Die Datenbank wird gesichert sobald Änderungen an dem System vorgenommen werden – also keine feste Zeit. Am Ende bedeutet das, dass die Änderung von früh morgens gesichert wird und die Änderung eine Stunde später schlägt fehl da die Sicherungsdatei den gleichen Namen hat.

Elegant drumherum

Spontan hatte ich nur eine Idee, die ich aber auch nicht wirklich schlecht finde. Mit “incron” (von Sascha vor längerer Zeit beschrieben) – dem Filesystem Event Cron. incron kann so eingerichtet werden, dass er eine Aktion ausführt, sobald etwas in einem Pfad geschieht. Also sowas wie Datei erstellt, Datei gelöscht, Datei umbenannt …

Im Fall TFTP sieht die Konfiguration aus wie folgt (/etc/incron.d/rfpbackup):

 /srv/tftp/rfpBackup IN_CLOSE_WRITE /bin/mv $@/$# $@/sav-$#
 

Als erstes das Verzeichnis welches beobachtet werden soll, dann das Event (IN_CLOSE_WRITE -> nach dem schreiben) und am Ende der Befehl. Das einzige was ich hier mache ist die Datei umbenennen in sav-<Originaldatei>. Damit habe ich immer die letzte Sicherung und kann neue Sicherungen empfangen. Da innerhalb des Dateinamens das Datum enthalten ist, habe ich somit immer eine Sicherung pro Tag.

XML ist ja wahnsinnig angesagt für alle möglichen Dinge. Ich selbst kann mich damit nicht so recht anfreunden – zumindest ist manuelles editieren immer ein Krampf. Ich habe meist mit Konfigurationsdateien in XML zu tun. So auch mit meinem Telefonprojekt. Die Snom Telefone nutzen für das Provisioning eine XML Datei, welche über einen Webserver abgerufen wird. Da ich die Konfiguration sehr dynamisch gemacht habe (Webfrontend etc.) wird auch die XML Konfig für die Telefone dynamisch erstellt. Diese Datei sollte sich unbedingt an den XML Standard halten, da ansonsten die Telefone mit dem ganzen nichts anfangen können (dabei habe ich schon die seltsamsten Fehler erlebt).

XML validieren

Um XML zu validieren gibt es ein recht einfaches Tool unter Linux – xmllint. Einfach als Parameter eine XML Datei angeben und gut. xmllint kommt auch mit http Links zurecht – was mir ebenfalls gerade recht kommt

Icinga Plugin

Absolut simpel kann man das ganze nun in ein Icinga/Nagios Plugin verwandeln:

#!/bin/bash

# validation of a remote XML File

# Ronny Becker, 02.2013

RET="`xmllint --noout $1 2>/dev/null; echo $?`"

case $RET in
 "0" )
 echo "XML Validation OK"
 exit 0
 ;;
 "1" )
 echo "XML Validation NOT OK"
 exit 2
 ;;
 * )
 echo "unknown return code"
 exit 3
 ;;
esac

Das ganze als command einbinden, als ersten Parameter bekommt das Plugin die remote Adresse (http://…) und fertig.

.. und hier ist mein, zugegeben sehr einfaches aber wie ich finde recht nützliches bash-Skript für die Lösung des “Problems”.

Es hat den einfallsreichem Namen: backup    

Meine Kollegen und ich verwendes es mittlerweile immer und überall. Auch in anderen Skripten, die mit Dateiänderungen arbeiten, kommt backup mit der -k Option zum Einsatz.

Kleines Beipiel

[root@myhost etc]# backup yum.conf
[root@myhost etc]# ls -l yum.conf*
-rw-r--r-- 1 root root 346 May 22 2012 yum.conf
-rw-r--r-- 1 root root 346 May 22 2012 yum.conf.20130207-084855
[root@myhost etc]# backup
usage: ./backup [-k <num> ] [-yv] file_to_backup [file_to_backup...]
options:
-k keep last backups and remove older files
-y assume 'yes' if backup a directory
-v verbose
[root@myhost etc]#


Features

• Sicherungskopien von mehreren Dateien und/oder Verzeichnissen erstellen
• Automatisches löschen alter Sicherungen mit der -k Option (nach dem Erstellen von Neuen).

Download und Installation

Einfach das Skript kopieren und irgendwo in den $PATH legen. Fertig.

Hier das backup Skript:

#!/bin/bash
#
# Creates a copy with timestamp of the file(s) given in argument.
# Optionally removes old copies
#
# by sascha.nowak@dfs.de
#

KEEPNUM=0        # 0 = disabled

function printhelp() {
        echo "usage:  $0 [-k <num>] [-yv] file_to_backup [file_to_backup...]" >&2
        echo "options:" >&2
        echo "      -k    keep last <num> backups and remove older files" >&2
        echo "      -y    assume 'yes' if backup a directory" >&2
        echo "      -v    verbose" >&2
        exit 1
}

[ "$1" == "" ] && printhelp

while getopts ":k:yvh" opt
do
        case $opt in
                k)
                        [ ${OPTARG:0:1} = "=" ] && KEEPNUM=${OPTARG/=} || KEEPNUM=$OPTARG
                        ;;
                y)
                        YES="y"
                        ;;
                v)
                        VERBOSE="v"
                        ;;
                *)
                        printhelp
                        ;;
        esac
done

shift $(($OPTIND-1))

FILENAMES=$*

[[ $KEEPNUM == [0-9]* ]] || printhelp


# pre check
ERROR=0
for FILENAME in $FILENAMES; do

        if [ ! -e $FILENAME ]; then
                echo "file not found or unsupported filetype: $FILENAME" >&2
                ERROR=1
        fi
        if [ -L $FILENAME ]; then
                echo "file is a symlink: $FILENAME" >&2
                ERROR=1
        fi
        if [ -d $FILENAME -a $ERROR != 1 ] ; then
                if [ "$YES" != "y" ]; then
                        echo -n "Do you want to backup the whole directory $FILENAME? [Y/n] "
                        read YN
                        if [ "$YN" == 'n' ] ; then
                                echo OK, nothing backuped >&2
                                exit 1
                        else
                                YES=y
                        fi
                fi
        fi
done
if [ "$ERROR" == 1 ] ; then
        echo 'Operation stopped because of previous errors. Nothing backuped!' >&2
        exit 1
fi



# copy files
for FILENAME in $FILENAMES; do
        # evtl / am Ende entfernen
        FILENAME=$(echo $FILENAME | sed 's#/$##')
        cp -pr$VERBOSE $FILENAME $FILENAME.`date +%Y%m%d-%H%M%S`
        RETVAL=$?
        if [ "$RETVAL" -ne 0 ] ; then
                echo Copy error at file: $FILENAME >&2
                exit $RETVAL
        fi
done

# remove old files
if [ $KEEPNUM -gt 0 ]; then
        for FILENAME in $FILENAMES; do
                # evtl / am Ende entfernen
                FILENAME=$(echo $FILENAME | sed 's#/$##')
                I=0
                for FILE in `ls -dr $FILENAME.????????-??????`; do
                        I=$(( $I + 1 ))
                        [ $I -gt $KEEPNUM ] && rm -rf$VERBOSE $FILE
                done
        done
fi

Für Ideen und Anmerkungen bin ich offen.

Das Problem hat bestimmt schon jeder mal gehabt. Man hat einen Haufen Dokumente in verschiedenen Formaten wie .doc, .odt, .ppt, .xls, … und möchte diese, beispielsweise für eine Präsentation oder einfach nur zum Verschicken, in einem Dateiformat (bspw. .pdf) vorliegen haben. Nur wie?

Für Leute die Zeit haben …

Wenn man Zeit hat, dann kann man einfach jede Datei in LibreOffice öffnen und dann als .pdf exportieren.

… für die anderen

Man kann durchaus auch mit LibreOffice auf der CLI arbeiten. Für unser Problem würde der Befehl entsprechend so aussehen:

libreoffice --headless --invisible --nologo --convert-to pdf *.{doc,docx,odp,odt,ppt,pptx,<wbr>xls,xlsx}

Aber Achtung! Man sollte bei LibreOffice vorher einmalig unter “Datei”->”Exportieren als PDF..”, beim Reiter “Allgemein” die Option PDF/A-1a aktivieren. Die so erzeugten PDFs eignen sich besser für die Archivierung und die Darstellung ist besser, da benötigte Schriftarten gleich mit eingebettet werden. Habe leider noch nicht herausgefunden, wie man das Verhalten ohne GUI beeinflussen kann.

“Damals” musste man immer eine CD brennen um die neueste Distribution auszuprobieren. Das hat – das herunterladen übrigens auch – immer lange gedauert und war im vergleich zu heute auch weniger bequem. Dann kamen die wiederbeschreibbaren CDs. Damit wurde schon mal der Müll reduziert – in der Theorie. Denn diese waren nicht von jedem Laufwerk lesbar und teurer

Alles wird gut …

Mittlerweile sind USB Sticks der Standard als Installationsmedium. Wenn auch nicht bei jedem Laptop ein USB Stick beiliegt oder auch andere Software oft noch als CD zu kaufen ist, so hat sich innerhalb der IT der USB Stick als Medium für Installationsmedien gegen die CD überwiegend durchgesetzt. Schon lange her, dass ich mir für eine Installation eine CD gebrannt habe …

… aber wie?

Die Frage die nun den ein oder anderen interessieren wird ist, wie man denn einen solchen Stick erstellt!?! Es gibt – und wir sprechen nur von Linux – einen Haufen Tools für diese Aufgabe. Eines der bekanntesten GUI-Tools ist wahrscheinlich Unetbootin. Unetbootin bietet beispielsweise auch an, das gewünschte .iso der Distribution selbst herunterzuladen. Des Weiteren gibt es Optionen wie ein persistentes Home. Spielt man mit einer Live CD, so können Daten erstellt und Änderungen gemacht werden, die auf dem USB Stick verbleiben und beim nächsten Start wieder zu Verfügung stehen.

Der liveusb-creator von Fedora hat einen vergleichbaren Funktionsumfang wie Unetbootin, fühlt sich allerdings im Fedoraumfeld um einiges wohler. Beide Programme sind übrigens auch für das gekachelte Badezimmer OS verfügbar. Das sind die meiner Meinung nach am meisten bekannten GUI Tools. Doch wie das unter Linux so ist, kann man auch diese Aufgabe recht einfach über die CLI lösen. Und wie ich finde sogar einfacher.

Das Tool “dd” sollte ein Begriff sein. Auch damit kann man einen bootbaren USB Stick erstellen. Der Befehl ist simpel:

dd if=/path/to/iso/image.iso of=/dev/usbdevice (bspw. sdc)

fertig.

Mein Favorit

Mein Favorit ist dd. Nicht weil ich ein CLI Junkie bin, sondern weil es damit ein Problem einfach nicht gibt – und das ist folgendes: Unetbootin erstellt einen eigenen Bootloader auf dem Stick und sucht innerhalb des .iso Files nach dessen Bootloader. Dieser wird analysiert und die Einträge werden dann soweit möglich übernommen. Das funktioniert leider nicht immer so gut. Dadurch fehlen öfters mal Einträge wie z.B. der Booteintrag um ein Rettungssystem zu starten oder ähnliches.

Bei dem Fedora Tool sieht das ganze nicht anders aus. Es funktioniert am besten mit Fedora, RHEL oder CentOS Images. Bei anderen gibt es ebenfalls das ein oder andere Mal Probleme.

Bisher keine Probleme hatte ich, wenn ich dd benutzt habe. Es bootet der Bootloader des .iso Images ohne Veränderungen und es stehen entsprechend alle Menüeinträge zur Verfügung.

Einen Nachteil hat die Sache mit dd natürlich. Es befindet sich im Gegensatz zu den anderen Tools kein “normales” Filesystem auf dem Stick und die Partitionstabelle ist auch nicht so, wie man es von einem Stick erwarten würde. Ein persistentes Home, wie es von den Tools angeboten wird, wird damit nicht so einfach funktionieren. Da muss man sich eben die Frage stellen, ob man das möchte bzw. braucht. Ich benötige meistens einfach nur ein Installationsmedium zur Installation oder zum Test und das sollte funktionieren.

Was nutzt ihr?

Konfigurationsbeispiele für Patton Geräte sind relativ schwer im Netz zu finden. Daher möchte ich hier einen weiteren Tipp platzieren.

Fax redundant? Wer braucht denn sowas?

Ein redundantes Fax? Also ich denke das ist nicht wirklich selten. Was macht man im Büro, wenn ein zentrales Faxgerät defekt ist? Natürlich versucht man für Ersatz zu sorgen, was jedoch nicht immer möglich ist, bzw. auch zuerst einmal seine Zeit braucht. Besser finde ich es, wenn ein defektes Fax einfach ausgeschaltet oder abgezogen werden kann und die Faxe einfach an einem anderen – vorher definierten – Faxgerät ankommen.

Schlagwort: Distribution Group

Wir sprechen hier von Geräten der Firma Patton (www.patton.com) und im speziellen von analog Gateways (z.B. SmartNode 4324).

Eine Distribution Group kann für diverse Anwendungsfälle herangezogen werden. Beispielsweise wenn mehrere Telefone gleichzeitig signalisieren sollen oder wenn – wie unserem Beispiel – erst eines und dann ein anderes klingeln soll. Eine solche DG ist über das Webfrontend schnell eingerichtet und auch nicht wirklich eine Herausforderung Allerdings … Bei der Portkonfiguration wird die Nummer des Ports gesetzt – die sog. “subscriber-number”. Ist diese gesetzt, so empfängt dieser Port lediglich Anrufe für diese entsprechende Nummer. Was passiert nun wenn der Anruf auf die zweite Nummer innerhalb der DG geschickt wird? Die Zielnummer stimmt nicht mehr – der Anruf wird nicht beantwortet.

Daher ist es notwendig über ein “routing-table” und eine Funktion die Zielnummer vor der Weiterleitung umzuschreiben. Für die Nummer 105 (Zielnummer 1) und als Backup die Nummer 321 sieht das ganze dann z.B. so aus:

# das standard routing table
# die route zeigt nicht mehr auf ein Interface, sondern auf die
# Distribution Group
routing-table called-e164 RT_LOCAL
  route 105 dest-service DG_redundant_105

# das spezielle routing-table und die mapping-table
# um die Nummer von Ziel 105 auf Ziel 321 umzuschreiben
routing-table called-e164 RT_FAX_REDUNDANT_105
  route default dest-interface FXS_0_6 MAP_REDUNDANT_105

mapping-table called-e164 to called-e164 MAP_REDUNDANT_105
  map default to 321

# die Distribution Group, dort wird zuerst auf das eigentliche Ziel
# und dann auf die routing-table verwiesen
service distribution-group DG_redundant_105
  timeout 7
  min-concurrent 1
  max-concurrent 1
  route call 1 dest-interface FXS_0_3
  route call 2 dest-table RT_FAX_REDUNDANT_105

Ab dem zweiten Ziel kann das ganze natürlich auch x-mal gemacht werden. Für weitere Ziele muss dann entsprechend ein routing-table und ein mapping-table angelegt werden.

Ich hoffe das ganze ist verständlich – falls nicht einfach fragen

Früher, ja da gab es das oft. Eine Installation auf recht neuer Hardware erforderte den Kernelparameter “acpi=off”, damit die Installation durchgeführt werden konnte. Ansonsten wurden teils Festplatten nicht erkannt oder es gab die wundersamsten Probleme. Dass ich das letzte Mal diesen Parameter für eine Installation benötigt habe ist allerdings schon recht lange her.

BIS HEUTE…

Heute hab ich ihn wiedereinmal gebraucht. Ja. Nachdem ich einen Tag lang das Problem gesucht habe.

Neue HP DL380G7 Server wurden geliefert und sollten installiert werden. Ein löbliches Debian (6.0.6) sollte sich dort heimisch fühlen. Schon das erste Menü des Installers machte mich nachdenklich. Normalerweise kann man aus allen möglichen Sprachen auswählen – dort stand aber lediglich C (no localization) und English. Sonst nix. Dabei ging dann der halbe Tag drauf, da ich gedacht habe das Image ist defekt. Neues geladen – wieder nix. Auf einem anderen Rechner geladen und auf den Stick gepumpt – nix. Egal, einfach mal so versuchen … weiter geht’s. Dann wollte das System Firmware nachziehen … auch diese auf den Stick gemacht und wieder auf’s Neue gebootet …

Zwischenruf

Nur als Zwischeninformation. Die Rechner heute werden zwar immer schneller, jedoch brauchen sie immer länger bis die Initialisierung durch ist. Das dauert durchaus 5 Minuten und länger. Gefühlt wird das mit jedem weiteren Mal natürlich immer noch mehr

Zwischenruf fertig

Die Installation lief durch. Ohne weitere Probleme. Nach dem ersten reboot wollte ich mich dann einloggen. Nada. Das root Passwort welches ich während der Installation vergeben hatte wurde nicht angenommen. Naja, es wurde ja zweimal eingegeben. Tippfehler würde ich ausschließen – es ging einfach nicht.

Da mir das Problem mit der Sprachauswahl nicht aus dem Kopf ging wollte ich weiter testen. Auf einem anderen Server – allerdings ein G6 – lief das ganze richtig. Im Bios war auch nichts zu finden was irgendwie Sinn machen würde oder wo ich mir vorstellen konnte, dass Probleme dadurch entstehen.

Am Ende hab ich mich dann an den acpi Parameter für den Kernel erinnert. Da ich eh keinen Rat mehr wusste hab ich diesen dann ausprobiert und siehe da – es geht!! Diesen Parameter hab ich schon ewig nicht mehr gebraucht. Und warum das ganze sich so äußerte kann ich auch nicht wirklich erklären. Ich möchte es hier dokumentieren, damit vielleicht jemand anderes nicht so lange suchen muss