Het komt inderdaad niet erg professioneel over. Maar je zou in de overeenkomst (/algemene voorwaarden/service level agreement etc.) moeten kijken om te zien of de hoster dit mag doen.

Het hangt ervanaf wat er overeengekomen is. Is de php een as-is service (take it or leave it) dan is het gewoon jammer maar helaas. Zijn er afspraken over gemaakt (evt. SLA) dan mag het natuurlijk niet zomaar gewijzigd worden zonder dat er met de klant is afgestemd.

Betreft het een shared-server ( en dat zal hier het geval zijn ), dan mogen ze dat gewoon doen ! Dat zal ook in de voorwaarden staan...
Je werkt niet alleen op die server en de update kan in algemeen belang noodzakelijk zijn en dus de belangen van een enkele gebruiker overstijgen...

Betreft het een dedicated server, dan is het geval anders...
Dan is het bedrijf in principe zelf "eigenaar" van de server en vaak ook zelf verantwoordelijk voor de update...
Dan kan zo'n update ongevraagd in principe dus niet plaatsvinden.

Gr. Phinder

@Phinder


Duidelijk verhaal.
Met die mogelijkheid van een dedicated server geef je ook nog eens antwoord op de vervolgvraag die bij me opkwam hoe je het beste zo'n serverapplicatie kan laten draaien!

Ook de anderen bedankt voor jullie reacties!

Groet AF

Phinder heeft toch niet helemaal gelijk.
Dedicated betekent dat je als enige die server gebruikt, je hoeft er geen eigenaar van te zijn, je kunt 'm zo huren.
Colocated betekent dat je ruimte/stroomaansluiting/internetaansluiting/beveiliging huurt in een datacenter. Daar kun je dan je eigen server(s) in plaatsen of servers die het datacenter levert. Bij co-located ben je zelf verantwoordelijk voor de werking van de servers en evt.updates. Bij dedicated doet de leverancier dat meestal. Het service level is dan afh. van de afspraken (SLA= Service Level Agreement).

Wat je veel ziet is dat een provider een Colocated of dedicated server huurt en daar ruimte op aanbiedt aan klanten. Iedereen kan dus providertje spelen. Een goede provider zal nooit zomaar software wijzigen. Ook een update zou niets mogen uitmaken voor PHP, tenzij het slecht wordt uitgevoerd en instellingen worden gewijzigd. Er is wel een uitzondering voor datum-velden van MySQL van versie 3 naar versie 4. Daarvoor moest je je software aanpassen.

Ik denk dat je bij jouw problemen doelt op beveiligings-instellingen die zijn gewijzigd in PHP.  Die zijn allemaal via .htaccess bestanden te overrulen. Zaken als addslashes, global variables en safe-mode.
Je provider had je daarover kunnen informeren, maar misschien is dat iemand die meer systeembeheerder is dan programmeur.

Zoek je een goede provider, dan moet je eens naar http://www.webhosters.nl. Daar kun je alle providers en prijzen vergelijken en ervaringen lezen.
Wij zitten nu met een dedicated server bij Proserve, een vrij grote provider (top-10 Nld) en ik ben heel tevreden. BIT is ook een hele goede (en grote), maar er zijn er natuurlijk meer.
Met bijv. Mihosnet (heel ander soort aanbieder) heb ik ook goede ervaringen.

Verder geldt natuurlijk: alle waar naar z'n geld, maar niet alles wat duur is is goed en niet alles wat goedkoop is hoeft slecht te zijn.

Als je op Nld gericht bent moet je altijd vragen waar de servers fysiek staan. Het liefste in Nld. In de US zitten veel slechte providers. Ben je internationaal gericht, dan moet je me nog maar eens vragen. Wij hebben ook nog iets in de US draaien, maar die provider weet ik zo uit mijn hoofd niet. Loopt al 10 jaar met 1 keer 3 minuten downtijd.

Bedankt voor je reactie.
Heb het script op een aantal punten gewijzigd en het werkt weer.
Voorzover ik kan beoordelen is het toch voornamelijk een kwestie van een nieuwere versie PHP waar het script op bepaalde punten op vast liep.
Het oorpronkelijke script is op een stokoude versie getest maar is nu in elk geval klaar voor PHP 4.
Zal binnenkort testen of ie op php 5 ook goed draait.

Vrgr. AF