Server- & netwerkstatusmeldingen XII

Problemen met de servers en de netwerkverbinding van Tweakers.net worden in deze .plan gemeld. De laatste informatie over de serverloads en -uptimes kun je volgen op de statistiekenpagina.

Statusmeldingen

10-04-2013 Vanwege onderhoud aan de sessiedatabase kan het voorkomen dat je een 'uitgelogte' pagina te zien krijgt als je Tweakers bezoekt. Dit onderhoud is naar verwachting rond 10 uur afgelopen.

23-03-2012 Door een klein foutje bij het opslaan van een config-file (het eerste karakter, de < van <?php, was verdwenen) kwam uiteraard de hele inhoud van dat configuratiebestand online te staan... Gelukkig was het verder een klein bestand en kon je niet zomaar wat met die wachtwoorden doen, maar het blijft natuurlijk een schaamtevol moment om te zien gebeuren

Voor zover wij na kunnen gaan heeft dit verder geen directe impact op de beveiliging van onze gegevens gehad en de wachtwoorden zijn ondertussen aangepast.

Voor degenen die ons dit meldden (via het forum, per mail, op irc, bij reacties, telefonisch, op twitter, etc): bedankt voor het informeren!

Het goede nieuws is dat we nu wel een redundante opstelling van onze memcached hebben en sinds vandaag ook gebruiken, waardoor daar minder kans op downtime is. En dat we nu ook gebruik maken van de nieuwe mongodb-servers.

28-02-2012 En toen had onze MongoDB server het even heel moeilijk om vrij geheugen te vinden. Dat kwam omdat hij bijna 50% van het geheugen gebruikte en MySQL de andere 50%. Na een restart van MongoDB gebruikt hij weer netjes 0.3% van het geheugen en hoeft de server ook niet zo hard meer te swappen.

20-02-2012 Zoals je al in een eerdere review hebt kunnen lezen, zijn we druk bezig met Project Phoenix. Op dinsdag 21 februari, gaan we de nieuwe netwerkhardware in gebruik nemen. Tussen 13:00 en 15:00 uur gaan we de servers overprikken en verwachten we een downtime van maximaal een half uur.

Update 21-02-2012 Alle kabeltjes zijn omgeprikt, en alles werkt weer :)

Reacties (61)

Waar is de tijd dat de sysadmins nog fanatiek de updates rond middernacht uitvoerden?

Er is al eens eerder in een review verteld dat ze dit niet meer 's nachts doen. Voornamelijk omdat het een niet lekker tijdstip is om in te werken, waarbij je goed je concentratie moet hebben.

Er is al eens eerder in een review verteld dat ze dit niet meer 's nachts doen. Voornamelijk omdat het een niet lekker tijdstip is om in te werken, waarbij je goed je concentratie moet hebben.

Mwoah, als je er een beetje aan gewend bent is 't geen probleem. Maar t.net doet z'n eigen onderhoud en kan dus zelf besluiten dingen overdag te doen. Klanten anders dan jezelf echter worden daar meestal minder blij van.

Mwoah, als je er een beetje aan gewend bent is 't geen probleem. Maar t.net doet z'n eigen onderhoud en kan dus zelf besluiten dingen overdag te doen. Klanten anders dan jezelf echter worden daar meestal minder blij van.

Dan zou ik je klant maar eens vertellen wat de voordelen zijn om als IT'er overdag je updates en changes e.d. te doen. Daarmee behouden ze een betere kwaliteit van dienst, willen ze die niet, kunnen ze altijd nog weg. Beetje nonsens antwoord dus. Meeste bedrijven zijn niet afhankelijk van het internet.

En jullie geen overurenvergoeding krijgen?

Vertrokken met de ooievaars die hun lading afleverden denk ik

Dat was vroeger, toen ze overdag nog ergens anders werkten en t.net er bij deden.

Ik geef ze geen ongelijk, t.net server beheerders zijn ook gewoon werkende mensen

1) Met al die nerds hier die vaak nachten doorhalen om te proggen is overdag juist het moment dat er minder mensen last van hebben!
2) Zie post van AW_Bos.
3) Kijk even bij "Gerelateerde content"; dit is de eerste keer sinds begin augustus (dik een half jaar geleden) dat er überhaupt downtime is. Server admins die zo'n goed werk leveren die hebben het wat mij betreft wel verdient om niet 's nachts te hoeven werken.

offtopic:
ps. Ik zag de titel "Server- & netwerk..." en het eerste wat ik dacht was "Oh ja, die hebben we ook nog..., da's lang geleden!"

[Reactie gewijzigd door robvanwijk op 22 februari 2012 07:57]

Je kan je Config file toch een directory lager zetten / toegang weigeren van buiten af?
Een van de eerste dingen die ik mogelijk maak als ik een website online moet zetten.

Dat is bij ons ook zo, maar dan moet je hem nog steeds inladen in je webpagina. En als hij dan als tekst geparsed wordt ipv php, dan krijg je dus dit soort situaties.

Eventueel zou je nog wel een output buffer kunnen gebruiken die je weggooit op het moment dat je gaat renderen (er van uitgaande dat dat een op zichzelf staande fase is).

De database servers van T.net zijn alleen intern bereikbaar (bron: http://gathering.tweakers...message/37915539#37915539 ), tevens zijn de gebruikersnamen en wachtwoorden toch al veranderd waardoor de potentiële hacker er niets mee kan.

Het is dan een beetje weggegooid geld voor een probleem dat toch niet weer zal voorkomen. Laat ze maar focussen op de nieuwe versie van T.net & Project Phoenix.

En daar hebben ze dus parse_ini_file voor: dan kun je netjes (gegroepeerde) configuratie variabelen laden vanuit een tekstbestand, zonder risico te lopen dat die waarden plots in je output komen.

Moet je er uiteraard wel voor zorgen dat gebruikers van buitenaf niet bij die configuratie files kunnen, maar dat is triviaal door ze buiten je webroot op te slaan.

Klopt, alleen als je deze include maakt dat verder niet zo veel uit.

wat moet ik morgen, nu weer, die 2 uur gaan doen.......

Maximaal een half uur bedoel je... tenminste, als alles gaat zoals gehoopt. En we weten allemaal hoe het in de IT-wereld gaat met verwachtingen...

Ik neem aan dat ze het in parallel opstellen en vervolgens letterlijk de UTP kabeltjes van de server overprikken. Mogen hopen dat het op voorhand al geconfigureerd en getest is.

Vroeg me net hetzelfde af ...

Sowieso moet je wachtwoorden niet leesbaar opslaan

En hoe zie je dat precies voor je in dit geval? Dat script moet toch verbinding maken met de database en heeft daarvoor het bijbehorende wachtwoord nodig...

Dat wachtwoord is bij elke pageview nodig. Hoe stel jij voor het wachtwoord op te slaan?

Door een klein foutje bij het opslaan van een config-file (het eerste karakter, de < van <?php, was verdwenen) kwam uiteraard de hele inhoud van dat configuratiebestand online te staan... Gelukkig was het verder een klein bestand en kon je niet zomaar wat met die wachtwoorden doen, maar het blijft natuurlijk een schaamtevol moment om te zien gebeuren

Ben ik wel benieuwd waarom deze fout zich niet op een acceptatieomgeving heeft voorgedaan, ik was in de veronderstelling dat jullie geen hotpatches uitvoeren buiten het reguliere deploymentproces om?

Daarnaast lijkt het me dat wanneer er een dergelijke error optreedt php besluit een statuscode != 200 te versturen, waardoor de cache (Varnish?) deze uberhaupt niet cachet?

Omdat juist configfiles voor de database vrijwel nooit identiek kunnen zijn

Uiteraard (gelukkig) niet

Wij hebben dit opgelost door een systeem in te zetten waarop de wachtwoorden van alles separaat worden opgeslagen (ja, dit is wel enigzins zwaar beveligid). Vervolgens wordt in het deployment proces deze wachtwoorden in de config files gezet.

Zo ziet een config file in git er bijvoorbeeld zo uit:
<?php
$config = array('password' => '###MYSQL_PASSWD###');
?>

Mocht iemand daar dan iemand (per ongeluk) van maken:
?php
$config = array('password' => '###MYSQL_PASSWD###');
?>

... dan was dit voorkomen geweest. Niet zozeer als kritiek bedoeld, maar wellicht iets om over na te denken

Ergens staat toch de waarde van ###MYSQL_PASSWD###? Sterker nog, zoals je al zegt wordt ie bij de checkout/deploy dan automatisch vervangen wordt en dan was er precies hetzelfde probleem ontstaan?

[Reactie gewijzigd door ACM op 23 maart 2012 11:41]

Nee, want dan had er gestaan '<?php' aan het begin. Had je die weggelaten in je scm, dan was dat in acceptatie al opgevallen.

Uiteraard, je moet ook een keer je wachtwoorden veranderen in zo'n wachtwoord administratie systeem, maar door dat niet rechtstreeks in je code te doen kan je dat wel 3 keer dubbelchecken zonder dat dat je productieomgeving aantast.

Edit: post van ACM is aangepast(?), daardoor is het eerste alinea'tje minder relevant.

[Reactie gewijzigd door Freeaqingme op 23 maart 2012 11:45]

En dan gaat er in die andere config file iets mis. Dan heb je geen database connectie. Weliswaar nog niet zo erg als de login gegevens online gooien. Maar nog steeds ongewenst.

Ik zet tegenwoordig om deze reden (of bijvoorbeeld als apache zou besluiten PHP niet meer te parsen) wachtwoorden in een vhost config. In de vhost config van apache doe je dan:

SetEnv MYSQL_PASS #password

In PHP is die dan te bereiken via

$_SERVER['MYSQL_PASS']

Je hebt dan gelijk de mogelijkheid om per omgeving (vhost) een andere database te gebruiken terwijl je PHP files van acceptatie naar productie niet veranderen.

Maar wel als nadeel dat je je webserver moet restarten voor een simpele config wijziging.

Herstarten? Simpele SIGHUP moet toch voldoende zijn

Dit is ook de manier die Symfony2 adviseert, leuk detail is dat elke ENV waarde die begint met SYMFONY__ automatisch word meegenomen in de parameterslijst.
http://symfony.com/doc/cu.../external_parameters.html

Een wachtwoord versleuteld opslaan is leuk, maar hoe haal je dat dan weer terug met een ander wachtwoord? En waar sla die dan weer op daar komt bij dat voor elke reqest een encryptie toepassen best zwaar is.

Ongeacht welke manier je ook bedenkt, als het proces waarmee je het uitvoert de configuratie kan lezen is er altijd wel een manier om er achter te komen.

Maar er is natuurlijk een groot verschil tussen een include en iets parsen.

[Reactie gewijzigd door s.stok op 24 maart 2012 11:30]

14:00uur: Diablo3-keys weggeven is iets opgeschoven dus?

"Gisteren geen Diablo III-key weten te bemachtigen? Vanaf 15:30 geven we er op ons forum nog eens 150 weg"

Bron: https://twitter.com/tweakers/status/171937768564473857

Op dit moment krijg ik 503's van Varnish, officiele error-pagina's van de diverse webservers, en zelfs witte pagina's geserveerd op elk onderdeel van Tweakers.net, zijn jullie weer aan het prutsen?

Had hetzelfde idee, maar gok dat we iets te snel zijn voor zo'n update

En daar gaan we weer. Ik had er net 2 van Astraeus en Aphrodite (meen ik).
EDIT: Dat moet waarschijnlijk Aphaea zijn

[Reactie gewijzigd door Xesxen op 1 maart 2012 12:57]

mbt MongoDB, stiekem zou die op een eigen server of cluster moeten draaien; idealiter draait Mongo op een systeem waar de volledige inhoud in het geheugen past.

Daarom hebben wij vandaag ook twee servers opgehangen waar mongo zo'n 48GB geheugen voor zichzelf krijgt (ok, en wat memcached en activemq, maar dat is max 2-4 gig)

ik dacht dat jullie gingen melden dat de webservers bijna onderuitgingen vanwege een bepaald script wat draaide nav de beta key give-away...

valt me weer tegen dat het spul zo goed draait