Ongezouten toegang

Hoewel we bij FOK! regelmatig grote delen van de codebase onder handen nemen en vaak (onzichtbaar aan de buitenkant) sterk wijzigen, blijven er altijd zaken drijven waar we niet zomaar wijzigingen in aanbrengen. In ontwikkeltermen heet dat legacy-code of -methoden, en gezien de leeftijd van FOK! (deze zomer alweer tien jaar) is die legacy nogal oud.

Daardoor heeft het ook kunnen gebeuren dat een verouderde wijze van passwords hashen nog steeds actief was op FOK!. De manier waarop we dat deden, zonder ’salt’ zoals dat heet, is geïntroduceerd voordat ikzelf actief was als ontwikkelaar en hoewel ik ergens een lijstje heb liggen met daarop dit precieze issue als aandachtspunt hebben we er tot noch toe niet naar gekeken.

Stom, zo blijkt nu. Een beetje SQL-injection links en rechts zorgde voor het blootstellen van onze ‘unsalted hashes’ en poef, grote kans dat je wachtwoord achterhaalbaar is. Grote kans, vraag je? Jazeker. Ik ga je niet vermoeien met de werking van het kraken (om een simpele term te gebruiken) van een passwordhash, maar het is mogelijk dat met de hash van jouw password als resultaat een ander password wordt gevonden. Hiermee zou je kunnen inloggen op FOK!, maar niet noodzakelijkerwijs ook op andere sites waar je hetzelfde wachtwoord gebruikt.

Het risico is er echter wel, en om dit in de toekomst volledig onmogelijk te maken hebben we gewerkt aan een aanpassing in het hashen van de gebruikerswachtwoorden op FOK!. Alle hashes zoals ze er tot en met dit weekend stonden zijn eruit, en we hebben alle users een nieuw wachtwoord, met nieuwe hash en nieuwe hashingmethode, gegeven.

Met salt? Goeie vraag: jazeker! Het hashingalgoritme MD5 is vervangen door de 512-bits variant van SHA2 en er zit een leuke korrel zout in de hele berekenmethode. Hiermee is het verdomde lastig om jouw wachtwoord, indien men over de hash beschikt, te achterhalen. Zo lastig, dat geen hacker zich eraan gaat wagen; de moeite die het zal kosten om een wachtwoord te achterhalen is de opbrengst niet waard.

Wat nu nog rest? Een advies: gebruik niet op meerdere sites hetzelfde wachtwoord, en als je dat risico wel wil nemen, maak dan wel een onderscheid tussen belangrijke persoonlijke toegangswachtwoorden (zoals die van je e-mail) en de minder belangrijke (zoals die van internetfora en -sites). Denk goed na over het risico; wij hebben nu onze verouderde opslag de deur uit gedaan, maar er kunnen andere sites zijn die nog steeds slecht hashen of dat simpelweg helemaal niet doen.

Oh, en bedankt voor je begrip. We voelen ons al lullig genoeg.

Over de downtime van 13/14 juni 2009

Vorig weekend was FOK! ruim een dag down. Helaas kwamen er wat klachten over de communicatie vóór en tijdens de downtime, dus daar gaan we in het vervolg opener mee om. Om gelijk goed te beginnen, staat hieronder een samenvatting van wat er allemaal is gebeurd bij dat onderhoud, waarom het zolang duurde, en wat we nog gaan doen om FOK! nog sneller te maken.

De schijven waarop de database bewaard wordt, moesten vervangen worden omdat ze voor 98% volzaten _{ergens anders stond 97%, maar dit was eigenlijk 98%}. De drie oude schijven waren 73 GB per stuk, de nieuwe (weer drie) 146 GB. De database moest meeverhuizen, en dat kun je op twee manieren doen: de bestandjes kopiëren of de inhoud uit de bestandjes halen en de bestandjes later opnieuw opbouwen. Wij besloten dat tweede te doen, want ondanks dat het iets meer tijd kost, bood het een aantal voordelen zoals defragmentatie (binnen de bestanden zelf) en het snel aanpassen van veel indices, waarover later meer¹.
Helaas ging het kopiëren van de inhoud van de bestanden al mis na 3GB: ’segmentation fault’ wat zoiets betekent als ‘als de software geen bug bevat dan is je hardware kapot’. Andere machine geprobeerd, zelfde verhaal. Toen de software maar eens geüpdatet, en toen ging het gelukkig wel goed. Zelfs sneller dan verwacht: binnen een uurtje klaar.

Dan de disks verwisselen. Daarvoor moest wat geschroefd worden. “Oh”, zei ik, “nu moet ik geen schroefje laten vallen want dan verdwijnt hij in dat rooster”. “Is niet erg”, zei Iteejer, “dat rooster kan open”. Nog geen minuut later mocht Iteejer het rooster openmaken Nieuwe schijven erin, netjes de RAID(5)-array aanmaken, partitioneren en formatteren, wat mapjes aanmaken, rechten op de mapjes goedzetten, en de backup kon worden teruggezet. Een mooi taakje om ’s nachts te laten lopen en zelf te gaan slapen. Iteejer zou vroeg opstaan om FOK! weer aan te zwengelen.

Helaas voor mij kwam Iteejer er ’s ochtends (vroeg!) achter dat er ’s nachts toch iets was misgegaan, en stelde mij daarvan op de hoogte zodat er van uitslapen niets terechtkwam. Sommige cruciale tabellen waren nog leeg. De backup zou toch wel volledig zijn aangemaakt? Totaal zonder enig idee van de oorzaak zijn we weer naar Amsterdam vertrokken.

De oorzaak werd al snel duidelijk: het backupprogramma maakt lekker grote pakketjes aan, wat gunstig is voor de snelheid bij het terugzetten. Helaas was één zo’n pakketje net te groot geworden, waardoor het terugzetten was gestopt. Kwestie van het configuratiebestand openen, max_allowed_packet vergroten, en nog een keer proberen met de gegevens die nog niet waren teruggezet. Dat ging prima, en ’s middags kon de site weer online komen.

Het viel direct op dat de site wel erg traag was. Dat heb je normaalgesproken de eerste minuut altijd omdat hij dan zijn geheugen (16GB) nog moet vullen en tot die tijd de harddisks veel te vaak moet raadplegen, maar dit keer bleef het traag. Uit de errorlog bleek al snel de oorzaak: er was iets misgegaan met InnoDB-logfiles. En daarvoor moest de site weer offline. Alle InnoDB-tabellen (waaronder de enorme tabel met alle forumposts) moesten door een programma worden nagelopen, wat tot in de avonduren duurde en waarvan geen duidelijke voortgangsmeter beschikbaar was. Pas nadat de forumposts-tabel was nagekeken had ik een idee van hoelang het nog ging duren; minutenwerk. En inderdaad: niet lang daarna kon FOK! weer online en werkte het weer prima

¹Zoals beloofd nog iets over indices. Daar valt veel snelheidswinst mee te halen als ze nog niet of niet goed ingesteld zijn. Indices zijn gesorteerde lijsten, en als je iets zoekt (zoals een naam in een telefoonboek) of iets nodig hebt dat gesorteerd is (zoals de forumposts in een topic die je op tijd wilt sorteren) dan ben je blij dat je zo’n al gesorteerde lijst kunt gebruiken. _{Overigens, voordat Replique (deels ten onrechte) de schuld krijgt van traagheid, de indices voor de forumposts waren prima, de winst is behaald op de andere subsites.} Voor elke tabel moet je apart die indices instellen, en het is niet op voorhand duidelijk welke indices het beste zijn. Er zijn in totaal honderden tabellen, en bij elke tabel is het aantal mogelijke indices enorm. En ze allemaal instellen is geen optie: die lijsten moeten worden bijgehouden en nemen ruimte in, dus als je ze niet nodig hebt dan wil je ze ook absoluut niet hebben.
Een voorbeeld waar indices groot verschil hebben gemaakt, is de userhistory op de frontpage. Het bleek dat het opvragen hiervan bij sommige users wel een minuut duurde. Toen dit duidelijk werd, is die functie enige tijd uitgeschakeld geweest. Nu met de juiste index duurt het nog maar milliseconden. Zo groot kan het verschil dus zijn, maar vaak is het verschil kleiner. De afgelopen maand zijn er ruim 50 wijzigingen doorgevoerd, waarvan ongeveer de belangrijkste helft tijdens de downtime, een klein deel overdag en de rest ’s nachts (zie oa. hier en hier).

Maar vaak is het niet zo eenvoudig om een index toe te voegen en direct resultaat te zien. Soms moet ook de software aangepast worden of moeten de gegevens net iets anders worden opgeslagen. Dat is oa. gebeurd bij het fotoboek en de eerdergenoemde frontpageuserhistory. Het effect is gelukkig merkbaar: was FOK! tot een maand geleden nog wel eens langzaam, sindsdien ben ik dat niet meer tegengekomen. Ook wat getallen die de database zelf bijhoudt, geven aan dat hij het rustiger heeft.

Momenteel is Breuls bezig met nieuwe software voor de frontpage, FOK!sport en FOK!games. Dat is de volgende stap met verbeteringen op databasegebied. Het is te hopen dat we daarmee alle traagheid voorgoed achter ons laten.

FOK! traag; even down

FOK! is sinds gisteren een stuk trager dan-ie moet zijn, vermoedelijk vanwege een proces in de databaseserver dat, hoewel al vriendelijk verzocht te stoppen (lees: het proces is al gekilled) nog steeds aanwezig is en veel resources vreet.

Tot dit moment was het idee om gewoon te wachten tot het proces zichzelf beëindigd had, in de verwachting dat dat niet zo lang meer zou duren. Maar aangezien het al de volgende ochtend is en we nog geen verbetering hebben, gaan we er even wat hardere acties tegenaan gooien.

De sites gaan zo even plat zodat we de ruimte hebben voor MySQL om te stoppen en te starten. Da’s in principe een taak van minder dan een minuut, maar we nemen het zeker voor het onzekere.

FOK! gaat, kortom, zo even down zodat we de boel weer sneller kunnen maken.

Update: na het afsluiten van processen, een reboot en een rondje crash recovery zijn we er weer. Uurtje downtime; langer dan gewenst maar we kunnen er weer tegenaan!

Database downtime

Omdat ik mezelf vandaag tot ‘ziek’ reken maar je niet in het duister wil laten tasten, even een kort bericht.

De MySQL server heeft vanmorgen wat problemen ondervonden (welke zijn mij nog niet duidelijk, maar dat zoeken we absoluut uit) waardoor een schone herstart niet mogelijk is. Er is daarom nu een reparatieproces aan de gang, waarna we net als gisteren de backupronde gaan herhalen.

Zet dus gerust even een DVD’tje op.

Down voor noodzakelijk onderhoud

De huidige downtime is een gevolg van een storing in de database die vannacht optrad en de site onbereikbaar maakte. Nadat we ons over het probleem hebben gebogen en verholpen (een weinig boeiende overbelasting van de DB), bleek uit een controle dat de storing ervoor zorgde dat het backup-proces vannacht niet goed heeft gelopen.

Omdat we onszelf later niet voor het hoofd willen slaan worden daarom eerst de backups opnieuw gemaakt, voordat we de site weer online gooien en vrolijk verder FOK!ken. En daar is momenteel het wachten op.

We zijn inmiddels klaar, dus je kunt weer FOK!ken.

Om nog een openstaande vraag te beantwoorden: waarom doen we de backups niet terwijl we de site online gooien? Gewoon, uit veiligheid. We willen eerst het backup-proces de ruimte geven onze data veilig te stellen, voordat we diezelfde data openstellen voor usergebruik. Doen we normaal gesproken niet, maar vandaag nemen we het zekere voor het onzekere.

Database downtime

Zoals je hebt gemerkt is FOK! down en melden de sites dat er zaken mis zijn in de database. Dat is inderdaad wat er speelt.

Om het iets verder toe te lichten: we hadden last van een aantal performanceproblemen door een aantal specifieke processen in de MySQL server. Het correct verhelpen van deze server bleek uiteindelijk alleen te kunnen door de boel heel even plat te gooien, met als risico dat bij de herstart MySQL wat herstelwerkzaamheden moest uitvoeren. Het risico hieraan is overigens downtime, geen dataverlies.

Dat laatste is nu bezig: MySQL draait, maar accepteert even geen normaal verkeer. Als je nog even kunt wachten kun je straks weer normaal FOK!ken.

Hee we zijn down

Verdomd, nu je het zegt! Voor zover wij kunnen zien is de situatie als volgt: er is een server plat. Stop. We zijn er mee bezig. Stop. We houden je op de hoogte. Stop.

In de tussentijd, hier is een lolcat:

En sinds even voor middernacht doen we het weer. Yay! Happy FOK!king!

De Formule 1 punten: wat was er aan de hand?

De afgelopen weken hebben we een, voor ons doen, redelijk ingrijpend besluit genomen: we hebben een lopende sportmanager tijdelijk stopgezet omdat we niet konden garanderen dat het zonder technische ingreep verder correct kon verlopen.

De reden hiervoor was dat vanaf ronde 4 van dit F1-seizoen er fouten optraden in de puntentelling van team-onderdelen en daardoor in de stand van de meespelende gebruikers. Reparatie-acties door de redactie maakten dit erger, omdat het systeem er niet (correct) op rekende dat een niet-ontwikkelaar correcties zou uitvoeren. Chaos alom, en bij gebrek aan ontwikkelaar (Light heeft na jaren hard werk en steun en toeverlaat te zijn geweest enige tijd terug zijn taak als sporttechneut neergelegd) een lastige situatie om te verhelpen.

Dus ik ben erin gedoken. Ik speel zelf niet mee, en ken het spelsysteem dus ook niet. Het is gebouwd voordat ik me met sport of IT binnen FOK! bemoeide en ik ben nooit betrokken geweest bij de ontwerp- of bouwfase (de functie IT-admin bestond nog niet, ontwikkelaars deden alles uit zichzelf zonder toezicht). Documentatie was er nauwelijks, dus het werd een rondje bladeren door code en database-schema’s. Een ongetwijfeld bekend scenario, maar bijzonder ongewenst.

Omdat niet goed te achterhalen was hoe een ‘reset’ of ‘reverse’ van een ronde kon worden uitgevoerd, en omdat ik er geen vertrouwen in had (heb? mwah, had) dat de nog te komen speelrondes foutloos verlopen, wilde ik de situatie rigoureuzer verhelpen: het systeem miste een algehele hercontrole en -berekening, dus, zo besloot ik in mijn, ahum, wijsheid, dat die er dan maar moest gaan komen.

Een algehele hercontrole en -berekening is, in mijn ogen, een procedure die je moet kunnen uitvoeren op de huidige status van de database om de fouten die daarin zijn opgeslagen eruit te halen. Wat het in de basis doet is opnieuw beginnen: de punten gaan op nul, de budgetten gaan terug naar het startbedrag en alle gedane handelingen worden vervolgens herhaald totdat we zijn waar we moeten zijn: bij een correcte stand. Let wel: helemaal naar nul is dat niet. Immers: van enkele rondes zijn al uitslagen bekend en alle users hebben al een team samengesteld, hierin gewisseld, er punten voor gekregen, etcetera. Het is dus belangrijk om niet alleen de punten te herberekenen, maar ook om het budgetverloop (inclusief aankopen, verkopen, wisseltarief en het gewonnen budget door het aantal punten) correct te laten verlopen. Het einddoel is ervoor zorgen dat iedereen het aantal punten heeft dat hij of zij heeft verdiend, inclusief het bijbehorende budget, zodat het spel de rest van het seizoen weer correct verder kan worden gespeeld.

Om dat te bereiken heb ik me verdiept in code en database en ben ik gaan testen. Wat voor data krijg ik uit deze query? Wat gebeurt er als ik dat vergelijk met dit? Klopt het dat ik een correct puntenaantal voor deze motor krijg als ik dit en dat tegen elkaar houd? Dit alles is een proces van code analyseren, stukjes code schrijven en combineren met de bestaande codebase en de resultaten aan de sportredactie voorleggen ter controle. “Nee, dat budget is veel te hoog.” Oh, back to the drawing board dan maar.

Een lang proces, zoals je zult begrijpen. Code moet geschreven, getest en na controle herschreven worden en voorkomen moet worden dat er fouten optreden. En dat is waarom het allemaal zo lang duurde. Niet alleen omdat dit een lang proces is, maar ook omdat ikzelf qua takenpakket niet beperkt ben tot sport-ontwikkeling. Je zult begrijpen dat dit een situatie is die wordt veroorzaakt door een gebrek aan ontwikkelaars. Bovenstaand verhaal verklaart crystal clear waarom we dedicated ontwikkelaars nodig hebben. Die komen er ook. Zelfs deze week is het team uitgebreid met twee ontwikkelaars voor sport, en na een periode van code lezen kunnen zij ervoor zorgen dat sportliefhebbers ongestoord hun managerspellen kunnen spelen.

En die oude F1-managercode? Dit is de laatste keer dat we die gebruiken. Er zitten goede concepten in, en deze zullen in een nieuw functioneel ontwerp worden gegoten zodat we met een schone lei kunnen beginnen. Nieuwe managers, met minder bugs, betere controle van processen en uiteindelijk (het einddoel) meer spelpezier, dat is waar we op uit zijn.

FOK! op Twitter

Sinds gisteren is er een post-to-twitter procedure verwerkt in het CMS waarmee het nieuws op de frontpage wordt gepost. Als gevolg daarvan meldt de Twitter-user @foknieuws al het, well, FOK!nieuws. Mocht je gebruik maken van Twitter en wel prijs stellen op nieuws tussen de updates, volg deze user dan.

De implemenatie is overigens nog beta, maar aangezien het best redelijk lijkt te werken denk ik niet dat er veel aan zal wijzigen.

Noodonderhoud

Op dit moment is er noodonderhoud aan het filesysteem van een van onze servers. Om te voorkomen dat de sites kreupel over het scherm kruipen hebben we alles even offline gehaald zodat iteejer ongestoord reparaties kan uitvoeren.

Deze downtime duurt natuurlijk zo lang als nodig, maar ook zo kort mogelijk. Relevante aanvullende updates melden we hier.

Excuses voor het ongemak!

Update 12.30: de verwachting is dat we niet voor een uur of 2 vanmiddag weer online zijn. Er moet het een en ander ter plekke gebeuren, en de reistijd is meer dan een uur.

Update 14.30: de fileserver is nog niet gereed, dus de downtime duurt nog even voort.

Update 15.30: de server is weer up. Na een aantal controles te hebben uitgevoerd lijkt de rest van het serverpark gewoon door te tuffen alsof er niets aan de hand is, met andere woorden: we zijn er weer!

Omdat we zo tegen het einde van de inschrijving van de EK Pool een aantal uren onbereikbaar waren, wordt er nagedacht over een compensatie voor diegenen die nog wilden inschrijven of wijzigingen maken, in de vorm van een verlenging van de inschrijftermijn. Zodra we bepaald hebben wat het precies wordt, lees je dat op FOK!sport.