Hi, wir betreiben auf einem Linux/Apache2/Postgres/PHP-System mehrere Drupal-basierte Websites, die alle Derivate eines Templates sind. Drupal hat relativ viele Dateien (Module, includes...) die dann in allen Sites identisch sind, nur einige sind für die jeweilige Kundengruppe modifiziert. Haltet Ihr es für eine gute Idee, alle unveränderten Dateien der Derivate durch Symlinks auf das Template zu ersetzen und im Apache also follow symlinks zu erlauben? (Das würde nicht nur Platz sparen, sondern auch die Versionsveraltung enorm erleichtern.) Fällt Euch eine günstige Alternative zu symlinks ein? Kann man follow symlinks auf Verzeichnisse begrenzen, so dass nur die innerhalb dieser liegenden Verlinkungen berücksichtigt werden.? Was für Angriffszenarien haltet Ihr für denkbar? Thx für jeden Tipp cu jth -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Fre, 21 Mai 2010, Joerg Thuemmler schrieb:
Alternative zu symlinks ein? Kann man follow symlinks auf Verzeichnisse begrenzen, so dass nur die innerhalb dieser liegenden Verlinkungen berücksichtigt werden.? Was für Angriffszenarien haltet Ihr für denkbar?
Alternativ gingen evtl. Hardlinks und 'mount --bind'. HTH, -dnh -- "Does anyone else sense the deep irony in a 'Family size' pack of condoms?" -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Jörg,
wir betreiben auf einem Linux/Apache2/Postgres/PHP-System mehrere Drupal-basierte Websites, die alle Derivate eines Templates sind. Drupal hat relativ viele Dateien (Module, includes...) die dann in allen Sites identisch sind, nur einige sind für die jeweilige Kundengruppe modifiziert.
Haltet Ihr es für eine gute Idee, alle unveränderten Dateien der Derivate durch Symlinks auf das Template zu ersetzen und im Apache also follow symlinks zu erlauben? (Das würde nicht nur Platz sparen, sondern auch die Versionsveraltung enorm erleichtern.) Fällt Euch eine günstige Alternative zu symlinks ein? Kann man follow symlinks auf Verzeichnisse begrenzen, so dass nur die innerhalb dieser liegenden Verlinkungen berücksichtigt werden.? Was für Angriffszenarien haltet Ihr für denkbar?
Ich bin auch ein kleiner Freund von Symlinks und verwende diese zur einfachen Verwaltung der jeweiligen Frameworks bzw. CMS-Systeme auf meinem Server. Jedoch kommt es sehr stark auf das eingesetzte Framework bzw. CMS-System an. Bei Frameworks bzw. CMS-System wie z.B. Zend Framework, Codeigniter, TYPO3 funktioniert es mit den Symlinks. In der Regel sollte nur das Cache-Verzeichnis von der Webanwendung beschreibbar sein, manchmal auch das Modul/Addon-Verzeichnis wie z.B. in TYPO3. Sinnvollerweise erstellt man eine Directory-Direktive [1] in der .htaccess (mit einem Schreibschutz versehen!) oder man schreibt gleich in die Apache-Konfiguration des vhosts, um Symlinks im beschreibbaren Verzeichnis zu verbieten. Somit werden potentielle Schwachstellen in der Webanwendung eliminiert, dass dazu genutzt werden kann, um z.B. die Systemkonfiguration zu symlinken und nach mögliche weitere Schwachstellen des Systems abzusuchen. Man sieht, worauf man achten muss, dass man nicht in die Falle läuft und unbeabsichtigt ein halboffenes System am Laufen hat. Ich habe z.B. folgende Struktur aufgebaut. Hier liegen die originale Frameworks/CMS-Systeme: /srv/www/framework/zend-1.10.3 /srv/www/framework/zend-1.10.4 /srv/www/framework/codeingniter-1.7.2 /srv/www/cms/typo3-4.3.3 ... Dann erstelle ich für die Entwicklungsumgebung globale Symlinks, somit habe ich sicher gestellt, dass ich als Entwickler immer das neueste Framework oder CMS-System vorliegen habe und nicht jedes Projekt noch prüfen muss, ob der Symlink noch aktuell ist. Der Vorteil ist für mich als Entwickler, dass ich immer mit der neuesten Version fahre und der globale Symlink ist auch schnell ausgetauscht. Das umständliche Umkopieren entfällt völlig. Globale Symlinks für die Entwicklungsumgebung (Links = Symlink, Rechts = Zielort): /srv/www/framework/zend -> /srv/www/framework/zend-1.10.4 /srv/www/framework/codeingniter -> /srv/www/framework/codeingniter-1.7.2 /srv/www/cms/typo3 ->/srv/www/cms/typo3-4.3.3 ... In der Entwicklungsumgebung werden die Symlinks direkt mit dem globalen Symlink verbunden und habe stets das neueste Framework bzw. CMS-System. z.B.: /srv/vhosts/domain.de/dev/htdocs/typo3_src -> /srv/www/cms/typo3 ... Wenn die Webanwendung in der Entwicklungsumgebung einwandfrei läuft, dann schalte ich in der Produktivumgebung den Symlink auf die aktuelle Version scharf: /srv/vhosts/domain.de/live/htdocs/typo3_src -> /srv/www/cms/typo3-4.3.3 ... Mit dieser Lösung bin ich auf der sicheren Seite und habe 'ne Menge Arbeitszeit eingespart, wenn ich haufenweise TYPO3-Webseiten umstellen muss. Daher Symlink austauschen, dann war es das für mich. Einfacher geht es wirklich nicht. Bitte auch immer die Sicherheitsaspekte im Hinterkopf behalten. ;-) Bei Hardlinks wie David es vorgeschlagen hat, kann man mit großen Einschränkungen auch machen. Jedoch hat es ein paar Nachteile. Denn dieser Hardlink ist nicht sofort ersichtlich bei der Ausgabe von 'ls -l' und je nach Distro wird es auch gar nicht farblich hinterlegt. Und beim Hardlink kannst du nicht über Gerätegrenzen (z.B. auf einer anderen Partition oder Festplatte) hinweg verlinken, dass geht hier nur mit einem symbolischen Link. Hardlinks auf Verzeichnisse lassen sich wegen der auferlegten Systembeschränkung nicht mehr anwenden und das ist für die o.g. Musterlösung leider ein k.o.-Kriterium. @David: Ausnahmsweise bin ich mal nicht deiner Meinung. ;-) Auweia, jetzt habe ich doch wieder ein Roman geschrieben. :-/ HTH, [1] - http://httpd.apache.org/docs/2.2/mod/core.html#directory -- Gruß Sebastian - openSUSE Member (Freespacer) http://de.opensuse.org/Benutzer:Freespacer Wichtiger Hinweis zur openSUSE Mailing Liste: http://de.opensuse.org/OpenSUSE_Mailinglisten-Netiquette -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (3)
-
David Haller
-
Joerg Thuemmler
-
Sebastian Siebert