[con 4.9.11] Module > HTML: Fehlende Schreibberechtigung

[homtata]

Also das ist definitiv ein Bug, ich kann das in einer Update 4.9.10 auf 4.9.11 auch nachstellen.
Egal, wie korrekt die Ordner- und Dateiberechtigungen seit Versionen stehen, egal, was man nachträglich ändert: die Fehlermeldung beim Aufruf des Smarty-HTML-Editors ist immer da, stimmt aber auch nicht, weil man in Wahrheit dann doch Schreibrechte hat und speichern kann
Der User "ulides" hat das in einer Neuinstallation 4.9.11 ebenfalls, obwohl da sonst auch alles stimmt.

[frederic.schneider_4fb]

Ich gebe Dir recht: Die Fehlermeldung ist häufig irrtürmlich. Das nehmen wir auf!

[frederic.schneider_4fb]

Ich bin Euch noch eine Rückmeldung schuldig:

Wir haben in der aktuellen Entwicklerversion die CHMOD-Rechte auf 755 zurückgefahren. Es wird also nicht mehr 777 vorausgesetzt. In meinen bisherigen Tests, lokal oder auf Testsystemen, hat dies problemlos funktioniert. Es bleibt natürlich ein Restrisiko, wenn die chown-Rechte gleichzeitig nicht übereinstimmen. Wir haben deshalb bei Neuinstallationen als auch bei Upgrades eine stets vorkommende Infomeldung im Setup eingebaut, die darauf hinweist. Außerdem ist dies bereits jetzt schon in der Dokumentation berücksichtigt.

Die Herabsetzung der CHMOD-Rechte von 777 auf 755 wird mit der nächsten regulären Version kommen.

Ich hoffe, dass diese Entscheidung auf Euer Wohlwollen stößt (und im Übrigen alles klappt). Es gab zugegebenermaßen bei uns intern mehrere Diskussionen darüber, ob wir das so machen sollten, und ich hatte mich für Euer Anliegen eingesetzt und am Ende waren wir uns alle einig, dass CHMOD-Rechte 755 eine gute Sache ist.

[rethus]

Jep, finde ich auch. Nur soweit öffnen, wie nötig.

Das Sahne-Häubchen wäre nun, wenn Ihr kurz einen chmod-Befehl postet, der (für die shell auf dem Server) einmal alle rechte beinhaltet... oder noch besser ein shell-script mit in die Installation legt, das diesen chmod ausführt.
Damit wäre das leidige Thema endgültig und Nachhaltig vom Tisch.

[Oldperl]

Das Sahne-Häubchen wäre nun, wenn Ihr kurz einen chmod-Befehl postet, der (für die shell auf dem Server) einmal alle rechte beinhaltet... oder noch besser ein shell-script mit in die Installation legt, das diesen chmod ausführt.

Keine gute Idee, da doch Niemand weiß wie auf dem Server die Rechte konfiguriert sind. Es gibt Server da reicht ein 775 und bei anderen braucht es ein 777. Das kommt darauf an wie auf dem Server die Rechte von Usern und Gruppen gesetzt sind und welches Apache-Modul beispielsweise läuft.
Falls Jemand ein Shell-Script schreiben kann welches all diese Möglichkeiten sicher abdeckt, dann her damit, denn so etwas könnte ich auch gut gebrauchen.

Gruß aus Franken

Ortwin

[Faar]

Falls Jemand ein Shell-Script schreiben kann ...

Ich wurde gerufen?

...welches all diese Möglichkeiten sicher abdeckt

Ohje, es sind inzwischen einige Jahre her, dass ich Shell-Scripts programmiert hätte.
Für Linux wird meistens das Bash: Bourne Again Shell benützt. (üblicher Pfad: /bin/bash)
Aus dem Stegreif könnte ich sowas nicht mehr programmieren.
Zumal dazu kommt, dass das Script auch mit den nötigen Rechten ausgeführt werden muss.
Damals hatte ich meistens Root Rechte und wenn einmal nicht, konnte es sein, dass nur die Scripte mit Root-Rechten ausgeführt wurden und die mit anderen Rechten völlig ignoriert wurden.
Da gibt es ein paar Gemeinheiten in Linux, die definitiv den root-User bevorzugen.
Aber root haben wir in den meisten Contenido Installationen nicht, sondern eher den FTP-User und im Zweifel hat das ausführende Programm bei manchen Hostern dann gar keine Rechte, bevor nicht auf den PHP-User umgestellt wurde.
Und wenn man schon soweit ist, kann man chown und chmod auch gleich von Hand umstellen.

[Faar]

Vielleicht geht das:

Code: Alles auswählen

#!/bin/bash
# Dingens

sudo cd /var/www/$contenidoverzeichnis
sudo chown ${USER:=$(/usr/bin/id -run)}:$USER /var/www/$contenidoverzeichnis
sudo chmod 755 /var/www/$contenidoverzeichnis

Wobei $USER manchmal nicht gesetzt ist und stattdessen die id genommen werden muss.
Aber anzunehmen ist, dass $USER auch der eingeloggte User in Linux ist, weil das beim ordentlichen Login gesetzt wird:

Code: Alles auswählen

setenv("USER", pwd->pw_name, 1);

Aber haben wir einen ordentlichen Login in Linux, wenn Contenido aus HTTP installiert wird?
Zum eine, FTP ist ein ordentlicher Linux User und wenn dann die Ausführungsrechte von PHP auch der Owner ist, dann entspricht das auch einem ordentlichen $USER.
Einige Hoster setzen FTP und PHP in eine Gruppe gleichen Namens, weshalb chown $USER:$USER schon passen würde.
Aber praktisch könnte man auch statt $USER den Usernamen ausschreiben und der Gruppe einen anderen Namen geben.
Das geht aber vermutlich nur manuell, da das Installationsscript den Namen nicht weiß, sondern nur von z.B. $USER beziehen kann.
In welchen Gruppen der User ist, kann man hiermit finden:

Code: Alles auswählen

$ grep Username /etc/group
oder
$ groups {username}

Aber was ist, wenn da mehrere Gruppen auftauchen? Welche ist dann die richtige?
Kurzum: Vermutlich läuft es darauf hinaus, dass man für einen Server ein solches Shell-Script optimieren könnte bis es einwandfrei läuft, aber ob es auf anderen Servern läuft, bezweifle ich mal.
Jeder Hoster kocht seinen eigenen Brei.

[Oldperl]

Jeder Hoster kocht seinen eigenen Brei.

Das sehe ich auch so. Daher ist ein solches Script in meinen Augen nicht umsetzbar. Auch mit der Empfehlung World-Schreibrechte (777) zu setzen wäre ich immer vorsichtig, denn auch das ist oft gar nicht notwendig.

Gruß aus Franken

Ortwin

[rethus]

Ok, danke für Euer Feedback.
Als erstes sei hier erwähnt, das es nicht um chown und eine Eierlegende-Wollmilchsau geht, sondern nur um die chmod-Rechte und eine kleine Hilfe für die Enwickler. K•I•S•S

1. Abstraktion-Ebene:
Von Contenido aus gesehen analysiert man, welche Verzeichnisse die gleichen Rechte brauchen und welches Resultat die Rechte erzeugen (schreibbar, lesbar, etc) [wohlgemerkt hier gehts noch nicht um 777 oder 775 !! -wird gleich klar... ]

2. Abstaktion-Ebene:
Nun wo wir die erforderlichen Resultate der Rechte haben, ist es einfach darauf zu reagieren. Wenn also bei Server 1 die Rechte 777 i.O. gehen, aber Server 2 nur mit 775 arbeitet (z.B. wegen suhosin Modul), passt man in dem Script die Rechte einfach an.

3. Fertig.

Wie gesagt, mir geht es hier nicht darum einen Automatismus zu haben, der alles Testet und jede Eventualität abdeckt. Ich finde sogar "Script" müsste nicht sein. Es reicht auch eine Textdatei mit einem vorgefertigten chmod-Befehl, den man sich zur Ausführung auf der Konsole kopieren kann. Es geht einfach darum, das man eine Gruppierung der Verzeichnisse entsprechend Ihrer angeforderten Zugriffs-Erfordernisse hat. Ob nun bei einem Server 775, 777, oder 644 gesetzt wird ist dabei nebensächlich, da man das dann kurz checken kann.

Klar, kann ich mir auch selbst mal austüfteln, und lokal auf Halde legen. Schön Entwicklerfreundlich wäre es aber, wenn so eine Textdatei direkt mit ausgeliefert wird. Vor allem weil die Berechtigungsprobleme immer und immer wieder im Forum auftauchen.

[Oldperl]

Klar, kann ich mir auch selbst mal austüfteln, und lokal auf Halde legen. Schön Entwicklerfreundlich wäre es aber, wenn so eine Textdatei direkt mit ausgeliefert wird. Vor allem weil die Berechtigungsprobleme immer und immer wieder im Forum auftauchen.

Nun, da kann ich mal wieder nur sagen RTFM

In der beiliegende README.txt kann man lesen

-------------------------------------------------------------------

Anleitungen zur Installation oder Aktualiserung finden sie im
Verzeichnis docs/ oder unter https://docs.contenido.org/display/COND.

Installation or upgrade guides can be found in the docs/ folder
or at https://docs.contenido.org/display/CONE.

-------------------------------------------------------------------

und in der entsprechenden pdf-Datei für die Systemvoraussetzungen findet man unter dem Punkt Dateisystem

Dateisystem
CONTENIDO benötigt zum Schreiben für einige Dateien Schreibrechte.

Die folgenden System Ordner benötigen Schreibrechte:
ROOT/data/logs/errorlog.txt
ROOT/data/logs/setuplog.txt
ROOT/data/cronlog/pseudo-cron.log
ROOT/data/cronlog/session_cleanup.php.job
ROOT/data/cronlog/send_reminder.php.job
ROOT/data/cronlog/optimize_database.php.job
ROOT/data/cronlog/move_old_stats.php.job
ROOT/data/cronlog/move_articles.php.job
ROOT/data/cronlog/linkchecker.php.job
ROOT/data/cronlog/run_newsletter_job.php.job
ROOT/data/cronlog/setfrontenduserstate.php.job
ROOT/data/cronlog/advance_workflow.php.job
ROOT/data/cache
ROOT/data/temp
ROOT/data/config/config.php

Die folgenden Mandanten Ordner benötigen Schreibrechte:
ROOT/cms/cache
ROOT/cms/cache/code
ROOT/cms/css
ROOT/cms/data
ROOT/cms/data/layouts
ROOT/cms/data/logs
ROOT/cms/data/modules
ROOT/cms/data/version
ROOT/cms/data/version/css
ROOT/cms/data/version/js
ROOT/cms/data/version/layout
ROOT/cms/data/version/module
ROOT/cms/data/version/templates
ROOT/cms/js
ROOT/cms/templates
ROOT/cms/upload

entsprechendes findet man auch online in der Entwickler-Dokumentation https://docs.contenido.org/display/COND ... quirements

Zu guter Letzt macht auch das Setup nochmal entsprechende Überprüfungen des Systems und gibt Meldungen bei fehlenden Rechten aus. Daher denke ich, dass CONTENIDO hier schon viele systemunabhängige Hilfestellungen gibt, ein bisserl sollte der Benutzer aber auch schon selbst über sein Web- oder Server-Paket wissen und damit arbeiten können.
Ansonsten gibt es auch immer noch die Möglichkeit eines "managed" Systems.

Und wenn man unbedingt den Befehl für sich Selbst zusammenbasteln möchte - kommt ja auch darauf an auf welchem Weg ich die Rechte ändere (Shell, FTP) - so kann man das mit den dort angegebenen Pfaden doch auch leicht selbst machen.

Gruß aus Franken

Ortwin

[rethus]

Vielleicht drücke ich mich einfach nur kompliziert aus?

Das in der Doku Infos darüber stehen wie die Rechte sein sollten ist mir schon klar
Nennen wir es mal einen "ShortCut" oder "Arbeitserleichterung" zum setzen von Rechten.

PS: Wer bis jetzt nicht verstanden hat, worum es mir geht... ...einfach ignorieren, und andere antworten lassen