komplizierter Webspace

Auch heute beschäftigte ich mich noch mal mit einem Webauftritt bei Manitu. Dort habe ich einen Nextcloud-Server zum Testen und Spielen. Schon vorgestern hatte ich versucht, die dort laufende nc-Version 20.0.4 auf die aktuelle 20.0.5 zu aktualisieren, war aber immer am Schritt 3, dem Backup gescheitert („Step 3 is currently in process. Please reload this page later.„). Es sah immer danach aus, dass dieser Teil-Script nach einer Weile „gekillt“ wird und dieser Step dadurch nicht fertig wird. Weil dieser Schritt nicht vernünftig beendet wurde, blieb eine Signal-Datei liege und der nächste Update-Versuch funktioniert dann nicht mehr. Vor einem neuen Versuch muss man erst umständlich diese Signal-Datei löschen. Zwischendurch versuchte ich die php-Variable „max_execution_time“ auf 240 (Sekunden) zu setzten, aber egal wo ich diese Variable nach trug, es brachte nichts. Dadurch schlugen auch der nächste Versuch, der übernächste, der über-übernächste und alle nachfolgenden Versuche fehl. Jedes Mal wurde aber ein weiteres backup-Verzeichnis angelegt. Zwischendurch legte ich mir dann schon eine php-Datei an, die nur eine phpinfo (); – Aufruf enthielt. Mithilfe dieses Aufrufs sah ich dann immer den aktuellen Wert für „max_execution_time“ und brauchte nicht noch mehr backup-Verzeichnisse anlegen :grr: – aber egal wie und wo ich die php-Variable eintrug, sie wurde nicht benutzt. Irgendwann kam ich auf die Idee, mal die php-Version für den Webspace von Version 7.4 (PHP Version 7.4.13) wieder zurück auf Version 7.3 zu setzen. Danach wurde die von mir gemachte Änderung der php-Variable plötzlich akzeptiert und unmittelbar lief auch das Update durch.
Nun hatte ich aber immer noch das Problem, dass ich in der Zwischenzeit reichlich dieser halb-fertigen und gänzlich unnützen backup-Verzeichnisse angelegt hatte und die wollte ich ganz gern löschen. Allerdings hatte mein ftp-User keine Rechte, um diese Verzeichnisse zu löschen. Scheinbar ist auf diesem Webspace einiges anders, als ich von anderen Webhostern gewohnt bin. Hier gibt es womöglich einiges mehr an Sicherheit, mit dem Erfolg, dass man, um zu arbeiten, Wege suchen muss, diese zu umgehen. Schon das Löschen des Signal-Files hatte ja einen gewissen Aufwand bedeutet, jetzt weiß ich aber noch nicht, wie ich die Verzeichnisse aufräumen will.
Übrigens, als ich nachher wieder die PHP Version 7.4 aktivierte, war laut phpinfo() das Problem der „max_execution_time 60“ auch wieder da. Nebenbei sah ich dann in den Informationen zum Webhosting-Paket, dass diese sechzig Sekunden wohl eigentlich die Maximal-Einstellungen sind. Dort steht nämlich: Diese Einstellungen sind fest mit dem Webhosting-Paket-Typ verbunden und können nicht geändert werden. – Wenn Sie größere Werte benötigen, buchen Sie bitte ein Upgrade auf ein anderes Webhosting-Paket. Dass ich es bei der Version 7.3 dennoch geschafft hatte, diese Einstellung zu umgehen, ist sicher nicht gewollt und bestenfalls eine „Selbst-Anzeige“. ;)
Damit ist dann wohl der Betrieb eines Nextcloud-Servers mit keinem der angebotenen Webspace-Pakete möglich, zumindest wenn man den Nextcloud-Webspace auch aktuell halten will. – Sorry, da gibt es dann von mir nicht so viele Punkte bei der Bewertung.