Beiträge von kk

  • PREVIEW LiveConfig 1.5.2-r1823

    Hallo,


    ab sofort steht die Preview für LiveConfig v1.5.2 bereit (r1823).
    Die wichtigsten Änderungen sind:

    • Unterstützung von AWStats
    • Auswahl von mod_php/suPHP/FastCGI pro Angebot/Vertrag
    • viele Detailverbesserungen und kleinere Fehlerbeseitigungen


    Ein ganzer Schwung weiterer Funktionen steht kurz vor Fertigstellung (u.a. weitere Anwendungen für den AppInstaller, Verwendung eigener AppInstaller-Repositories, u.v.m.) - weitere Infos dann in Kürze.


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] DOCUMENT_ROOT stimmt nicht. Rewrite(?) statt VHosts! Ernstes Problem!

    Ja, wir haben hier auf einigen unserer Server auch mal eine solche Suche gemacht. Ich vermute, dass diese Fragestellung bislang deshalb kaum ein Problem war, weil komischerweise 95% aller Kunden alle Domains jeweils im Hauptverzeichnis konfiguriert haben, und die restlichen Kunden (zumindest bei LiveConfig) das DOCUMENT_ROOT bislang nicht anderweitig genutzt hatten.
    Insgesamt sehe ich das aber auch eher problematisch, nicht zuletzt nach den Erlebnissen mit Typo3.


    Und ja, Sie können das auch für bestehende Kunden ändern; eine ausführliche Beschreibung dazu folgt ebenfalls.


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] DOCUMENT_ROOT stimmt nicht. Rewrite(?) statt VHosts! Ernstes Problem!

    Zitat

    Es wird eine größere Herausforderung sein, dem Kunden den Verzicht auf DOCUMENT_ROOT klar zu machen.


    Hmm, das ist natürlich nicht Sinn und Zweck der Sache.


    Wir bauen kurzfristig einen Switch in LiveConfig ein, mit dem Konfigurationen auch mit einzelnen <VirtualHosts> erzeugt werden können, dann entfällt diese Problematik vollständig. :)
    Gedulden Sie sich bitte bis heute Abend, dann gibt es ein Update.


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] DOCUMENT_ROOT stimmt nicht. Rewrite(?) statt VHosts! Ernstes Problem!

    Hallo Herr Groh,


    Zitat

    So ganz ist das zwar noch nicht mein Freund, da mit VirtualHosts auch spezielle Berechtigungen für eben diesen zu realisieren wären


    Das kann man in der RewriteRule-Variante i.d.R. ebenfalls, nur eben mit entsprechenden <Directory>/<Location>-Anweisungen.


    Zitat

    Oh wie ich mir vorstellen kann, wie Sie dieses "aber bei Confixx geht..." annerven muss.


    Naja, sooo schlimm ist es zum Glück auch wieder nicht. ;)


    Zitat

    Aber jetzt das AAABER! Völlig egal ob Confixx oder Plesk oder was auch immer. Irgendwie ist es doch Standard, dass VirtualHosts eingesetzt werden.


    Jein. VirtualHosts sind am einfachsten zu konfigurieren (das bekommen also auch die einfachsten Programmierer hin ;)). Einen echten "Standard" gibt es aber nicht. Vor allem sehr große Hosting-Umgebungen (>10.000 Verträge pro Server) werden in der Regel nicht mit einzelnen <VirtualHosts> für jede einzelne (Sub-)Domain arbeiten (s.u.).


    Zitat

    Ebenso werden wohl die meisten Anwendungen, ob nun Open-Source oder Kommerziell, mit dem Grundgedanken entwickelt, die Anwendung läuft auf dem vermeindlichen DOCUMENT_ROOT.


    Hoffentlich nicht - da DOCUMENT_ROOT eben nur auf irgendein Starterzeichnis des Webspaces verweist und die Anwendung somit nicht in einem Unterverzeichnis betrieben werden kann.


    Zitat

    Ich würde mich aber freuen, wenn Sie mir noch - nur aus Interesse - erklären könnten, warum Sie keine VirtualHosts einsetzen.


    Ausschließlich aus Performancegründen.
    Apache prüft bei jedem Reload, ob jedes in "DocumentRoot" angegebene Verzeichnis existiert. Löscht ein Kunde beispielsweise ein Verzeichnis per FTP, das gleichzeitig noch im LiveConfig als Startverzeichnis für eine Subdomain konfiguriert war, würde Apache hierfür dann eine WARNING bringen (was bei einer Subdomain noch egal sein mag, bei hunderten oder tausenden aber schon lästig wird).
    Um aber herauszufinden, ob ein Verzeichnis existiert, ist ein sog. stat()-Aufruf notwendig. Wenn die Webspaces nun z.B. auf einem vergleichsweise langsamen NFS liegen, kann es eine beträchtliche Zeit dauern, die Apache nur mit tausenden stat()-Aufrufen beschäftigt ist - in dieser Zeit werden keine HTTP-Anfragen verarbeitet. Zudem findet ein Reload der Konfiguration relativ häufig statt (jedes mal, wenn an irgendeiner Subdomain-Konfiguration irgendwas geändert wird) - daher sollte der Reload also möglichst flott ablaufen.


    Wenn man beispielsweise 500 Kunden mit durchschnittlich 5 Domains auf einem Server betreibt und jede Subdomain als VirtualHost konfigurieren würde, dann wären das bis zu 5000 <VirtualHost>-Einträge (500 Kunden * 5 * 2 (mit/ohne "www")).
    Beim Apache-Reload also 5000x stat().
    Mit LiveConfig sind das 500x stat() - wir können also sagen "Ein mit LiveConfig konfigurierter Apache startet bis zu 95% schneller" :P
    (Apache kann man ab Version 2.2.17 auch mit der Option -T starten, welche den DocRoot-Check überspringt - in Debian Squeeze ist aber nur Apache 2.2.16 verfügbar).


    Verstehen Sie also unsere Motivation für die so erzeugte Konfiguration?


    Prinzipiell besteht immer die Möglichkeit, die zuständige Funktion in der apache.lua auszutauschen und tatsächlich für verschiedene Sudomains einzelne <VirtualHost>s zu erzeugen, ohne dass man hierzu in LiveConfig selbst irgendwas ändern/anpassen müsste. Wir sehen aber (derzeit?) keinen Vorteil darin.


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] DOCUMENT_ROOT stimmt nicht. Rewrite(?) statt VHosts! Ernstes Problem!

    Hallo Herr Groh,


    nun - "Problem" ist relativ, und über die eigentliche Ursache lässt sich vermutlich vortrefflich streiten. Im Grund ist es nämlich "suboptimal", in einem PHP-Script aus DOCUMENT_ROOT irgend etwas anderes auslesen zu wollen als das Webspace-Startverzeichnis (DocumentRoot-Einstellung in Apache). Denn auf diese Weise kann ein Script nicht in ein beliebiges Unterverzeichnis verschoben werden, selbst wenn DOCUMENT_ROOT auf das Startverzeichnis der tatsächlich aufgerufenen Domain verweist.
    Um absolute Verzeichnisnamen zuverlässig und unabhängig von jeglicher Serverkonfiguration auszulesen, sollte idealerweise die Variable SCRIPT_FILENAME genutzt werden:

    Code
    $path = basename($_SERVER['SCRIPT_FILENAME']);


    Das nächste Problem sehe ich nämlich auch schon: in dem von Ihnen verwendeten grep-Ausdruck suchen Sie nach /html/ - in LiveConfig liegen die Webspace-Verzeichnisse in ~/htdocs/ (statt ~/html/). Das ließe sich aber auch anpassen.


    Wir verstehen LiveConfig nicht als 1:1-Ersatz für Confixx, da unserer Meinung nach die damit erzeugten Konfigurationen nicht unbedingt ideal sind; daher wird LiveConfig also auch nicht "identische" Konfigurationen erzeugen.


    Konkret gibt es für die vorliegende Fragestellung zwei Lösungen:
    Variante 1: Kunden erziehen:
    Das sich das Controlpanel ändert wird den Kunden vermutlich nicht entgehen (i.d.R. ändern sich ja einige Daten, u.a. die Controlpanel-URL, die Einstellungsmöglichkeiten, etc.). Im Rahmen eines Rundschreibens an die Kunden könnte man darauf hinweisen, dass aufgrund der neuen Konfiguration ein paar Dinge zu beachten sind - dort könnte man dann u.a. auf die Vorteile von SCRIPT_FILENAME ggüber DOCUMENT_ROOT hinweisen.
    Außerdem könnte man (wie auch oben schon gezeigt) mit grep betroffene Kundenscripts identifizieren und die Kunden informieren (am besten schon vor dem Umzug ;)


    Variante 2: Konfiguration anpassen:
    Mit folgenden Änderungen wird DOCUMENT_ROOT für PHP-Scripte angepasst:

    1. Erzeugen Sie eine Datei namens /usr/lib/liveconfig/document_root.inc.php mit folgendem Inhalt:

      PHP
      <?php
  if (isset($_SERVER['DOMAIN_ROOT'])) {
    $_SERVER['DOCUMENT_ROOT'] = $_SERVER['DOMAIN_ROOT'];
  }
?>


    2. Erzeugen Sie eine Datei namens /etc/php5/conf.d/liveconfig.ini mit folgendem Inhalt:

      Code
      auto_prepend_file=/usr/lib/liveconfig/document_root.inc.php


    3. In der Datei /usr/lib/liveconfig/lua/apache.lua suchen Sie die Zeile mit folgendem Inhalt (ca. Zeile 1716):

      Apache Configuration
      fh:write("        RewriteRule ^/(.*)       ", string.gsub(opts.path .. "/htdocs/" .. key, " ", "\\ "), "/$1 [L]\n\n")


      Ändern Sie darin den Eintrag "[L]" in das hier um:

      Code
      [L,E:DOMAIN_ROOT=',opts.path,'/htdocs/',key,']



    Sobald nun an einer vHost-Konfiguration eines Kunden irgendwas geändert wird (oder an den verwendeten Hostingangeboten, was zu einer Aktualisierung der vHosts führt), wird künftig automatisch die Variable DOMAIN_ROOT gesetzt. Durch das auto_prepend in der php.ini wird diese dann in DOCUMENT_ROOT übernommen.
    Dieser Workaround funktioniert eigentlich reibungslos, gilt aber nur für PHP-Scripte.
    Wenn Bedarf besteht, können wir die DOMAIN_ROOT-Umgebungsvariable auch standardmäßig setzen lassen (also ohne dass man die apache.lua anpassen muss)


    Für eine Änderung von ~/htdocs/ in ~/html/ gibt es in Kürze noch eine bequeme Konfigurationsmöglichkeit über die custom.lua


    Als "Worst-Case-Alternative" könnte die apache.lua auch so angepasst werden, dass tatsächlich für jede Subdomain ein eigener <VirtualHost>-Abschnitt erzeugt wird - das bläst aber schnell die Apache-Konfiguration auf.


    Viele Grüße & schönen Sonntag


    -Klaus Keppler

  • SSL Zertifikat

    Einfach am Ende mit anfügen.


    • RSA-Private-Key
    • SSL-CRT
    • CA-Intermediate-1
    • CA-Intermediate-2
    • [...]


    Werden wir sicherheitshalber auch mal mit in den Artikel aufnehmen...

  • [ERLEDIGT] PHP FastCGI unterstützung.

    Die von LiveConfig erzeugte vHost-Konfiguration unterstützt FastCGI durchaus, nur wird noch kein Startscript automatisch angelegt bzw. ist die Auswahl des PHP-Modus über GUI noch nicht möglich. Mit einem manuellen Eingriff (zB. ".httpd.conf") kann FastCGI also schon genutzt werden (ist hier im Forum an anderer Stelle auch schon beschrieben)


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] Anwendung kann nicht installiert werden

    Zitat

    Sollte bzip2 dann nicht auch ueber liveconfig-meta installiert werden?


    Exakt - wir haben bzip2 und unzip inzwischen dort mit aufgenommen (ist also beim nächsten Update dabei).
    Uns ist das bislang auch nicht aufgefallen, da wir bzip2 auf unseren Testsystemen auch standardmäßig immer mit installiert hatten.


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] Awstats

    AWStats wird nun auch unterstützt (ab r1788), ist also in v1.5.2 enthalten, die Preview wird in den nächsten Tagen noch mal aktualisiert.
    Der Admin kann entscheiden, ob Webalizer und/oder AWStats zur Verfügung stehen sollen, der Endkunde kann dann ggf. zwischen diesen Tools selber wählen.


    Viele Grüße


    -Klaus Keppler

  • Reseller anlegen - Vertragstyp nicht wählbar.

    Zitat

    Im Fenster "Neuen Vertrag erstellen" versuche ich verzweifelt, etwas anderes als "Webhosting-Vertrag" zu wählen. Geht aber nicht, weil das der einzige Eintrag ist.


    Hmm, ich verstehe das Problem. Für uns sind auch Resellerverträge in diesem Sinne "Webhosting-Verträge" - die andere Alternative wäre nämlich ein "Server-Vertrag" (das ist für künftige Versionen geplant, wenn man einem Kunden quasi einen kompletten Server zuweisen möchte). Derzeit ist das aber verwirrend; ich denke mal wir werden diese "alternativlose" Dropdown-Box daher vorerst mal entfernen.


    Zitat

    Und siehe da, der Vertrag erscheint beim Kunden. Im Fenster Statistiken stehen die Angaben Hosting-Angebot: mit dem Reseller-Angebot, der WebServer, den ich ausgewählt habe und der Speicherplatz. Sollte da nicht auch der Datenbank-Server und Mailserver auftauchen? Und sollte das nicht klar als Reseller-Vertrag gekennzeichnet sein?


    Die Anzeige wird für Reseller- bzw. Endkundenverträge aus unterschiedlichen Funktionen zusammengestellt; so wie es aussieht werden bei Reseller-Verträgen tatsächlich einige Daten unterschlagen. Wird gleich behoben, das sollte natürlich mit da stehen.


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] Anwendung kann nicht installiert werden

    Hallo Herr Groh,


    der Download sollte unter /var/cache/liveconfig/downloads gecached sein (d.h. dort sollte die Datei "owncloud-4.0.7.tar.bz2" zu finden sein, SHA-Checksum=99b9c5b6b26b75a6ddac610ed47c342e80897c9a).


    Aufgrund der Fehlermeldung vermute ich, dass eventuell das bzip2-Tool nicht installiert ist?
    (aptitude install bzip2)


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] Kennwortlänge des Admin

    ... noch was: in /var/log/liveconfig/liveconfig.log sollten fehlgeschlagene Login-Versuche auftauchen. Falls diese das nicht tun, sind Sie vielleicht auf dem falschen Server? (nicht falsch verstehen, aber das passiert uns hier mit unseren vielen Test-VMs auch ab und zu mal...)


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] Kennwortlänge des Admin

    Das ist absolut merkwürdig... Um einen Passwort-Fehler auszuschließen können Sie auch einfach mal direkt in U_PASSWORD den Wert "$1$Ahe6lrV7$NAJBLmpFnU6ey64PJfXPe/" eintragen - das ist ein MD5-Hash für "admin".
    Oder schicken Sie mir einfach mal einen Hash von Ihnen durch, dann teste ich den mal kurz durch.