Onderwerp: Onopzettelijke crash virtual hosting

Hoi,

Ik heb afgelopen weekend de server van mijn hoster (onopzettelijk) over de kop laten gaan. Ik was op de helft van het porteren van een van mijn webpagina's, maar op de een of andere manier zat er in een van de vele PHP scripts een constructie die hun IIS (op een W2K3) niet leuk vond. Nadat mijn volledige account geblokkeerd was, wat ik goed kan begrijpen aangezien er nog andere websites op dezelfde server staan, heb ik per direct aangegeven om volledig mee te werken om het probleem te zoeken en op te lossen. Na wat email over en weer was hun standpunt echter dat ik mijn eigen 2K3 server in moest richten om het probleem op te lossen.
Ze waren niet van plan om het probleem gezamenlijk op te lossen aangezien ze script-support niet gratis aanbieden, en pas als ik het probleem zelf opgelost had, dit inclusief onderbouwing hun kant opstuurde en hun het geverifieerd hadden, zou ik weer toegang tot mijn account krijgen. Aangezien ik geen informatie over de specifieke situatie op hun server kan vergaren (mijn account was geblokkeerd en meer informatie kreeg ik niet) en het voor mij (financieel) onmogelijk is om een 2K3 server in te richten (anders hoefde ik zelfs niet te hosten), kwam ik dus in een positie waar ik niet meer uit kon. Teneinde raad heb ik maar aangeboden dat ze de website verwijderden en ik hem ergens anders zou gaan hosten, maar nu zit ik dus met ruimte die ik maar ten dele (delen die wel werken zoals andere PHP en ASP.NET code) gebruik.

Ik ben niet echt te spreken (eigenlijk ben ik zeer teleurgesteld) over de dialoog die via de email plaatsvond, en ben erg benieuwd hoe de webhosters onder jullie een dergelijke kwestie aan zouden pakken.

Dit is mijn eerste post op dit forum en ik weet dan ook niet of het toepasselijk is dat ik de dialoog hier ter beoordeling neerzet, maar diegene die deze interessant vinden laten het maar weten.

Groeten,

Peter Vrenken

Toevallig kennen wij de situatie.

Bij ons is er ook een tijdje een klant geweest die "ruzie" had met win2k3 en IIS.

In ons geval hebben wij die klant gratis geholpen met het reorganiseren van de code.
Dit vind ik ook niet meer dan logisch, daar bereik je veel meer mee dan met afsluiten van accounts en dergelijke.

Probleem waar jouw hoster mee zit is dat de server er misschien nog wel 10x uitklapt voor jij de bug gevonden hebt.

Vind het dus vrij logisch dat ze het zo aanpakken. En je scripts hoor je lokaal op een develop 'server' te testen, niet op een productie server.

ben ik het niet helemaal mee eens.
Ik zou niemand afsluiten.

afkappen vind ik dan beter.
ik heb toen de resources die de gebruiker mocht gebruiken wat beperkt, totdat het weer gefixt was.

Zo voorkom je gefrustreerde klanten en gefrustreerd bezoekers van de website van je klanten...

Met het oog op service (ik begrijp dat de gedupeerde klant meerdere hostingfaciliteiten afneemt) is mijn mening dat hier best enige tijd aan besteed mag worden.

Komt het vaker voor, wordt het een ander verhaal, echter we hebben nu maar 1 kant van het verhaal gelezen.

Zoals ik er nu over denk vind ik dat het bedrijf een beetje te snel 'opgegeven' heeft de klant te helpen.

Maar tenzij het niet verantwoord is om de eventuele communicatie hier neer te zetten zou ik zeggen.. laat de reacties van het desbetreffende bedrijf ook eens zien ?

Ik weet niet bij wat voor hoster je je diensten afneemt, maar als je niet bij een zogenaamde 'budget' hoster zit (en dus wel wat meer service kan verwachten), had ik van de hoster verwacht dat ze in ieder geval een blik op het script zouden werpen en eventueel aangeven waar het fout zit.

Ik begrijp wel dat ze niet willen dat je de bug gaat vinden op hún server, dan krijg je immers meerdere keren problemen, wat hen geld gaat kosten. De oplossing van nitroserve is dan eventueel een goede manier om toch te kunnen ontwikkelen op de server.

Andere oplossing is natuurlijk dat je lokaal een servertje inricht en hiermee het script ontwikkeld. Hoewel ik niet zeker weet of je de exacte situatie kan nabootsen (want dan moet je weten wat het probleem van IIS is met jouw script).

Jochem

Ik kan me goed voorstellen dat de hoster niet blij is dat jij zijn server plat legt, zeker als het een reseller is (weet niet of dat zo is, maar die hebben geen invloed op de server zelf). Het is niet zo makkelijk om met een PHP script een server plat te laten leggen anders dan met een hoog resource gebruik. Als de hoster wil is dat laatste wel (tijdelijk) in te perken.

Aan de andere kant hebben ze ook wel weer gelijk natuurlijk dat je geen overlast mag bezorgen aan de andere gebruikers van de server. Ik heb wel eens wat gehost op een server waar door andermans gerommel regelmatig de load erg hoog werd en daar werd niemand blij van.

Het zou mooi zijn als de hoster ergens een testaccountje beschikbaar zou kunnen stellen waar jij het probleem op kan lossen, maar de vraag is of ze over extra machines beschikken (is bij de kleinere bedrijven meestal niet het geval). In principe zijn jouw scripts jouw probleem hoe vervelend dat ook klinkt, in de praktijk geldt natuurlijk wel weer dat de hoster alleen geld kan verdienen als jij jouw site kunt runnen!

Origineel geplaatst door t.bloo


Het zou mooi zijn als de hoster ergens een testaccountje beschikbaar zou kunnen stellen waar jij het probleem op kan lossen, maar de vraag is of ze over extra machines beschikken (is bij de kleinere bedrijven meestal niet het geval)

En als die down mogen .

Origineel geplaatst door Croab
Maar tenzij het niet verantwoord is om de eventuele communicatie hier neer te zetten zou ik zeggen.. laat de reacties van het desbetreffende bedrijf ook eens zien ?

Het enige waar ik nieuwsgierig naar ben is of dit juist is afgehandeld, en het lijkt me inderdaad dat de emails die over en weer zijn gestuurd een goed beeld van geven. Wel heb ik alle (domein)namen verwijdert; ik heb geen zin om nog meer gerommel te krijgen.

Aub geen kritiek op de codesnippet. De code werkte uitstekend maar is uit een tijd dat beveiliging voor mij nog geen issue was...
(uit mijn jonge wilde jaren )…

Peter Vrenken

een terechte afsluiting lijkt mij, je kunt bijvoorbeeld zelf ook ff iis installeren gewoon op je pc en je scripts testen.
Natuurlijk hadden ze je ff kunnen helpen, en ze hadden je miscchien van te voren ook wel DUIDELIJK mogen maken dat je alles zelf eerst op een ander systeem uitprobeerd. Dit lijkt me niet meer dan logisch trouwens tenminste als je niet zeker weet dat je script naar behoren zal kunnen functioneren.

Origineel geplaatst door Hypernia
een terechte afsluiting lijkt mij, je kunt bijvoorbeeld zelf ook ff iis installeren gewoon op je pc en je scripts testen.
Natuurlijk hadden ze je ff kunnen helpen, en ze hadden je miscchien van te voren ook wel DUIDELIJK mogen maken dat je alles zelf eerst op een ander systeem uitprobeerd. Dit lijkt me niet meer dan logisch trouwens tenminste als je niet zeker weet dat je script naar behoren zal kunnen functioneren.

Ben het hier niet mee eens. Een klant afsluiten is een machtig wapen en dat wordt op deze manier misbruikt. Als ik de klant zou zijn zou ik het probleem anders neerleggen: Dat de hoster in gebreke is omdat hij zijn servers niet in orde heeft. Je wil toch gewoon iets kunnen ontwikkelen zonder dat je bij iedere 'domme' fout naar een andere hoster op zoek wil?

Dat de hoster de samenwerking met de klant intrekt betuigt van een tekort aan respect voor zijn klanten, ik hoop dat ze dat begrijpen.

Origineel geplaatst door kilian


Ben het hier niet mee eens. Een klant afsluiten is een machtig wapen en dat wordt op deze manier misbruikt. Als ik de klant zou zijn zou ik het probleem anders neerleggen: Dat de hoster in gebreke is omdat hij zijn servers niet in orde heeft. Je wil toch gewoon iets kunnen ontwikkelen zonder dat je bij iedere 'domme' fout naar een andere hoster op zoek wil?

Dat de hoster de samenwerking met de klant intrekt betuigt van een tekort aan respect voor zijn klanten, ik hoop dat ze dat begrijpen.

hoezo? De hosting werkt gewoon, script is alleen buggy. Je verkoopt hosting, geen script support.

zou een mooie bak wezen. Klant maakt bagger code en jij mag het fixen. En in de tussentijd vliegt de server er 20x uit vanwege het testen. En alle klanten die er vervolgens last hebben jouw er op aanspreken. En kan dan ook nog zo zijn dat personeel van dat hosting bedrijf een dag bezig is om het dan te fixen, dat kost ook geld.

Hun reactie is ook logisch, fix het script, laat zien wat je verbeterd hebt en vervolgens zullen zij het testen. Ik vind dat gewoon netjes afgehandeld. Want wat Peter nu doet is: Het script crasht jullie server, dus jullie mogen mijn bagger code fixen.

Zo werkt het gelukkig niet

Mja.. aan de andere kant, als je 2 klanten hebt en je hebt heel de dag toch geen reet te doen mag jij het best fixen. (deze reactie naar bedrijven die aangeven wel te helpen).

Mijn conclusie nogmaals: ik zie niet in wat dit bedrijf fout doet, ze hebben immers getracht jouw te helpen waar het mogelijk was.

Dit is overigens een persoonlijke reactie, geeft niet weer hoe zulke situaties binnen ons bedrijf opgelost worden.

Ik kan begrijpen dat de hoster er een probleem van maakt, want andere klanten hebben er last van. Een beetje kwaliteitshoster kijkt toch even in de logs, kijkt het script even na, etc.

Wat ik echter wel vind is dat de hoster nogal kortaf/bot is. Hier hou ik persoonlijk helemaal niet van.

nou het duurde even voor ik door had dat de correspondentie in reverse volgorde stond, ik dacht al wat een botte bedoening!

jouw hoster is niet echt meewerkend maar ik snap best dat hij geen zin heeft om ieder moment z'n server plat te zien gaan.

maar waarom hij plat gaat dat staat nergens en mijn mening is dat dat stukje script de server echt niet mag laten crashen. een header() functie hoort iets naar de browser te sturen die daar vervolgens met een andere reactie op reageert. de server software moet hier vervolgens iets mee doen en dat weer doorgeven aan een nieuwe script actie. Apache en IIS reageren hier anders op en daarom zijn de reactie scripts niet helemaal hetzelfde. meer hier over op http://nl2.php.net/manual/en/features.http-auth.php

Maar nogmaals, dit moet niet een server plat laten gaan, dat is echt niet de bedoeling. dat de server er een probleem mee heeft ligt wat mij betreft aan de server en niet aan het script. de server reageert als het goed is niet op de headers maar op wat er vervolgens van de browser terug komt dus dat is erg vreemd dat dat problemen geeft. "does not work" is niet hetzelfde als "does crash the server". als je dergelijke functies echt niet zou mogen gebruiken dan zijn die uit te zetten in de php.ini via disable_functions

de vraag rijst, waarom zit je in hemelsnaam op een windows server. de vraag is natuurlijk eigenlijk waarom bestaan er in hemelsnaam windows servers maar dat is natuurlijk een beetje te breed

ik zou als je PHP scripts gebruikt snel verhuizen naar een server met apache, tenzij je hele goede redenen hebt om dat niet te doen. en ik zou als hoster wel eens willen weten waarom zo'n onschuldig scriptje mijn server plat legt, want het lijkt me een fout in de server die makkelijk misbruikt kan worden door kwaadwillenden (een gewaarschuwd hoster telt toch ook voor twee?)

Origineel geplaatst door The MAzTER


hoezo? De hosting werkt gewoon, script is alleen buggy. Je verkoopt hosting, geen script support.

zou een mooie bak wezen. Klant maakt bagger code en jij mag het fixen.

Volgens mij was het script niet buggy. Ik zie het meer als een combinatie van een script ‘dat exotische acties uitvoert’ en een ‘minder goed ingestelde’ server. Het is onderdeel van een CMS dat al een geruime tijd goed draait (ok, alleen op een windows 2K en linux server maar het draait), en is ontwikkeld in de tijd dat ik nog tot over mijn knieeen in de PHP code zat. Echte script-support in de zin van ‘waarom doet mijn script het niet?’ heb ik niet echt nodig. Wat ik wel nodig heb is meer informatie. Ik ben benieuwd hoeveel mensen in deze situatie het probleem kunnen verhelpen zonder situatie-specifieke (lees configuratie-specifieke) informatie waarmee het probleem te repliceren valt.
Ik kan inderdaad misschien thuis wel op mijn Windows XP Pro systeem IIS gaan installeren, maar de kans is toch wel heel klein dat ik deze specifieke (systeem)crash op een nagenoeg niet vergelijkbaar systeem kan repliceren?

En in de tussentijd vliegt de server er 20x uit vanwege het testen. En alle klanten die er vervolgens last hebben jouw er op aanspreken. En kan dan ook nog zo zijn dat personeel van dat hosting bedrijf een dag bezig is om het dan te fixen, dat kost ook geld.

Een server crash is in mijn ogen niet niks, en ik heb dan ook direct aangeboden om in elk opzicht mee te werken. Het lijkt me echter wel dat je als hoster (ik ben er zelf geen) er alles aan doet om een dergelijk gat dicht te timmeren zodat het in de toekomst niet nog een keer gebeurt.

Er komt nu eigenlijk nog een andere vraag in me op. Hoe kijken hosters tegen dergelijke fouten aan? Volgens mij wordt er bij het opstellen van een server aardig wat tijd gestoken in het afschermen van onveilige situaties. Voor zover ik weet worden er ontzettend veel maatregelen genomen dat klanten alleen maar in hun eigen afgebakende deel kunnen werken zonder dat ze invloed op andere gebruikers kunnen uitoefenen, en dat ze zelfs in hun eigen doen en laten gelimiteerd worden om security issues te voorkomen. Mede hierdoor ontstaan er ‘oneindig’ veel hoster-specifieke configuraties, waardoor de ene code op de ene server wel werken en bij de andere voor een fatale server crash zorgt.
Mogen hosters er vanuit dit perspectief wel van uitgaan dat gebruikers nooit of te nimmer onveilige situaties creëren?

Hun reactie is ook logisch, fix het script, laat zien wat je verbeterd hebt en vervolgens zullen zij het testen. Ik vind dat gewoon netjes afgehandeld. Want wat Peter nu doet is: Het script crasht jullie server, dus jullie mogen mijn bagger code fixen.

Zo werkt het gelukkig niet

Mijn conclusie nogmaals: ik zie niet in wat dit bedrijf fout doet, ze hebben immers getracht jouw te helpen waar het mogelijk was.

Is dit echt zo? Naar mijn mening hebben ze niets anders gezegd dan "zoek het maar uit, ohja, kijk misschien eens in die en die richting, en kom maar terug als het werkt".