Ik maak voor mijn clients thuis geen gebruik van een bepaalde distributie en compileer alle software zelf. Dit betekent dat bij mij niet alles zomaar werkt. Een voorbeeld van iets dat niet meteen werkte was het gebruik van een USB muis. Ik gebruikte altijd een PS/2 muis en configureerde Xorg via het configuratiebestand /etc/X11/xorg.conf om de PS/2 muis te gebruiken. Bij de nieuwere versies van Xorg is het configuratiebestand niet meer nodig en ik besloot met de aanschaf van een USB muis meteen over te stappen op de automagische configuratiemethode van Xorg. Ik zal hieronder kort beschrijven wat er nodig is om hotplugging van input-devices onder Xorg aan de praat te krijgen.

Voor hotplugging van input-devices (USB muizen, keyboards, enz.) zijn op dit moment vier componenten van belang op een Linux systeem. Namelijk, de kernel, udev, d-bus, en HAL. De kernel heeft de taak om nieuwe hardware te detecteren. Udev heeft als taak voor de gedetecteerde hardware een device-file (indien nodig) in /dev aan te maken. HAL heeft de taak om de gedetecteerde hardware te identificeren en programma's (zoals Xorg) op de hoogte te stellen dat een bepaald type hardware is aangesloten en hoe deze aangesproken kan worden. De D-bus wordt gebruikt voor de communicatie tussen udev, HAL en programma's die geïnteresseerd zijn in de gedetecteerdehardware.

Ik gebruik momenteel de volgende versies van bovengenoemde software:

• kernel 2.6.25.9
• udev 1.13
• HAL 0.5.13
• D-Bus 1.2.16
• Xorg 7.4

Voor de kernel moet ondersteuning voor USB (uhci, ehci) en voor input-devices (Human Interface Devices) worden aangezet. Daarnaast moet ook de "Event interface" worden aangezet. Dit laatste levert device nodes in /dev onder de naam eventX waarbij X dan een nummer is. Via deze device nodes worden dan events van input-devices toegankelijk gemaakt voor bijvoorbeeld de X server. Voor udev dienen we de juiste regels in /etc/udev/rules.d/ toe te voegen zodat de eventX device-files worden aangemaakt. Gelukkig voldoen de standaard bijgeleverde regels van udev. Ik sluit de muis aan en kijk met udevmonitor wat de kernel en udevd voor events uitzetten.

bash-3.2# udevmonitor
udevmonitor will print the received events for:
UDEV the event which udev sends out after rule processing
UEVENT the kernel uevent

...
UEVENT[1265218519.642876] add /devices/pci0000:00/0000:00:10.3/usb5/5-1/5-1:1.0/input/input8/mouse0 (input)
UEVENT[1265218519.659071] add /devices/pci0000:00/0000:00:10.3/usb5/5-1/5-1:1.0/input/input8/event4 (input)
...
UDEV  [1265218519.734160] add /devices/pci0000:00/0000:00:10.3/usb5/5-1/5-1:1.0/input/input8/mouse0 (input)
UDEV  [1265218519.738460] add /devices/pci0000:00/0000:00:10.3/usb5/5-1/5-1:1.0/input/input8/event4 (input)

Ah kijk, daar zien we dat er een input-apparaat wordt gedetecteerd. De udev daemon (udevd) heeft er blijkbaar ook een regel voor (anders zouden we de UDEV regel niet krijgen). Als je wilt zien welke acties udevd allemaal uitvoert op basis van een kernel event (UEVENT) kun je bovenstaande UEVENTs als argument opgeven aan udevtest. Je krijgt dan een hoop tekst te zien maar voor het apparaat waar het hier om gaat is alleen het volgende echt van belang:

bash-3.2# udevtest /devices/pci0000:00/0000:00:10.3/usb5/5-1/5-1:1.0/input/input8/event4
...
udev_node_add: creating device node '/dev/event4', major=13, minor=68, mode=0660, uid=0, gid=0
...

In bovenstaand voorbeeld zien we dat de juiste device-file wordt aangemaakt. Xorg zal dit bestand uitlezen om erachter te komen hoe de muis wordt bewogen. De device-file is een character device en we kunnen deze met bijvoorbeeld met het commando cat uitlezen:

bash-3.2# cat /dev/event4

Als we dan de muis bewegen worden er een heleboel rare karakters op het scherm getoond. Mij zeggen deze karakters niets, maar Xorg weet er hopelijk wel raad mee.

Dit is veel belovend dus ik start Xorg op en probeer de mouse pointer te bewegen over het scherm. Helaas geen beweging in te krijgen. Dat wordt verder puzzelen. Problemen oplossen is vooral het uitsluiten van mogelijke oorzaken. De kernel detecteert de muis en udev pikt het ook op. Dus daar hoef ik me niet op te concentreren. Wellicht dat HAL het apparaat nog niet juist herkend. Eens even kijken of mijn muisje wel wordt opgepikt door HAL.

# hal-device | grep 'input.'
0: udi = '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial_0_logicaldev_input'
  info.category = 'input'  (string)
  info.capabilities = { 'input', 'input.mouse' } (string list)
  input.originating_device = '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial_0' (string)
  input.device = '/dev/event4'  (string)
  input.product = 'Kensington USB Mouse'  (string)
  linux.subsystem = 'input'  (string)
  input.x11_driver = 'evdev'  (string)
  info.subsystem = 'input'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_ffffffff_ffffffff_noserial_0_logicaldev_input' (string)
  linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:10.3/usb5/5-1/5-1:1.0/input/input4/event4' (string)

De daemon hald ziet het apparaat dus correct als input-device. Nog even controleren of ik Xorg wel met HAL ondersteuning gecompileerd heb. Dit is het geval, dus daar kan het ook niet aan liggen. Even controleren of de D-Bus daemon wel draait. Ja, die draait ook. Hmmm, tja, dan weet ik het even niet meer. Ik heb een vermoeden dat Xorg nog een module mist, maar welke? Er zit niets anders op dan de alwetende te raadplegen:

http://www.google.com/search?q=Xorg+HAL+input+devices

Ik krijg een aantal sites als resultaat waarvan de volgende:

http://wiki.archlinux.org/index.php/Xorg_Input_Hotplugging

me duidelijk maakt dat Xorg de module xf86-input-evdev nodig heeft voor input hotplugging. Die had ik inderdaad nog niet gebouwd omdat dat in mijn oude setup niet nodig was. Nadat ik de module gecompileerd en geïnstalleerd heb en Xorg opnieuw heb opgestart probeer ik met vol goede moed mijn muisje. Woohoo! Het kruisje beweegt netjes mee met mijn muisje! En dit allemaal zonder /etc/X11/xorg.conf.

De HAL soap

Bovenstaand verhaal over mijn muisje heeft nog een klein staartje. In de toekomst zal ik bovenstaande waarschijnlijk weer op een andere manier moeten doen aangezien HAL wordt uitgefaseerd. HAL is erg monolithisch en lastig te onderhouden. Om dit op te lossen heeft men HAL opnieuw (modulair) ontwikkeld onder de naam devicekit. Echter, devicekit heeft voordat het enigzins gebruikt werd (Ubuntu en Fedora gebruiken het deels) alweer de doodsteek gekregen en men is tot het inzicht gekomen dat de functionaliteit thuis hoort in udev. In de toekomst zal Xorg dan geen gebruik meer maken van HAL of devicekit maar direct udev aanspreken.

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.