Der Weg zum Fullstackdeveloper

Apache lokal einrichten

🧱 Einleitung

Wenn man anfängt, sich eine lokale Entwicklungsumgebung unter Linux aufzubauen, landet man früher oder später bei einem der nervigsten Themen:

Dateirechte.

Ich habe im Laufe der Zeit einige Ansätze ausprobiert:

  • Apache klassisch als www-data
  • Projekte in /var/www
  • Gruppenrechte + umask
  • Bind-Mounts über /etc/fstab
  • Apache direkt als eigener Benutzer

Jeder Ansatz hat funktioniert – aber keiner war wirklich zufriedenstellend.

Das größte Problem war immer das Gleiche:

Neue Dateien hatten plötzlich wieder falsche Rechte.

Egal ob durch Git, Downloads oder Entpacken – ich musste ständig nacharbeiten.

🛞 Meine bisherige Erfahrungen

Meine allererste Erfahrung mit PHP machte ich mit XAMPP auf Windows. Für Anfänger, die Programmieren lernen, ist das eine einfache Lösung. Für komplexere Entwicklungsumgebungen eher ungeeignet, da es sich nicht komplexer konfigurieren lässt, sehr unsicher und weit entfernt von der Produktionsumgebung. Es reicht, um die ersten Kommandos in PHP zu lernen, und mehr hatte ich mit PHP bisher nicht zu tun. Meine erste Programmiersprache ist Java und ich war da noch in diesem Kosmos unterwegs.

In meinem Praktikum während meines Informatikstudiums. Da habe ich mich intensiv und schnell in PHP eingearbeitet. Damals hatte ich Ubuntu auf meinem Laptop während die Kollegen mit Mac arbeiteten. Damals sah mein Linux-Setup so aus, dass ich in /var/www/ einen symbolischen Link zu meinen Projektordnern gesetzt habe und mit chmod 777 so gesetzt, dass Apache und alle anderen User Zugriff haben. Wir wussten schon damals, dass das ein fürchterliches Setup ist. Wir wussten es aber damals nicht besser.

Die längste Zeit hatte ich ein Bindfs-Setup. Das war tatsächlich sehr sinnvoll. In diesem Setup liegen die Dateien in /var/www/ und werden ins Home-Verzeichnis gespiegelt, während die Dateien Besitzer und Gruppe tatsächlich www-data ist und die gespiegelten Dateien meinen Benutzer und meine Gruppe besitzen. Das Problem ist jedoch, dass sich IntelliJ beim Indexieren schwer tut und denkt, dass die Dateien auf einem externen Datenträger und Netzlaufwerk liegen.

Mit MAMP Pro auf einem MacBook, das mal für kurze Zeit mein Arbeitsgerät war , kam ich nicht gut klar und wollte wieder zurück zu einem reinen Apache-Setup. Allerdings verhielt es sich nicht, wie es sollte, und ich verstand nicht, was das Problem war. Nach vielen Stunden stellte ich fest, dass die Konfigurationsdateien nicht griffen, sondern in einer Datenbank Apache-Konfigurationen von MAMP lagen, die meine Konfiguration überschreibt. Es gibt einen speziellen Weg, wie man MAMP Pro deinstallieren muss, und dies ist nicht trivial.

Ja, der Unix-Way, kam schon sehr nah an eine praktische Lösung, die dem Produktivsystem nah kommt. Dazu habe ich meinen Benutzer zur Gruppe www-data hinzugefügt und die Rechte auf 775 und umask auf 002 gesetzt, so dass Mitglieder der Gruppe Schreibrechte auf die Dateien haben. Das ging auch soweit gut, wenn ich die Dateien erstellt bzw. bearbeitet habe. Allerdings machen Datei-Vorgänge wie git pull, das Entpacken von Archiven oder über PHP-Upload hochgeladenen Dateien dies nicht und setzen die Dateirechte entweder so, dass nur ich oder Apache darauf Zugriff haben. Ich musste ständig die Dateirechte neu setzen.

Dann hatte ich tatsächlich auch mal ein Docker-Setup. Nicht einfach wp-env. Dies für meine Ansprüche anzupassen war komplizierter, statt eine eigene Docker-Konfiguration zu entwickeln. Es ist ziemlich kompliziert gewesen, manchmal funktionierten die Path-Mappings nicht und es ist umständlich, sich in den jeweiligen Container einloggen zu müssen, wenn man nach Fehlern sucht. Das Schlimmste allerdings war. dass ich den Debugger nicht zum Laufen bekommen habe bzw. nur eine kurze Zeit lang mittels eines speziellen Plugins, das jedoch mit einer neueren IntelliJ-Version nicht mehr funktionierte und nicht gepflegt wurde. Auch innerhalb der WSL funktionierte Debugging nicht mehr. Das war sehr frustrierend und war damals schon kurz davor, wieder zurück zu Linux zu kehren. Das Windows-10-Ende war dann der entscheidende Grund, zurückzukehren.

Noch in Windows mit der WSL habe ich meine Entwicklungsumgebung vereinfacht. Die Projekte blieben in meinem Home-Ordner und ich ließ Apache unter meinem Benutzer laufen. Damit gab es keine Probleme mit den Dateirechten mehr. Heute und viele Jahre später erfahre ich, dass es eine ganz einfache Lösung gibt 🙈 ➡️ ACL

🎯 Ziel

  • keine Rechte-Probleme
  • keine Gruppen-Konfiguration
  • kein chmod-Chaos
  • Projekte direkt im Home-Verzeichnis
  • schnelle und einfache Entwicklung
  • keine manuelle Nacharbeit bei Dateirechten
  • keine 777-Rechte
  • Zugriff über projekt.local
  • Apache läuft standardkonform (www-data)

📁 1. Projektstruktur

Ich nutze eine einfache Struktur im Home-Verzeichnis:

/home/chidraeve/www/
    projekt1/
    projekt2/

👉 Vorteil:

  • volle Kontrolle
  • keine Arbeit in Systemverzeichnissen
  • einfach zu sichern

📦 2. Apache installieren

sudo apt update
sudo apt install apache2

Test:

http://localhost

🔧 3. Wichtige Module aktivieren

sudo a2enmod rewrite
sudo a2enmod headers
sudo systemctl restart apache2

👉 Besonders wichtig: rewrite für WordPress.

🌐 4. VirtualHost für Projekte

Beispiel:

sudo vim /etc/apache2/sites-available/projekt1.conf
<VirtualHost *:80>
    ServerName projekt1.local    

    DocumentRoot /home/chidraeve/www/projekt1    

    <Directory /home/chidraeve/www/projekt1>
        AllowOverride All
        Require all granted
    </Directory>    
    
    ErrorLog ${APACHE_LOG_DIR}/projekt1_error.log
    CustomLog ${APACHE_LOG_DIR}/projekt1_access.log combined
</VirtualHost>

Aktivieren:

sudo a2ensite projekt1.conf
sudo systemctl reload apache2

🧭 5. hosts-Eintrag

127.0.0.1 projekt1.local

💥 6. Das eigentliche Problem: Dateirechte

Typisches Szenario:

  • Projekt wird geklont
  • ZIP entpackt
  • neue Dateien erstellt

👉 Ergebnis:

  • Apache kann nicht schreiben
  • oder nicht lesen
  • oder du musst wieder chmod ausführen

🧠 7. Klassische Lösungen (und ihre Probleme)

LösungProblem
chmod 777unsauber
Gruppen (www-data)inkonsistent
umaskgreift nicht immer
Apache als Usernicht realitätsnah
Symlinkslösen Rechteproblem nicht

🔥 8. Die Lösung: ACL (Access Control Lists)

Hier kommt der Gamechanger:

👉 ACL erlaubt es, zusätzliche Rechte unabhängig von Unix-Standardrechten zu definieren

Und vor allem:

Default-Rechte für neue Dateien

⚙️ 9. ACL installieren

sudo apt install acl

Falls es nicht bereits installiert sein sollte. Meine neue Ubuntu-Installation hatte es bereits vorinstalliert

🔧 10. Rechte setzen

Für dein Projektverzeichnis:

setfacl -R -m u:www-data:rwx ~/projects

👉 Apache bekommt Zugriff auf bestehende Dateien

💡 11. Der entscheidende Schritt: Default ACL

setfacl -dR -m u:www-data:rwx ~/projects

👉 Jetzt passiert automatisch:

  • neue Dateien → Apache hat Zugriff
  • neue Ordner → Apache hat Zugriff
  • Git / unzip → funktioniert ohne Nacharbeit

🔍 12. Prüfen

getfacl ~/projects

🧠 13. Warum das funktioniert

Normalerweise:

  • Rechte werden durch umask bestimmt
  • Gruppen müssen stimmen

Mit ACL:

Das System erzwingt zusätzliche Rechte – unabhängig davon, wie Dateien entstehen

⚖️ 14. Vergleich

AnsatzBewertung
Apache als User✅ einfach
Gruppen + umask⚠️ fehleranfällig
Docker⚠️ Overhead
ACL✅ sauber & zuverlässig

🚀 15. Fazit

Nach vielen Experimenten ist das für mich die beste Lösung:

  • Apache läuft standardmäßig als www-data
  • Projekte liegen im Home-Verzeichnis
  • ACL regelt die Rechte automatisch

👉 Ergebnis:

Keine Rechteprobleme mehr – egal wie Dateien entstehen.

🔜 Nächster Schritt

Im nächsten Artikel:

  • PHP installieren
  • MySQL einrichten
  • typische Probleme (Socket, Auth) lösen

💡 Persönliche Erkenntnis

Ich habe lange versucht, das Problem mit klassischen Unix-Mitteln zu lösen.
ACL wirkt auf den ersten Blick wie „Overkill“, ist aber genau das fehlende Werkzeug für diesen Anwendungsfall.

🔄 15. Projektstruktur mit /var/www + ACL (empfohlener Standard)

Für eine möglichst kompatible und systemnahe Lösung liegen die Projekte direkt unter /var/www:

/var/www/
    projekt1/
    projekt2/

🔧 Rechte setzen

Zunächst stelle ich sicher, dass ich selbst Zugriff habe:

sudo chown -R $USER:www-data /var/www
chmod -R 775 /var/www

🔥 ACL setzen (entscheidender Schritt)

Damit Apache (www-data) dauerhaft Zugriff hat – auch auf neue Dateien:

setfacl -R -m u:www-data:rwx /var/www
setfacl -dR -m u:www-data:rwx /var/www

👉 Ergebnis:

  • bestehende Dateien → zugreifbar
  • neue Dateien → automatisch korrekt
  • keine Nacharbeit mehr bei Git, unzip, etc.

🔗 Komfort: Symlink ins Home-Verzeichnis

Um nicht ständig in /var/www arbeiten zu müssen:

ln -s /var/www ~/www

👉 Entwicklung erfolgt dann bequem über:

~/www/projekt1

⚠️ 16. Sonderfall: Projekte auf separatem Laufwerk

In meinem Setup liegen die Projekte nicht direkt unter /var/www, sondern auf einem anderen Laufwerk:

/mnt/myhome/www/

Ich nutze weiterhin /var/www als Einstiegspunkt für Apache und löse das über einen Symlink:

sudo ln -s /mnt/myhome/www /var/www

👉 Alternativ (oft sauberer):

sudo ln -s /mnt/myhome/www/projekt1 /var/www/projekt1

❗ Problem: Zugriff über das Home-Verzeichnis

Zusätzlich habe ich einen Symlink im Home:

ln -s /mnt/myhome/www /home/chidraeve/www

Mein Home-Verzeichnis hat jedoch restriktive Rechte:

chmod 750 /home/chidraeve

👉 Wichtig:

Apache kann nicht „durch“ Verzeichnisse gehen, auf die es keinen Zugriff hat.

🧠 Entscheidender Punkt

Für Apache zählt nicht der Symlink im Home, sondern:

👉 der reale Pfad (/mnt/myhome/www/...)

✅ Lösung mit ACL

Auch hier löst ACL das Problem sauber:

setfacl -R -m u:www-data:rwx /mnt/myhome/www
setfacl -dR -m u:www-data:rwx /mnt/myhome/www

🔍 Optional: Zugriff auf übergeordnete Verzeichnisse

Falls notwendig:

setfacl -m u:www-data:rx /mnt
setfacl -m u:www-data:rx /mnt/myhome

👉 Damit kann Apache den Pfad traversieren

🧠 Wichtige Erkenntnis

Symlinks sind für Komfort da – aber für Berechtigungen zählt immer der echte Pfad.

Und:

Apache benötigt Zugriff auf jedes Verzeichnis im Pfad, nicht nur auf das Projekt selbst.

🚀 Abschlussfazit

Mit dieser Kombination ergibt sich ein robustes Setup:

  • Projekte unter /var/www (klassisch)
  • optional auf externem Laufwerk ausgelagert
  • Zugriff über Symlinks im Home (Komfort)
  • Rechte sauber über ACL geregelt

👉 Ergebnis:

  • keine Rechteprobleme mehr
  • kein chmod-Nacharbeiten
  • kompatibel mit Tools und realen Servern

Das ist jetzt richtig rund:

  • dein ursprüngliches Problem gelöst ✅
  • dein Spezialfall eingebaut ✅
  • und gleichzeitig „Best Practice“-fähig geblieben ✅