[GELÖST] Unklare / Fehlerhafte User+Group-Zugehörigkeiten

Archive Shopware 3.5
1

Die ersten Fehler sind behoben, geht “nur” noch um die zuletzt aufgeführten Probleme…

Hallo,

ich habe meinen Shop aus der Testumgebung in den Live-Bereich des Servers gezogen.
Die Domain unterscheidet sich und der DB-Name + DB-Benutzername. In der DB und der config.php wurden entsprechende Änderungen eingetragen. Alle Dateien wurden übertragen, die Datenbank in eine neue gespiegelt.
An beiden Systemen wurden bewußt keine Änderungen zwischenzeitlich vorgenommen.
Liegt beides auf dem gleichen Server, nur in unterschiedlichen “Kundenbereichen”.

Folgende Fehler treten nun auf, und ich habe keinerlei Ansätze, wo ich da nach einer Lösung suchen kann. Ich hole mal weit aus, vlt. hilft es bei der Fehlereingrenzung:

  1. Login-Problem

Ich habe zwei Testaccounts. Der erste Login läuft über Info@Domainname.de und als Paßwort 11X1XX11.1111 (natürlich nur ein Syntax-Beispiel :quite:)
Darüber kann ich mich immer problemlos einloggen, auch wenn ich das Kundenkonto lösche und wieder anlege, es gibt nie Probleme.

Der zweite läuft über H.Nachname@gmx.de und als Paßwort 1111,1111. Da klappt der Login nie mit dem angelegten Paßwort, der Shop sagt [quote]Ein Fehler ist aufgetreten! Ihre Zugangsdaten konnten keinem Benutzer zugeordnet werden[/quote].

Lasse ich mir dann ein neues Paßwort per Mail zuschicken, kann ich mich mit dem dort angegebenen PW einloggen. Melde ich mich dann aber ab und versuche mich erneut mit dem PW aus der Mail einzuloggen, kommt wieder die Fehlermeldung. Auch wenn ich das Paßwort zwischenzeitlich ändere, geht es nicht. Löschen und neu anlegen des Accounts führen immer zum gleichen Fehler. mit dem Paßwort 1111111 (also ohne Komma) geht es.

  1. Plugin “Begrüßung im Header”

Wenn ich in der Kopfzeile auf abmelden gehe, wird der Screen wie gewohnt ausgegraut, aber statt des Fenster mit der Logout-Erfolgsmeldung kommt nur ein schwarzer Strich. Nach klick irgendwo hin verschwindet dieser, und man ist auch ausgelogt.
Auch ein komplettes deinstallieren, löschen und neu installieren zeigen keine Veränderung. Testweise - wenn auch unlogisch - hatte ich auch die Änderung an der .htaccess gemäß http://artdevil.de/shopware-plugins/beg … r/#Hinweis vollzogen, natürlich ohne Ergebnis.

Beide Fehler treten in der Testumgebung nach wie vor nicht auf.
Im Backend zeigt die Einstellungen/Systeminfo keine Fehler an. Zugriffsrechte der Verzeichnisse wurden am neuen System manuell angepasst.
Ein kurze grober Quervergleich der beiden DBs zeigt keine Unterschiede.

Tja, wo kann das nur dran liegen? Auf das Plugin könnte ich ja noch verzichten, aber das Login-Problem ist ein nogo - wer weiß wann das bei welchem Kunden auch auftritt.

Also, liebe Experten hier, vlt. seht ihr ja auf den ersten Blick etwas, was mir verschlossen ist :sunglasses:

2

Nachtrag: Im Backend lassen sich auch keine Widgets mehr hinzufügen. Es kommt zwar die Meldung „Widget added successfully“, aber es erscheint kein Widget. Das eine, das ich vor dem Umzug aktiviert hatte, ist aber noch da.

3

Nach wie vor kann ich in der DB und bei den Datei-/Verzeichnisrechten keinen Fehler finden. Hat denn wirklich keiner eine Idee?

4

war nicht der Cache sondern Fehler im Zusammenhang mit SSL

5

Ok, nach knapp 2 Stunden rumsuchen in der Datenbank und dem Filesystem ist aufgefallen, das durch das kopieren die Besitzer- und Gruppenzugehörigkeiten tlw. falsch sind. So muss bei /files/config user+group auf wwrunw/www stehen, ebenso bei engine/Shopware/Proxies/ Wahrscheinlich noch an mehreren Stellen der doch recht verzweigten Ordnerstruktur - das wird noch ein richtiger Spaß, alles zu kontrolieren. :wtf:

6

Hast Du Shell-Zugriff? Dann ginge es über chown -R wwrunw:www . ,wenn Du im Hauptverzeichnis stehst. Es müßte auch ein paar FTP-Programme geben, die rekursive Commands ausführen können.

1 „Gefällt mir“
7

Danke für den Hinweis (nachdem ich hier sonst nur Selbstgespräche führe :P). Ja habe Shell-Zugriff und die oben erwähnten Rechte auch so geändert. Nur: meinst Du ich kann einfach für alle Dateien in allen Verzeichnissen die Rechte enstprechend ändern? Mit den Rechten kapiere ich noch nicht so ganz, und im Standard sind ja nur einige Dateien mit diesen abweichenden Rechten versehen…

8

Ja, definitiv! Guck nochmal nach ob der user wirklich wwrunw und nicht wwwrun heisst. Es kann für den gesamten Bereich der DocumentRoot nur einen User und eine zugehörige Gruppe geben. Alles andere wäre Blödsinn.

1 „Gefällt mir“
9

Ja heißt natürlich wwwrun, war nur ein Schreibfehler hier. Standardmäßig sind bei mir die Rechte - auch bei einer frischen Installation über den SW-Onlineinstaller - immer auf den entsprechenden in Plesk eingerichteten User zur Domain eingetragen. Z.B. User:happyhooping Group: psacln. Bis auf einige Ausnahmen halt… Daher muss ich doch nochmal nachhaken, ob es denn bei Deiner Aussage bleibt, das ich die wirklich einfach alle auf www/wwwrun ändern kann?

10

Nein, dann wird es komplizierter, fürchte ich. Dann müssen wir erst mal den richtigen suexec-User ermitteln. In diesem Fall läuft der Apache Webserver Prozess unter wwwrun:www und der User wwwrun liefert die Dateien bzw. parst sie quasi “virtuell” unter dem User der Domain bzw. es ist ein ähhh… für Webserver User gemachtes “su” (switch user). Bitte mal folgendes auf der Shell prüfen: ps -efa | grep apache | grep -v grep Je nach Linux/Unix Distribution kann auch erst: ps -efa | grep httpd | grep -v grep das gewünschte Ergebnis liefern. Am Anfang der Liste siehst Du den eigentlichen Webserver User (Prozess Owner). Das müßte nach meiner Vermutung dann wwwrun sein. Jetzt wird es etwas tricky. Du musst den VirtualHost Eintrag in der Apache Config finden, der über das sog. suexec_module im Namen des Users des Webspaces die Apache Prozesse in eingeschränktem Rahmen nutzen darf, d.h. irgendwo unter (normalerweise) /etc/apache/ ist ein Eintrag, der ungefähr so aussieht: [code] (…)

SuexecUserGroup happyhooping psacln

DocumentRoot /pfad/zu/deinem/webspace/verzeichnis
ServerName www.deinedomain.de

(…)
[/code] An anderer Stelle müßte das auch nochmal für Port 443 definiert sein, falls Du ein SSL-Zertifikat einsetzt (SSL/HTTPS über Port 443 statt Standard HTTP Port 80) Wenn die DocumentRoot das Verzeichnis ist, das Du für Shopware nutzt, ist der User und die Gruppe dafür das, was hinter SuexecUserGroup steht. Hier müßte es dann so gehen: cd /pfad/zu/deinem/webspace/verzeichnis chown -R happyhooping:psacln . Sollte das nicht funktionieren, ist bei Dir über Plesk irgendetwas falsch eingerichtet worden. In diesem Fall: Backup ziehen, Domain und Webspace in Plesk löschen, neu anlegen, Backup in das neue Webverzeichnis zurückspielen und dann das chown mit dem neuen User und der Gruppe erneut ausführen.

1 „Gefällt mir“
11

Vielen vielen Dank, das Du Dir soviel Mühe gibts. Wenn man sich das alles selber beibringen muss, verzweifelt man irgendwann, und auch die Zeit wird ein Problem (ich bin jetzt schon sooo lange dabei). Bevor ich das mache, aber noch ein paar Rückfragen: - muss ich mich als root oder als der User in der Shell einloggen, oder ist das egal? (alles geht nur um den User myheadshop24, alle anderen Sites laufen problemlos, da dort nichts umgezogen wurde) - wenn der Server es parst, müsste dann nicht wirklich einfach reichen, die Rechte für myheadshop24 überall auf www/wwwrun umzustellen? Momentan sind die Rechte halt je nach Verzeichnis bei allen Domains(=User) auf User/psacln oder eben www/wwwrun Sorry wenn ich “doofe” Rückfragen stelle, aber das ist alles ein Rätsel für mich. Und das obwohl ich Wirtschaftsinformatik studiert habe und wir 6 Monate lang Linux inkl. Shellprogrammierung und Rechten gelernt haben. Aber irgendwie war dieses theoretische gelerne wohl nicht wirklich praxistauglich… ich sehe grad noch: [quote]chown -R happyhooping:psacln .[/quote].

Also bei mir jetzt myheadshop24:psacln - sorry das ich das vorhin durcheinander geworfen habe.
Aber eben diese Rechte sind standardmäßig eingetragen, mussten ja aber bei den erwähnten Verzeichnissen auf www/wwwrun geändert werden…

LG - Heiko

12

Überlege schon, ob ich nicht einfach ein Backup ziehe, alle Rechte für myheadshop24 auf www/wwwrun setze und schaue, was passiert. Aber ich kann überhaupt nicht einschätzen, was der technische Hintergrund ist und welche Auswirkungen das dann evtl. auf die anderen Shops hat. Was vlt. nicht sofort auffällt und dann wieder “unerklärliche” Fehler produziert…

13

Wenn Du ein chown durchführen willst, solltest Du root sein. Der darf alles - auch Besitztümer von Dateien ändern. Wenn der Server es parst, hast Du nur etwas davon, wenn nur lesend zugegriffen wird. Du brauchst aber auch Schreibrechte - und zwar für den User, der in meinem Beispiel happyhooping hieß, jetzt heißt er anscheinend myheadshop24 . wwwrun als Prozesseigner schaut im suexec Eintrag nach, für wen er da sozusagen stellvertretend einen Prozess aufmachen darf (Im Endeffekt läuft es noch anders, aber das geht hier zu weit). Das ist dann laut Eintrag myheadshop24 . Gehören die Dateien alle wwwrun, wird lesend alles funktionieren, weil ohnehin alle Dateien immer public readable sind. Das Schreiben (Cache, Config in Dateien, etc) wird aber von myheadshop24 gemacht und der darf die Dateien von wwwrun nicht schreibend anfassen. Anders herum schon, weil es im suexec Eintrag des Webservers so definiert ist. Letztlich müssen alle Dateien der in der DocumentRoot dem User gehören, der genau dafür angelegt ist. In Deinem Fall dann wohl myheadshop24 . Ich weiß nicht genau, wie Plesk arbeitet, aber wenn ich bei meinem System so einen Webspace mit Domain frisch anlege, legt mein System erst mal eine Dummy index.html rein (“Hier entsteht eine neue Domain, bla, bla”). Der User mit Gruppe dieser Datei muss für alle Shopware-Dateien in diesem Verzeichnis und seinen Unterverzeichnissen identisch sein.

1 „Gefällt mir“
14

Ok, bin grad in der Shell… der Webserver User (Prozess Owner) ist wwwrun. Den Rest schau ich grad. Aber zu Deiner letzten Antwort (wenn ich das richtig verstehe): alles auf User/psacln geht ja eben nicht. So muss bei /files/config user+group auf wwrunw/www stehen, ebenso bei engine/Shopware/Proxies/. Ansonsten produziert der Shop die zuerst erwähnten Fehler. Aber ich poste gleich erstmal, was bei SuexecUserGroup steht, suche noch…

15

Ok, stehe schon wieder auf dem Schlauch: Teilweise finde ich die von Dir beschriebenden Einträge (in mehreren Dateien), tlw. auch garnicht, und nie mehrere zusammen.

16

Im Verzeichnis /etc/apache2 finde ich nirgends(!) „SuexecUserGroup“.…

Hey, und wenn das zu komplex für Dich wird, mir aus der Ferne Tips zu geben, dann schau ich wirklich einfach alle Verzeichnise in der Testumgebung durch, wo die Rechte auf www/wwwrun stehen müssen…

Habe mir eben nochmal die verschiedenen Apache-Config-Dateien angesehen, und die verweisen immer wieder auf unterschiedliche Config-Dateien. Das macht die Sache natürlich komplizierter… Habe schon viele durch, finde aber nichts passendes.

Sag mir einfach, ob es Dir zu stressig wird, mir da weiter zu helfen, das könnte ich absolut verstehen - Ferndiagnose ist immer schwer :slight_smile:

17

Du hast aber bisher auch „nur“ die globale Config gefunden. Wenn die Config so aufgebaut ist, wie in den Kommentarzeilen beschrieben, liegen die VirtualHosts im Verzeichnis /etc/apache2/vhosts.d/ . Die werden ja auch alle per Include /etc/apache2/vhosts.d/*.conf geladen. By the way: Bitte in Deinem Interesse keine vollständigen Config Dateien posten.

1 „Gefällt mir“
18

Hallo, in \apache2\vhosts.d sind nur zwei Template-Dateien als Beispiele, .conf sind dort keine abgelegt… Daher war ich da nicht weiter drauf eingegangen.
Ok, war wohl doch etwas spät gestern, jetzt habe ich es auf Anhieb gefunden, nur in einem …vhost/conf - Verzeicnis weit verzweigt und versteckt :wink: Dort stehen die gesuchten Parameter auf myheadshop24/psacln.

Was nun aber nicht weiterhilft…

Zur Verdeutlichung nochmal:
ich habe 5 verschiedene Installationen von SW in verschiedenen Entwicklungsstufen, inkl. einer komplett nicht geänderten Originalinstallation. Die 5 liegen auf drei verschiedenen User-Bereichen des Servers.

Bei ALLEN sind grundsätzlich die Rechte auf User/psacln - außer (auch bei ALLEN Installation) bei z.B. /files/config und /engine/Shopware/Proxies. Sobald ich die beiden Verzeichnisse mal testweise auf User/psacln stelle, läuft der Shop nicht mehr fehlerfrei.

Daher kann es doch, zumindest bei mir, garnicht sein das ALLE Verzeichnisse auf User/psacln stehen müssen?!

19

Dann ist aber entweder Dein Plesk fehlerhaft oder diese Verzeichnisse haben falsche Rechte. Diese Verzeichnisse gehören zu den wenigen, wo dynamisch zur Laufzeit reingeschrieben wird - und zwar vom Webserver User. Der scheint jetzt plötzlich aus mir unerfindlichen Gründen nur noch wwwrun zu sein, obwohl es myheadshop24 sein müßte. Da stimmt etwas mit suexec_module nicht bzw. mit der Art, wie Plesk diese Webbereiche anlegt. Um die Installation zu retten, würde ich daher nun alles(!) auf wwwrun:www stellen, aber toll ist das nicht.

1 „Gefällt mir“
20

1&1 hat ungefragt das Plesk hier und da öfters geupdatet, ich habe da nichts gemacht. Ansonsten ist das die Grundkonfig, wie 1&1 den vServer anlegt. Überlege eh schon - auch aus Perfomance-Gründen - den Anbieter zu wechseln, aber erstmal muss es noch bei 1&1 laufen. Leider kann ich auch den Support zu diesem Thema nicht befragen, da 1&1 bei Root-Serven diesen vollständig verweigert. (was nicht zu den ungefragten Updates etc. passt) Ich muss noch eine allerletzte Rückfrage stellen: kann es denn negative Auswirkungen, insbesonderes Zugriffsprobleme oder Sicherheitsrisiken geben, wenn ich alles auf www/wwwrun stelle? Ich verstehe diese User-/Gruppeneinstellungen noch nicht, werde mich da künftig mal mit befassen, allerdings habe ich da momentan weder die Zeit noch die geistige Kapazität zu :wink: - zu viel andere Sachen zeitnah zu erledigen. Nochmal vielen Dank für Deine umfangreichen Bemühungen, die mich trotz allem weitergebracht haben, auch besonders im Lernprozess…!!!