Archiv verlassen und diese Seite im Standarddesign anzeigen : Dateisystem blockiert Zugriffe nach Software Update
Hallo alle Spezialisten hier!
Ich suche jemanden, der mit bei folgendem Problem "unter die Arme greifen" kann und will:
Ich habe einen VPS mit WHM/Cpanel, mit "root"-Zugriff, von dem ich außer der Bedienung des WHM nichts verstehe, dessen Software vor Kurzem (von Datacenter-Support) updatet wurde. Jetzt habe ich Centos 6.1.0; Easy Apache 2.4, PHP 5.4 … 7.3 und PERL 5.8.8. laut WHM-Ausgabe.
phpinfo sagt dazu "Linux … 2.6.32-042stab132.1". Ich weiß nicht, was zuvor war.
Der VPS bedient mehrere Websites, zum Teil rein HTML, zum Teil PHP und auch einige mit PERL-Scripts.
Bis zum Update liefen alle Websites (und sämtliche Scripts) offenbar problemlos, seit dem Update geht (fast) nichts mehr - außer: alle Seiten, die nur Ausgaben zum Browser sind, laufen gut. Alle Seiten, bei denen Dateizugriffe (durch Scripts) erforderlich sind, laufen nicht mehr (richtig).
Ich habe ein kleines (PHP) Script zur Reparatur ausgewählt und habe den Code geändert, dass es Ausgaben erzeugt, sobald irgend ein Zugriff fehlschlägt. Es zeigte eindeutig, dass (sämtliche?) Dateizugriffe fehlschlagen. Versuchsweise habe ich die zu schreibenden Dateien (manuell) auf perms. 777 gestellt, da läuft es, kann aber keine neue Datei schreiben.
Das Script läuft jetzt unter PHP 5.4.45 (lt. PHPinfo). Ich kann nicht sagen, unter welcher PHP-Version das Script zuvor problemlos lief, aber es lief bis 24. März (laut Log-Datei); da wurde das Update gemacht.
Auch die PERL-Scripts haben das geiche Problem, mit perms. 777 können sie erweitert werden, aber es kann keine neue Datei erstellt werden.
Der Datacenter-Support lässt mich im Regen stehen "Support of custom scripts is outside of our support scope" …
Mein Frage hier: Gibt es hier jemand, der bei solchen Problem Tipps geben kann, wie ich der Sache auf den Grund gehen kann? Nachdem so gut wie jeder Dateizugriff blockiert ist, nehme ich an, dass es sich hier um eine "Grundeinstellung" handelt, die falsch ist, doch habe ich keinerlei Erfahrung mit Systemeinstellungen, die machte der Support stets klaglos (wenn ich sagte was ich will). Irgend etwas am Dateisystem ist geändert worden, doch weiß ich nicht, wie ich diesen Status überwinden kann.
Nähere Einzelheiten gebe ich natürlich gerne bekannt, wenn sich jemand findet, der mir helfen kann und will. Doch ersuche ich vorweg schon um Verständnis: "Adminesisch" kommt mir meist spanisch vor :( also bitte: Sie sprechen mit Otto Normalverbraucher.
Danke! Ich hoffe sehr auf Hilfe, denn ich bin mit meinem Latein am Ende. Falls ich hier am "falschen Markt bin", bin ich dankbar, wenn mir das jemand gleich sagt.
Liebe Grüße, Helmut
corresponder
09.05.19, 17:49
ist das dateisystem nur read only gemountet?
poste mal die ausgabe von
mount
in quote tabs.....
stefan.becker
09.05.19, 18:51
Das ist ja wie Fahren ohne Führerschein. Wieso bist du für einen Server verantwortlich und hast keine Ahnung davon?
ist das dateisystem nur read only gemountet?
poste mal die ausgabe von
mount
in quote tabs.....
Danke für den Hinweis! Um das zu tun, muss ich mir erst einen Client suchen und installieren (Putty?), denn ich habe bisher nie am Server selbst igend etwas getan, nur am WHM und CPanel. Ich komme hierher zurück, sobald ich das erledigt habe.
Allerdings meine ich, dass das nicht der Fall ist, weil ich mit Perms. 777 ja die Dateien beschreiben kann - aber ich bin kein Fachman, habe nur "periphere Kenntnisse" und bin deshalb für jeden Hinweis und jede Hilfe dankbar. Ersuche bitte um etwas Geduld.
Bis bald dann, und schönen Abend sowie gute Nacht!
Helmut
Ganz lieb, Stefan.Becker, danke, und sehr hilfereich! Und die Antwort lautet schlicht:
Ich habe mich nie für den Server verantwortlich gefühlt, weil mir vom Datacenter die Wartung des Servers zugesichert wurde (und auch seit Jahren besorgt wurde). Nur jetzt bekam ich erstmals "out of scope of our support" zu hören. Alles, was zu tun war, konnte ich mit WHM und CPanel über Jahre erledigen. Soll ich mich jetzt erschießen?
Alles Liebe, Helmut
Ich habe ein kleines (PHP) Script zur Reparatur ausgewählt und habe den Code geändert, dass es Ausgaben erzeugt, sobald irgend ein Zugriff fehlschlägt. Es zeigte eindeutig, dass (sämtliche?) Dateizugriffe fehlschlagen. Versuchsweise habe ich die zu schreibenden Dateien (manuell) auf perms. 777 gestellt, da läuft es, kann aber keine neue Datei schreiben.Deutet daruf hin , dass das da Dateisystemsystem voll ist. Für 'root' bleiben aber meist ein paar reservierte Prozent, weswegen der so noch agieren kann ...
Der Datacenter-Support lässt mich im Regen stehen "Support of custom scripts is outside of our support scope" …Sie sollten Dir aber zumindest/hoffentlich sagen können, wo (temporäre) Installationsdateien liegen, die ggf. jetzt unnötig sind und nur Platz verbrauchen ...
Ist beides mangels besserem Wissens nur Spekulation, Du musst verstehen, dass wir nicht an Deiner Stelle sitzen und damit nicht jede unserer Vermutungen sofort bestätigen/widerlegen können.
Gruß, FM_81
Deutet daruf hin , dass das da Dateisystemsystem voll ist. Für 'root' bleiben aber meist ein paar reservierte Prozent, weswegen der so noch agieren kann ...
Sie sollten Dir aber zumindest/hoffentlich sagen können, wo (temporäre) Installationsdateien liegen, die ggf. jetzt unnötig sind und nur Platz verbrauchen ...
Ist beides mangels besserem Wissens nur Spekulation, Du musst verstehen, dass wir nicht an Deiner Stelle sitzen und damit nicht jede unserer Vermutungen sofort bestätigen/widerlegen können.
Gruß, FM_81
Vielen Dank, FM_81, für den Hinweis! Wegen der Installationsdateien werde ich nachfragen, auch das ist ein für mich recht wertvoller Hinweis, für den ich dankbar bin. Das Dateisystem dürfte abe nicht voll sein, ich habe diese Daten aus dem WHM:
Filesystem Size Used Avail Use% Mounted on
/dev/vzfs 60G 48G 13G 80% /
none 512M 4.0K 512M 1% /dev
Herzlichen Dank und schönen Tag!
Helmut
Danke corresponder! Hier die Ausgabe (ist zwar größtenteils "spüanisch" für mich, aber ich sehe doch, dass alle "rw" sind :
root@biz [~]# mount
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type devtmpfs (rw,relatime,mode=755)
none on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=000)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
Wie geht's da weiter? Wäre froh, mehr zu erfahren!
Inwzischen: Einen schönen Tag!
Helmut
Sorry, aber der aktuelle Ansatz scheint mir komplett falsch - "wild" an irgendwelchen Rechten rumbasteln ist keine Lösung.
Ich würde erst mal prüfen:
* welche Rechte, User, ... haben die Scripte und die zu erzeugenden / bearbeitenden Dateien, Verzeichnisse, ... aktuell
* mit welchen Rechten läuft der entsprechende Prozess
* was sagt das OS da parallel dazu, ggf. auch bezüglich Administrativer Einschränkungen wie AppArmor, SELinux, ...
* genaue Fehlermeldung
Abgesehen davon - wenn das ein Managed-System ist welches lief und dann der Hoster etwas gemacht hat (und es dann nicht mehr lief) - ist erst mal nur der Hoster dafür zuständig, das wieder zum laufen zu bekommen.
Danke corresponder! Hier die Ausgabe (ist zwar größtenteils "spüanisch" für mich, aber ich sehe doch, dass alle "rw" sind :
root@biz [~]# mount
/dev/vzfs on / type reiserfs (rw,usrquota,grpquota)
...rw ist zwar, aber hat eventuell eine Quota zugeschlagen?
Gruß, FM_81
Sorry, aber der aktuelle Ansatz scheint mir komplett falsch - "wild" an irgendwelchen Rechten rumbasteln ist keine Lösung.
Ich würde erst mal prüfen:
* welche Rechte, User, ... haben die Scripte und die zu erzeugenden / bearbeitenden Dateien, Verzeichnisse, ... aktuell
* mit welchen Rechten läuft der entsprechende Prozess
* was sagt das OS da parallel dazu, ggf. auch bezüglich Administrativer Einschränkungen wie AppArmor, SELinux, ...
* genaue Fehlermeldung
Abgesehen davon - wenn das ein Managed-System ist welches lief und dann der Hoster etwas gemacht hat (und es dann nicht mehr lief) - ist erst mal nur der Hoster dafür zuständig, das wieder zum laufen zu bekommen.
Danke für diese Hinweise, marce!
Zum letzten Absatz (bzw. Anmerkung bzgl. Hosterzuständigkeit) stimme ich 100% zu - es nützt mir aber nichts, solange ich ihnen nicht "nachweisen" kann, dass sie Mist gebaut haben. Die Sache ist schlicht so: Alles, was innerhalb von user-Scripts läuft, wird (jetzt erst?) als "out of scope" erachtet - und meine Probleme liegen ja innerhalb dieser Scripts. Genauer gesagt: Alle (PERL sowie PHP) Script arbeiten fein mit Dateien, die bereits vorhanden sind, können aber keine neuen Dateien erstellen.
Erstelle ich (per FTP) z.B. eine neue Datei (mit Rechten 644), dann können die Scripts diese lesen, aber nicht beschreiben, dazu brauchen sie Rechte 777. (Das sagte mir auch Support des Hosters.) Dann können sie auch von den Sripts verändert werden.
Ich habe jetzt einige Tage lang diverse "Analyse"-Scripts gebastelt und bin zum ziemlich eindeutigen Schluss gekommen, dass es nur am "Eigentümer" der Dateien (und deren Verzeichnisse) und/oder Eigentümer der Scripts liegen kann - die passen irgendwie nicht zusammen. (Ist gewiss laienhaft ausgedrückt, aber wie ich schon eingangs sagte: Otto-Normalverbraucher.)
Da aber stehe ich an, weil ich mich doch nicht traue, mit PuTTY (Befehlszeilenclient) am Server "herumzufuhrwerken". Ich habe z.B. noch nicht herausgefunden, wie ich die Eigentümer ("owner") herausfinden kann, und wie sie (das scheint mir noch wichtiger zu sein!) korrekt sein sollen. Ich habe noch nicht einmal das Dateisystem durchschaut (z.B. auf welchem Pfad finde ich Owner, auf welchem Pfad finde ich WHM-User?
Ich bin da also wirklich auf Hilfe angewiesen. (Bin auch durchaus willens, etwas dafür zu zahlen - nur habe ich kein unbegrenztes Budget dafür und habe natürlich Bedenken, "jedem" Zugriff auf meinen Server zu geben! Aber wo fidne ich solche versierte Hilfe? Ich hoffte, vielleicht hier?)
Alles Liebe,
Helmut
Nachtrag zu "owner": Ich sehe per FTP als owner nur numerischer Werte, habe aber noch nicht herausgefunden, wie ich diese Werte in "Owner" (also deren "username") übersetzen/übertragen kann. Und ohne diesen Zusammenhang zu kennen scheint es, kann ich nicht erkennen, was "los ist". Ich habe bei der Suche mit PuTTY schon eine Datei gefunden, in der "owner" in Klarschrift gespeichert sind, aber nicht, welcher numerische Wert dazu gehört. Etwas Ähnliches liegt mit "Rechten" vor.
Stellen wir doch mal fest:
(1) es tut
(2) der Hoster macht Updates
(3) es tut nicht mehr
-> Einzige Änderung wurde durch den Hoster gemacht. Damit ist die Schuldfrage - auf der hier bekannten Faktenlage - erst mal klar.
Zudem - unter welchen Usern Jobs und Scipte laufen kann Dir auch nur der Hoster sagen bzw. das korrigieren.
Auch hier gilt wieder - vorher tat's, hinterher nicht mehr.
Das einzige, auf das sich der Hoster noch zurückberufen _könnte_ - Du hast root-Zugriff und daher hast Du ggf. was kaputt gemacht. Wird schwer.
Ob Du hier jemanden findest, der dir "vor Ort" (also auf dem Server) zur Hand geht - gut möglich, ggf. suchst Du aber auch noch z.B. in https://serversupportforum.de/ - da sind mehr "reguläre Dienstleister" und Freelenancer unterwegs als hier. Hier bei uns bekommst Du eher Hilfe zur Selbsthilfe, das sehe ich in dem Fall bei Dir aber eher weniger als Lösungsweg.
Abermals vielen Dank und Hut ab! So schnell geantwortet, alle Achtung!
Danke für den Hinweis auf "Jobs und Rechte" - dem werde ich nachgehen. Und auch für den Tipp auf's serversupportforum zu gehen, danke ich. Werde natürlich alles versuchen, weil ja meine Arbeit unter dem Stauts qou leidet.
Herzlichen Dank noch mal für jeden Hinweis, ich wünsche einen schönen Abend und alles Gute!
Helmut
Abermals vielen Dank und Hut ab! So schnell geantwortet, alle Achtung!
Danke für den Hinweis auf "Jobs und Rechte" - dem werde ich nachgehen. Und auch für den Tipp auf's serversupportforum zu gehen, danke ich. Werde natürlich alles versuchen, weil ja meine Arbeit unter dem Stauts qou leidet.
Herzlichen Dank noch mal für jeden Hinweis, ich wünsche einen schönen Abend und alles Gute!
Helmut
Nachtrag dazu an marce:
Ich habe die einschlägigen Anfragen an "meinen" Support gesichtet und herausgefunden, dass ich offenbar bis jetzt immer die "falsche" Frage gestellt habe bzw. deren Aufmerksamkeit nicht auf das wirklich Problem gelenkt habe - eben aus meiner laienhaften Sicht des Problem: "Meine Scripts laufen nicht mehr!"
Können Sie mit bitte helfen, mein Problem dem Support so darzustellen, dass die nach der "richtigen" Einstellung schauen?
Alle meine bisherigen Anfragen waren darauf angelegt, dass die Scripts nicht mehr laufen - die haben etwas untersucht und dann gesagt "Scripts sind nicht Teil unserer Supports" (dem ich ja zustimmen muss, das ist wirklich nicht ausgemacht). Ich müsste also etwas wie "die Prozesse in meinem Webspace sind nicht korrekt berechtigt" sagen, dass sie dort nachschauen statt in meinen Scripts. Aber wie drücke ich mich sachlich korrekt aus?
Wie ich die Sache jetzt (nach einer Menge Arbeit an Untersuchungen) sehe, verstehe ich das Problem so (auch wieder laienhaft dargestellt):
Wenn im WHM ein User erstellt wird, wird für ihn als "username" ein Cpanel mit "Dateisystem" (d.h. ein "Wurzelverzeichnis" mit Unterverzeichnissen für alle Dateien, die er brauchen wird) erstellt; dieses "gehört" ihm (owner) (UID?), sodass er darin alles machen kann, was er braucht (Dateimanager des Cpanel etc). (Es wird da auch Dateien geben, die nicht ihm "gehören", sondern dem System.) Der "owner" scheint dann (z.B. im WHM) mit "username" auf, aber im Dateisystem (dreistelligen) Zahl (owner), dazu gibt es eine Oktalzahl, die bestimmt, welche Zugriffsrechte er hat. Dies ist in meinem Fall offenbar OK - alle Dateizugriffe (außer Schreiben) laufen ja.
Es müssen aber noch andere "Jobs" Zugriff haben, z.B. FTP, diverse Handler, die Serververwaltung und natürlich auch die Scripts, die im Speicher des Users abgelegt sind und da gestartet werden. Diese "Berechtigten" sind in einer Gruppe zusammengefasst, die ebenfalls im Dateisystem mit einer (dreistelligen) Zahl notiert ist, dazu eine Oktalzahl für die Zugriffsrechte ("group") (GID?).
Jeder dieser "Berechtigten" läuft als ein Prozess (PID?) zu irgend einer Zeit; wenn dieser Prozess auf das Dateisystem zugreifen will, muss er in der Gruppe der Berechtigten enthalten sein, sonst erhält er keinen Zugriff, oder einen, der in der dritten Oktalzahl des Dateisystems enthalten ist.
Wenn diese Überlegung stimmt, dann liegt mein Problem darin, dass die Scripts ("Prozesse"), die in meinem WHM laufen, nicht in der Gruppe der Berechtigten enthalten sind.
Kann ich annehmen, dass ich das Problem im Wesentlichen erkannt habe? (Mir ist schon klar, dass im System eine Menge mehr ablaufen wird!)
Alles Liebe,
Helmut
Kann ich annehmen, dass ich das Problem im Wesentlichen erkannt habe? (Mir ist schon klar, dass im System eine Menge mehr ablaufen wird!)
Da Prosa immer mehr Internpretationsspielraum bietet als Fakten: Klingt gut.
Da Prosa immer mehr Internpretationsspielraum bietet als Fakten: Klingt gut.
Danke, tut gut zu erfahren, dass man nicht ganz auf einem Holzweg ist. Damit kann ich schon "zielsicherer" an einer Support-Anfrage arbeiten.
Schönen Arbeitstag noch!
Helmut
Sorry, aber der aktuelle Ansatz scheint mir komplett falsch - "wild" an irgendwelchen Rechten rumbasteln ist keine Lösung.
Ich würde erst mal prüfen:
* welche Rechte, User, ... haben die Scripte und die zu erzeugenden / bearbeitenden Dateien, Verzeichnisse, ... aktuell
* mit welchen Rechten läuft der entsprechende Prozess
* was sagt das OS da parallel dazu, ggf. auch bezüglich Administrativer Einschränkungen wie AppArmor, SELinux, ...
* genaue Fehlermeldung
Abgesehen davon - wenn das ein Managed-System ist welches lief und dann der Hoster etwas gemacht hat (und es dann nicht mehr lief) - ist erst mal nur der Hoster dafür zuständig, das wieder zum laufen zu bekommen.
Hallo marce!
Nachdem Sie sich hier bisher so sehr meiner Sache angenommen haben (und mich an das Serversupport-Forum verweisen haben, danke!), traue ich mich zu fragen:
Würden Sie mir bitte helfen, eine fachlich (administrativ) entsprechende (aussagekräftige) Anfrage an meinen Support zu richten? (Unter Berücksichtigung meiner "in Prosa formulierten" Einsichten, sofern die hilfreich sind. (Und ... wofür steht "TE" in Ihrem Post im Serversupportforum?)
Und ... haben Sie PayPal? Ich würde mich diese Hilfe gerne eine Einladung auf ein Mittagessen kosten lassen. ;)
Schönen Tag und alles Liebe!
Helmut
(1) TE - Thread-Ersteller. Gerne auch mal OP (origin / original poster) oder anderweitig genannt.
(2) Muss ich leider ablehnen. Ich leiste gerne öffentlichen Support im Rahmen div. Foren aber "privaten, persönlichen Support" biete ich nicht.
(zumal ein entsprechendes Schreiben mit "Fakten" aus meiner Sicht bedingen würde, daß ich mir die entsprechenden Fakten auf dem System direkt besorge - und da bin ich (siehe (2)) raus. Daher ja auch mein Verweis auf's andere Forum, wo Leute unterwegs sind, die sowas machen. - die finden sich ggf. sicher auch hier, ich bin es aber nicht)
Danke marce!
Klares Wort; hohe Wertschätzung! Damit kann ich gut leben.
Alles Liebe,
Helmut
Erstelle ich (per FTP) z.B. eine neue Datei (mit Rechten 644), dann können die Scripts diese lesen, aber nicht beschreiben, dazu brauchen sie Rechte 777. (Das sagte mir auch Support des Hosters.) Dann können sie auch von den Sripts verändert werden.
Bemerkung am Rande:
falls der Kundendienst tatsächlich empfohlen hat die Rechte auf 777 zu stellen heisst es dass dieser selber ziemlich ahnungslos ist; da muss man wohl irgendwie klarstellen dass man die nächsthöhere Abteilung sprechen will.
Der "owner" scheint dann (z.B. im WHM) mit "username" auf, aber im Dateisystem (dreistelligen) Zahl (owner), dazu gibt es eine Oktalzahl, die bestimmt, welche Zugriffsrechte er hat. Dies ist in meinem Fall offenbar OK - alle Dateizugriffe (außer Schreiben) laufen ja.Sollte er nicht auch im Dateisystem mit seinem Namen erscheinen???
Wenn er das nicht tut, deutet das doch darauf hin, das die "Übersetzung" UID/GID zu Username/Gruppenname nicht klappt, und da wäre doch auch ein Blick in /etc/passwd und /etc/group nicht verkehrt; zumindest als erste Anlaufstelle. Das dann mit den Rechten auf das/die Verzeichnisse, um die es geht, abgleichen? Beispiel '/var/www' mit Name und numerisch:
ls -la /var/www
ls -lan /var/wwwWobei man einschränkend sagen muss, dass die Verwaltung der Benutzer im konkreten Fall durchaus wesentlich komplexer gelöst sein kann, aber das wissen wir hier nicht ...
Gruß, FM_81
Nachtrag: zu den Rechten "777" kann man zum Testen machen (und nur dann), sonst auf KEINEN Fall, da muss ich den Vorpostern zustimmen ...
Sollte er nicht auch im Dateisystem mit seinem Namen erscheinen???
Wenn er das nicht tut, deutet das doch darauf hin, das die "Übersetzung" UID/GID zu Username/Gruppenname nicht klappt, und da wäre doch auch ein Blick in /etc/passwd und /etc/group nicht verkehrt; zumindest als erste Anlaufstelle. Das dann mit den Rechten auf das/die Verzeichnisse, um die es geht, abgleichen? Beispiel '/var/www' mit Name und numerisch:
ls -la /var/www
ls -lan /var/wwwWobei man einschränkend sagen muss, dass die Verwaltung der Benutzer im konkreten Fall durchaus wesentlich komplexer gelöst sein kann, aber das wissen wir hier nicht ...
Gruß, FM_81
Nachtrag: zu den Rechten "777" kann man zum Testen machen (und nur dann), sonst auf KEINEN Fall, da muss ich den Vorpostern zustimmen ...
Danke herzlich! Habe einige Zeit nicht geantwortet weil zu viel geschehen ist (familiärer Notfall), und zwischendurch (am 22. Mai) das Problem doch endlich von meinem Support gelöst worden ist. Nach all den hier erhaltenen Informationen habe ich mich an den "Billing"-Zuständigen gewendet und ihm das Problem mit seinen Konsquenzen geschildert und ihm 4 sehr gezielte Fragen gestellt. Habe die Kündigung meines Vertarges davon abhängig gemacht, dass alle vier Fragen it "JA" beantwortet werden. Das hat gewirkt. :)
Noch zu den Rechten "777" - das war mir durchaus bewusst, und ich wollte das sowieso nicht belassen - um aber zumindest die wichtigesten Updates in den Dateien zu speichern, musste es wohl verübergehend sein.
Herzlichen Dank noch einmal für die mir gebotene Hilfe und Information!
Helmut
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.