DailyStuff

Met de introductie van DeviceKit werden dingen zoals notificatie van defecten aan harddisks ineens mogelijk geworden. Hardware werd toegankelijk voor userland zonder smerige hacks of setuid executables. Voorzieningen om deze notificaties weer te geven werden onderdeel van GNOME bij release 2.28.

Alleen wanneer zie je die notificaties? Achter deze vraag ben ik recentelijk gekomen, want hoewel de RAID weer in orde was besloot een disk om toch een paar extra herallocaties van sectoren. MD besloot om de disk weer uit de RAID-set te gooien en DeviceKit zag dat de threshold van de leverancier voor deze disk werd overschreden. Zolang de disk zichtbaar is blijft de waarschuwing zichtbaar voor de gebruiker tenzij hij of zij deze notificatie uitzet.

Gebruikers krijgen tegenwoordig tijdig een waarschuwing als er structurele fouten optreden en geeft ze een kans om preventief aan de slag te gaan. Zeker met veel disken die je gewoon kan laten omruilen als ze binnen de garantieperiode zitten. Sommige mensen kiezen daar blijkbaar niet voor, maar daar heb ik aan het einde van de dag ook geen medelijden meer mee.

Hoewel de data op de disk was geencrypt met LUKS loopt er nu toch een wipe sessie om de disk een aantal keer te overschrijven met random data. Hierna kan deze terug naar de leverancier en is het wachten op een nieuwe. Dit heeft me ook aan het denken gezet of er plugins voor Nagios zijn of dat ze nog geschreven moeten worden.

In een vorige posting liep er nog een zelftest op een harddisk. De zelftest was na enige tijd klaar en smartmontools leek geen fouten te hebben gevonden of toch wel? Want als het onderstaande ziet dan ziet het er goed uit.

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Maar zodra je verder kijkt in de output van smartctl dan blijken dat er drie sectoren waren die moesten worden vervangen. Nu deze zijn intern zijn vervangen accepteert de RAID-software weer de disk na een volledige synchronisatie.

5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 3

Voor de zekerheid toch eens bij de leverancier eens op de website gekeken en die boden een applicatie voor onder DOS aan of als live CD. Bij controle blijkt die software exact hetzelfde te doen als wat smartmontools doet en werkt ook met S.M.A.R.T. De vraag is dan misschien wanneer Windows deze functionaliteit standaard aan boord krijgt nu dit al jaren bij de Unix’en standaard is.

De vraag die nog wel overbleef was of er ook een interface was die geen root-privileges vereiste, want smartctl moet nu direct met de disk kunnen praten. Gelukkig kan met behulp van DeviceKit ook worden uitgevraagd naar de status van een disk. En ook hier lijkt zoals bij dmidecode er een duidelijke verbetering te komen in de benodigde privileges die nodig zijn.

$ udisks --show-info /dev/sdb
...
ATA SMART: Updated at za 03 apr 2010 15:17:51 CEST
overall assessment: Disk has a few bad sectors

Zal Linux dan toch langzaam aan volwassen worden? Maar tot die tijd blijft smartmontools nog regelmatig de status van de disken controleren om zo problemen snel te detecteren.

Op BSD heb je /etc/mtab en op SVR heb je /etc/mnttab. Vreemd genoeg heeft men bij Linux gekozen voor de BSD oplossing terwijl de rest in de richting van SVR is. De andere vraag is of beide oplossingen nog wel nodig zijn nu ook alle informatie wordt aangeboden via /proc/mounts.

Nu steeds meer informatie netjes via /proc beschikbaar komt op Linux wordt het misschien tijd om oude gewoonten achter ons te laten. Het gebruik van dmidecode is al niet meer nodig en met bugreports worden scripts bij Debian nu omgeschreven om de kernel interface te gebruiken. Hopelijk volgen andere onderdelen ook en wordt /etc weer echt voor configuratie en niet ook voor semi-statische confirgutatie items.

Soms krijg je meldingen die je niet wilt zien. De volgende in de logfiles na een reboot is er z’n eentje:

md: md1 stopped.
md: bind
md: bind
md: kicking non-fresh sdb2 from array!
md: unbind
md: export_rdev(sdb2)
raid1: raid set md1 active with 1 out of 2 mirrors

Op het eerste gezicht lijkt er geen fout te zijn en met md –re-add ging de disk weer terug de array in. En dan wachten totdat de resync klaar was, maar het was sneller klaar dan verwacht. De volgende melding gaf te raden waarom.

ata3.00: exception Emask 0x10 SAct 0x0 SErr 0x40c0202 action 0xe frozen
ata3.00: irq_stat 0x00000040, connection status changed
ata3: SError: { RecovComm Persist CommWake 10B8B DevExch }
ata3.00: failed command: FLUSH CACHE EXT
ata3.00: cmd ea/00:00:00:00:00/00:00:00:00:00/a0 tag 0
res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error)
ata3.00: status: { DRDY }
ata3: hard resetting link
ata3: softreset failed (device not ready)
ata3: applying SB600 PMP SRST workaround and retrying
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata3.00: configured for UDMA/133
ata3.00: device reported invalid CHS sector 0
end_request: I/O error, dev sdb, sector 0
raid1: Disk failure on sdb2, disabling device.
raid1: Operation continuing on 1 devices.

Er zijn duidelijk issues, maar wat precies blijft de vraag. Onder Linux kan met behulp van smartmontools worden gekeken naar de status van een disk en testen doen. Dus het wordt tijd om een long selftest te doen en ook wat informatie op de vragen.

$ sudo smartctl -t long /dev/sdb
$ sudo smartctl -l error /dev/sdb
$ sudo smartctl -l selftest /dev/sdb
$ sudo smartctl -a /dev/sdb

Dit is een redelijk lange testcycle en wachten is voorlopig het enige wat kan gebeuren, maar er lijkt een disk wissel aan te komen binnenkort.

Controle krijgen over een machine en behouden begint door te weten wat er allemaal speelt. Een van de aspecten is om te weten wat er met bepaalde bestanden gebeurt. Windows NT heeft deze functionaliteit al jaren, maar met de komst van de 2.6 kernel is Linux nu ook in staat om auditing op bestanden en directories vast te leggen.

Op veel Linux-distributies is tegenwoordig al de audit-daemon geïnstalleerd en actief, maar vaak ontbreekt er nog een configuratie. Toch beginnen we met het installeren om zeker te zijn dat onze Debian-machine de juiste software heeft.

$ sudo apt-get install auditd audispd-plugins

Nu de machine voorzien is van de juiste software wordt het tijd om aan te geven welke bestanden we willen monitoren voor wijzigingen. In het voorbeeld hieronder gaan we /etc/passwd monitoren op schrijfacties en /etc/shadow op schrijf- en leesacties. En bij controle zien we wat de configuratie is waarmee de auditing draait op het systeem.

$ sudo auditctl -w /etc/shadow -p wa
$ sudo auditctl -w /etc/passwd -p w
$ sudo auditctl -l
LIST_RULES: exit,always watch=/etc/shadow perm=rw
LIST_RULES: exit,always watch=/etc/passwd perm=w

Door nu bv met cat de inhoud van /etc/shadow te tonen kan worden gezien in /var/log/audit/audit.log wat er gebeurt, maar ook wie het doet inclusief welke inode dit is. Het wordt dus tijd om elk bestand met een username/password te gaan monitoren wat er precies gebeurt.