[knip req. for distributed debian upgrader, lack of same on *BSD etc]

Nee, ik wil geen distrowar, iedereen heeft zijn eigen wensen, doelen nutten etc.

Overigens er is ook OpenSSH voor Windows dus die zijn ook de pisang. Wat doen de meesten overigens met hun J doosjes? SSH acl'd?

Wie verstandig is heeft *allang* aan ACL die management/monitoring etc access voor z'n dozen beperkt tot alleen noodzakelijke machines. Dan scheelt een hoop paniek als je leest dat er een bug (of exploit) uit is, maar vooral maakt het je dozen stukken minder kwetsbaar voor een DoS attack. [J's RP hangt met 100Mbit aan de linecards, als ik me niet vergis. En hoe snel kan de RP sshd forken (of hoeveel sshd's maximaal) ? C's GSR's hebben een vergelijkbare beperking. "receive access-list" is daar het magische woord. ] Boudewijn

On Wed, 17 Sep 2003, Jeroen Massar wrote:

(Als iemand een koel docje heeft om makkelijk zonder world overnieuw te builden makkelijk tig bsd doosjes te upgraden, de from: kan gebruikt worden voor hints/faq's/rtfm's en ja ik ken cvsup maar dat is niet echt handig om op elke doos te doen vind ik, imho dus)

Er is wel iets leuks, op 1 doos een buildworld en buildkernel doen, en met nfs /usr/src en /usr/obj op target doos mounten. Daarna op target doos een make installworld en een make installkernel KERNCONF=UNFIX (uiteraard een mergemaster daarna) en je bent klaar. Het kost je dan geen tijd om de wereld zelf te builden op de target doos. -- /- Met vriendelijke groet/With kind regards, -\ <- Peter Batenburg - ProServe B.V. - www.proserve.nl -> \- tel: +31-184-423815 - fax: +31-184-417160 -/

Boudewijn schreef verder:

...

C's GSR's hebben een vergelijkbare beperking. "receive access-list" is daar het magische woord. ]

"ip receive-acl" naar ik begrepen heb. En bij Vendor J is het een kwestie van een input filter op lo0 unit family inet, en los daarvan is er een rate-limit op telnet, ssh etc. in te stellen.

Yups, die inderdaad. details http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guid... Een van de dingen waar ik eens van schrok was dat bij vendor C telnet access-lists (access-class op vty lines), snmp access-lists etc allemaal pas op de RP uitgevoerd worden. Ze zijn dus niet geimplementeerd als onzichtbare access-lists die overal op de linecard/VIP zitten, dat is pas het geval met de ip receive-acl. (en de 'gewone' access-lists, natuurlijk ). Ik ga er trouwens van uit dat naast genoemde vendors C en J de kans bijzonder groot is dat dit type gedrag bij wel meer vendors speelt. (Niels, hoe zit 't met vendor F bv ? ) Boudewijn

On woensdag, sep 17, 2003, at 21:07 Europe/Amsterdam, Boudewijn Visser wrote:

...

Een van de dingen waar ik eens van schrok was dat bij vendor C telnet access-lists (access-class op vty lines), snmp access-lists etc allemaal pas op de RP uitgevoerd worden.

Niet zo raar. Het gros van de produktlijn van Vendor C heeft 1 CPU voor alles, en het design van de software dat ze draaien is weinig veranderd sinds de AGS+, lijkt 't.

Het zou me niet verbazen als het code pad tussen vty access-class en echte access-lists ook op single-CPU platformen dus anders is. (En er ook op 1-CPU C platformen een performance verschil is). Maar ik zou dus gedacht hebben dat die feature gewoon gebouwd zou zijn als normale access-list. Blijkbaar is het dus aan het betreffende proces gehangen.

De vraag voor hen is: hoeveel implementaties van OSPF en BGP en IS-IS willen ze parallel onderhouden? Het antwoord is uiteraard "Zo weinig mogelijk", wat een reden kan zijn voor een monolithic OS, maar misschien liggen de verschillende architecturen nu zodanig ver uit elkaar dat het lonend wordt om het IOS-roer fundamenteel om te gooien en er een echt OS onder te hangen met memory protection en andere nieuwerwetse fratsen van dien.

Ha, dat kan een leuke thread worden, IOS architectuur features en het hoe & waarom , historische bagage etc. (next wishlist item: modulair IOS. 'insmod BGP,IS-IS , rmmod DLSW+ etc). Ik zou wel benieuwd zijn naar een beschrijving van cisco's software development proces & infrastructuur. Ze hebben een behoorlijk aantal geografisch verspreide teams, die vzviw per team een bepaalde feature of driver supporten, over alle versies en platformen. Dan het enorme aantal versies die in principe allemaal gerecreeerd moeten kunnen worden etc. Beslist een niet trivaal source code versioning systeem, en build omgeving. [cue Larry McVoy en hoe uniek BitKeeper is, en hoeveel echt moeilijke problemen er zijn bij wijd verspreide software ontwikkeling die mensen niet zien ... ] Vendor J lijkt (qua joblisting op de website) alle development (nog?) centraal te doen. En heeft natuurlijk een stuk kortere historie, zowel letterlijk als qua legacy platform support.

...

Ze zijn dus niet geimplementeerd als onzichtbare access-lists die overal op de linecard/VIP zitten, dat is pas het geval met de ip receive-acl. (en de 'gewone' access-lists, natuurlijk.)

Je zou denken dat als je ergens - waar dan ook - een access-list zet, het systeem slim genoeg zou moeten zijn om dit te vertalen in de juiste entries in de verschillende TCAM's en dergelijke, maar helaas is de techniek bij de meeste vendors nog niet zo ver.

Om even een item van mijn wishlist te plukken: JunOS mist ook een `prefix-list me' die automatisch gevuld wordt met alle adressen van alle lokale interfaces.

...

(Niels, hoe zit 't met vendor F bv ? )

(welke Niels?) Daar kon je lang maar beter geen incoming access-lists

Die Niels @ams-ix die wel ervaring moet hebben met vendor F ....

doen (of waren het outgoing?) aangezien deze allemaal over de CPU gingen in plaats van in TCAM geprogrammeerd te worden. De SSH-implementatie is gebaseerd op die van F-Secure, dus naar ik vermoed niet vatbaar voor de bug uit het begin van deze thread.

Maar wel het probleem dat elke access naar een lokaal IP adres (bij gebruik als L3 device) hoe dan ook via de CPU loopt, met of zonder acl,of is dat tenminste niet (meer) het geval ? Boudewijn

On woensdag, sep 17, 2003, at 23:09 Europe/Amsterdam, Boudewijn Visser wrote:

...

Het zou me niet verbazen als het code pad tussen vty access-class en echte access-lists ook op single-CPU platformen dus anders is.

Dat is er zeker wel. Maar of het nu op process-niveau in IP Input wordt gedropt of op process-niveau in Virtual Exec maakt niet bijster veel verschil. Pas als je het op interrupt-niveau kan doen (CEF/dCEF - wat verplicht is voor "ip receive-acl") ga je verschil zien.

Klopt, maar ook gewone access-lists (net als ip receive-acl) worden dus (mits niet loggend) via CEF/dCEF behandeld. ip receive-acl is dus niet specialer dan een reguliere access-list die matched op source x.y.z destination <any local IP address> . Wel heel veel handiger om te gebruiken, natuurlijk.

...

Maar ik zou dus gedacht hebben dat die feature gewoon gebouwd zou zijn als normale access-list.

Zoals ik al schreef, er wordt nauwelijks magic juju gedaan met het optimaliseren van access-lists, voor zover ik weet. "ip receive-acl" is een stukje implicit access-list dat bij elke interface applied wordt.

Het ligt eraan wat je magic juju noemt. Intern re-orderen niet, voor zover ik weet. 'compiled access-lists' stoppen ze in een datastructuur zodanig dat de lookup min of meer constant is, en niet meer lineair door alle regels van de acl heen loopt. Maar in elk geval worden reguliere access-lists dus wel CEF-switched. (mits niet loggend). En dat is het grote verschil met de vty access-class, snmp access-lists etc.

Volgens mij herordent JunOS geconfigureerde firewall filters ook om packets niet onnodig door het chassis te sturen.

[..]

...

(next wishlist item: modulair IOS. 'insmod BGP,IS-IS , rmmod DLSW+ etc).

insmod??? hoewel het voortdurende succes van Linux anders doet vermoeden, het tijdperk van monolithische kernels is eigenlijk wel over. Hier zou je geen goed cijfer voor krijgen van de heer Tanenbaum.

Huh, zo af en toe geeft de heer Torvalds ook nog wel eens zijn mening over microkernels en de delen van de comp.sci academia die daar heel erg hard in geloven, en hij klinkt erg overtuigend.

Juniper doet het al vrij goed met hun strikte scheiding tussen control en forwarding planes

Doel je op linecard - RP , of zit er meer scheiding in JunOS ? [zijn er eigenlijk goede beschrijvingen van juniper/JunOS architectuur ? Ik heb wel eens gekeken, maar kon niet al te veel vinden op de site.] [..] Boudewijn

On donderdag, sep 18, 2003, at 14:12 Europe/Amsterdam, Boudewijn Visser wrote:

...

[..]

...

(next wishlist item: modulair IOS. 'insmod BGP,IS-IS , rmmod DLSW+ etc).

insmod??? hoewel het voortdurende succes van Linux anders doet vermoeden, het tijdperk van monolithische kernels is eigenlijk wel over. Hier zou je geen goed cijfer voor krijgen van de heer Tanenbaum.

Huh, zo af en toe geeft de heer Torvalds ook nog wel eens zijn mening over microkernels en de delen van de comp.sci academia die daar heel erg hard in geloven, en hij klinkt erg overtuigend.

Ik kan me niet voorstellen dat de heer Torvalds voorstander is van het integreren van langlevende server processes in de kernel. khttpd en kmod weer verdwenen, named zal er nooit inkomen, en ik vraag me ten zeerste af wat het draaien van een bgpd in ring 0 heeft op het in een apart stuk address space met eigen protectie zetten ervan.

...

Juniper doet het al vrij goed met hun strikte scheiding tussen control en forwarding planes

Doel je op linecard - RP , of zit er meer scheiding in JunOS?

Er zit meer scheiding in Junipers. Het control plane is een Pentium dat een flink gehackte versie van FreeBSD kernel en userland draait, met een uitstekende CLI om de zaak te configureren, en uiteraard eigen implementaties van alle routing protocols. Het forwarding plane bestaat uit PIC's (PA's in Cisco-speak), die in FPC's zitten (VIP's in Cisco-speak). Alleen is een VIP2 een module met een generieke processor, waar FPC's een stapel ASIC's is die de forwarding policy te horen krijgen van het control plane en binnenkomende packets aan de hand daarvan correct afhandelen. Elke FPC voegt een brokje shared memory toe aan het backplane dat gebruikt wordt om packets in te zetten en uit op te halen (in J-Cells van 64 bytes).

[zijn er eigenlijk goede beschrijvingen van juniper/JunOS architectuur? Ik heb wel eens gekeken, maar kon niet al te veel vinden op de site.]

Je kan langsgaan. De vorige keer dat ik als (toekomstige) klant daar was werd me verteld "Hier is een schroevendraaier, ik ben even koffie halen in de andere kamer!" Dat was medio 2000 dus misschien gaat het tegenwoordig anders. :) En, waarde mede-systeembeheerders op deze lijst, ik hoop dat u allen de ./configure command lines voor OpenSSH nog in uw respectievelijke shell histories heeft staan of anderszins onthouden heeft, aangezien dit zeer binnenkort weer nodig gaat zijn. -- Niels. --

On Thu, 18 Sep 2003, Niels Bakker wrote:

On donderdag, sep 18, 2003, at 14:12 Europe/Amsterdam, Boudewijn Visser wrote:

...

...

[..]

...

(next wishlist item: modulair IOS. 'insmod BGP,IS-IS , rmmod DLSW+ etc).

insmod??? hoewel het voortdurende succes van Linux anders doet vermoeden, het tijdperk van monolithische kernels is eigenlijk wel over. Hier zou je geen goed cijfer voor krijgen van de heer Tanenbaum.

Huh, zo af en toe geeft de heer Torvalds ook nog wel eens zijn mening over microkernels en de delen van de comp.sci academia die daar heel erg hard in geloven, en hij klinkt erg overtuigend.

Ik kan me niet voorstellen dat de heer Torvalds voorstander is van het integreren van langlevende server processes in de kernel. khttpd en kmod weer verdwenen, named zal er nooit inkomen, en ik vraag me ten zeerste af wat het draaien van een bgpd in ring 0 heeft op het in een apart stuk address space met eigen protectie zetten ervan.

de conclusies na dat soort experimenten waren altijd dat het slimmer is om de delen van de kernel die vertragen gewoon te fixen. Daemons wil je gewoon in userland, kernel coding is gewoon te veel moeite zonder gain. Voor khttpd en tux zijn nu userland alternatieven die harder gaan. Threading wil je trouwens wel weer in de kernel, maar das weer een heel ander verhaal :).

En, waarde mede-systeembeheerders op deze lijst, ik hoop dat u allen de ./configure command lines voor OpenSSH nog in uw respectievelijke shell histories heeft staan of anderszins onthouden heeft, aangezien dit zeer binnenkort weer nodig gaat zijn.

gelukkig doe ik packages, maar toch : NIET nog es! -- Sten Spans There is a crack in everything that's how the light gets in.

On donderdag, sep 18, 2003, at 14:12 Europe/Amsterdam, Boudewijn Visser wrote:

...

...

[..]

...

(next wishlist item: modulair IOS. 'insmod BGP,IS-IS , rmmod DLSW+ etc).

insmod??? hoewel het voortdurende succes van Linux anders doet vermoeden, het tijdperk van monolithische kernels is eigenlijk wel over. Hier zou je geen goed cijfer voor krijgen van de heer Tanenbaum.

Huh, zo af en toe geeft de heer Torvalds ook nog wel eens zijn mening over microkernels en de delen van de comp.sci academia die daar heel erg hard in geloven, en hij klinkt erg overtuigend.

Ik kan me niet voorstellen dat de heer Torvalds voorstander is van het integreren van langlevende server processes in de kernel. khttpd en kmod weer verdwenen, named zal er nooit inkomen, en ik vraag me ten zeerste af wat het draaien van een bgpd in ring heeft op het in een apart stuk address space met eigen protectie zetten ervan.

...

Niet in die mate inderdaad. T's argument is meer dat filesystems, de netwerk stack e.d. er *wel* inhoren Maar vooral een afkeer van nodeloze complexiteit en traagheid toevoegen vanwege het theoretische ideaal van een microkernel. (Een aantal dingen die altijd zeker in een monolithische kernel zitten worden heel veel trager en complexer in userspace bij een microkernel) Nu was inderdaad insmod bgp niet helemaal de juiste term, aangezien ook/(zelfs?) IOS die ook als apart proces draait. Bij gebrek aan (gebruik van) memory protectie helpt dat niet ontzettend veel, maar IOS processen -kunnen- crashen zonder de router mee te nemen. Ik neem aan dat de reden voor het gebrek aan memory protectie in de diepe historie ligt, en daarnaast (of daardoor?) de keus voor CPUs zonder MMU. [68EC030 in de low end; Geen idee of de MIPS-klonen in de higher-end routers wel MMU's hebben ].

...

...

Juniper doet het al vrij goed met hun strikte scheiding tussen control en forwarding planes

Doel je op linecard - RP , of zit er meer scheiding in JunOS?

Er zit meer scheiding in Junipers. Het control plane is een Pentium dat een flink gehackte versie van FreeBSD kernel en userland draait, met een uitstekende CLI om de zaak te configureren, en uiteraard eigen implementaties van alle routing protocols.

Het forwarding plane bestaat uit PIC's (PA's in Cisco-speak), die in FPC's zitten (VIP's in Cisco-speak). Alleen is een VIP2 een module met een generieke processor, waar FPC's een stapel ASIC's is die de forwarding policy te horen krijgen van het control plane en binnenkomende packets aan de hand daarvan correct afhandelen. Elke FPC voegt een brokje shared memory toe aan het backplane dat gebruikt wordt om packets in te zetten en uit op te halen (in J-Cells van 64 bytes).

VIP2 ? Jij bent al even uit de cisco-lijn ... Hiernaar kijkend denk ik dat de GSR een beter analogon is. Ook een cell gebaseerd switch fabric (er is een interessant paper over van Nick McKeown over, de ontwerper ervan). Route Processor, en linecards die zelf forwarden. Wel zijn de linecards geintegreerd met hun iterfaces, niet meer het VIP+PA model.Afhankelijk van het type linecard kan er alleen een CPU op zitten die een mini-IOS draait voor het packet switchen, of naast de CPU ook asics ter versnelling van de packet switching. [Engine[0..4] linecards. 0 : Alleen CPU, 1 tm 4 hebben in meer of mindere mate asics erbij. ] Ik zag overigens in wat Juniper docs dat er naast de Asics ook een generieke CPU (PPC variant) op de FPCs zit.

...

[zijn er eigenlijk goede beschrijvingen van juniper/JunOS architectuur? Ik heb wel eens gekeken, maar kon niet al te veel vinden op de site.]

Je kan langsgaan. De vorige keer dat ik als (toekomstige) klant daar was werd me verteld "Hier is een schroevendraaier, ik ben even koffie halen in de andere kamer!" Dat was medio 2000 dus misschien gaat het tegenwoordig anders. :)

Ik denk dat het "Hoi, ik wil misschien jullie dozen gaan kopen" (vs : "Hoi, ik heb niks te doen en wil graag eens met jullie dozen spelen") meer verschil maakt dan 2000 vs 2003 ;-)

En, waarde mede-systeembeheerders op deze lijst, ik hoop dat u allen de ./configure command lines voor OpenSSH nog in uw respectievelijke shell histories heeft staan of anderszins onthouden heeft, aangezien dit zeer binnenkort weer nodig gaat zijn.

Meer, meer ... Boudewijn

On Thu, 2003-09-18 at 23:08, Boudewijn Visser wrote:

...

Niet in die mate inderdaad. T's argument is meer dat filesystems, de netwerk stack e.d. er *wel* inhoren

Ik vermoed dat de "T" hier "Torvalds" is en niet "Tanenbaum" (of Turing) ;-)

Uh, ja. Zeker niet Tanenbaum, als hij erg consequent microkernel is, en Turing deed niet aan overbodige luxe als OSen. Sterker, Turings bekendste werk deed niet eens aan hardware ;-)

...

Maar vooral een afkeer van nodeloze complexiteit en traagheid toevoegen vanwege het theoretische ideaal van een microkernel. (Een aantal dingen die altijd zeker in een monolithische kernel zitten worden heel veel trager en complexer in userspace bij een microkernel)

En andersom.

Denk aan het filesystem dat op de disk wacht, of de IP stack die op een ARP reply wacht. In een pure monolithische kernel staat het systeem in principe stil gedurende deze tijd, want de kernel kan niet pre-emptive gescheduled worden.

Dus heeft men de Pinguin opgezadeld met Bottom Half handlers, Task Queues, Wait Queues... Feitelijk niets meer dan hacks om ervoor te zorgen dat de kernel de CPU niet nodeloos vasthoudt. Er wordt een soort van scheduler emulatie in de kernel ingebouwd, naast de bestaande process scheduler... die nota bene alleen werkt alleen als alle onderdelen van de kernel zich netjes gedragen (dus ook de dynamic kernel modules). Vergis je niet, dit maakt de kernel een stuk complexer dan strikt noodzakelijk. Bij alle functionaliteit die wordt toegevoegd moet je goed kijken of er plekken zijn waar je de CPU tijdelijk kunt vrijgeven.

Hm, voor zo ver ik de verschillen begrepen heb is het cruciale onderscheid tussen micro en monolitische kernels veel meer kernel-space vs userland, en is het in meer of mindere mate pre-emtible zijn van de kernel geen criterium. [zoek zoek zoek... term micro kernel heeft een hoop betekenissen, maar Bill Stallings noemt ook kernel vs user, en het naar userland brengen van dingen als device drivers, vmm, filesystems etc. als de typische microkernel kenmerken. ]

Dit "nette" pre-emptive gedrag krijg je gratis bij de microkernel opzet -- ten koste van wat overhead, maar ik denk dat er ergens een omslagpunt ligt.

Er zijn trouwens genoeg voorbeelden van prima werkende (en presterende) microkernels: AmigaOS, FreeBSD, JunOS, Darwin.

Blup ? FreeBSD een microkernel ? Ik heb het idee dat de definitie van microkernel dan wel heel erg veel is verschoven van het comp.sci ideaal, en Linus' afkeer. Is dat geen buzzword compliancy ? AmigaOS is inderdaad een heel fraai OS, maar speelt qua prestatie een beetje vals vanwege het ontbreken van allerhande protectie, en het OS maakt daar ook goed ge/mis bruik van. Dat maakt een deel van de geclaimde voordelen van de microkernel aanpak nogal zinloos. JunOS ken ik dan nauwelijks, maar wordt omschreven als een gestripte BSD kernel waaronder allerlei processen draaien. Wat dat betreft lijkt het me evenveel of evenweinig microkernel als FreeBSD. Darwin (is dat het OS deel van MacOS X, of was het wat anders) ken ik te weinig, maar is dan misschien de beste kandidaat.

T & T hebben allebei een beetje gelijk. Geen van beide aanpakken is 100% heilig.

Overigens heb ik colleges bij Tanenbaum gelopen, maar gebruik ik de kernel van Torvalds... en uiteindelijk is alles een Turing machine.

Dat is 1 van Linus' argumenten (theorie vs praktijk ) ;-) Tsja, mijn oude C128 is ook een Turing machine (en boot een stuk sneller dan al z'n opvolgers), maar er zijn toch wel wat redenen waarom ik sommige Turing machine & programma verkies boven andere .... Boudewijn

On vrijdag, sep 19, 2003, at 10:14 Europe/Amsterdam, Steven Bakker wrote:

Eigenlijk zijn alleen QNX en Darwin nog serieuze kandidaten en ik ben benieuwd waar OpenBeOS (NewOS) naar toe gaat.

Darwin is in de praktijk geen OS met microkernel. Kort door de bocht gebruikt het een Mach microkernel om een monolithische FreeBSD kernel te draaien. FreeBSD zelf heeft trouwens al vrij lang geleden de laatste sporen van Mach uit het VM subsystem geschreven. QNX is een op 'n microkernel gebaseerd real-time operating system. On vrijdag, sep 19, 2003, at 02:51 Europe/Amsterdam, Boudewijn Visser wrote:

AmigaOS is inderdaad een heel fraai OS, maar speelt qua prestatie een beetje vals vanwege het ontbreken van allerhande protectie, en het OS maakt daar ook goed ge/mis bruik van.

Amiga's zijn ook begonnen met een Motorola 68000, en die CPU's hebben geen MMU, dus het OS kon weinig anders...

JunOS ken ik dan nauwelijks, maar wordt omschreven als een gestripte BSD kernel waaronder allerlei processen draaien. Wat dat betreft lijkt het me evenveel of evenweinig microkernel als FreeBSD.

Maar dat onderscheid doet er niet toe, want belangrijke zaken gebeuren in user-space (routing processes, user interface interaction) of in dedicated hardware die kan functioneren zonder de routing engine.

Tsja, mijn oude C128 is ook een Turing machine

Haal je hier nu Von Neumann-machines en de Turing-test door elkaar? (En waar is de oneindig lange tape in je C=?) -- Niels. --

-----BEGIN PGP SIGNED MESSAGE----- Boudewijn Visser wrote:

...

On vrijdag, sep 19, 2003, at 10:14 Europe/Amsterdam, Steven Bakker wrote:

...

Amiga's zijn ook begonnen met een Motorola 68000, en die CPU's hebben geen MMU, dus het OS kon weinig anders...

Zonder MMU kon het OS geen protectie gebruiken, maar het nam wel shortcuts die het moeilijk/onmogelijk maken om te profiteren van een CPU met MMU wanneer die wel beschikbaar zou zijn. Toen de A3000/A4000 (68030/68040) uitkwamen is er niks gedaan met de MMU daarvan in AmigaOS.

Ik heb toendertijd *speciaal* die mtec030 gehaald want dan had ik jawel, voor me schattige 1200tje met laffe ec020 een heuse 68030 + MMU op 28mhz en een 68882 FPU want dan ging lightwave ook een factor te veel harder. De voornaamste reden voor die MMU was overigens Enforcer en swee hardware buffer overflow detection. Er ligt me overigens ook bij dat er appjes waren om virtual memory te maken. Maar per process memory protection zat er niet echt in helaas. Zonder MMU moest je het doen met Mungwall. Goeie oude tijd, alhoewel... ;) Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen at unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP2rjoimqKFIzPnwjEQLTNgCeLo4XrgEifqEwBCYDNoXRtGXsFtoAoIVf HSbw/7MaE9z0PkOV4f31wfoc =PPKy -----END PGP SIGNATURE-----