In een vorig blog
heb ik een backupscript behandeld dat gebruikt wordt om
laptops te backuppen naar een externe usb hardeschijf. Het uitvoeren van dit
script laat ik natuurlijk niet door de gebruikers doen, maar wordt automatisch
gedaan als ze de disk aansluiten. Hiervoor maak ik gebruik van de
functionaliteiten die de udev-daemon op linux biedt.

In mijn blog “Hotpluggen van input-devices”
heb ik het al eens gehad over udev.
In onderstaand verhaal hoeven we alleen udev het backupscript te laten
opstarten wanneer de
usb-disk wordt aangesloten. Hiervoor moeten we wel voor udev de disk uniek
kunnen identificeren. Anders wordt er wellicht op elk USB storage apparaat dat
wordt aangesloten een backup gemaakt.
Om de disk uniek te identificeren gebruik ik de Universal Unique Identifier
die je door middel van het
commando blkid kan opvragen. Bijvoorbeeld:

blkid -o udev /dev/sdc1
ID_FS_UUID=03ef5f17-221b-4120-b417-fe04be37fa1d
ID_FS_UUID_ENC=03ef5f17-221b-4120-b417-fe04be37fa1d
ID_FS_TYPE=ext3

De optie -o udev zorgt ervoor dat blkid de output in een formaat giet dat
voor udev bruikbaar is.
Mocht je geen UUID krijgen dan kun je die met behulp van tune2fs
alsnog toevoegen.

De udev-configuratie kun je vinden onder /lib/udev/rules.d. Echter dit zijn
de regels die
door udev zelf en je distributie zijn gemaakt. Hier dien je niet je eigen
regels aan toe te voegen, maar dat dien je in /etc/udev/rules.d te doen.
Meestal zie je dat de bestanden in */rules.d directories worden voorafgegaan door een nummer. Dit geeft
dan de volgorde aan waarin udev
de regels moet afhandelen. Door geen nummer op te geven wordt het bestand als
laatste afgehandeld en dat is in ons geval prima.
We maken een bestand aan genaamd backuplaptop.rules en dit bestand hoeft in ons geval alleen de
volgende
regel te bevatten.

ENV{ID_FS_UUID_ENC}=="03ef5f17-221b-4120-b417-fe04be37fa1d", RUN+="/usr/bin/backupserver $name"

Deze stelt dat als de variabele ID_FS_UUID_ENC gelijk is aan
03ef5f17-221b-4120-b417-fe04be37fa1d de udev-daemon
het programma /usr/bin/backupserver moet runnen met als argument de naam
van de device-file.
De variabele $name is een interne variabele van udev en bevat de device node
naam (bijvoorbeeld sdg1, sda2, tty, etc.) van het apparaat.

Ik ga er hier wel vanuit dat de variabele ID_FS_UUID_ENC wordt ingesteld als
er een externe USB harddisk wordt aangekoppeld.
Mocht dat nu niet het geval zijn, dan kun je dat alsnog bewerkstelligen door
vóór bovenstaande regel in backuplaptop.rules
het volgende op te nemen:

IMPORT{program}="/sbin/blkid -o udev -p $tempnode"

IMPORT{program} zorgt ervoor dat de udev-daemon het commando /sbin/blkid
uitvoert en verwacht dan dat de uitvoer ervan een lijst van variabelen met
waarden is die het dan instelt. De variabelen kunnen we dan via ENV weer
opvragen om bijvoorbeeld te vergelijken.

Om te testen dat de rule goed wordt opgepikt kun je udevadm in test-modus
als volgt gebruiken.

udevadm test /sys/block/sdc/sdc1/

Je moet hierbij niet de device-file onder /dev opgeven maar het sysfs-pad
voor de betreffende partitie.
udevadm zal dan alle udev-configuratie inlezen en kijken welke regels door
de udev-daemon zullen worden uitgevoerd.
Als het goed is geeft dit een heleboel uitvoer, maar zou je ook moeten zien dat
het script backupserver zal worden uitgevoerd:

udevadm_test: run: '/usr/bin/backupserver sdc1'

Wanneer je nu je USB disk ontkoppelt en weer aansluit zou het script
/usr/bin/backupserver moeten worden uitgevoerd. Dit script zal
waarschijnlijk nog niet correct werken aangezien zenity toegang wil
tot een Xorg server en dit niet zomaar is toegestaan.
Dit probleem is het makkelijkst op te lossen door
te zorgen dat wanneer de gebruiker inlogt het commando xhost + wordt gedraaid
en in het script /usr/bin/backupserver de shell-variabele DISPLAY juist wordt
ingesteld (meestal volstaat export DISPLAY=:0.0).

Een goede systeembeheerder maakt scripts. Scripts om zoveel mogelijk van z’n
taken te automatiseren. Dat is fijn want dan kan de systeembeheerder zich
namelijk met nuttiger dingen bezig houden.

Soms is echter een taak niet volledig te automatiseren en is er
gebruikersinteractie nodig.
Nu kan dat natuurlijk via een tekstuele interface en soms is dat ook de enige
mogelijkheid. Maar wanneer je in een grafische omgeving werkt dan vind ik zo’n
tekstuele interface toch wel een beetje oubollig en mis ik bijvoorbeeld
de mogelijkheid
om notificaties via de desktop naar de gebruiker te sturen.

Een voorbeeld van een script waarbij grafische gebruikersinteractie erg
wenselijk is, is het backupscript dat ik gebruik om laptops te
backuppen op een externe USB harddisk. Gebruikers moeten zelf voor de backup
de externe harddisk aansluiten. De backup-procedure start dan automatisch maar
het tijdig aansluiten van de externe harddisk vergeten ze natuurlijk. Dus ze moeten
hierop gewezen worden. Ik gebruik een script dat controleert hoe lang het
geleden is dat er een backup is gemaakt. Als dat langer dan
zoveel dagen geleden is dan moet de gebruiker hier een melding van krijgen als
hij is ingelogd op zijn systeem.

De tool die ik voor de grafische gebruikersinteractie gebruik is Zenity.
Er zijn alternatieven, maar zenity integreert nu eenmaal erg goed met de GNOME
of KDE
desktop omgeving.
Zenity heeft een scala
aan opties, zie de manpage voor een overzicht.
Voor mijn backup-oplossing heb ik er maar een paar nodig en zal ik wat
voorbeelden geven hoe ik in bepaalde situaties zenity gebruik voor de
gebruikersinteractie.

• Bij problemen moet de gebruiker op de hoogte worden gesteld en eventueel worden verzocht het probleem te verhelpen.
  Bijvoorbeeld wanneer de harddisk niet toegankelijk is. Dit kan met zenity als volgt:

zenity --question --title="Backupdisk niet toegankelijk" \
--text='De backupdisk is niet toegankelijk.
Koppel de disk en klik vervolgens op "Ga door" om verder te gaan.' \
--cancel-label='Stoppen' --ok-label='Ga door'

Op basis van de exit-code kunnen we dan achterhalen wat de gebruiker heeft
geantwoord. Exitcode 1 voor “Stoppen” en 0 voor “Ga door”.

• Het script zal ook weleens een notificatie moeten kunnen sturen naar de gebruiker.
  Bijvoorbeeld wanneer de backup klaar is. Het volgende zal de notificatie in
  het panel van de desktop laten zien:

zenity --notification --window-icon=/usr/share/pixmaps/gnome-note.png \
--text "De backup is klaar. U mag de backupdisk nu ontkoppelen"

Ik vind dit zelf echter onvoldoende opvallen en een wat meer in het oog
springende oplossing is de volgende:

zenity --info --text "De backup is klaar. U mag de backupdisk nu ontkoppelen"

Dit zal een notificatie midden op het scherm tonen. Backups zijn nou eenmaal
belangrijk.

• Tijdens het maken van de backup wil ik graag weten wat de vorderingen zijn.
  Hier heeft zenity een mooie optie voor genaamd --progress. Je dient dan via de
  standard input het percentage aan te geven en zenity zal dan de
  progression-bar netjes aanpassen. Een voorbeeld van het gebruik is als volgt:

for i in $(seq 1 100)
do
    echo "${i}"
    sleep 1
done |  zenity --percentage=0 --progress --title "Backup wordt gemaakt" \
--text='Backup is in gang gezet.\nNiet de disk ontkoppelen tijdens het \
backup proces!'

Nadeel is dat het niet altijd mogelijk is om de progressie-bar netjes te updaten tijdens de backup-procedure.
Wanneer je de bestanden die zijn gekopieerd in een lijst wilt zien, kun je de --list
optie gebruiken als volgt:

zenity --list --title "Backup wordt gemaakt" --text='Backup is in gang gezet.
Niet de disk ontkoppelen tijdens het backup proces!' --column "Files" < /tmp/gebackupt

Hierbij moet je vervolgens ervoor zorgen dat het bestand /tmp/gebackupt steeds
de actuele lijst met bestanden die zijn gebackupt bevat. Zenity leest de
updates dan steeds in en toont deze dan in een grafisch scherm. Het scherm
heeft vervolgens een Cancel en OK knop. Ook hier kunnen we dan weer op basis
van de exitcode achterhalen welke knop de gebruiker heeft ingedrukt.

Volgende keer zal ik laten zien hoe ik zenity in mijn backup-script toepas.

AT Computing heeft enige tijd geleden besloten
over te gaan op een compleet nieuwe infrastructuur. Het gewone, bekende
spul, zoals een SAN, virtualisatie en Linux.

Nu heb ik aardig wat van die systemen ingericht en geconfigureerd en ik wilde
op een duidelijke manier kunnen zien op welke server ik zat. Nu kan dat in de
prompt en op allerlei andere manieren, maar mij leek het leuk om dat voor het
daadwerkelijke inloggen te doen. Met SSH is het mogelijk om in de
configuratie te zetten dat er voor het inloggen een banner wordt getoond. Dit
is van oorsprong bedoeld om juridische teksten over het gebruik van het systeem
te tonen, maar dat kun je natuurlijk ook voor andere zaken gebruiken.

Nu alleen nog de inhoud van de banner file. Hiervoor heb ik het
programma Figlet gebruikt en wanneer ik nu
inlog op de server zou het er zo uit moeten zien:

 _ __ ___  _   _ ___  ___ _ ____   _____ _ __
| '_ ` _ \| | | / __|/ _ \ '__\ \ / / _ \ '__|
| | | | | | |_| \__ \  __/ |   \ V /  __/ |
|_| |_| |_|\__, |___/\___|_|    \_/ \___|_|
           |___/

Maar zo af en toe als ik in log staat er niet wat ik verwacht, maar

 _ __ ___  _   _ ___  ___ _ ____   _____ _ __
| '_ ` _ \\| | | / __|/ _ \\ '__\\ \\ / / _ \\ '__|
| | | | | | |_| \\__ \\  __/ |   \\ V /  __/ |
|_| |_| |_|\\__, |___/\\___|_|    \\_/ \\___|_|
           |___/

Nou, dat is niet wat ik bedoel. Alle backslashes worden verdubbeld en ik weet
nog niet waarom. Discussie met collega’s stuurde me richting het programma
mingetty, omdat dat de inlog procedure afhandelt. Op ons CentOS 5.4 systeem
staat in de source code van mingetty

if ((fd = fopen (ISSUE, "r"))) {
    while ((c = getc (fd)) != EOF) {
        if (c == '\\')
            output_special_char (getc(fd));
        else
            putchar (c);
    }
    fflush (stdout);
    fclose (fd);
}

dus dat zou het best wel eens kunnen zijn.

Om nu niet direct mingetty opnieuw te compileren en allerlei andere
problemen te veroorzaken, heb ik als eerste test een mingetty escape
code in de banner file opgenomen. Bij het inloggen werd die niet
door mingetty geparsed, dus dat kon de oorzaak niet zijn. Even verder
nadenkend kwam ik tot de conclusie dat mingetty in het hele spel niet
voor komt en dat dit dus een dood spoor is.

Dan zijn er niet meer zo heel veel opties over.

Uit de OpenSSH server source code bleek duidelijk dat daar het probleem niet
kon zitten, omdat deze de banner file met een ‘atomic write’ naar de
overkant stuurt. Daar zit dus geen enkele vorm van processing tussen.

Maar als het de server niet is, dan misschien de client. Verder zoekend in
de source code toonde aan dat hier het probleem zou moeten zitten.
In de file sshconnect2.c staat (in mijn versie, OpenSSH version 5.3p1) de
functie input_userauth_banner die de banner laat zien die door de server
gestuurd wordt. Op regel 417 staat:

strnvis(msg, raw, len * 4 + 1, VIS_SAFE|VIS_OCTAL);

Dus
“unsafe” characters en “octal” tekens worden gecodeerd. De manual pagina van
strnvis zegt:

There is one additional flag, VIS_NOSLASH, which inhibits
the doubling of backslashes and the backslash before the
default format

Ik heb de regel dus veranderd in

strnvis(msg, raw, len * 4 + 1, VIS_SAFE|VIS_OCTAL|VIS_NOSLASH);

en daarna SSH opnieuw gecompileerd. Als ik nu met deze nieuwe client
inlog in de nieuwe server, dan is het probleem spoorloos verdwenen.

Toen ik dit probleem als bug report wilde aanmelden bij de OpenSSH
ontwikkelaars bleek dat ongeveer een uur voor mij iemand anders dezelfde
bug en patch al had ingediend. Het probleem zal worden opgelost in
versie 5.4, maar het kan wel even duren voordat het in de distributies
beschikbaar is.