Webserver/FTP/PHP > Schreibrechte FCGID

[BoBBeer]

Fatal error: Uncaught --> Smarty: unable to write file /var/customers/webs/

 

Das ist mein Ergebnis, nachdem ich mit einem FTP User Daten auf den FTP geladen habe und im Browser öffne.

 

Ich habe das jetzt 3x gemacht und immer wieder ein neues Image draufspielen müssen. Deswegen frage ich jetzt nochmal:

FCGID löst dieses Problem, oder?

 

Wenn ich es jetzt Aktiviere in Froxlor, muss ich noch etwas danach oder Dabei beachten?

Bei den letzten versuchen, warum auch immer konnte ich apache2 nicht neustarten.

 

Diesmal habe ich die Beta von Froxlor installiert.
 

[d00p]

Ich wüsste nicht welches Script mit smarty was in /var/customers/webs/ zu suchen hätte. Ist das Script was du da hast wohl komisch und will unterhalb des customer-docroot schreiben

[BoBBeer]

Habe es falsch Kopiert, sorry.

Fatal error: Uncaught --> Smarty: unable to write file /var/customers/webs/BENUTZER/cache/smarty/compile/ea/fa/4a/wrt56fbf93955e4d2_36502868 <-- thrown in /var/customers/webs/BENUTZER/tools/smarty/sysplugins/smarty_internal_write_file.php on line 46

So wird ein Schuh draus

[d00p]

Gibt es denn den entsprechenden cache Ordner auch? Welche Berechtigungen hat er?

 

Das hat jetzt weniger mit mod_PHP oder fcgid zu tun. Ist ein anwendungsproblem.

[BoBBeer]

Ja, der Ordner existiert.

 

Ich habe einen Kunden angelegt. Der Kunde hat einen Ftp Account angelegt.

 

Dann hat der Kunde die Domain als host angegeben und sich im ftp eingeloggt.also ich, ich bin der Kunde

 

deswegen ging ich davon aus, das ftp und Webserver nicht mit der gleichen Berechtigung laufen.

 

Alle Ordner haben Besitzer und Gruppe 1000 in filezilla

 

Der Ordner BENUTZER, der rot vom Benutzer eben hat in winscp "Besitzer 1000"

[BoBBeer]

Habe gerade das gefunden :https://forum.froxlor.org/index.php/topic/1867-rechteproblem-zwischen-apache-und-ftpuser/

 

Ärgert mich, dass ich es nicht früher gefunden habe.

 

Ich nutze ein Apache2 mit Debian penny u d der aktuellen beta von froxlor.

 

Damals hieß es in dem o.g. Thema, dass froxlor das eigentlich automatisch machen müsste. Da ich hier aber keine tausend Themen dazu finden kann wird es wohl wie schon erwähnt ein Problem vor dem Rechner sein.

 

Auf jeden Fall sehe ich gerade den Wald vor lauter Bäumen nicht.

 

Im o.g. Thema wurde ja gesagt, das man das Problem mit den Rechten mit fcgid umgehen kann

Entweder schreibst du "manuell" in die ftp-user-tabelle, dass die alle die Gruppe www-data haben (keine so gute Idee) oder Du stellst einfach auf FCGID um und umgehst dieses Rechteproblem komplett.

Da ich das mit der stable Version von froxlor versucht habe zu aktivieren und danach Apache2 nicht mehr ging und meine Webseite ein connection refuse zurück geworfen hat frage ich nochmal so:

Könnte mir jemand sagen oder einen Tipp geben wie ich mittels froxlor fcgid aktiviere?

 

Oder

 

Wie ich das aktuell bestehende Problem anders lösen kann.

 

Danke für eure tolle Hilfe

[d00p]

Du mischt hier einiges durcheinander, Achtung. Guck bitte mal auf das Datum des Threads auf den du dich beziehst...

[BoBBeer]

Ja, das Thema ist sehr alt. Trotzdem Frage ich mich, wieso es so ist, wie es ist.

 

1. Server einrichten + Froxlor

2. Also Admin einen Kunden Anlegen

3. Der Kunde Legt DB und FTP an.

4. Der Kunde schiebt Wp,Joomla, Drupal etc. auf seinen FTP Account (/var/www/customers/BENUTZER [default Einstellung von Froxlor])

5. Der Kunde ruft seine URL auf: example.de

6. Der Kunde erhält die Rückmeldung, dass das Script (also doch der Webserver [Apache2] keine Schreibrechte besitzt)

 

Deswegen habe ich ja das Thema auf gemacht. Ich hatte es mit der Stable versucht und jetzt mit der Aktuellen RC.

 

Da in dem von mir genannten Thema hatte ich den Eindruck, dass dieses "Problem" behoben ist. Da ich davon ausgehe, dass es kein "Problem" ist, wird es wohl der DAU vor dem Bildschirm sein, der das Problem ist.

 

Daher hat der Webserver www-data jetzt volle Rechte in dem Kundenverzeichniss(/var/www/customers/BENUTZER [default Einstellung von Froxlor]), damit eine Entsprechende Nutzung der CMS möglich ist. Dadurch hat der FTP Benutzer von Punkt 3. keine Schreibrechte mehr. Logischer weise.

 

Nun müsste FTP Nutzer und Webserver ja eig. in die gleiche Gruppe. Doch da hatte ich öfter mal gelesen, wenn ich es richtig verstanden habe, dass es dabei zum Entzug von Schreibrechten z.B. beim Webserver kommen kann

 

Deswegen mein zweiter Gedanke:

Dann aktiviere ich in Froxlor doch FCGID, denn das soll ja solche Missverständnisse der Rechte lösen.

 

Dabei kam es aber immer wieder zu Problemen den Apache2 Server neu zu starten. Ich ging nach dieser Anleitung vor:

https://redmine.froxlor.org/projects/froxlor/wiki/FCGID_-_Handbuch

 

Bei dem Punkt:

a2enmod suexec
/etc/init.d/apache2 restart

Kann ich den Webserver aber nicht mehr neustarten. Da scheint etwas nicht zu stimmen. Wohl aufgrund der OS (Debian Jessie).

 

Das fängt schon da an, dass ich das nicht ausführen kann:

apt-get install libnss-mysql nscd

Ausgabe wäre das:

:~# apt-get install libnss-mysql nscd
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package libnss-mysql is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'libnss-mysql' has no installation candidate
:~#
 

also habe ich weiter gesucht:

https://forum.froxlor.org/index.php/topic/12267-solved-debian-wheezy-0929-libnss-problem/ (Auch ein sehr viel älterer Beitrag - Finde keine Aktuellen dazu....)

 

Aber:

apt-get install libnss-mysql-bg nscd 

bringt es eben auch nicht.

 

 

Demzufolge kann ich das auch nicht ausführen:

chmod 600 /etc/nss-mysql.conf /etc/nss-mysql-root.conf 

weil die Dateien schlicht nicht da sind. Der nscd restart geht.

ls -al /var/customers/webs/ 

wird auch Korrekt angezeigt.

 

Aber :

/usr/lib/apache2/suexec -V 

geht dann schon wieder nicht, weil die Dateien nicht da sind.

:~# /usr/lib/apache2/suexec -V
-bash: /usr/lib/apache2/suexec: No such file or directory
:~#

Was ja auch klar ist. Konnte ich ja auch nicht installieren.

 

Ich frage mich auch, ob ich nur den Hacken setzen muss, dass Froxlor FCGID nutzt (und im Hintergrund alles macht) oder ob ich es installieren muss und dann den Hacken setzen (oder umgekehrt).

 

Was also tun? Die Funktion ist Froxlor ist da und wenn ich die nutzen will und mich dazu belesen möchte gelange ich immer zu diesem Handbuch. Danach gehts aber nicht.

 

Aber ob nun FCGID oder nicht: Frage mich deshalb trotzdem, wieso das so ist, wie es ist, wie ich es oben geschrieben habe, dass der Webserver auf das Verzeichnis (default) des Kunden keine Schreibrechte hat.

 

 

Aktuell ist es ja so, dass wenn ich das eintrage:
 

ls -al /var/customers/webs/

mir u.a. der FTP Account ja angezeigt wird. Besitzer und Gruppe ist nur eben www-data statt des FTP Benutzers.

 

 

Also weiter, ich aktiviere FCGID in Froxlor und starte den Apache2 neu. Reicht das, oder muss man dann noch etwas dazu anpassen? Eben weil ich nur alte Beiträge finde ist mir das nicht ganz eindeutig.

 

Ansich steht ja da:

Wenn eine Distribution wie Debian, Ubuntu oder Suse benutzt wird, kann hiermit weitergemacht werden. 

Aber was nutzt es mir dann "apt-get install apache2-suexec! auszuführen, wenn ich oben nicht mal  "apt-get install libnss-mysql nscd" ausgeführt habe bzw. konnte.

 

Aber ich glaube nicht, das es ein Froxlor Fehler ist. Ich bin mir sicher, dass der Fehler vor dem Bildschirm sitzt. Finde nur im Moment keine Lösung außer in alten (ganz alten Themen zu suchen). Will ja nicht, dass mir das wer einrichtet. Will es schon verstehen bzw. selbst irgendwie hinbekommen. Aber im Moment eben : Keine Ahnung wie ich weiter verfahren soll / kann.

 

Das war so der Kern meiner Gedanken 

[v3ng]

apt-get install nscd
wget http://ftp.us.debian.org/debian/pool/main/libn/libnss-mysql-bg/libnss-mysql-bg_1.5-4_`dpkg --print-architecture`.deb
dpkg -i libnss-mysql-bg_1.5-4_`dpkg --print-architecture`.deb
rm libnss-mysql-bg_1.5-4_`dpkg --print-architecture`.deb

libnss-bg ist unter Debian 8 nichtmehr verfügbar, daher muss es über den oben beschriebenen Weg heruntergeladen werden. 

 

Grüße

[d00p]

Steht doch alles in unseren Configuration-Templates...