My RSS Feeds
Lekker Solaris 10 en Sun Ray 3.1 aan het draaien
Donderdag 5 november, 16.30 uur.
Door een automatische wijziging in de configuraties van de Windows 2003 terminal server door Webroot SpySweeper accepteerde de server geen nieuwe verbindingen meer.
Terwijl ik daarmee bezig was begint onze Sun Fire 280R Solaris 8 server opeens te racen. De twee UltraSPARC III's liepen naar 100% en het hele systeem begon raar te doen.
Onderzoek wees uit dat er iets héél goed mis was. Het root filesystem gaf compleet belachelijke uitdraaien met ls. Sommige bestanden kregen een I/O error, anderen waren opeens vele tientallen terabytes groot, weer anderen waren gemaakt op 1 juli 1980 of iets dergelijks. De types van de bestanden waren volledig fucked up ende kaput.
Toen iedereen weg was heb ik de console aangesloten en begon ik aan een 1-on-1 met de server, die nog de hele nacht zou duren. Er was geen redden meer aan. Het hele systeem was een langzame en pijnlijke dood aan het sterven. In de onvermijdele reboot weigerde Solaris nog te starten of zelfs maar foutmeldingen te geven of een mogelijkheid tot maintenance mode te bieden.
De rapen waren gaar. Ik kon nergens meer in, heen of op. Alles op / was volledig in de soep gedraaid en iedereen moest morgen weer aan het werk natuurlijk. Ik zag nog maar één uitweg: Opnieuw installeren.
Nu hadden we reeds gevorderde plannen om onze verouderde Solaris 8/Sun Ray Server Software 1.3 stack te upgraden naar Solaris 10/Sun Ray Server Software 3.1, en dit was een goed moment om dat dan maar meteen te gaan doen.
De Sun Fire 280R heeft een keuzeoptie: óf een CD-ROM speler óf een DDS4 tapedrive. Wij hadden voor het laatste gekozen in verband met de backups. Natuurlijk had ik een JumpStart of een andere installatie-op-afstand mogelijkheid kunnen proberen, maar gezien het feit dat ik hier al langer van baalde en omdat ik geen zin had in nog meer onverwachte problemen en omdat ik net zelf Sun Enterprise 250-bakken heb gekocht, besloot ik om er daar een CD-ROM speler uit te slopen en de tapedrive te vervangen.
Een flinke pot koffie gezet, de eerste CD van Solaris 10, met dank aan Sun Microsystems, er in gedropped en de installatie gestart.
Les 1 over seriële consoles: Ze zijn godsgruwelijk traag. Ofschoon er in de OpenBoot Environment (Sun's equivalent van de BIOS) een optie stond om de snelheid op te hogen, had ik geen zin in nog meer potentiële problemen en ben doorgegaan met de default 9600-baud setting.
In combinatie met de Windows HyperTerminal geeft dit al problemen genoeg met de Solaris installer, en 't is, zoals gezegd, hoeretraag, maar 't liep gelukkig.
Voor een Sun Ray server wordt ten strengste aangeraden om als minimaal installatieniveau "Entire Distribution" te kiezen. Hier rees een nieuw probleem. Cards Engineering, onze leveranciers, hadden de machine afgeleverd met een root slice van slechts 2 GiB, terwijl een "Entire Distribution" installatie rond de 5 eist.
Dit betekende dus dat ik met de hand door de hele package lijst mocht gaan baggeren om pakketten te selecteren die ik niet nodig zou hebben om ruimte uit te sparen.
Uiteindelijk heb ik op de eerste harde schijf een nieuwe indeling gemaakt en de root slice vergroot ten koste van de swap slice, die vreemd genoeg ook in mirror stond. Door daar een einde aan te maken, de swap slices te halveren en individueel in het swap systeem te hangen heb ik nu dus nog evenveel swap als vroeger, wat sneller werkt omdat de twee slices intern als stripe worden benaderd, en ik heb een GiB extra vrij kunnen maken. Nog een GiB van de data slice afgepakt en 4,4 GiB stonden tot mijn beschikking.
Na wat hak- en sloopwerk in de package configuratie konden we dan eindelijk beginnen. Vlotjes werd de ene CD na de andere afgewerkt en een dik uur later gaf uname -srv trots SunOS 5.10 Generic_118822-20 sparc aan.
Daarna heb ik de laatste patches over de OBP, de POST en de RSC gegooid, de laatste Recommended Patch Cluster van Solaris 10 geïnstalleerd en het platform was klaar voor verdere installatie en configuratie.
Dit klinkt allemaal heel simpel, maar geloof me, tegen deze tijd was het al 24 uur geweest :-/
Vervolgens de oude data slice van de tweede harde schijf leeggetrokken naar de gekrompen nieuwe data slice. In de tussentijd kon ik mooi Webmin, SWAT en Samba configureren. Na wat heen en weer gehannes kwam ik er achter dat de meegeleverde versies hiervan niet bepaald op standaard locaties staan, en al behoorlijk verouderd zijn.
Nu ja, te laat om naar te kijken. Webmin werkte gelukkig vlotjes nadat ik had uitgevogeld dat er zoiets bestond als webminconfig, en ook Samba liet zich relatief gewillig configureren.
Daarna waren de SunPCI ProII kaarten aan de beurt. Gelukkig had ik hier al eens naar gekeken, anders had het nog wel eens wat later kunnen worden dan het toch al was. SunPCI ProII-kaarten zijn Celeron-733 CPUtjes op een PCI-X kaart gezet, met eigen SO-DIMMs en een eigen grafische kaart. Middels de PCI Pro software zijn ze te configureren. Ze draaien op virtuele harde schijven, die als binary images aangemaakt worden op de harde schijf van het hostsysteem.
Met behulp van deze hack, die verder zonder enige problemen werkte, ben ik in staat geweest om de twee kaarten die we hadden weer op de been te helpen en terug in Boot@Boot configuratie te zetten. Zonder enig probleem. Voor de Windows'en op deze kaarten was het alsof er niets was gebeurd.
Ofschoon de directe interface met deze kaarten nogal wat gebreken vertoont (dit is met een patch weer gedeeltelijk op te lossen) zijn ze als RDP-hosts nog meer dan prima te gebruiken.
Tot slot nog alle gebruikers aangemaakt, zonder wachtwoorden of wat dan ook zodat iedereen aan het werk kon.
Het was reeds 8 uur 's ochtends geweest, vele bakken koffie en flink wat frustratie later. Echter, het hele spulletje werkte! Boeltje gepakt, tijd om te gaan slapen. Nog één runtest, voor de zekerheid. Alles ging prima, totdat... Ik plotseling opmerkte dat de SuSE Linux Pro 9.3 FileMaker 5.5 (die ik overigens nog dankzij deze geniale hacks aan de gang gekregen heb) database-server bepaald niet aardig aan het doen was.
<<<ZUCHT>>>
PuTTY opentrekken, inloggen via SSH en erachter gekomen dat de NFS-mount naar de Solaris-doos (natuurlijk) niet meer functioneerde.
Dit zou an sich nog niet zo erg zijn geweest, ware het niet dat een aantal cronscripts op die NFS-share stonden. En cron kon daar niet om lachen. Zeker niet omdat de NFS niet geunmount was (zoals toch redelijkerwijs aangenomen mag worden) maar gewoon stond te timeouten als iemand die in de rij staat voor een uitkering.
Cron daarentegen ging natuurlijk verder en probeerde het gewoon bij gebrek aan een statusmelding nog een keer. En nog een keer. En nog een keer. En dat al vanaf 18 uur de volgende dag. Gevolg: 300 (of zo) processen in een race om CPU-tijd om te wachten. En wie werd daar de dupe van? Juist, het half dozijntje FileMaker processen. kill -9 mocht niet meer baten, en zelfs een init 6 ging gewoon niet meer functioneren (niet binnen 15 minuten tenminste).
<<<ZUCHT>>>
Dan maar de stekker eruit. Geen zin meer, geen energie meer, geen heldere gedachten meer, dan maar de stekker er uit. 30 seconden afgewacht, schietgebedje naar boven en de stroom er weer op gezet.
Het goede nieuws was: Linux keerde terug. Filemaker ook, min of meer.
Het slechte nieuws was dat de netwerkinterface gewoon non-existent was. Een paar foutmeldingen @ boot en géén hme0 te bekennen. Nog maar eens rebooten, dit keer "gracefully". No go. Op dat moment begonnen de eerste collegae al weer binnen te druppelen.
Damn. Dat had ik nou juist willen voorkomen. Na nog wat verder kloten en rondzoeken op het internet uiteindelijk met ifconfig handmatig geprobeerd de interface terug op de been te krijgen, wat na enkele vruchteloze pogingen ("HOEZO HME0 BESTAAT NIET!?!?") en een beetje hulp van YAST wonderbaarlijk genoeg nog lukte ook.
MOOI. Nu Filemaker nog ff herstarten en opnieuw aan de interface binden en dan kan ik naar huis (dacht ik).
En hoewel ik inmiddels beter zou moeten weten, was wederom de teleurstelling groot toen dat niet zo makkelijk bleek te gaan. Filemaker startte wel, bindde nog keurig aan de interface ook, accepteerde verbindingen, en... liep vast.
99% CPU, geen reactie meer uit te krijgen. Aantal keren geprobeerd en er was geen donder aan te doen, het gebeurde gewoon.
Laatste geniale inval voor vandaag: Alle bestanden van de database uit de directory verplaatst, FileMaker gestart en ó wonder! Het ging! Vervolgens alle bestanden één voor één terugzetten en inladen. Toen bleek dat naast het een en ander aan consistency checks ook de indexen opnieuw opgebouwd werden. Da's mooi, dat kostte niet teveel tijd, maar blijkbaar moest het wel met mate gebeuren.
En zo, na het handmatig voeren van 55 bestanden aan de database kon ik om 10.30 uur e-i-n-d-e-l-i-j-k naar huis. Iemand riep me nog na dat de e-mail het niet deed, maar ik heb er de bout aan gegeven (en het die avond nog binnen 5 minuten opgelost door de e-mailserver handmatig te voorzien van een briefpapiertje voor de e-mail, wat normaliter, u raad het al, over een niet meer bestaande NFS-mount heenkwam).
Vervolgens bij een goede vriend van me (die 's avonds rond 23.00 uur gearriveerd was en de hele avond support had geleverd) nog een biertje nagedronken en een hartaanval af weten te weren, en dat was dan weer het avontuur voor de donderdag 5 en vrijdag 6 november.
