Beiträge von kk

  • Confixx Import Script Problem

    Zitat

    Webserver not found or not permitted


    Merkwürdig... wir werden morgen auch mal ein Multi-Server-Setup vorbereiten und das da testen.


    Zitat

    No reseller settings found - can't create customer ID automatically.


    Ok... bitte melden Sie sich mal unter "res1" an, und füllen dort unter Einstellungen -> Wiederverkäufer-Einstellungen die entsprechenden Felder aus.
    Das Import-Script braucht u.a. die Infos zur automatischen Erzeugung von Kundennummern.


    Viele Grüße


    -Klaus Keppler

  • Confixx Import Script Problem

    Standardmäßig verwendet das Script für Web/Mail/DB-Server jeweils "localhost".
    Rufen Sie es bitte mit den Parametern "--webserver", "--mailserver" und "--dbserver" auf, bei denen Sie jeweils die Server-ID des zuständigen Servers angeben - das sollte dann eigentlich funktionieren.
    Alternativ können Sie auch tricksen und den Reseller manuell in LiveConfig anlegen (der Reseller-Vertrag muss dann nur genau so heißen wie auf dem zu migrierenden Confixx-Server, also zB. "res1").


    Viele Grüße


    -Klaus Keppler

  • Migration von Confixx® zu LiveConfig

    Das Migrationsscript und die Anleitung wurden aktualisiert: http://www.liveconfig.com/de/kb/5


    Nun werden auch MySQL-Datenbanken und E-Mail-Postfächer/Adressen umgezogen.


    Wir haben das Script bislang nur auf einer relativ kleinen Zahl an Confixx-Installationen testen können, auf diesen wurden aber alle Accounts erfolgreich migriert.
    Falls bei Ihnen Fragen oder Probleme auftauchen, wenden Sie sich bitte direkt an uns (per Forum oder info@liveconfig.com).


    Viele Grüße


    -Klaus Keppler

  • PREVIEW LiveConfig 1.5.2-r1823

    Die Preview wurde eben noch mal aktualisiert - es handelt sich dabei größtenteils um ein Bugfix-Release. Jeder Nutzer der bisherigen Preview (r1823) sollte das Update ausführen.
    Außerdem enthält die neue Version einige Erweiterungen für das neue Confixx-Migrationsscript (wird in ca. 1 Std auf der Website aktualisiert).


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] Fehler in der Postfix Konfiguration

    Ja, wird nur bei Neukonfiguration/Neuinstallation erzeugt.


    Und ja: Aaaargh! :-/


    Ursache ist eine Änderung in postfix.lua, mit der künftig eine frei konfigurierbare Liste an RBLs selbst verwaltet werden kann.
    Um so was künftig zu vermeiden erweitern wir unser Testsystem gleich so, dass auch automatisch eine E-Mail an ein neues Postfach gesendet und abgerufen wird - damit sollte der komplette Mail-Prozess vollständig durchgetestet werden.


    Fehler ist in r1830 beseitigt, Update wird in den nächsten Stunden im Test-Repo bereitgestellt (die aktuelle "Stable"-Version ist davon nicht betroffen)


    Viele Grüße


    -Klaus Keppler

  • [ERLEDIGT] Awstats Cronjob

    Danke für den Hinweis - hier fehlte eine Prüfung ob /etc/awstats/liveconfig überhaupt existiert.
    Ist ab r1829 beseitigt, der Cron in /etc/cron.d/liveconfig sieht dann so aus:

    Code
    32    03    * * *     root       [ -d /etc/awstats/liveconfig ] && /usr/lib/liveconfig/cron.awstats.sh

  • Apache Konfiguration von gelöschten Verträgen.

    Ah ja, sehe ich nun auch auf einem Testsystem. Das ist so nicht beabsichtigt. In der aktuellen Version (r1823) gab es einige Änderungen in der apache.lua, um u.a. auch abweichende Verzeichnisse für Webspace konfigurieren zu können; ich schätze mal, dass da nicht ordentlich aufgeräumt wird.
    Ist also vermutlich ein Fehler, wird kurzfristig beseitigt und auch in unser Testprotokoll mit aufgenommen (LiveConfig soll keine unnötigen Rückstände hinerlassen)


    Viele Grüße


    -Klaus Keppler

  • Apache Konfiguration von gelöschten Verträgen.

    Meinen Sie z.B. für einen Vertrag "web1" die Konfigurationsdatei "/etc/apache2/sites-available/web1.conf"?
    Diese sollte eigentlich schon gelöscht werden.
    Was steht bei Ihnen denn noch in der Datei drin - oder ist sie 0 Bytes groß?
    Gibt es eventuell Fehlermeldungen in /var/log/liveconfig/liveconfig.log ?


    Viele Grüße


    -Klaus Keppler

  • Directory-Listing Icons werden nicht angezeigt

    Ich habe das eben mal überflogen; das Problem liegt vermutlich darin, dass die betroffene Domain in einem Unterverzeichnis konfiguriert wird und daher die RewriteRules nicht mehr greifen.
    In der vHost-Konfiguration (/etc/apache2/sites-available/###.conf) sehen Sie irgendwo etwa folgenden Eintrag:

    Apache Configuration
    # Don't rewrite /cgi-bin/ and /.errorFiles/ URLs:
RewriteRule ^/(cgi-bin)|(.errorFiles)/.* - [L]


    Erweitern Sie diesen mal einfach testweise um "icons" und starten Apache dann neu:

    Apache Configuration
    RewriteRule ^/[B](icons)|[/B](cgi-bin)|(.errorFiles)/.* - [L]


    Alternativ installieren Sie die aktuelle LiveConfig-Preview (r1823) und lassen die betroffene vHost-Konfiguration neu erstellen (z.B. durch das Speichern irgendeiner Domaineinstellung) - mit der neuen Version werden auch Subdomains standardmäßig mit eigenen <VirtualHost>-Abschnitten eingerichtet. (die bisherige RewriteRule-basierte Konfiguration kann optional natürlich weiterhin so erzeugt werden)


    Viele Grüße


    -Klaus Keppler

  • Kunde sperren

    Ja, aber vorsicht - aktuell wird nur das LiveConfig-Login für den betroffenen Kunden gesperrt - FTP/EMail/Webspace bleiben nach wie vor aktiv. Diese Funktion wird aber auch in den nächsten Tagen abgeschlossen (so dass es zur v1.5.2 "final" enthalten ist).
    Ist auch keine ganz triviale Angelegenheit - ausführliche Beschreibung folgt dann, sobald die Funktion fertig ist.

  • [ERLEDIGT] Letzte Anmeldung ohne Funktion

    Ok, gefunden: mit r1508 gab es eine Änderung in der Protokollierung der Logins; diese wurde in der betroffenen Anzeige noch nicht berücksichtigt. War also nur ein Anzeigefehler - die Login-Informationen sind korrekt protokolliert. Ab r1826 ist das dann beseitigt.


    Viele Grüße


    -Klaus Keppler

  • 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