Beiträge von kk

    Hmm, ok... dann bräuchte ich eine genauere Fehlerbeschreibung:

    Zitat

    Beim Speichern passiert wieder nichts, außer das im Log folgender Eintrag entsteht:


    Was bedeutet "nichts" - schließt sich das Popup-Fenster nicht?
    -> falls doch: erscheint die Weiterleitung dann in der (Sub)Domain-Liste? Falls ja, erscheint diese auch in der dazugehörigen Konfigurationsdatei (/etc/apache2/sites-available/##VERTRAG##.conf)?
    -> falls nein: steht in dem Popup unter der Optionsbox "Webspace" jeweils auch etwas bei "Software/IPs:" und "IPv4-Adresse"...? Welchen Browser verwenden Sie?


    Viele Grüße


    -Klaus Keppler

    Bitte prüfen Sie, ob Sie das Apache-Modul mod_rewrite auf dem Server aktiviert haben.
    (z.B. Debian: "a2enmod rewrite", danach ggf. "/etc/init.d/apache2 restart")


    Ich nehme es mal als Feature Request mit auf, dass LiveConfig darauf hinweist, falls mod_rewrite nicht aktiviert ist.


    Viele Grüße


    -Klaus Keppler


    PS: die Meldung mit "Unknown CGI variable..." ist rein kosmetisch, wird in Kürze verschwinden.

    Danke, wir können den Fehler reproduzieren. Dieser tritt dann auf, wenn ein Webspace-Angebot PHP mit FastCGI konfiguriert hat, und dieses direkt zum Anlegen eines Vertrages verwendet wird.
    Beim Anlegen von Verträgen mit suPHP und späterer Umstellung auf FastCGI tritt das nicht auf.


    Bugfix wird gerade vorbereitet, Update steht in Kürze bereit.


    Viele Grüße


    -Klaus Keppler

    Hmm, die Logs sagen doch eigentlich alles:


    Zitat

    suexec policy violation: see suexec log for more details


    -> was steht in /var/log/apache2/suexec.log ?


    Zitat

    /usr/lib/php5/20090626+lfs/fileinfo.so: cannot open shared object file: No such file or directory


    Soweit ich weiß ist fileinfo seit PHP 5.3 fester Bestandteil. Welche Distribution verwenden Sie denn?
    Evtl. existiert noch eine Datei /etc/php5/conf.d/fileinfo.ini, die vielleicht entfernt werden muß?


    Viele Grüße


    -Klaus Keppler

    Zitat

    CGI Scripte werden nicht gefunden


    Im Rahmen des Updates wurden die CGI-Verzeichnisse von ~/cgi-bin/ nach ~/htdocs/cgi-bin/ verschoben (siehe hier).
    Wenn bei einem Webspace das Zielverzeichnis (~/htdocs/cgi-bin) bereits existierte, wurde nichts verschoben, um keine Dateien zu überschreiben.


    Mit folgendem Befehl können Sie sich alle nicht verschobenen cgi-bin-Verzeichnisse anzeigen lassen:

    Code
    ls -ld /var/www/*/cgi-bin


    Diese müssten einfach nur unterhalb ~/htdocs/ verschoben werden.


    Zitat

    Internal Server Error


    Was sagt denn /var/log/apache2/suphp.log bzw. /var/log/apache2/error.log dazu?


    Viele Grüße


    -Klaus Keppler

    Hallo,


    welche Distribution verwenden Sie, bzw. wie haben Sie auf Dovecot v2 aktualisiert?


    Jedenfalls gibt es eine solche Möglichkeit. Installieren Sie bitte das Paket "sqlite3". Führen Sie danach folgende Schritte aus:

    • beenden Sie LiveConfig: /etc/init.d/liveconfig stop
    • öffnen Sie die SQLite-Datenbank von LiveConfig:
      sqlite3 /var/lib/liveconfig/liveconfig.db
    • Führen Sie folgenden SQL-Befehl aus:
      UPDATE POP3IMAPSERVERS SET PI_MANAGED=0;
    • beenden Sie SQLite3 mit ".quit" (Punkt am Anfang beachten!)
    • starten Sie LiveConfig wieder: /etc/init.d/liveconfig start
    • gehen Sie nun zur Serververwaltung -> Mail und aktivieren die Konfiguration von Dovecot erneut.


    Somit sollte die Konfiguration von Dovecot aktualisiert werden, die Datei /etc/dovecot/passwd bleibt unverändert.


    Ich werde das aber als Anregung aufnehmen, die Konfiguration auch "auf Knopfdruck" aktualisierbar zu machen - insbesondere wenn jemand zB. von Debian 6 auf 7 aktualisiert...


    Viele Grüße


    -Klaus Keppler

    Der cgi-bin-Ordner wird normalerweise komplett verschoben, außer eben es existiert bereits ein Verzeichnis mit dem Namen ~/htdocs/cgi-bin/.
    Dann wird nichts gemacht, um nicht (unerwünscht) Dateien zu überschreiben.


    Viele Grüße


    -Klaus Keppler

    Von einigen Nutzern kam eben der Wunsch, z.B. die Website unter http://www.example.org/ und gleichzeitig ein Blog unter http://www.example.org/blog/ zu betreiben. Der Grund dafür ist eigentlich zweitrangig - egal ob es nun um SEO oder SSL-Zertifikate geht.
    Aktuell kann man das mit einer RewriteRule bereits erreichen (einfach in ~/htdocs/ eine .htaccess anlegen, die Zugriffe auf /blog/ umbiegt nach /var/www/web#/apps/<AppId>/).
    Wir stellen uns das so vor, dass man bei der Installation einer App (und eventuell auch später bei bereits installierten Apps) neben der Auswahl der Subdomain auch den Pfad einstellen kann, über den die Anwendung erreichbar sein soll.

    Hallo,


    die Preview wurde eben noch mal aktualisiert (v1.5.2-r1890). Wir haben diese erfolgreich auf knapp einem Dutzend eigener Server produktiv in Betrieb; falls keine Probleme auftreten wird diese Version morgen (02.10.) produktiv freigegeben.


    Die wichtigste Änderung ist das Verschieben von ~/cgi-bin/ nach ~/htdocs/cgi-bin/ (siehe Forum).


    Viele Grüße


    -Klaus Keppler

    Mit dem Update auf LiveConfig v1.5.2 (ab r1888) wird für alle Webspaces das Verzeichnis
    ~/cgi-bin/
    automatisch verschoben nach
    ~/htdocs/cgi-bin/


    Wir wissen, dass dies in bestehenden Setups vereinzelt Anpassungen erfordern kann und hätten das gerne vermieden - geht aber leider nicht anders.


    Ablauf:
    Beim Update auf 1.5.2-r1888 (und später) wird automatisch geprüft, ob diese Anpassung auf dem Webserver bereits durch LiveConfig vorgenommen wurde (ein Update ist also nach wie vor von jeder auf jede Version möglich). Ggf werden die notwendigen Rechteänderungen dann automatisch vorgenommen - darum kümmert sich das Script /usr/lib/liveconfig/lcservice.sh (Parameter "fix-permissions").
    Alle vHost-Konfigurationen werden beim Start von LiveConfig ebenfalls automatisch aktualisiert (sowohl für Apache als auch für NGINX).
    Betroffen ist übrigens ausschließlich Webspace, der Erlaubnis für CGI-Scripte besitzt; ohne CGI-Berechtigungen sorgt die neue Konfiguration dafür, dass Zugriffe auf die URL /cgi-bin/ nicht erlaubt sind (falls dort jemand sensible Dateien liegen hat werden diese also nicht versehentlich abrufbar gemacht). Für NGINX ist der Zugriff auf /cgi-bin/ komplett verboten.


    Hilfs-Befehle:
    Mit folgendem Befehl kann nach Verzeichnissen gesucht werden, die nicht automatisch verschoben wurden (das ist dann der Fall, wenn ~/htdocs/cgi-bin/ bereits existiert hat - so stellen wir sicher, dass nichts versehentlich überschrieben wird):

    Code
    ls -ld /var/www/*/cgi-bin


    Mit folgendem Befehl kann gesucht werden, ob in den erfolgreich verschobenen Verzeichnissen irgendwo die alten Verzeichnispfade hardcodiert enthalten waren:

    Code
    find /var/www/*/htdocs/cgi-bin -type f -print0 | xargs -0 grep '/var/www/.*/cgi-bin'


    Sollte sich da tatsächlich etwas finden, kann man das z.B. mit sed automatisch anpassen lassen (selbstverständlich stehen wir hierfür bei Fragen gerne zur Verfügung!)


    Hintergrund:
    Mit Version 1.5.2 werden die Web-Verzeichnisse noch besser geschützt - diese gehören dann root:root. Damit suexec aber Programme im cgi-bin-Verzeichnis ausführen kann, muss dieses dem Benutzer gehören (z.B. web1:web1). Damit der Apache-Webserver da aber auch lesend zugreifen kann (vor der Ausführung eines CGI-Scripts) müssten auch alle anderen Benutzer Leserechte dafür bekommen (0755) - was natürlich indiskutabel ist.
    Daher wird /cgi-bin/ eben nach /htdocs/cgi-bin/ verschoben: das htdocs-Verzeichnis gehört zB. web1:www-data mit Modus 0750 - somit kann der Webserver zwar darin lesen, aber kein anderer Benutzer zugreifen.


    Die einzige Alternative wäre gewesen, /cgi-bin/ mit ACLs zu schützen; das ist an sich einfach und sicher, nur müssen ACLs bei vielen Dateisystemen erst explizit aktiviert werden, die ACL-Tools sind standardmäßig oft nicht installiert, bei Backups werden ACLs häufig nicht berücksichtigt, und so weiter...
    Ein "anderes" Controlpanel löst das /cgi-bin/-Rechteproblem übrigens so, indem es ein modifiziertes suexec-Binary ausliefert, das wiederum auch alternative Gruppen-Besitzer für /cgi-bin/ erlaubt. Das erfordert aber auch ein modifiziertes mod_suexec für Apache - somit würde also wieder viel zu tief in die von der Distribution bereitgestellten Pakete eingegriffen werden (was wir aus Prinzip nicht möchten).


    Fazit:
    Wir gehen davon aus, dass in den allermeisten Umgebungen praktisch niemand die Veränderung bemerken wird :)
    Nur in den Fällen, in denen Benutzer CGI-Scripte mit hardcodierten Pfaden verwendet haben, ist eine Anpassung erforderlich - diese lassen sich aber mit o.g. find-Befehl schnell identifizieren.
    Sollten Fragen oder Probleme auftauchen, stehen wir gerne zur Verfügung.


    Das Update (v1.5.2-r1888+) wird in den nächsten Stunden noch mal als aktualisierte Preview bereitgestellt, derzeit testen wir den Updatevorgang auf knapp 10 produktiv betriebenen Servern durch, um Überraschungen zu vermeiden.

    Der FastCGI-Starter (~/conf/php5/php-fcgi-starter) enthält ab Version 1.5.2-r1884 nun explizit ein "umask 0022" - damit wird eine eventuell im System restriktiver konfigurierte umask entsprechend korrigiert.


    Und suhosin.session.encrypt wird ab 1.5.2-r1877 standardmäßig auf "off" gesetzt, da auch andere Anwendungen Probleme damit haben.


    Viele Grüße


    -Klaus Keppler

    ERROR: Wrong 'suhosin.session.encrypt' option value. Read REQUIREMENTS section in INSTALL file or use Roundcube Installer, please!


    Ab LiveConfig 1.5.2-r1877 wird suhosin.session.encrypt nun in den individuellen php.ini-Dateien automatisch auf off gesetzt (es gibt noch viele andere Anwendungen, die damit Probleme haben).
    In Kürze ist die Oberfläche zur Verwaltung eigener php.ini-Einstellungen fertig, da kann man das dann auf Wunsch auch wieder auf "on" stellen.


    Viele Grüße


    -Klaus Keppler

    Zitat

    Furthermore the home folder is owned by the user so the user him/herself can change the permission to read-write.


    This is not correct. To change the permissions of a folder, you need write permission in its parent folder.
    This is also the reason why the user must not have write permissions to his home folder - otherwise he could for example rename the "conf" folder to "conf.old" (no matter who actually owns this one!) and substitute it by a new conf folder.
    Just try it out. :)


    So you need to be really careful when planning write permissions to users.

    Zitat

    Ich habe die customerid definiert: 'customerid' => '3', Als ich Customeradd ausgeführt habe, erhielt ich den Rückgabewert 3. Tatsächlich hat er auch die ID: 3. Die API sagt jedoch: Error while calling Web Service: Invalid customer ID


    customerid oder cid? Das spielt einen wichtigen Unterschied!
    In der Funktion CustomerAdd geben Sie eine beliebige Zahl als Kundennummer an (z.B. 3). In der Antwort bekommen Sie zwei Felder zurück: id und cid. Das Feld id enthält eine Datensatz-ID (12 Zeichen lang), die Sie dann bei anderen Funktionen wie z.B. HostingSubscriptionAdd im Feld customerid übergeben müssen.


    Zitat

    Error while calling Web Service: Database Error: A transaction is already running (BEGIN)


    Wenn dieser Fehler auftritt, müssen Sie LiveConfig am besten kurz neu starten (/etc/init.d/liveconfig restart). Wäre es Ihnen möglich, uns die Logdatei (/var/log/liveconfig/liveconfig.log) zu schicken, damit wir herausfinden können, wo/wie der Fehler aufgetreten ist? (entweder per Forum oder per Mail an info@liveconfig.com)


    Besten Dank & viele Grüße


    -Klaus Keppler

    nscd ist nicht installiert. Laut xferlog hat es nie einen Zugriff via FTP auf den Account gegeben.


    Danke für die Info, dann werden wir mal weitersuchen.
    In unserem Fall zeigt z.B. auch "lastlog" an, dass der betroffene Benutzer sich noch nicht angemeldet hatte, trotzdem wird er von userdel als "logged in" vermerkt...


    Bitte installieren Sie folgendes Update: http://download.liveconfig.com…fig_1.5.2-r1857_amd64.deb


    Anschließend öffnen Sie mit sqlite3 die Datenbank /var/lib/liveconfig/liveconfig.db und setzen mit folgendem Befehl den Lösch-Status des betroffenen Vertrags zurück:

    SQL
    UPDATE HOSTINGCONTRACTS SET HC_DELETED=0;


    Danach sollten Sie den Vertrag erneut über die LiveConfig-Oberfläche löschen können.
    Entschuldigen Sie bitte die Unannehmlichkeiten; ich versuche trotzdem noch herauszufinden woher das "user still logged in" kommt.


    Viele Grüße


    Klaus Keppler