Server- & netwerkstatusmeldingen

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 Statusmeldingen

07-12-04 In verband met een storing in het netwerk van onze hostingprovider en sponsor TrueServer is Tweakers.net sinds het eind van de middag moeilijk bereikbaar. De storing heeft betrekking op het netwerk tussen de locaties Redbus Interhouse en TeleCity 1 op het Amsterdam Science Park en heeft tot gevolg dat het algemene VLAN tussen Redbus en TeleCity 2 offline is. Hierdoor zijn systemen die op Redbus Interhouse staan maar hun gateway op Telecity 2 hebben voor de buitenwereld onbereikbaar.

Als gevolg van de storing moet het netwerkverkeer over andere links zoals bijvoorbeeld Level3 gerouteerd worden en dat resulteert in de nodige traagheid. De overlast verschilt per provider.

Meer informatie van TrueServer:

Een van de glasleveranciers van trueserver kampt met een fiberbreuk. Naar aanleiding hiervan hebben we een performance probleem op het interne netwerk op Telecity en zijn wij genoodzaakt om binnen nu en een uur onderhoud te plegen op een van de twee Juniper M20's op Telecity. Tijdens dit onderhoud zullen er verschillende interfaces op de router gewisseld moeten worden. Deze werkzaamheden zullen ongeveer 45 minuten in beslag nemen. Een van de interfaces die gewisseld gaat worden is de glasmodule die aangesloten is op een van de core-switches op Telecity er zal daarom een onderbreking in de connectivity plaats vinden. We verwachten dat dit een totale downtime van maximaal 15 minuten met zich mee zal brengen.

De onderbreking van de connectiviteit heeft inmiddels plaatsgevonden maar men is nog aan het switchen.

21-09-04 Vannacht zal het forum meer dan een uur offline zijn. De nieuwe database server (een dual Opteron 244, met 8GB geheugen) zal de taken van de oude database server overnemen. Om dataverlies te vermijden zal het forum enige tijd niet bereikbaar zijn. De werkzaamheden beginnen na middernacht.

11-09-04 De fileserver is heel even offline geweest om een nieuwe kernel te proberen, dit ging niet geheel volgens plan.

11-09-04 Zoals al gemeld in het aboneeforum, wordt dit weekend de mailserver overgezet naar een andere server, dit ging helaas een beetje met horten en stoten, op dit moment wordt eraan gewerkt en we verwachten dat het probleem vrij snel is opgelost.

17-08-04 De fileserver is nog steeds niet stabiel. Ondanks dat hij nu niet midden in de nacht zichzelf ophangt heeft hij wel andere problemen. Hierom zullen we er vanmiddag wederom mee bezig gaan en een aantal dingen bij langs lopen. De search zal uitgeschakeld zijn, de rest van de site zal enige minuten downtime te verduren krijgen.

11-08-04 De fileserver is ondanks een aantal veranderingen nog steeds niet stabiel. Ondanks dat hij nu niet midden in de nacht zichzelf ophangt heeft hij wel andere problemen. Daarom zullen er vanavond enige diagnostische programma's gedraaid worden waardoor de search, plaatjes en usericons het tijdelijk niet zullen doen.

27-05-04 Vannacht rond een uur of twee is de fileserver gecrasht. De oorzaak van deze crash is een al langere tijd minder goed functionerende IDE raid. We waren al bezig met het zoeken naar alternatief voor deze raid, maar uiteindelijk heeft hij het sneller laten afweten dan wij een vervanging konden regelen.

Op het moment werken de volgende onderdelen niet, of minder goed: De search van GoT, plaatjes op de frontpage, usericons van users op GoT, private storage en fotoalbums van de abonnees. Er is naar verwachting geen data verloren gegaan, maar de data zal helaas enige tijd niet bereikbaar zijn.

Update 8:25: Daniel en Kees zijn inmiddels in Telecity aanwezig om de problemen te verhelpen. Het vermoeden is gerezen dat de middelste positie van de IDE-bay kaduuk is. Met de schijven zelf lijkt niets mis te zijn.

Tegelijkertijd heeft (ter verhoging van de feestvreugde) forumserver Apollo ook besloten er de brui aan te geven. Slechts met een hele harde power-cycle (voeding eruit en er weer in) was Apollo weer tot leven te wekken. Op dit moment wordt een backup teruggezet om de corrupte database te vervangen. Omdat de backupserver er om 02:00 mee ophield en de backups van Apollo normaliter om 04:00 worden gemaakt houdt dit mogelijk in dat alle postings en topics van gisteren verloren zullen gaan. Uiteraard doen we er alles aan om dat te voorkomen.

Update 9:35: Om te voorkomen dat alle postings, topics en users van de afgelopen 30 uur verloren gaan wordt de database van Apollo op dit moment gedumpt en vervolgens geforceerd weer ingelezen. Daarmee hopen we het overgrote deel van de data te kunnen herstellen. E.e.a. heeft wel tot gevolg dat Apollo nog een aantal uurtjes zoet zal zijn. Atlas is inmiddels weer hersteld, maar de reden van het uitvallen is ons tot nu toe nog niet duidelijk. Er is niets kapot gegaan, dus waarom hij er afgelopen nacht ineens mee ophield na ruim anderhalve maand probleemloos gewerkt te hebben is een raadsel. Bijkomend probleem is dat de situatie alleen verbeterd kan worden door een volledige herinstallatie.

Update: 28-05-04: De recovery van de database gisteren is gelukt, echter hield atlas er vannacht weer mee op. Atlas is onderhand weer gefixt, en zal een aantal taken verliezen zodat hij niet om de haverklap over de kop gaat.

10-04-04 Vanmiddag vanaf 15:00 uur zullen de schijven (1 x HP/Seagate 36,7GB 10k rpm SCSI en 1 x 200GB Maxtor 7200 rpm) die afgelopen dinsdag overleden zijn vervangen worden. Omdat IDE-schijven niet hot-swappable zijn zal fileserver Atlas daarvoor enige tijd uit de lucht moeten. Verder zal van de gelegenheid gebruik gemaakt worden om een tweede Xeon-processor in development-server Achelois te plaatsen.
Als alles goed gaat zal er nauwelijks downtime zijn.

Update 16:15 uur: De werkzaamheden zijn zonder problemen verlopen en alles draait weer zoals vanouds .

6-04-04 Het forum en de frontpage waren enige tijd down. Dit was het gevolg van een overleden schijf in de SCSI-array van de fileserver.

Alhoewel er twee hotspares aanwezig zijn (omdat de fileserver nogal eens SCSI-disks opeet) heeft de RAID-controller eenzijdig besloten om het filesystem van de array stuk te maken, waardoor er een backup teruggezet moest worden van vannacht 2.00 uur. Hierdoor kan het zijn dat vandaag geüploade usericons, private storage of een foto in het fotoalbun, helaas verdwenen zijn.

Daar wij nu de RAID-controller niet meer vertrouwen zal deze zo snel mogelijk door een nieuwe controller vervangen worden, eentje die niet de RAID-array met zich meesleept als hij een hotspare rebuildt.

Tevens zal de search van het forum langere tijd niet bereikbaar zijn daar deze opnieuw geïndexeerd moet worden.

8-03-04 Als alles meewerkt gaan we dinsdagmiddag de forumsoftware van een upgrade voorzien. Het grootste deel van het database-onderhoud is al gedaan dus de downtime zal redelijk kort zijn; we gokken op ongeveer een uur. Mocht alles niet op schema lopen, dan wordt het pas woensdagmiddag dat we het updaten.

5-03-04 Vanmiddag wordt er op kleine schaal onderhoud gepleegd aan de servers. De verwachting is dat de downtime mee zal vallen. De langste downtime zal Atlas hebben, in deze server wordt een nieuwe netwerkkaart geplaatst. We zijn er echter vrij zeker van dat dit binnen enkele minuten geklaard kan worden.

29-02-04 GoT is rond 23:00 uur uit de lucht gehaald om enige wijzigingen aan de message table van de database door te kunnen voeren. Deze aanpassingen zijn nodig om de upgrade naar React 1.9.2 mogelijk te maken. Er is voor gekozen om dit voorbereidende werk op zondagnacht uit te voeren, om de overlast tot een minimum te beperken. De schatting was dat de operatie minstens vijf uur in beslag zou nemen. Het voordeel is dat er bij de daadwerkelijke upgrade naar de nieuwe versie van React door deze voorbereiding waarschijnlijk geen langdurige downtime zal zijn. Rond een uur of 1 konden we echter concluderen dat de database een stuk sneller is dan de vorige keer, na amper 65 minuten waren alle aanpassingen doorgevoerd.

11-02-04 Zoals men al wel heeft kunnen bemerken is de upgrade gister niet helemaal vlekkeloos verlopen. De meeste downtime was niet de switch, maar Artemis die na een ongeplande reboot geheel onverwacht de geest gaf en helemaal opnieuw geinstalleerd moest worden. De combinatie van hardware die wij hebben (een Tyan opteron plank met een Megaraid controller erop, evenals een zeer trage boot) zorgde ervoor dat ik de hele avond nog van het geluid van een stapel servers heb kunnen genieten in telecity. De grootste problemen (oa een webserver die om onbekende redenen down ging en niet door de loadbalancer eruit gepikt werd) zijn nu opgelost. We hopen vanmiddag nog een aantal dingen op te lossen die nu nog liggen.

10-02-04 Vandaag zal de interne switch van het serverpark vervangen worden door een 3Com 3824 Gigabit Ethernet switch. Verder zal Achelois (development-server) vervangen worden door een HP Compaq Proliant DL140-server (dual Intel Xeon 2,4GHz, 1GB geheugen, twee 80GB ATA schijven, 1U rackmount) en zal een Cyclades Alterpath ACS console switch in het rack gehangen worden. Op de werking en het nut van dit laatste apparaat zullen we binnenkort verder ingaan. De werkzaamheden zullen enige downtime met zich meebrengen omdat Atlas enige tijd down zal moeten voor het plaatsen van een Intel Pro/1000 MT Dual Port netwerkadapter. Zie voor meer informatie Serverstatus (5 minuten vertraagd)

Reacties (113)

[klaaz]

Ik heb hetzelfde ooit meegemaakt in een IBM file server. Een aantal engineers hebben 12 uur lang geprobeerd de zaak te repareren, niet gelukt. Uiteindelijk een nieuwe schijf erin (4 uurs SLA waarna ze doodleuk na 36 uur een nieuwe schijf kwamen brengen)

restore en klaar. Bedrijf 2 dagen plat.

Gezocht naar de oorzaak bleek aan de combinatie 3com Gbit NIC en de IBM RAID Controller te liggen... Intel NIC erin en nooit weer problemen gehad...

[Fauna]

Ik snap niet dat de crash van de fileserver meteen heel t.net en GoT naar beneden haalt?

(en ik zie nu ook dat iedere server behalve Apollo is gereset )

[aKra]

(en ik zie nu ook dat iedere server behalve Apollo is gereset )

Ze wisten niet meer op welke APC poort de FileServer zat

[Daniel]

Jawel...maar dat leverde niks op vreemd genoeg. Toen heeft Kees een aantal andere poorten geprobeerd (misschien vergisten we ons toch) maar dat maakte niets uit. Misschien accepteert deze server geen power cycle op beide voedingen tegelijk.

[Gromba]

http://www.teamnewton.nl/blaat

Ik heb alleen geen idee wie hij was, maar ach

[decramy]

Wow, wat zie k nu? Alles down

[img]http://picserver.org/view_image.php/Q160L3RH4KA/128[/img]

[Femme]

De serverstats werden niet geupdate waardoor alle servers een kruisje kregen.

[Anoniem: 116850]

[Cynisch]

Het forum zal een uur down zijn, ik ga er maar weer vanuit dat de downtime tot ver in de ochtend zal duren.

Er gaat bij t.net nogal wat mis altijd, er crasht vanalles, dingen gaan kapot. Waarom overkomt dit tweakers en nooit andere sites? We zullen het er maar op houden dat tweakers.net er ruchtbaarheid aan geeft en andere sites niet (je merkt het pas wanneer het niet meer werkt).

[Kees]

De laatste keer dat er serieus iets mis ging was 27-5. en dat was de enige keer dit jaar.

Nu werk ik wel iets vaker dan 1 keer per jaar. Als je er niets van merkt, betekend het niet dat ik niets doe. Ik probeer meestal zoveel mogelijk donwtime te voorkomen, dus van de meeste vervangingen merk je weinig tot niets. In dit geval was dat niet mogelijk, dus melde ik dat we down gingen. En inderdaad, we zijn 1 uur en 10 minuten down geweest, ongeveer 5 minuten korter dan ik berekend had.

En verder praat je gewoon poep, crashen deed dit jaar alleen atlas (brak geheugen), en apollo (bugs in de bios) 1 keer. Artemis, athena, achelois, arethusa, abaris, acidalia, argus, alle switches, masterswitches e.d., zelfs de fok servers, aphrodite, alicia en athena zijn de afgelopen twee jaar niet langer down geweest dan geplanned. Voor het gemak vergeten we dan maar even dat we op een gegeven moment meerder servers met meer dan een jaar uptime hadden.

En inderdaad, als andere sites plat liggen dan wordt er niets over gemeld, wij zijn dan mischien een vreemde eend in de bijt dat we het de community melden, maar een site als nu.nl/telegraaf.nl heeft geen community die zij op de hoogte moeten houden.

[Anoniem: 116850]

Hmmm

Tweakers.net bestaat al langer dan twee jaar, voor jouw tijd was het in elk geval wel erg, in 2001 geloof ik was er een big crash 3, en dus kennelijk daarvoor ook nog twee...

Niks persoonlijks verder.

[jwpmzijl]

10 uur geen GOT, dat wordt afkicken:

Maar even serieus, natuurlijk gaat een upgrade van een systeem als GOT niet on-the-fly en uiteraard is de zondagavond daarvoor het meest aangewezen tijdstip. Maar ik geef in overweging om dit voortaan aan te kondigen.... (als ik het gemist heb dan heb ik niet op de juiste plaats gekeken - af was het te ver verstopt - en ja hoor het was aangekondigd en ik heb niet goed opgelet

De schatting van 10 uur is die alleen nodig om alle records door te lopen of zit daarin ook tijd gecalculeerd voor het maken van een backup en ander onderhoud. Ik zou nl. verwachten dat Artemis met 6 gig en 2x opteron 246 sneller door zijn tabellen zou lopen .

[jwpmzijl]

En de Opterons i.c.m. 6 gig en LSI controller hebben toch met een record-tempo de records doorgeploegd.

Zou leuk zijn om de serverbelasting tijdens de werkzaamheden te weten.

[Femme]

De serverbelasting (load, processorgebruik, disk I/O's, mysql stats enz.) kun je hier bekijken. Overigens heeft Apollo op dit moment maar 4GB omdat 6GB nog niet stabiel wil draaien. Dit probleem wordt waarschijnlijk veroorzaakt door een combinatie van processor, moederbord en RAID-adapter, maar zeker weten we dat niet (en helaas is het ook moeilijk te achterhalen omdat we natuurlijk niet zomaar van alles kunnen gaan uitproberen op een productieserver).

We gaan met nieuwe hardware proberen om wel een systeem te maken dat goed werkt met 6GB. Het extra geheugen kan goed gebruikt worden op Apollo.

[jwpmzijl]

Chips, ik had nog niet verder gekeken dan de samenvattingen voor alle servers bijeen. Blijkt dat ik gewoon door had kunnen klikken. Hoe simpel kan een mens worden

[chem]

het was een dag ofzo geleden aangekondingd.

[DarkX]

Er heeft wel degelijk vandaag (of eerder?) een aankondiging gestaan in MED op GoT, lijkt mij toch voldoende

Daarin was trouwens een schatting van 5 uur gemeld, maar ik denk dat ze tactisch keer 2 gedaan hebben uit voorgaande ervaring

[joepP]

Ehm,

als ik het goed begrijp leidt het trekken van een stekker uit de computer bij mySQL dus tot datacorruptie? Fijn dbsm is dat...

[Kees]

Klopt. De server hield er echter mee op voordat wij er iets mee konden doen. We hadden net atlas weer gereanimeerd en opeens deed apollo heel weinig..

Na een restart bleek daar de db verrot van te zijn. Nu zijn er wel manier om dat op te lossen (geforceerd starten, data dumpen, db importeren) maar dat duurt redelijk lang (en dat doen we nu dus)

9 van de 10 keer overleefd mysql (/ innodb) een crash, maar deze keer niet..

[joepP]

9 van de 10 keer is voor een site van jullie kaliber natuurlijk niet genoeg. Het is in mijn ogen totaal onacceptabel dat het belangrijkste deel van de site op zo'n manier onderuit kan gaan.

Zijn er geen oplossingen/alternatieven?

[Bezulba]

waarom is dit onacceptabel? ze zijn de belastingdienst niet waar alles altijd 10x gebackuped is.

het is nog steeds een site die zeer groot is, maar gerunt word door liefhebbers en niet door een groot bedrijf wat centen heeft om voor alle servers een backup te hebben

[André]

Oplossingen en alternatieven kosten geld

Als we allemaal nu een abbo aanschaffen hebben ze meer mogelijkheden iig.

[joepP]

Het zal voor hunzelf onacceptabel moeten zijn. Downtime is niet zo erg, maar dataverlies wel. Als je gebruik maakt van een dbms dat niet de integriteit van de data kan bewaren, wordt het tijd naar alternatieven te kijken.

En als die er niet zijn, of alleen duur betaald, dan moeten ze ermee leren leven dat dit zo af en toe zal gebeuren.

[marshal]

Reactie op werkeend:

offtopic:
Uit betrouwbare bron kan ik melden dat dat bij de belastinddienst ook niet altijd is.

De lijn van Helmond naar ??, iig de verbinding met Apeldoorn (denk ik, want daar zit al het ICT gebeuren) lag er vandaag uit.

Heeft van 8.30 tot 12.30 geduurt voordat de KPN op locatie was. En toen moest het probleem nog opgelost worden.

Oftewel, in die tijd kan er niemand iets doen, hooguit papierwerk.

Ik zeg natuurlijk niet dat ze daar de integriteit van de data niet waarborgen, daar ben ik wel van overtuigd. Alleen ik zou verwachten dat er minstens nog een back-up verbinding zou zijn met Apeldoorn.

Algemeen:
Maar het is soms niet te verwachten dat er een bepaalde server/verbinding/whatever onderuit gaat.

Onlangs zelf nog gehad met m'n router. Nadat dat ding een tijdje zonder stroom had gestaan deed dat ding helemaal niks meer (nouja, switchen, maar daar had ik niks aan). Dan heb ik nog geluk dat ik nog een router achter de hand heb, want anders had ik toch een week geen internet gehad.

Persoonlijk ben ik al blij voor T.net dat er nu financiele middelen beschikbaar zijn voor een nieuwe database server en andere zaken die het beheer makkelijker maken.
En vergeet niet dat (correct me if i'm wrong) het voor Kees een beetje een uit de hand gelopen hobby is, en dat hij naast T.net nog andere bezigheden heeft.

[Ritch]

Tuurlijk, een echt DBMS, neem bijvoorbeeld Oracle. Zullen we het ff niet hebben over de kosten van Oracle en allemaal code die herschreven moet worden?

[Anoniem: 13546]

Natuurlijk zijn er alternatieven! De grote redenen waarom MySQL zo populair is, is omdat het zo snel is en gratis. Andere reden die worden genoemd zijn natuurlijk dat het goed te gebruiken is met PHP, maar dat kunnen andere DBMSes (Database Management Systems) ook.
Aan de andere kant is MySQL niet ACID compatible. ACID:
A - Atomicity:elke transactie op de database wordt gezien als 1 groot geheel, dus hij wordt of helemaal uitgevoerd, of helemaal niet (niet gedeeltelijk)
C - Consistency Preservation: de database verkeert voor een transactie in consistente staat, en na de transactie gegarandeerd ook
I - Isolation: 'tusseneffecten' van een transactie zijn niet merkbaar voor de buitenwereld (andere transacties)
D - Durability: als er een 'commit' wordt gegeven (signaal van het DBMS: "data is opgeslagen en in orde") dan is die data ook bij een crash terug te halen

Het moge duidelijk zijn: Tweakers.net heeft duidelijk gemerkt dat MySQL niet ACID compatible is (vooral die "Durability" ontbrak). Een goed alternatief is PostgreSQL, ook gratis, plus veel meer functionaliteit (meer een 'echt' DBMS), maar wel iets trager (door die uitgebreidere functionaliteit). En bovendien: PostgreSQL claimt ACID-compatible te zijn!

Als je dus een database gaat gebruiken moet je de overweging maken: snel (goedkopere hardware) of safe (maar minder snel, dus meer/duurdere hardware). In web-omgevingen kun je soms overwegen om voor de snelheid te kiezen, maar persoonlijk zou ik voor een site als T.net (die zoveel dataverkeer per dag moet verwerken en opslaan) kiezen voor safe. T.net lijkt me redelijk kapitaalkrachtig (veel advertentieinkomsten), dus een goede PostgreSQL-server (met flinke hardware, zodat de snelheid van T.net er niet op achteruit gaat) moet mogelijk zijn... Dan voorkom je dus dit soort vervelende dingen!

[Kees]

De hardware en snelheid is het probleem niet. Meer de omscholing, herschrijven van de scripts etc waardoor we niet zomaar overstappen op een nieuwe db.

Postgresql houden we zeker in de gaten (en draait zelfs al op de servers) maar je bent niet zomaar om

[Anoniem: 13546]

Ik had eigenlijk gehoopt dat T.net stiekem rekening had gehouden met eventuele database-wijzigingen en zelf een db-backend had geschreven, zodat je vrij eenvoudig (zonder alle scripts aan te passen) van database kunt verwisselen...

Overigens hoeft er imho niet veel te veranderen aan queries voor een overstap, omdat vrijwel alle functionaliteit van MySQL door PostgreSQL ook ondersteund wordt... Je zou kunnen zeggen (in de taal van de logica) dat MySQL een subset is van PostgreSQL...

[Cyphax]

Als het ergste straks is dat je posts van 1 dag kwijt bent lijkt me de schade te overzien toch?

Maarre, veel succes ermee!

[FastBunny]

Wat is het adres van de webcam bij telecity ookalweer? Kunnen we kijken en misschien weer een blije kees foto maken

[MatHack]

Op de cams heb ik al sinds 8:30 geen enkel persoon gezien.

[TD-er]

er stond zojuist wel iemand in een geel-groene trui te gluren naar de racks. (met de armen over elkaar en hij keek niet al te vrolijk)

[Kees]

Dat was Daniel

[TD-er]

[cartman-mode]
Kewl, I've seen Daniel, who wants to touch me...
[/cartman-mode]

[3dfx]

@Kees: Is u degene met beige trui en zwarte broek?
(om 9.32 eveneens met armen over elkaar, lijkt wel bijeenkomst van de FNV daar )

[ripexx]

Alleen bij het vervangen van hardware zal er iemand aanwezig zijn, de rest wordt toch remote gedaan. Met de nieuwe console switch kan men zelfs remote in het bios werken dus er is geen noodzaak om in die herrie te werken.

[gomaster]

schijnbaar is daar wel een reden toe. Je moet alleen wel ff lezen wat ze schrijven

Update 8:25: Daniel en Kees zijn inmiddels in Telecity aanwezig om de problemen te verhelpen.

[ripexx]

@gomaster

Heb ik ook gedaan, het probleem met atlas is waarschijnlijk zoals aangeven een hardware probleem met de brackets van de RAID array. En apollo heeft een hard reboot nodig gehad, zelfs met de remote power switch is het niet gelukt dus dan moet je er heen, maar verder is het zelden nodig, zeker met de console switch.

[Joen]

Nu om 9.46 uur zit er een man in groene trui hurkend aan het einde van een gangetje te kijken en er liepen 2 mannen met iets roods aan langs.
Maja, allen zijn nu direct al weer weg.

[3dfx]

Hier zie ik wat bewegen:
http://cam3.telecity-2.trueserver.nl/view/view.shtml

[Grubeater]

Ik wil eigenlijk wel weten waarom Ares, Abaris en Acidalia vannacht na elkaar zijn gecrashed. De site zag er daardoor niet helemaal goed uit, mysql down.
Hier staat wel wat op GoT maar veel wijzer wordt ik daar niet van. http://gathering.tweakers.net/forum/list_messages/901027

[Femme]

Ik geloof dat ze gereboot zijn ivm een upgrade van Slackware 8.1 naar 9.1.

[Zym0tiC]

En hoe is die upgrade gegaan? Een verse install en dan config files overhevelen of doormiddel van bijv. swaret: swaret --update swaret --upgrade -a

[Thrillseeka]

is got down?


@junkbuster.. hier krijg ik alleen maar dns errors.. dat ie het adres niet kan vinden.. op 2 pc's geprobeert en 2 verschillende proxy servers in het pand.

[junkbuster]

Nee hoor, hier werkt 'ie nog steeds.