Voorbereiden voor DNSSEC

Hoewel DNSSEC eigenlijk op mijn todo-lijst stond voor over een paar maanden als PowerDNS daadwerkelijk ondersteuning zou krijgen, maar helaas is daar verandering in gekomen door recente ontwikkelingen. Zeker nadat er serieuze problemen zijn ontdekt waardoor vrij snel nameservers die acteren als resolver kunnen worden voorzien van valse data. En hoewel er voorlopig tijdelijke oplossingen zijn is een echte oplossingen eigenlijk alleen DNSSEC.

Aangezien DNSSEC ondersteuning bij PowerDNS en NSD beperkt is blijft voorlopig alleen Bind over als bruikbare optie aangezien het wel crossplatform moet werken. Bind is en blijft de defacto-standaard op bijna elke Unix-platform zoals HP-UX, Solaris, AIX, BSD en vele Linux-distributies. Ook omdat dit de referentie implementatie is van bijna elke RFC gerelateerd aan DNS.

Een eerste probleem dook al op bij de eerste testen, want goede entropy gaat een probleem vormen. De normale pseudogenerator voor deze getallen is blocking totdat er weer voldoende random getallen zijn, maar helaas kan het dus even deuren voordat er onvoorspelbare sleutels zijn. Een alternatief is om de non-blocking pseudogenerator te gebruiken welke vrij snel getallen kan opleveren, maar deze kunnen voorspelbaar zijn door hergebruik van oude getallen. Als dit laatste gebeurt zijn we weer terug af bij waar we begonnen zijn met de huidige DNS-problemen.

Voor deze problemen zal een oplossing moeten worden gezocht welke hoogstwaarschijnlijk in de vorm van hardware zal gaan zijn om aan de vraag van willekeurige getallen te kunnen voldoen. De eerste apparaten die lijken te voldoen zijn ongeveer 100 euro per stuk wat een redelijke prijs is. Nu wordt het uitzoeken of deze worden ondersteunt onder oa Linux en Solaris, maar hopelijk zijn er andere oplossingen zeker nu het kernel cryptographic framework vormt heeft gekregen in Solaris 10.

Een paar MB besparen

Geheugen is goedkoop wordt vaak geroepen, maar is dat wel zo? Soms moet je dan volledige nieuw geheugen kopen om te kunnen uitbreiden. Of er is geen mogelijkheid om uit te breiden zoals bij steeds meer mini-ITX systemen het geval is waarbij de Mac Mini mogelijk het bekenste voorbeeld wel mogelijk is. Of omdat geheugen toch niet zo goedkoop blijkt te zijn voor je drie jaar oude computer omdat men nu ineens de hoofdprijs wil hebben voor een paar reepjes geheugen.

Gelukkig zit er in sommige systemen nog wel wat ruimte om zonder aanpassingen aan de hardware er wat meer performance uit te krijgen. Bij veel Linux-distributies heb je de mogelijkheid om virtuele consoles te gebruiken, maar bijna niemand gebruikt deze virtuele consoles nog terwijl ze wel draaien. Dit terwijl je gelijktijdig bijvoorbeeld KDE of GNOME gebruikt en het is misschien een paar een megabyte, maar het is wel voldoende om /var/run in geheugen te houden.

In het bestand /etc/inittab kom je het volgende tegen:

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

En door dit te veranderen naar:

1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2
#3:23:respawn:/sbin/getty 38400 tty3
#4:23:respawn:/sbin/getty 38400 tty4
#5:23:respawn:/sbin/getty 38400 tty5
#6:23:respawn:/sbin/getty 38400 tty6

Als men nu een `kill -HUP 1` doet of reboot dan zal er nog maar een console overblijven welke kan worden gebruikt in geval van problemen. Maar de overige virtuele consoles zijn gestopt en nemen nu niet meer een paar honderd kilobyte per console in beslag. En dit is iets wat soms net het kleine beetje kan zijn om wat oudere of kleinere machines snel te houden.

Linux gaat groen

Ben nooit zo’n voorstander geweest van daemons om processor frequency scaling te gaan regelen en bij wat onderzoek blijken deze ook niet nodig te zijn gelukkig. De Linux kernel kan geheel zelfstandig voor dit je regelen en bespaart dus ook weer op geheugen en processortijd. Gelukkig is het opzetten niet zo bijzonder lastig en op Debian moet je alleen package sysfsutils installeren voordat je begint.

Als eerste stap is het laden van de module welke de processor kan aansturen om de snelheid aan te passen. In mijn geval is dat p4-clockmod omdat ik nog een oudere Pentium 4 processor heb, maar als je zoekt in de directory /lib naar de directory cpufreq dan kon je andere modules ook tegen. De andere module is cpufreq_ondemand en waarom wordt later duidelijk.

Plaats deze modules in /etc/modules:

p4-clockmod
cpufreq_ondemand

Nu moet nog worden duidelijk gemaakt welke policy er gebruikt moet worden als de machine opstart. En hoewel dit per processor-core is in te stellen heb ik dit alleen gedaan voor cpu0, omdat cpu1 een hyperthread is en daarmee afhankelijk is van cpu0. Het is dus belangrijk om dit voor elke fysieke processor-core in te stellen. Een tweede wat ik heb ingesteld is een ondergrens, want mijn huidige processor doet er te lang over om de snelheid te verhogen. Dit is een probleem in de Pentium 4 processoren en lijkt 1200 MHz een goede snelheid als ondergrens, maar moderne processoren zouden hier geen last van moeten hebben.

Plaats de regels in /etc/sysfs.conf:

devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu0/cpufreq/scaling_min_freq = 1200000

Nu is het enige wat nog nodig is is een reboot om alles te activeren of je met de aanpassingen met de hand activeren, maar een reboot is vaak makkelijker. Je zal in /proc/cpuinfo nu de actuele snelheid van je processor zien. En als je hier vanaf wilt dan zet overal een hash-teken voor en reboot.

Maar waarom geen daemon en alleen de policy ondemand? Er wordt gesteld dat de snelheid moet worden beperkt vanwege hitte productie, maar dit is iets wat de kernel moet oplossen en ook daadwerkelijk doet gelukkig. Zeker als je bedenkt dat een kernel altijd alle triggers heeft om dit te bewerkstelligen, maar ook de juiste prioriteiten heeft om dit uit te voeren waneer het nodig is. Een proces in userland kan bijvoorbeeld niet de juiste prioriteit krijgen of toevallig naar disk zijn verplaatst omdat het geheugen nodig was.

Een andere stelling is dat een lagere snelheid altijd bespaart, maar is dat wel zo? De mensen van lesswatts.org hebben er een mooi voorbeeld over wat misschien nog wel wat wenkbrauwen zal doen fronzen. Daarbij wil je je performance beperking en zeker nu de tickless kernel zijn intrede heeft gedaan om de processor zoveel mogelijk in idle-stand te brengen om daadwerkelijk energie te besparen.

Muziek op USB-storage

Het multimedia geweld werd altijd gezien als een probleem op Linux, want het was moeilijk en je moest cryptische dingen overtypen. Maar dit tijdperk is al een geleden tijd afgesloten met de komst van oa HAL en D-BUS welke een abstractielaag vormen om automatisch bijvoorbeeld een muziek CD-ROM te starten of je USB-storage beschikbaar te maken. Projecten zoals GNOME en KDE maken dankbaar gebruik van deze functionaliteit wat direct merkbaar is voor de gebruiker.

Een praktisch voorbeeld hiervan is je muziekverzameling op USB-storage welke netjes bruikbaar is in bijvoorbeeld Rhythmbox. Maak een bestandje aan met de naam .is_audio_player op het hoogste niveau van het USB-storage device en vul deze met de volgende inhoud:

audio_folders=MUSIC/,RECORDINGS/
folder_depth=3
output_formats=application/ogg,audio/x-ms-wma,audio/mpeg

Elke keer als je dit USB-storage device in een computer steekt welke de specificaties van freedesktop.org begrijpt zal oa je muziekspeler op de hoogte worden gebracht. Dit kan zijn bij je eigen Linux-desktop of de FreeBSD-desktop bij een kennis, maar ook je Sun Solaris-workstation op je werk. Het begint er op te lijken alsof computers eindelijk makkelijk beginnen te worden voor de normale gebruiker.

Geheugen filesystem onder Linux

Onder Solaris zijn geheugen gebaseerde filesystemen al jaren gemeengoed en zo zijn bijvoorbeeld /var/run en /tmp de meest bekende filesystemen die in geheugen worden gehouden. Linux heeft ook al flink wat jaren ondersteuning voor geheugen gebaseerde filesystemen, maar lijkt niet echt voorstanders te vinden binnen de gemeenschap. Dit terwijl er voordelen zijn omdat geheugen sneller toegankelijk is dan disk en de prijs van geheugen zorgt ervoor dat je eigenlijk niet meer op geheugen hoeft te beknibbelen.

Het eerste voorbeeld versnelt veel Linux-machines bij onder andere het stoppen en starten van het systeem, maar geeft ook minder disk IO. Veel processen schrijven een PID-file weg in de directory /var/run voor eigen gebruik of door andere applicaties. Dit is zinloze ruimte eigenlijk, want deze files zijn alleen van toepassing voor de machine in de huidige staat en hoeven dus ook geen reboot te overleven.

We voegen de onderstaande regel toe aan /etc/fstab en reboot hierna om alles files in /var/run correct op de nieuwe locatie te krijgen. Maar wat doet deze regel nu echt. Het zorgt ervoor dat er een geheugen gebaseerd filesysteem van maximaal 4MB wordt gemount op /var/run met de correcte permissies en de noexec flag. Deze laatste is niet nodig maar zorgt ervoor dat niemand daar een bestand kan plaatsen en dan kan executen.

/dev/shm   /var/run   tmpfs noexec,size=4m,mode=0755,uid=0,gid=0 0 0

Een andere plek waar veel te winnen is /tmp en zoals FHS aangeeft hoeven bestanden op deze locatie een reboot niet te overleven. Er is alleen wel een uitdaging met /tmp dat de juiste grote wordt gekozen om problemen met ruimte te kort te voorkomen. In dit voorbeeld zijn de beperkingen op wat mag met dit filesysteem wat scherper gezet en behoeft bij oa Debian wat aanpassingen aan APT. Ook is er een limiet gezet van maximaal 256MB, maar deze kan online met een remount worden vergroot en verkleint.

/dev/shm   /tmp   tmpfs noexec,nosuid,nodev,size=256m,mode=7777,uid=0,gid=0 0 0

Wat levert het op? Minder disk IO en iets snellere applicatie, want een gemiddelde disk haalt z’n 20MB per seconde en hedendaags geheugen als minimaal 1800MB per seconde. Dit is dan ook iets wat voor applicaties met veel tijdelijke bestanden zoals bij amavisd-new een grote performance impact kan hebben. Ook levert dit inzichten op om te kijken of Linux zonder disken kan werken of met een minimale disktoegang mogelijk is. Iets wat nu bij Flashdrives al een voordeel heeft om de levensduur te verlengen van een Flashdrive door het aantal writes te beperken.

Het levert ook besparing qua energie en warmte op doordat disken meer in idle-state kunnen verkeren en zometeen als Linux 2.6.25 a 2.6.26 beschikbaar komen ook de SATA-link op een lager vermogen kunnen laten draaien. Dit laatste is nog vrij experimenteel, maar de technologie is er en komt beschikbaar. Ik gebruik de technologie van geheugen gebaseerde filesystem nu al een tijdje en de machines zijn stiller geworden omdat er minder vaak naar disk wordt geschreven.