PDA

Bekijk Volledige Versie : Onopzettelijke crash virtual hosting



Peter Vrenken
02/05/05, 19:15
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

Nitroserve
02/05/05, 19:20
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.

The MAzTER
02/05/05, 19:33
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.

Nitroserve
02/05/05, 20:06
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...

Croab
02/05/05, 20:14
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 ?

XBL
02/05/05, 20:32
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

t.bloo
02/05/05, 20:53
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!

Vane
02/05/05, 21:06
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 ;).

Peter Vrenken
02/05/05, 23:36
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 :cool: )…

Peter Vrenken

Hypernia
02/05/05, 23:55
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.

kilian
03/05/05, 01:20
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.

The MAzTER
03/05/05, 02:05
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.

Remigius
03/05/05, 02:06
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.

t.bloo
03/05/05, 11:15
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?)

Peter Vrenken
03/05/05, 11:23
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".

Peter Vrenken
03/05/05, 11:27
Origineel geplaatst door t.bloo
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. [/B]

De hoofdreden hiervoor is dat er zowel PHP als ASP.NET op draait. Ondanks dat ik overgestapt (...overgelopen hehe) ben wil ik mijn oude code evengoed nog ergens hebben draaien...
Daarnaast vond ik het pakket dat ze daarnaast aanboden qua prijs/opties zeer interessant.

Peter Vrenken

Vane
03/05/05, 11:52
Origineel geplaatst door Peter Vrenken


zowel PHP als ASP.NET op draait.

Daarnaast vond ik het pakket dat ze daarnaast aanboden qua prijs/opties zeer interessant.


Dan heb ik zo al een idee om welke hoster het gaat *denk ik* :p.

FreddyB
03/05/05, 12:49
Ouch, die bewuste contactpersoon voor dat bedrijf heeft een paar cursussen customersupport nodig. Als ik zo omga met klanten ben ik ontslagen. Al die uitroeptekens en termen zoals "je scriptje" zijn ernorm fout. Ze komen hierdoor in ieder geval niet over als een professionele webhost. Als een klant iets verkeerd doet wijs je hem daar beleefd op.

Ik zie trouwens niet in wat er mis is met je script. Deze kan ik zonder problemen draaien op een server van webstekker.nl (win2k3 server + IIS). Wellicht heeft de host een aparte instelling/limiet? Ongetwijfeld kan de host dit uitzoeken door het bekijken van logfiles, maar heeft deze geen zin om moeite te doen voor een klant.

eMiz0r
03/05/05, 16:06
Even buiten het feit dat de communicatie van het betreffende bedrijf wel erg offensief is en kinderlijke trekjes vertoont, stel ik ze wel in het gelijk.

De meeste hostingbedrijven stellen de klant verantwoordelijk voor de inhoud van een website. Als deze problemen veroorzaakt kunnen ze je simpelweg afsluiten, vaak op basis van een Algemene Voorwaarde. Zij zijn niet verplicht je te helpen om het probleem in het script op te lossen.

Een reactie als deze:



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.

Is natuurlijk ondoordacht. Dit soort zaken kun je doen als je 100 klanten hebt, maar zodra dit een vorm van duizendtallen aanneemt kun je voor dit soort zaken gerust 2 of 3 extra personeelsleden aannemen á 4500 euro per maand. Dat is echt (geloof me) gewoon een onzinnige uitgave en ik kan me absoluut NIET voorstellen dat je dat zelf ook zou doen.

Het bedrijf treft echt geen enkele blaam dat het weigert de klant te helpen met het oplossen van een scriptfout. Het maakt niet uit hoe aardig of vriendelijk je de mail opstelt. Je kunt alleen hopen op sympathie van de hoster, maar uiteindelijk blijft het feit dat de server crasht en andere klanten hierdoor in de problemen komen. Iets wat je op den duur de kop gaat kosten.

Santario
04/05/05, 00:38
Ik neem aan dat je er wel begrip voor hebt dat ik dit voorval ergens op webhosters.nl of dergelijke websites rapporteer.

Na alles gelezen te hebben (en de hoster in het gelijk te stellen) zou deze zin alle medewerking onzerzijds tot een einde brengen. Je mag blij zijn dat ze niet de schade op je verhalen. Beetje doordrammerig gedrag lijkt het wel. Als je een script niet kan testen moet je dat zeker niet op een productieserver doen.

Jij stelt hun nu de vraag hoe je het moet oplossen maar je vergeet dat dat JOUW probleem is. Als je niet de middelen hebt moet je overwegen of je wel goed bezig bent....

Vind het not-done btw dat je de hele dialoog openbaar stelt overigens...

Moet wel een noot maken van het feit dat de hoster zijn taalgebruik iets professioneler kan uitdragen ;)

Peter Vrenken
04/05/05, 08:54
Origineel geplaatst door Santario

Vind het not-done btw dat je de hele dialoog openbaar stelt overigens...

Dit kan ik me voorstellen. Ik heb enige tijd getwijfeld, maar na beraad er toch voor gekozen om hem te publiceren. Zolang er maar geen namen in staan wordt de dialoog enkel en alleen gebruikt om de mening van anderen te vragen, en niet om gal-te-spuien.


Origineel geplaatst door Santario

Als je een script niet kan testen moet je dat zeker niet op een productieserver doen.

Jij stelt hun nu de vraag hoe je het moet oplossen maar je vergeet dat dat JOUW probleem is. Als je niet de middelen hebt moet je overwegen of je wel goed bezig bent....


Ik heb eerder (eerste pagina onderaan) gevraagd hoe dat nu precies zit. Ik krijg de indruk dat het de bedoeling is dat je naast je extern gehoste website thuis een volledig identiek systeem configureert om op te testen, wat volgens mij (zeker bij server crashes) nagenoeg onmogelijk is.

Santario
04/05/05, 13:39
Origineel geplaatst door Peter Vrenken

Dit kan ik me voorstellen. Ik heb enige tijd getwijfeld, maar na beraad er toch voor gekozen om hem te publiceren. Zolang er maar geen namen in staan wordt de dialoog enkel en alleen gebruikt om de mening van anderen te vragen, en niet om gal-te-spuien.



Ik heb eerder (eerste pagina onderaan) gevraagd hoe dat nu precies zit. Ik krijg de indruk dat het de bedoeling is dat je naast je extern gehoste website thuis een volledig identiek systeem configureert om op te testen, wat volgens mij (zeker bij server crashes) nagenoeg onmogelijk is.

Ik snap jouw visie ook hoor, begrijp me goed maar het feit dat je dit soort dingen niet op een productie-server doet alsmede het feit dat je toch verstand van zaken dient te hebben prefereert nog altijd.

t.bloo
04/05/05, 14:09
als je het mij vraagt dan wordt er door diverse mensen aan voorbij gegaan dat het een zeer onschuldig scriptje betreft dat gewoon zou moeten werken op een server waar PHP ondersteuning op verkocht wordt. en als het al niet zou werken dan mag het in ieder geval niet de machine laten crashen. ik blijf erbij dat het een probleem is van de hoster en niet de gebruiker

Sander-
04/05/05, 15:14
Ik vind dit hele verhaal ronduit belachelijk... vooral het gedeelte van "Ik wil ook een nacht rustig slapen"... Dan had je maar geen webhostingbedrijf moeten beginnen of moet je daar iemnad voor aannemen. ik vind dat zo'n zwak en belabberd verhaal, kom op zeg.

En als je PHP + ASP.Net op een Windows server draait dan moet je daar ook support op leveren en zorgen dat je klanten weten wat de beperkingen zijn aan PHP door de keuze voor Windows. Verder denk ik dat het over en weer zeuren enzo meer tijd kost dan het checken van het script. TEnzij de supportmedewerker er zelf ook de ballen verstnad van heeft (wat ik vermoed)

Ik vind dit zeer slechte service... Opzich kan ik daar wel deels inkomen als jij een budgethost hebt (wat ik beetje uit je verhaal opmaak), maar dan nog... Beetje aardig zijn voor je klanten mag wel vind ik. En files verwijderen is helemaal uit den boze.

Ik heb je stukje code ook ff bekijken en kan er ook niks in ontdekken, misschien wat minder met globals en die headers werken, kijken wat ie dan doet... Heb zelf weinig ervaring met beperkingen van apache onder ISS

FreddyB
04/05/05, 15:30
Zoals ik al zei; copy-paste script op mijn webstekker 2k3/IIS server -> werkt. Het scriptje is erg klein en makkelijk te begrijpen; je kan mij niet vertellen dat de host dan niet even kan kijken "goh waarom zou zo'n simpel scriptje nou mijn server crashen". Lijkt er meer op dat deze geen zin/verstand had van zaken, hij doet zich er wel heel simpel van af.

Als ik webhost was en inderdaad een legale (gedocumenteerd in php.net zonder warning: don't use in IIS!) functie-aanroep in PHP mijn server zou crashen zou ik snel zoeken naar de oorzaak, en dan a) fixen of b) aan mijn users vertellen dit niet te doen - van te voren.

Kortom ik vind dat je in je recht staat om dit bij webhosters.nl te vertellen; vooral het kinderlijke gedrag met nachtrust e.d.