Startseite
  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche
Startseite › Forum › Drupalcenter.de › Allgemeines zu Drupal ›

Sichere Dateirechte: Wissen verbreiten und Provider überzeugen

Eingetragen von Jenna (1883)
am 13.09.2015 - 14:54 Uhr in
  • Allgemeines zu Drupal
  • Drupal 7.x oder neuer

Ich verweise hier auf den Thread mit dem Titel von Carsten: http://www.drupalcenter.de/node/53862

Sehr interessant und bisher völlig untergegangen bei mir. Habe das https://www.drupal.org/project/security_review installiert und konnte bis auf eine Meldung auch alles auf grün bekommen.

Meine Frage zu der Meldung: Some files and directories in your install are writable by the server.

Hier folgt nach Check durch das Modul eine ellenlange Liste die bemängelt wird, mehrere hundert Einträge, einige Beispiele dazu:

./themes/seven/images/arrow-next.png
./profiles/standard/standard.profile
./modules/update/update.api.php
./modules/toolbar/toolbar.js
./sites/all/modules/addressfield/addressfield.install
./sites/all/libraries
./cgi-bin

Was muß man da tun? Wenn ich die 755 auf 644 setze (Hauptordner) funktioniert die Seite nicht mehr und alle einzeln abzuändern würde Tage dauern.

Gibt es dazu eine verständliche Anleitung welche Ordner auf 644 laufen sollten, bzw. ist 644 überhaupt richtig oder wie geht man hier vor?

An Carsten großen Dank für die Hinweise auf die Security Einstellungen.

Besten Dank vorab

Jenna

‹ [gelöst] Nochmal: default-Sprache für Startseite festlegen Drupal 8: Felder eines referenzierten users anzeigen ›
  • Anmelden oder Registrieren um Kommentare zu schreiben

bei Managed Hosting leider oft ein Provider-Problem

Eingetragen von C_Logemann (912)
am 13.09.2015 - 18:08 Uhr

Hallo Jenna,
vielen Dank für das Aufgreifen des Themas.
Deine Frage lässt sich nur teilweise beantworten ohne mehr Informationen zu haben. Zunächst mal gibt es keine pauschal richtige Einstellung für die Datei-Rechte, die auf allen Server-Konfigurationen funktionieren und sinnvoll sind.
Wer ohne Wissen über die Hosting-Umgebung dazu eine Empfehlung gibt, zeigt damit meistens nur, wenig Ahnung zu haben. Das heißt, die korrekte Konfiguration für sinnvolle und das heißt für mich auch sichere Schreib-, Lese und Ausführungsrechte hängt von der Server-Konfiguration ab. Der sichere Aspekt – der leider nicht auf allen Webservern funktioniert – ist, daß Drupal/der Webserver nur in speziellen Ordnern Schreibrechte haben sollte. Das kann sehr unterschiedlich sein und lässt sich somit nicht pauschal beantworten. In meinen Setups bedeutet das häufig 750 allgemein und in diesen Ordnern (z.B. "files") 660, da bei mir der Webserver über die "Gruppe" (zweite Zahl) Zugriff auf die Dateien hat. In anderen Server-Konfigurationen kann das aber auch mal über den dritten Wert (für alle) nötig sein. Dies ist dann allerdings ein Indiz dafür, daß evtl. andere System-Benutzer (z.B. andere Kunden) Zugriff auf das Drupal-System haben und selbst bei Betrieb nur eines Projekts, wäre eine Abgrenzung aus Sicherheitsgründen ratsam.

Wenn die Änderung auf dem Webroot schon ein Fehler auslöst, dann macht es in den darunter liegenden Ordnern und Dateien wahrscheinlich auch keinen Sinn. Wenn man aber heraus gefunden hat, wie die richtigen Einstellungen auf einem Server sind, gibt es Befehle, die jeweils Ordner und Files suchen auch rekursiv in verschachtelten Ordnern und auf das Suchergebnis dann die Änderungen vornehmen. Das ist auch auf der Seite "Securing file permissions and ownership" beschrieben. Wenn wir dafür noch keine Übersetzung in Handbuch hier auf Drupalcenter haben, wäre es nützlich wenn sich vllt. ein, zwei Leute mal die Zeit nehmen könnten.

Wenn Du ein fremd verwaltetes System (Managed Hosting) nutzen solltest, ist die entscheidende Frage, ob der Webserver dafür überhaupt die Möglichkeit bietet. Wenn nicht (was leider meiner Erfahrung nach nicht ungewöhnlich ist), liegt auch bei Dir vermutlich das Problem beim Provider. In der Regel verwenden diese zwar separate System-Benutzer, um Kunden-Projekte gegeneinander abzuschirmen, kümmern sich aber nicht darum, daß man innerhalb eines Projekts/einer Domain den Webserver nur begrenzte Schreibrechte einräumen kann. Das heißt, Dein Webserver läuft dann mit den Rechten des einen System-Benutzers.
Es schadet nicht, wenn jeder Drupal-Admin mal höflich bei seinen jeweiligen Hosting-Lieferanten nachfragen würde. Aber wenn die Provider Ihre managed-Systeme darauf nicht konzipiert haben, könnten die nötigen Änderungen evtl. aufwendig und damit teuer für sie sein. Das man es anders machen kann, habe ich sowohl bei Hosteurope gesehen und mir auch selbst erarbeitet mit Standard-Linux-Technolgien (z.B. fcgid und suexec), die man nur mit etwas Basis-Verständnis einer PHP-Webanwendung etwas anders konfigurieren kann. Meine Erkenntnisse dazu werde ich zunächst mal auf drupal.org publizieren, plane dann aber dafür auch eine deutsche Version für das Drupalcenter ein.

Um etwas in der Provider-Landschaft zu bewirken, suche ich Mitstreiter, um zusammen mit dem Drupal e.V. und der Drupal Association kleine und große Provider entsprechend anzusprechen (nicht nur als einzelner Kunde). Als erstes interessieren mich da diejenigen Provider die mir Drupal-Hosting werben. Ich frage hier auf Drupalcenter schon seit Jahren in verschiedenen Kommentaren, ob jemand außer Hosteurope andere Provider kennt und habe leider noch nie einen Hinweis bekommen. Ich finde gut, daß es wenigstens bei einem Provider diese Möglichkeit gibt aber für mich ist diese Sicherheits-Einstellung so essentiell, daß es meiner Meinung nach Standard bei allen Providern sein sollt, die den Betrieb von PHP-Webanwendungen ermöglichen. Das Problem existiert nicht nur bei Drupal.

Siehe auch mein Session-Vorschlag für das DrupalCamp Essen Ende Oktober und meine gerade gegründete g.d.o-Gruppe "Safe file system permissions".

Viele Grüße,
Carsten

Edit: Anfang überarbeitet, um konkrete Frage besser zu beantworten

  • Anmelden oder Registrieren um Kommentare zu schreiben

also die rechte bei

Eingetragen von caw (2762)
am 14.09.2015 - 05:00 Uhr

also die rechte bei hosteurope finde ich immer nervend, weil man immer zwischen www und ftp nutzern untercheidet. das ist bei alfahosting viel einfacher und besser.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sicherheit ist immer anstrengend

Eingetragen von C_Logemann (912)
am 14.09.2015 - 10:58 Uhr

Wenn man in Wohnungen und Büros die Türen nicht abschließt, muss man auch nicht ständig die Schlüssel suchen zum Ab- und Aufschließen. Es ist auch leichter, überall das gleiche, einfache Passwort zu verwenden usw.

caw schrieb

also die rechte bei hosteurope finde ich immer nervend, weil man immer zwischen www und ftp nutzern untercheidet. das ist bei alfahosting viel einfacher und besser.

Als ich das erste mal dies bei Hosteurope entdeckt habe vor Jahren, habe ich mich auch gefragt, warum die das so kompliziert machen. Aber genau diese Benutzer-Unterscheidung (deren Einstellung man vllt. verbessern könnte) und die es dann wohl bei Alfa-Hosting nicht gibt, macht den Webspace sicherer zum Betrieb einer Webanwendung wie Drupal.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Hallo Carsten, vielen Dank

Eingetragen von Jenna (1883)
am 15.09.2015 - 00:47 Uhr

Hallo Carsten,

vielen Dank für deine ausführliche Antwort, aber ich habe hier ein Verständnisproblem. Mein Provider ist sehr flexibel wenn es um sinnvolle Änderungen geht, aber momentan wüßte ich nicht mal was ich ihn genau fragen sollte.

Ich habe über das Security Modul alle nachstehenden Punkte auf grün bekommen:

Base URL is set in settings.php.
Error reporting set to log only.
PHP files in the Drupal files directory cannot be executed.
Dangerous tags were not found in any submitted content (fields).
Untrusted users are not allowed to input dangerous HTML tags.
Private files directory is outside the web server root.
No sensitive temporary files were found.

Nur dieser eine Punkt bleibt rot:
Some files and directories in your install are writable by the server.

Die Liste mit Dateien ist mehrere hundert Einträge lang und zieht sich auch durch Drupal Ordner wie modules, also nicht nur meine installierten Plugins.

Schreibrechte kann ich setzen, aber wo soll man da denn anfangen, man kann doch nicht hunderte Dateien / Ordner händisch jedesmal absichern?

Kannst du mir da auf die Sprünge helfen, bzw. wäre es bei deinem Hoster so das alle diese Dateien von vornherein auf grün stehen durch eine andere Server Config? Oder müssen die dort auch händisch angepasst werden?

Ich spreche gern mit meinem Provider, die hosten sehr komplexe Anwendungen und bisher hatte ich auf alles Zugriff was ich benötigt habe.

Hier fehlt mir nur der Ansatz für eine sinnvolle Fragestellung, daher würde mich interessieren wie die Standard Config bei deinem Hoster ist?
Falls dort keine Anpassungen nötig sind würde ich ein Testpaket buchen, damit ich meinem Provider auf beiden Servern die Unterschiede der Drupal Config zeigen kann die das Modul Security auswirft. So komme ich jedenfalls nicht weiter. Mir geht es nicht darum ein paar Schreibrechte zu setzen, sondern um die riesige Menge an Dateien die das betrifft.

Wenn du magst gebe ich dir auch gern einen Zugang mit einer Testdomain von meinem Flexserver, schreib mir dann gern eine PN.

Mich würde auch sehr interessieren ob noch andere hier das Security Review Modul nutzen und auch so eine lange Liste haben an Some files.....

Grüße Jenna

  • Anmelden oder Registrieren um Kommentare zu schreiben

Sind zwei System-Benutzer vorhanden?

Eingetragen von C_Logemann (912)
am 15.09.2015 - 08:05 Uhr

Hallo Jenna,
die Länge der Liste beschreibbarer Files deutet darauf hin, daß das gesamt File-System unsicher ist und nicht nur einzelne Dateien vergessen wurden. Und gerade weil es passieren kann, daß einzelne Dateien und Verzeichnisse vergessen wurden z.B. bei der Installation eine Modules (was auch in meinen Projekten passieren kann), macht es Sinn, daß der Test des Security-Review-Moduls sich das den ganzen Webroot inkl. Unterverzeichnisse von Drupal "anschaut".

Es ist meiner Meinung nach die Aufgabe von Providern, nicht nur Kundenprojekte gegeneinander abzusichern, sondern den Kunden Werkzeuge zu geben, ihre Webanwendungen bestmöglich absichern zu können, insbesondere, wenn sie sogar damit Werben, daß man dort prima Wordpress, Drupal und Co. betreiben kann. Ich weiß dafür aber bisher keinen anderen sinnvollen Weg als dies mir zwei Benutzer pro Webhost zu organisieren. Wenn ein Hosting-Provider das nicht vorgesehen hat, gibt es dafür auch kein Konfigurations-Möglichkeiten. Wie von CAW schon angesprochen, kann es auch nervig sein, diese zwei System-Benutzer jeweils zu verwalten und zu konfigurieren.

Mir geht es hier nicht darum speziell für Hosteurope Werbung machen. Ich hätte diese Option gerne bei allen Providern. Sobald ich von anderen Providern erfahre, die auch eine sichere Konfiguration ermöglichen, nehme ich diese sehr gerne in eine Liste auf. Auch für meine Demonstration z.B. auf dem DrupalCamp in Essen würde ich gerne mehr als ein positives Beispiel demonstrieren können. Wenn Dein Provider signalisiert, die Situation verbessern zu wollen, bin ich da gerne auch bei behilflich. Du kannst mich da gerne persönlich per Mail oder Kontakt-Formular ansprechen.
Die Einstell-Möglichkeiten bei Hosteurope dokumentiere ich sobald wie möglich auch für meinen Vortrag. Wenn Du meinst, man müsste Deinem Provider das Security-Modul in Action zeigen, können wir ihm das auch mit einem Test-System in einem managed Server von Hosteurope zeigen. Mit meinem selbst verwalteten Servers (Root-System), bei denen ich das selbst auf Server-Ebene konfiguriert habe, kann ich genau erklären, wie das im Detail funktionieren kann. Denn bei Hosteurope weiß ich gar nicht, mit welcher Server-Software und -Konfiguration das dort genau umgesetzt wird.

Viele Grüße,
Carsten

  • Anmelden oder Registrieren um Kommentare zu schreiben

also ich kann die rechte doch

Eingetragen von caw (2762)
am 15.09.2015 - 10:22 Uhr

also ich kann die rechte doch einfach per filezilla und ausgewählten ordnern anpassen.
ich habe gerade mal getestet: ich habe alle dateien auf 644 gesetzt! und das modul zeigt die allerdings immer noch falsch an! das die eben nicht auf 644 stehen. also kann man das modul vergessen?!
ich habe sogar den ordner einmal auf 744 gesetzt, immer noch fehlerhaft

  • Anmelden oder Registrieren um Kommentare zu schreiben

Informationen zu FTP- und Webserver-Benutzer bei Hosteurope

Eingetragen von C_Logemann (912)
am 15.09.2015 - 10:21 Uhr

Hier ist das Konzept grundsätzlich beschreiben:
https://faq.hosteurope.de/index.php?cpid=16595

Da Hosteurope auch die Möglichkeit zulässt, seine Scripte nur mit einem Benutzer zu verwalten und sich als "Webserver-Benutzer" einzuloggen bei SSH-Zugang oder FTP-Zugänge entsprechend zu konfigurieren gibt es somit auch mehr Konfigurations-Möglichkeiten und Gelegenheiten, Fehler zu machen.
Da manchmal Drupal Dateien erzeuget z.B. Cache-Dateien bei denen es "vergisst", der Gruppe Schreibrechte zu geben, kann man bei Hosteurope sich dann sogar als Webserver einloggen und dies korrigieren oder man nutzt die Datei-Verwaltung in der Kunden-verwaltung "KIS" zur Korrektur.

Eine detaillierte Anleitung wäre hier sinnvoll. Aber ich habe da im Moment keine Zeit, diese zu schreiben.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Rechte müssen zur Eigentümer und Gruppen-Konfiguration passen

Eingetragen von C_Logemann (912)
am 15.09.2015 - 10:29 Uhr
caw schrieb

also ich kann die rechte doch einfach per filezilla und ausgewählten ordnern anpassen.
ich habe gerade mal getestet: ich habe alle dateien auf 644 gesetzt! und das modul zeigt die allerdings immer noch falsch an! das die eben nicht auf 644 stehen. also kann man das modul vergessen?!
ich habe sogar den ordner einmal auf 744 gesetzt, immer noch fehlerhaft

Offensichtlich wird auch bei Dir der Webserver mit den Rechten des Datei-Eigners ausgeführt oder der Webserver ist als Datei-Eigner eingetragen, wie man es auch auf Hosteurope konfigurieren kann, bzw. was die Default-EInstellung dort ist. Wenn aber die Konfiguration des Webservers dies Sicherheits-Konzept nicht zulässt, dann kann man es auch nicht mit dem Setzen von Datei-Rechten korrigieren. Das ist dann kein Fehler des Moduls sondern ein Fehler des Drupal-Administrators und/oder des Providers.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Zitat: ich habe gerade mal

Eingetragen von Jenna (1883)
am 15.09.2015 - 13:33 Uhr
Zitat:

ich habe gerade mal getestet: ich habe alle dateien auf 644 gesetzt! und das modul zeigt die allerdings immer noch falsch an!

Hab das auch grad gemacht, auf (644), wie vom Modul empfohlen, als Test bemängelte Dateien aus themes/garland:

./themes/garland/...plus etlicher Unterdateien.

Dieses taucht nun in Security Review nicht mehr als bemängelt auf, dafür gibt es jetzt diese Error Meldung unter Protokolle:
Warning: filemtime() [function.filemtime]: stat failed for themes/garland/garland.info in _system_rebuild_theme_data() (Zeile 2551 von /palxrsqq/meine-domain-punkt-de/modules/system/system.module).

Da ich also Schreibrechte setzen kann und diese auch übernommen werden, wäre ja eigentlich schon mal alles gut... nur:

- kein Mensch wird diesen Aufwand händeln für mehrere hundert Dateien, Files... und zig Installationen
- Error Meldungen möchte ich auch nicht haben

Das halte ich so für nicht umsetzbar.

@carsten
Daher nochmal meine Frage: Wenn ein empfohlenes Drupal Webpaket bei deinem Hoster gebucht wird, ist dann bereits alles auf grün unter Some files and directories in your install are writable by the server oder müßte ich auch dort händisch anpassen?

Nur wenn ich dort keinerlei Änderungen vornehmen müßte, wäre ja der Sicherheitsaspekt gegeben um dieses Webpaket zu empfehlen.

Bevor ich mit meinem Provider spreche würde ich diese Info gern haben, falls du es nicht weißt bleibt nur ein Standard Webpaket (für Drupal empfohlen) dort zu buchen um es selbst zu testen.

Grüße Jenna

  • Anmelden oder Registrieren um Kommentare zu schreiben

Nicht allein auf security_review verlassen

Eingetragen von C_Logemann (912)
am 16.09.2015 - 13:53 Uhr

Grundsätzlich: Die Tipps des Handbuchs über sichere Einstellungen des Webservers sind entscheidend und diese basieren auf ein Zusammenspiel aus Datei-Eigner und Webserver-Gruppe. Ich habe vorhin mal testweise auf meinem lokalen Rechner die Situation "Datei-Eigner gleich Webserver-Benutzer" simuliert. Dem Websrever habe ich dann mit "chmod -R u-w" (-R läuft rekursiv durch alle Unterverzeichnisse), das Schreibrecht entzogen. Daraufhin hat das Modul security_review den File-test grün angezeigt. Das ist aber dann noch nicht so sicher, wie es sein sollte, da der Webserver sich selbst die Schreibrechte zurück geben kann, bei einem entsprechenden Angriff. Diesen habe ich mit dem PHP-Modul ebenfalls simuliert und z.B. dem Order mit dem PHP-Befehl "

<?php
chmod
("misc", 0777);
?>
" das Schreibrecht für alle erteilt. Dies bedeutet für mich, daß dieses Modul noch nicht sicher genug überprüft und werde eine entspreche Issue auf drupal.org eröffnen.

Jenna schrieb

...
Da ich also Schreibrechte setzen kann und diese auch übernommen werden, wäre ja eigentlich schon mal alles gut... nur:

- kein Mensch wird diesen Aufwand händeln für mehrere hundert Dateien, Files... und zig Installationen
- Error Meldungen möchte ich auch nicht haben

Das halte ich so für nicht umsetzbar.

Ich habe schon darauf hingewiesen, daß es dafür Befehle gibt, die viele Datei-Rechte auf einem ändern können. Wenn man allerdings kein SSH zur Verfügung hat helfen dabei oft auch FTP-Programme und die Hoster haben in ihren Benutzerverwaltungen oft Hilfs-Werkzeuge. Also ist eine massenhafte Änderung der vielen Dateien nicht nötig.
Allerdings ergeben die Schreibrechte z.B. als Zahlencode nur im Zusammenhang mit dem Dateieigner und der Gruppe einer Datei oder Ordners eine sinnvolle Konfiguration.
Darauf habe ich schon merhfach hingewiesen. Wenn – wie in meinem oben beschriebenen Test – der Webserver-Benutzer selbst der Datei-Eigner ist, hat er in der Regel die Macht, Änderungen an den Dateien vorzunehmen. Hier gibt es zwar noch Möglichkeiten als Root-Benutzer eine übergreifende Sperre einzurichten, aber die ist im Alltag viel unpraktischer in der Anwendung als das Operieren mit zwei Benutzern.

Jenna schrieb

@carsten
Daher nochmal meine Frage: Wenn ein empfohlenes Drupal Webpaket bei deinem Hoster gebucht wird, ist dann bereits alles auf grün unter Some files and directories in your install are writable by the server oder müßte ich auch dort händisch anpassen?

Auch bei Hosteurope ist das nicht die Default-Konfiguration. Man muss das aktiv konfigurieren inkl. der SSH- und FTP-Benuter, mit denen man dann auf das Projekt zugreift zur Pflege des Systems.

Jenna schrieb

Nur wenn ich dort keinerlei Änderungen vornehmen müßte, wäre ja der Sicherheitsaspekt gegeben um dieses Webpaket zu empfehlen.

Bevor ich mit meinem Provider spreche würde ich diese Info gern haben, falls du es nicht weißt bleibt nur ein Standard Webpaket (für Drupal empfohlen) dort zu buchen um es selbst zu testen.

Mir ist leider zur Zeit kein managed Hosting Paket bekannt, das Out of the Box hier sicher konfiguriert ist. Wer solche kennt, möge mich bitte darüber informieren. Ich würde mich schon freuen, wenn es immerhin Standard wäre, das eine Webanwendung überhaupt mit zwei System-Benutzer absichern zu können. Wenn das die Default-EInstellung wäre, wäre das noch besser und in Sachen Information und einfacher Bedienung kann auch bei Hosteurope noch einiges verbessert werden.

Dieser Thread bestätigt mich darin, daß Wissen zu verbreiten insbesondere bei Drupal-Admins und Hosting-Dienstleister zu überzeugen auf jeden Fall zusammen gehört.

Edit: Link zur neuen Issue hinzugefügt.

  • Anmelden oder Registrieren um Kommentare zu schreiben

Modul zum Reparieren der Dateirechte

Eingetragen von C_Logemann (912)
am 29.09.2015 - 22:43 Uhr

Ich habe ein Modul zum Reparieren der Dateirechte geschrieben, das fast fertig ist:
https://www.drupal.org/project/chmod

  • Anmelden oder Registrieren um Kommentare zu schreiben

Benutzeranmeldung

  • Registrieren
  • Neues Passwort anfordern

Aktive Forenthemen

  • für drupal11 ein Slider Modul
  • [gelöst] W3CSS Paragraphs Views
  • Drupal 11 neu aufsetzen und Bereiche aus 10 importieren
  • Wie erlaubt man neuen Benutzern auf die Resetseite zugreifen zu dürfen.
  • [gelöst] Anzeigeformat Text mit Bild in einem Artikel, Drupal 11
  • Social Media Buttons um Insteragram erweitern
  • Nach Installation der neuesten D10-Version kein Zugriff auf Website
  • Composer nach Umzug
  • [gelöst] Taxonomie Begriffe zeigt nicht alle Nodes an
  • Drupal 11 + Experience Builder (Canvas) + Layout Builder
  • Welche KI verwendet ihr?
  • Update Manger läst sich nicht Installieren
Weiter

Neue Kommentare

  • melde mich mal wieder, da ich
    vor 1 Tag 8 Stunden
  • Hey danke
    vor 2 Tagen 2 Stunden
  • Update: jetzt gibt's ein
    vor 2 Tagen 21 Stunden
  • Hallo, im Prinzip habe ich
    vor 1 Woche 6 Stunden
  • Da scheint die Terminologie
    vor 1 Woche 9 Stunden
  • Kannst doch auch alles direkt
    vor 1 Woche 4 Tagen
  • In der entsprechenden View
    vor 1 Woche 4 Tagen
  • Dazu müsstest Du vermutlich
    vor 1 Woche 4 Tagen
  • gelöst
    vor 4 Wochen 1 Tag
  • Ja natürlich. Dass ist etwas,
    vor 4 Wochen 2 Tagen

Statistik

Beiträge im Forum: 250233
Registrierte User: 20449

Neue User:

  • Mroppoofpaync
  • 4aficiona2
  • AppBuilder

» Alle User anzeigen

User nach Punkten sortiert:
wla9461
stBorchert6003
quiptime4972
Tobias Bähr4019
bv3924
ronald3857
md3717
Thoor3678
Alexander Langer3416
Exterior2903
» User nach Punkten
Zur Zeit sind 0 User und 9 Gäste online.

Hauptmenü

  • » Home
  • » Handbuch & FAQ
  • » Forum
  • » Übersetzungsserver
  • » Suche

Quicklinks I

  • Infos
  • Drupal Showcase
  • Installation
  • Update
  • Forum
  • Team
  • Verhaltensregeln

Quicklinks II

  • Drupal Jobs
  • FAQ
  • Drupal-Kochbuch
  • Best Practice - Drupal Sites - Guidelines
  • Drupal How To's

Quicklinks III

  • Tipps & Tricks
  • Drupal Theme System
  • Theme Handbuch
  • Leitfaden zur Entwicklung von Modulen

RSS & Twitter

  • Drupal Planet deutsch
  • RSS Feed News
  • RSS Feed Planet
  • Twitter Drupalcenter
Drupalcenter Team | Impressum & Datenschutz | Kontakt
Angetrieben von Drupal | Drupal is a registered trademark of Dries Buytaert.
Drupal Initiative - Drupal Association