AT Blog

AT Computing is bezig met een migratie project van Active Directory naar een complete open source oplossing.

Aangezien Active Directory (AD) ondermeer bestaat uit een ldap en kerberos implementatie is het niet gek dat we daar OpenLdap en MIT's Kerberos voor gebruiken - beide pakketten zijn volledig open source.

Nu is het opzetten van een directory service (ldap) en kerberos niet heel moeilijk en zijn er genoeg HOWTO's te vinden die je daar door heen leiden. De problemen die wel pittig zijn, komen voort uit het feit dat:

• Alle wachtwoorden worden in Kerberos bewaard en niet in OpenLdap, er dus extra configuratie nodig in de vorm van SASL.
• Alle nieuwe (Linux) thin clients deze gebruiken
• Er vooralsnog een AD draait die leidend is. Er moet dus een synchronisatie plaats vinden van AD naar OpenLdap.
• De AD daarna minder belangrijk wordt en de OpenLdap/Kerberos service leidend is en er een synchronisatie naar AD moet plaatsvinden.

De AD kan niet helemaal uitgezet worden omdat er nog Windows clients overblijven, die hiervan gebruik blijven maken. Het is mogelijk om hier Samba 4.0 voor te gebruiken, maar dat is voorlopig nog niet aan de orde.

De omgeving moet natuurlijk ook robuust genoeg zijn om uitval van servers te kunnen opvangen, dus:

• Zijn er twee ldap servers die in een master/slave setup werken, de replicatie loopt via SyncRepl.
• Als er write acties plaats vinden op de slave ldap server, dan worden die transparant omgeleid worden naar de master server, via een zogenaamde overlay chain.
• Zijn er twee kerberos servers die ook in een master/slave setup werken. Hier wordt altijd de master server gebruikt voor schrijf acties. Is deze down, dan kunnen er dus (tijdelijk) geen wachtwoorden meer gewijzigd worden, maar draait de kerberos service gewoon verder.

Ook is er veel te vertellen over het inrichten van het netwerk zelf:

• De gekozen Linux distributie(s) en waarom.
• Opzet van een interne update server.
• Het gebruik van een open source Exchange server.

Zodra het project is afgerond kunnen we wat meer vertellen over de implementatie details en hoe we de problemen waar we tegen aan liepen hebben opgelost. Dit zal waarschijnlijk in Q1 van 2009 zijn.

Afgelopen weekend besloot ik dat het weer eens hoog tijd werd om mijn eeePC eens een keer te updaten.

Ik gebruikte hiervoor de standaard commando mantra die iedereen wel kent:

apt-get update
apt-get upgrade

en dit gaf me 287 nieuwe en ge-update pakketten.

Hierna was een reboot noodzakelijk, natuurlijk omdat ik wel erg veel nieuwe pakketten gekregen had, waaronder ook een nieuwe kernel.

En daar begon de ellende. Geen X omgeving, geen netwerk, geen muis, geen USB enzovoort. Het leek op sterven na dood.

Al zoekende en hier en daar wat reparerend, kreeg ik de X omgeving aan de praat, maar nog steeds geen muis, geen USB en geen netwerk. Ik begon me af te vragen of er niet iets structurelers aan de hand was, want ik kon me niet voorstellen dat alles zo plotseling stuk was.

Verder gravend viel mijn oog plotseling op wel heel erg veel bestanden met de extensie dpkg-new. Hier ontstond het idee dat er tijdens de update iets goed fout gegaan was, omdat er een groot aantal bestanden niet was aangepast. Het waarom hiervan is nog niet helemaal duidelijk, maar het resultaat wel. Maar, prioriteiten moeten gesteld worden, dus eerst de boel weer in de lucht zien te krijgen.

Nu ik wist waar de pijn zat, was het tijd voor drastische acties. Alle rare bestanden stonden in de /etc directory dus daar moest ik me op concentreren. Een klein scriptje was zo in elkaar gesleuteld , dit om de boel moet herstellen. Deze actie kan twee uitkomsten hebben, ik krijg weer een werkende eeePC of het is zo stuk dat er weinig anders op zit dan compleet opnieuw beginnen.

Hier is het script (niet moeilijk, maar wel efficient):

cd /etc
for f in $(find . -type f -name \*.dpkg-new)
do
    a=$(echo $f | sed 's/\.dpkg-new$//')
    mv $a $a.NOT
    mv $a.dpkg-new $a
done

Nadat ik dit script gedraaid had, werkte alles weer en voelde als nieuw.

Het enige dat me nu nog dwars zit is het waarom van de verkeerde update. Zou gauw ik daar achter ben wordt dit artikel vervolgd.

Stel, je hebt net een prachtige Acer Aspire One gekocht en je denkt, dat Linpus Linux is wel grappig, maar ik wil toch ook een echt OS gebruiken. Als je dan ook nog ruimte genoeg hebt, omdat je een 120GB harddisk erin hebt, waarom niet dual boot maken?

Waarschuwing: Als je dit gaat proberen met je eigen Acer Aspire One of vergelijkbare hardware, zorg dan voor een goede werkende backup! De restore operatie van Acer veegt je hele schijf leeg en het resizen van de disk kan ook mislukken!!

Een beetje googlen levert wel wat nuttige informatie op over het installeren van Ubuntu of Fedora op zo'n apparaat, maar niet echt over dual boot. Maar ja, wat voor problemen kun je nou helemaal tegenkomen?

Nou ja, bijvoorbeeld dat Acer standaard 119 GB voor Linpus reserveert en 1GB voor swap. (De getallen zijn enigzins fictief, aangezien de disk 120.000.000.000 bytes is en niet 120 GiB.)

Poging 1

Dus start je op met je verse bootable USB sticky met bijvoorbeeld Fedora 10 erop, maar Ubuntu, of iets anders kan ook natuurlijk, en die heeft de optie "resize partition", dus da's handig (NOT!). Deze optie sloopt namelijk gewoon een x aantal bytes van je partitie af, zonder het filesystem erop te resizen, dus, back to the drawingboard...

Na het rescue verhaal van Acer te hebben toegepast (boot van de rescue dvd, usb-stick van >= 2G erin, sticky aanmaken, Acer Aspire One booten van het sticky (bij het opstarten het bootmedium kiezen met toets F12) en dan het systeem opnieuw Linpussen) kun je vrolijk weer opnieuw beginnen.

Poging 2

We booten opnieuw van ons Fedora sticky, zoeken een shell op, even root worden (su -) en dan gaan we de Linpus partitie resizen (voor mij leek 8GB wel genoeg):

resize2fs -p /dev/sda1 2000000 (8GB in 4k blocks)

e2fsck -f /dev/sda1

Nu starten we de systeem installatie opnieuw en dan resizen we de partitie sda1 tot iets wat een beetje groter is dan 8GB, bijv. 8,5GB, voor de zekerheid. Daarna maken we partities aan voor het te installeren systeem. (De Linpus swap heb ik verwijderd, omdat die aan het einde van de disk stond, en een nieuwe aangemaakt meteen na de eerste partitie)

Nu heb ik de partities:

• sda1 (Linpus) 8,5G
• sda2 (swap) 1,1G
• sda3 (extended) 108G
• sda5 (/) 12G
• sda6 (/home) 90G

De bootloader

Bij het installeren van Fedora (of Xubuntu, waar ik in dit stadium inmiddels mee bezig ben) kun je kiezen om grub op de root partitie te installeren in plaats van de MBR, waar de originele Linpus bootloader al op staat. Dit doen we en om het nu netjes te doen gaan we de oorspronkelijke Linpus bootloader (ook grub) aanpassen zodat ook de nieuwe Linux daarbij te kiezen valt.

De boot configuratie van Linpus staat op /dev/sda1, dus die moeten we eerst mounten;

mkdir /tmp/a1; mount /dev/sda1 /mnt/a1
cd /mnt/a1/boot/grub
vim grub.conf

NB: normaal gesproken wordt dacht ik menu.lst gebruikt, maar hier dus niet...

hier voegen we in, tussen "hiddenmenu" en "title Linpus Linux RCD"

(X = rootpartitie van de nieuwe linux -1!):

title Nieuwe Linux
root (hd0,X)
chainloader +1

NB: als de nieuwe linux op sda5 staat wordt het root (hd0,4)

Nu kun je bij het booten kiezen voor de originele Linpus, of de bootopties die er door de nieuwe Linux bijgemaakt zijn.

En verder:

Nu kunnen we gaan optimaliseren en spelen en als er iets stuk gaat kunnen we altijd terugvallen op het originele OS.

Links:

• Fedora Acer Aspire One
• Ubuntu Acer Aspire One
• Aspire One Wiki