Beiträge von arnoldB

    Kundenmassen im Shared-Hosting sind für mich einfach nur viele Kunden. Bei dem Thema hier entsteht wohl der Eindruck das man [einen] Server (mit Web, Mail, MySQL, etc.) der HA wegen 1:1 clustern/ spiegeln möchte. Das ist bei mir nebenbei bemerkt nicht der Fall.


    Zitat

    Einige Hoster bringen soviele Kunden auf einem Server unter wie es maximal geht bevor alle rumjammern. Ist halt auch immer ne Kalkulationsfrage.


    Darum geht's in diesem Thread aber nicht.

    Ganz ehrlich: im "Mass Shared Hosting" geht die Tendenz dahin, die Dienste auf einzelne (ggf. virtuelle) Server zu verteilen und zentrale Services (insbes. zentrale Storage) zu vermeiden.


    Ich denke nicht das hier jemand Massen Shared-Hosting Server clustern möchte. :)

    1. In LiveConfig Domain-Einstellungen der gewünschten Domain aufrufen
    2. *Irgendeine* Einstellung ändern und wieder rückgängig machen um speichern zu können
    3. /etc/apache/sites-enabled/<VERTRAGSNAME>.conf auf "Include /var/..." prüfen


    Erst dann wird die .httpd.conf beachtet.


    Tipp: Wenn du nachträglich priv/ genauso wie bereits htdocs/ öffentlich freigibst, macht dein Vorhaben aus meiner Sicht überhaupt gar keinen Sinn mehr. ;)

    Wäre meines Erachtens ein Sicherheitsfeature.


    Du kannst in /var/www/<VERTRAGSNAME>/ die Datei .httpd.conf mit beliebig validem Apache Konfigurationscode erstellen. LiveConfig prüft bei der nächsten vHost-Erstellung/Änderung ob diese existiert und setzt ein "Include /var/www/<VERTRAGSnAME>/.httpd.conf" in den passenden vHost.


    Auf typo3_src/ also => priv/typo3_src <= versuche ich als HTTP-Client/ Besucher deiner Website zuzugreifen. Das darf ich nicht. "Order allow,deny" bzw. "allow from all" fehlt ja für priv/.


    Bei einem include/require in PHP greift der PHP-Interpreter auf dem Server selber auf priv/... zu was durch die open_basedir-Einstellung ja erlaubt ist.

    Das priv(ate) Verzeichnis ist ja grundsätzlich nur für Daten gedacht, die nicht öffentlich zugänglich sein sollen.


    Dem Apache (und Nginx) werden keinerlei Infos/ Anweisungen (Zugriff, Ausführung v. Interpreter, ...) für dieses Verzeichnis mitgeteilt. Deswegen sollte das oben aufgeführte Vorgehen grundsätzlich nicht funktionieren.


    It's not a bug, it's a feature. Welchen Sinn das auch haben wird, benutze nur htdocs/ für deine HTTP-Dokumente. ;)



    Nachtrag: Notfalls mit der .htaccess die Zugriffsrechte auf bestimmte Daten entziehen?

    Ich habe den Link gerade nicht zur Hand, das Thema (E-Mail/DBs werden nicht gelöscht) ist aber auf jeden Fall bekannt, nur leider noch noch nicht behoben.

    Man kann sich diese Funktion aber bei Bedarf umbiegen und die Daten in eine eigene Logdatei ausgeben lassen.


    Völlig korrekt.



    Bei lclua handelt es sich im Grunde "nur" um den normalen Lua-Interpreter, erweitert um einige LC-Bibliotheken (LC.expect, LC.mutex, Shared-Memory-Tabellen für IPC, etc.).


    Genau diese finde ich eigentlich ziemlich nützlich und würde dem bequemen Entwickler oder dem ungeschultem Sysadmin *etwas* Arbeit abnehmen.



    Ein Ausbau in ein "größeres" Tool ist derzeit nicht geplant (ich sehe hierfür derzeit auch keinen konkreten Anwendungsfall).


    Schade, kann man aber akzeptieren.

    Freundlicher Hinweis: Ein Hosting Control Panel ersetzt Admin-Kenntnisse nicht.


    Du findest die vHost-Dateien des Webservers in /etc/apache2/sites-available/ (Debian).

    Vieles/ das meiste was LiveConfig am System verändert geschieht über die frei einsehbaren LUA-Skripte. Arbeitet man die durch weiß man so in etwa was die machen und kann notfalls update-sicher die jeweiligen Funktionen überladen.

    Hat sich hier schon was neues ergeben?


    In den nächsten Tagen setze ich ein ähnliches System (Active/Passive Server) auf. DRBD/Pacemaker/Corosync für /var/www, /var/mail/ und diverse weitere Verzeichnisse (im ext4), MySQL Master-Master, etc.


    Wie ich das im einzelnen umsetze/ einrichte muss ich noch prüfen.

    Beim Download von ioncube liegt auf jeden Fall eine Anleitung bei. Die Module legt man dann z.b. unterhalb /usr/local/lib/ ab und erstellt die Datei /etc/php5/conf.d/ioncube.ini (o.ä.) mit dem Inhalt "zend_extension = /usr/local/lib/...". Webserver neustarten und das war dann der ganze Zauber..