Zondag 10 oktober 2010 is het weer zover, dan ziet Ubuntu 10.10 het daglicht. Enkele weken voor de gebruikelijke datum in de releasecycle, maar de vreugde zal er misschien niet minder om zijn. De release candidate is afgelopen week beschikbaar gekomen dus werd het tijd om te kijken hoe Ubuntu er voor staat. Ik kan al wel vast verklappen dat ik gemengde gevoelens heb, maar toch mogelijkheden zie voor Ubuntu.
Jarenlang heeft Canonical getracht om Ubuntu op een CD te persen en out of te box alles aan de praat te hebben voor de gebruiker. Dit lukte al jaren redelijk goed door oa opties te beperken, maar nu is de installatiemethode nog verder te zijn versimpelt. De vraag blijft alleen waarom Ubuntu niet standaard voor /home een apart volume aanmaakt en machines standaard niet laat synchroniseren via NTP.
Verder zie lijkt Canonical met Ubuntu goed te hebben gekeken naar Google en Apple, want Ubuntu lijkt langzaam het appliancemodel te volgen waarbij data wordt opgeslagen bij bv Ubuntu One. Muziek is daar een voorbeeld van, maar ook contactgegevens uit oa Evolution. Dit is wel een punt wat mij doet twijfelen of dat wel een goed idee is. Zeker met de speeches over de freedom-box nog in het achterhoofd.
Het andere punt is dat Ubuntu prettige verschijning moet worden. Het nieuwe Ubuntu font is tegenwoordig standaard actief en hoewel er toch iets mis mee lijkt te zijn geeft het wel een prettig beeld om naar te kijken. Maar dit geldt ook voor het standaard thema welke bij de vorige release de standaard is geworden. Veel punten zijn aangepakt waardoor het geen donkere brei meer lijkt te zijn en meer contrast heeft. Helaas is er nog veel te verbeteren op zowel het gebied van de interface als de interactie met gebruiker, maar hier in een latere posting meer over.
De technische verbeteringen bij deze release zijn een update naar GNOME 2.32 en Linux 2.6.35. Ook wordt bij deze release een applicatie ingeruild voor een andere applicatie en dat is deze keer F-Spot die wordt vervangen door Shotwell. Het is te hopen dat bij de volgende release van Ubuntu Tomboy wordt ingeruild voor Gnote zodat er ruimte vrij komt op de installatie CD doordat dan de noodzaak voor Mono op de installatie CD ontbreekt. Hopelijk worden de plannen voor 11.04 in de komende maanden definitief en kunnen we zien wat de toekomst gaat brengen.
Toch ben ik wel te spreken over deze Ubuntu release en doet me mogelijk Debian Testing toch inruilen voor Ubuntu op de desktop. Het is een redelijke balans tussen recente software, weinig wijzigingen, maar ook goed bruikbaar voor iedereen op vele hardware combinaties. Dit is misschien ook het sterke punt van Ubuntu, elke zes maanden een release met duidelijke plannen vooraf waar de gemeenschap aan kan meewerken. We zullen zien hoe de release volgende week zondag verloopt.
Sinds enige tijd doe ik mee aan de IPv6-pilot van XS4ALL om gebruik te kunnen maken van IPv6 zonder dit via een extra tunnel te doen. In een recente update, versie 54.04.81-17599, voor oa de Fritz!Box 7270 van AVM is de ondersteuning voor RFC 5006 goed aangepakt. Helaas staat deze optie standaard uit, maar wel begrijpelijk om potentiële problemen te voorkomen met minder goed werkende netwerk hardware. Gelukkig zijn zowel MacOS X als vele Linux distributies klaar voor RFC 5006.
De vraag alleen is wat heb je aan RFC 5006? Het ligt eigenlijk in de provisioning van de nameservers die kunnen worden gebruikt als resolver. Met de komst van IPv6 is een DHCP-server eigenlijk niet meer nodig en blijft de vraag over hoe je sommige configuratie-items gaat zetten. En hoewel RFC 5006 een smerige hack lijkt is het eigenlijk wel netjes, want er zijn voorzieningen om bepaalde uitgiften te laten ondertekenen in IPv6. Hiermee gebruikt de client alleen gegevens met het juiste signature en is het eigenlijk veiliger dan vele DHCP-oplossingen die nu binnen bedrijven staan, maar een daadwerkelijke bruikbare oplossing laat nog op zich wachten.
Het aan de praat krijgen op bv Debian of Ubuntu is vrij simpel met de volgende opdracht.
$ sudo apt-get install rdnssd resolvconf
Als je nu reboot en kijkt in /etc/resolv.conf krijg je bv het volgende te zien:
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver fd00::21f:3fff:fe30:4ff0
nameserver 192.168.178.1
search fritz.box
Wat nu nog overblijft is NTP wat met behulp van NTP-broadcasting gedaan zou kunnen worden, maar hier kleven wel nadelen aan. Want hoe kan je de broadcaster vertrouwen dat hij de juiste tijd geeft? Hoor ik hier een oplossing in DNSSEC?
Bij het lezen van idee #25103 op de Ubuntu Brainstorm-site kwam de vraag hoever Debian dit nu heeft opgelost. Zeker aangezien Debian de moederdistributie van Ubuntu is en ze enige tijd geleden al waren overgegaan op een GeoDNS oplossing voor sommige sites.
Een brand, een zware verstoring en een update van OpenOffice.org heeft ervoor gezorgd dat model van security.debian.org anders moest. Het moest van een enkele server naar een schaalbare oplossing gaan zonder daar de gebruikers mee op te zadelen. Dit is gelukt aangezien security.debian.org nu mbv GeoDNS en HTTP-polling voor iedereen bereikbaar is gemaakt door een bereikbare mirrorserver in de buurt van het gebruiker aan te bieden.
Voor de algemene repository is de urgentie wat minder groot, omdat de gebruiker zelf kan kiezen in welk land de mirrorservers moeten worden benaderd. De vraag blijft of deze manier blijft schalen, want er zal altijd wel ergens een server onbereikbaar zijn door werkzaamheden. De Nederlandse mirror is daar geen uitzondering van, maar voor gratis hosting moet je iets over hebben. En waarom zou een andere server dit werk niet “transparant” kunnen overnemen?
Een klein project loopt nu om te testen of te kijken wat de meest ideale manier is om dit ook voor de normale mirrors van de repository te doen. Gelijk komt hier het probleem naar voren dat niet alle mirrors alle architecturen aanbieden, maar iedereen met een i386 of amd64 installatie zou overal zijn packages moeten kunnen krijgen. De aanpassing aan sources.list zoals hieronder is vrij simpel.
deb http://cdn.debian.net/debian/ testing main
deb-src http://cdn.debian.net/debian/ testing main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main
Nu al enige tijd staat cdn.debian.net in mijn configuratie voor APT en ik moet zeggen dat ik voorlopig tevreden ben. Hopelijk wordt dit project verder uitgewerkt en opgenomen in zeg Debian 7.0, maar dan moet 6.0 wel eerst uitkomen natuurlijk.
In de afgelopen periode is SpamAssassin al meerdere malen aanbod gekomen en vooral in de context met Bayesian-filtering, maar er is nog veel meer. Zeker nu recentelijk release 3.3 het daglicht heeft gezien wordt het tijd om eens wat dieper in SpamAssassin te duiken.
Een van de grootste probleempunten met SpamAssassin was altijd de ruleset en de strijd met de spammers om die rules net te omzeilen. Bayesian-filtering lost een deel van dit probleem op, maar het andere probleem is de ruleset zelf. Voorheen werden rules met SpamAssassin meegeleverd en werden ze pas bijgewerkt als je een nieuwe versie van SpamAssassin installeerde. Het mag duidelijk zijn dat dit een onbegonnen strijd is, maar ook een gevaarlijke strijd. Zeker voor installaties die afhankelijk waren van DNS blacklists cq whitelists en waarbij de beheerder van de lijst besloot om zijn lijst op te heffen bijvoorbeeld.
De SARE-regels zijn een hele tijd populair geweest en zijn dat helaas nog steeds. Dit terwijl ze stelselmatig worden opgenomen in de ruleset van SpamAssassin zelf. Gelukkig heeft oa SARE er wel voor gezorgd dat er een update methode kwam die met de 3.3 release verplicht is geworden. Hiermee volgt SpamAssassin eigenlijk ClamAV in de voetsporen en is het verspreiden van een vaste ruleset overbodig geworden.
De eerste stap is eigenlijk heel simpel met het draaien van het commando sa-update als de gebruiker root op Debian. Als we nu in /var/lib/spamassassin/ kijken dan zien we het volgende:
$ ls -l /var/lib/spamassassin/ /var/lib/spamassassin/*/
/var/lib/spamassassin/:
total 8
drwxr-xr-x 3 root root 4096 2010-01-02 14:46 3.002005
/var/lib/spamassassin/3.002005/:
total 8
drwxr-xr-x 2 root root 4096 2010-01-02 14:46 updates_spamassassin_org
-rw-r--r-- 1 root root 2431 2010-01-02 14:46 updates_spamassassin_org.cf
We zien netjes de betreffende versie van SpamAssassin en in die directory de ruleset zoals die nu voor versie 3.2.5 wordt aanbevolen door SpamAssassin. Deze regels worden automatisch meegenomen als SpamAssassin de volgende keer start. Nu kan je zelf een paar regels in de crontab van de gebruiker root zetten, maar in Debian zijn al voorzieningen getroffen. Door het onderstaande aan te passen in het bestand /etc/dedault/spamassassin zal automatisch de sa-update worden gedaan en wanneer nodig SpamAssassin worden geherstart.
CRON=1
Helaas stopt hier het verhaal niet, want op dit moment worden services zoals Amavisd-new, die ook de SpamAssassin ruleset kan gebruiken, niet herstart. Op moment van schrijven staan bugs 315961 en 567205 hier nog over open. Totdat die zijn opgelost kan de volgende extra code geen kwaad aan het einde van /etc/cron.daily/spamassassin
test -f /var/run/amavis/amavisd.pid && /etc/init.d/amavis force-reload
Dit laatste is natuurlijk op eigen risico, maar het lost de bug voor mij al een redelijke tijd op.
Bij de introductie van Linux 2.6.32 is blijkbaar besloten om anders om te gaan bij bumps in de ABI en DKMS reageert daar nog niet goed op. Helaas merk je dit bij oa VirtualBox vrij snel en zo te zien zijn ze er nog niet uit hoe ze oa bug #563246 gaan oplossen. Het onderstaande commando zorgt voorlopig voor de juiste triggers om de modules opnieuw te laten genereren.
$ sudo apt-get install --reinstall virtualbox-ose-dkms
Misschien wordt het tijd om strikter de testing-tree te gaan volgen nu de freeze voor Debian 6.0 onderweg is.
Recent Comments