Das ist auch kein Problem mit ISPCONFIG 3, denn Aliasdomain macht genau das was du willst.
Lege ein Ordner z.B. "subdomain.domain.de" im "web"-Verzeichnis des gewünschten V-Hosts und dann ein Aliasdomain an.
dann stelle folgendes im Aliasdomain ein:
Domain: "subdomain.domain.de"
Parent Website: "domain.de"
Redirect Typ: "No flag"
Redirect Pfad: "/web/subdomain.domain.de"
Auto Subdomain: "none"
Active: "v"
Und das ganze läuft mit einem einzigen Benutzer. Was auch dann höchstwahrscheinlich bedeutet, dass die Resourcen von "subdomain.domain.de" z.B. in PHPs memory-limit des V-Hosts einfließt. Diese lösung ist eher für primäre Ziel sinnvoller(firmadomain.de und firmadomain.net und firmadomain.com).
Also seit vorsichtiger mit diesen Lösung, besonders wenn ihr sowas für mehrere Entwickler einrichtet.
Gruß
Rafael.K
Hallo nochmal,
ich habe es nochmal analysiert und festgestellt, dass meine Antwort die Frage nicht wirklich beantwortet.
In diesem Thread geht es eher um die Erstellung eines echten Apache-VHosts im Verzeichnis eines bestehenden Apache-VHosts und zwar mit gleichen USER:GROUP wie beim bestehenden Apache-VHost.
In diesem Fall soll sich die zu erstellende Subdomain einer echten Webdomain(in ISPCONFIG) gleichen, weil die Ressourcen(Festplatte, CPU, RAM) des Hostsystems nicht unendlich sind.
Im ISPCONFIG solle dann ein Auswahl für Echte||Rewrite beim Erstellen einer Subdomain geben. Außerdem muss einz(1) von (für Kunden gesetzen Limit) "Max. Anzahl an Web Domains" abgezogen werden.
Solche Lösung möge für Viele wegen FTP, SSH, SFTP und vor allem Zentrale-Datenhaltung bequemer sein. Aber es ist ganz schön viel Arbeit, denn selbst für die Sicherheit muss man viel machen.
Beispiele:
1.
Q: 2 unterschiedliche Benutzer sollen die Inhalte von einander nicht lesen/schreiben können, wie löst man es im ISPCONFIG?
A: OK kein Problem -> zwei FTP Benutzer
Q: und was ist mit shell und CGIs?
A: na dann Standartlösung mit mehreren Webs
2.
Q: was passiert wenn Anwendung von sub1.domain.de von Schurken maniepuliert wird?
A: alles was zum schüren auf sub1.domain.de, sub2.domain.de, sub3.domain.de gab, wird geschürt.
Q: ne lieber Standartlösung mit mehreren Webs
3.
Q: Welche Vorteil bietet mir neue Lösung, außer dass es Zentrale-Datenhaltung im Web-Verzeichnis des Domains ist?
A: hm, spontan fällt mir nicht ein
Was Rewrite-Rules angeht, hatte ich weder Aliasdomain- noch Subdomainlösung in Typo3, Joomla, FLOW3 probleme gehabt.
Gruß
Rafael.K