Beiträge von kk

    In die /etc/liveconfig/sslcert.pem muss nur das Zertifikat eingetragen werden, welches den Zugriff auf LiveConfig selbst betrifft. Siehe Wiki.


    Wenn der Kunde seine SSL-Zertifikate selbst verwaltet, muss man als Admin also nichts weiter machen. Im Vertrag des Kunden muss halt SSL aktiviert sein, sowie die Option dass der Kunde seine Zertifikate selbst verwalten darf. Und in der IP-Gruppe des Webservers muss SSL (ggf. mit SNI) aktiviert sein (Serververwaltung -> Web -> IP-Gruppe bearbeiten).

    Aktuell lässt sich über die Funktion "HostingDomainAdd" die IP-Gruppe nicht auswählen.
    Ich habe eben einen Feature-Request dazu angelegt (#195), wir nehmen das ins nächste oder übernächste Update auf (das nächste Update ist ein "großes" Release, daher evtl erst in das darauf folgende).

    Nachtrag: die "Standard-Version" (also der Handler für "php5") wird immer dann verwendet, wenn der Benutzer keine bestimmte andere PHP-Version für eine (Sub)Domain ausgewählt hat. Daher sucht LiveConfig hier nach einem Handler für "php5".

    Kurz gesagt: es scheint keine "Standard-Version" von PHP installiert zu sein - deren Konfiguration wäre dann nämlich in ~/conf/php5/
    Ich vermute, dass das Paket "php5-cgi" nicht installiert ist. Installieren Sie das nach, und speichern den betroffenen Vertrag danach neu ab (z.B. irgendeine (Sub)Domain-Einstellung bearbeiten - damit wird die vHost-Konfiguration und auch der php-fcgi-starter neu geschrieben).


    Viele Grüße


    -Klaus Keppler

    Bitte installieren Sie noch das Paket "php5-cgi", starten LiveConfig danach neu und speichern dann die Verträge oder irgendein Angebot noch mal neu ab. Im meta-Paket ist bislang das PHP-CGI-Paket nicht enthalten (kommt mit einem der nächsten Updates dazu).


    Viele Grüße


    -Klaus Keppler

    Ich tippe mal darauf, dass die Grundkonfiguration des Servers nicht ganz sauber ist.
    Was liefert denn der Befehl "hostname -f"?


    In /etc/hostname gehört der Hostname (wenn der Server z.B. "www.example.com" heißt, dann muss da "www" drin stehen). In /etc/hosts gehört dann ein Eintrag in der Form "<IP> <FQDN> <Hostname>", also z.B. "123.45.67.89 http://www.example.org www".
    Danach sollte "hostname -f" als Ausgabe z.B. "www.example.org" liefern, der Aufruf von "hostname" dagegen nur "www".

    Problem 1: wer maldet zum Scannen von PHP-Uploads (mittels Suhosin) nutzt, sollte unbedingt prüfen, ob in der Datei /usr/local/maldet/conf.maldet die Variable "scan_user_access" auf "1" gesetzt ist.
    Auf unseren Systemen wurde die offenbar durch das große maldet-Update vom 19.09. auf "0" zurückgesetzt, wodurch suhosin alle PHP-Uploads abgeleht hatte. :-/
    Also: auf "1" setzen, danach ca. 10 Minuten warten oder den Befehl "maldet --mkpubpaths" ausführen.


    Problem 2: wer maldet zusammen mit ClamAV installiert hat, hat(te) eventuell kaputte Symlinks im ClamAV-Signatur-Verzeichnis herumliegen. Bitte ggf prüfen ob in /var/lib/clamav/ alles passt.
    Der Fehler ist bei GitHub beschrieben.
    Ggf die kaputten Links löschen, danach clamav-daemon neu starten.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    am 19.09.2015 wurde vom LMD (Linux Malware Detect) ein Update ausgerollt, was zu enigen Problemen führt. Wir analysieren das im Moment, in Kürze gibt's hier weitere Infos dazu.
    Betroffen sind insbesondere der Scan von Uploads via PHP sowie z.T. ClamAV-Daemon (der u.a. zum Scannen von E-Mails verwendet wird, was also zu Problemen bei SMTP führen kann).


    Wer maldet nicht installiert hat, ist hiervon nicht betroffen (wird von LiveConfig nicht automatisch mit installiert).


    Viele Grüße


    -Klaus Keppler

    Setzen Sie ClamAV (Virenscanner) ein?
    Wenn ja, dann prüfen Sie bitte, ob der "clamav-milter" und "clamav-daemon" noch laufen.


    Ansonsten steht der Grund für "Service not available" sicherlich in den einschlägigen Log-Dateien (/var/log/mail.log).


    [EDIT] Hab' erst jetzt Ihren Abschnitt über ClamAV gesehen. Ja, vermutlich ist das ClamAV-Update nicht ordentlich gelaufen und hat beim Reload den Prozess zerlegt.


    Viele Grüße


    -Klaus Keppler


    PS: aktuelle LiveConfig-Version ist 1.9.1-r3767.

    Letztendlich scheint das Programm "/usr/sbin/postmap" nicht zu existieren. Haben Sie eventuell Postfix entfernt? Wenn nein, was liefert "liveconfig --diag"? (Mailserver-Abschnitt genügt, oder einfach alles per Mail an support@liveconfig.com)


    Um das zumindest temporär zu lösen müsste es genügen, die Datei /etc/postfix/liveconfig.status umzubenennen (z.B. in /etc/postfix/liveconfig.status.temp) und dann das Upgrade erneut auszuführen.

    Ich habe da noch eine Idee. Ungetestet, könnte aber klappen:
    nach dem Upgrade von Debian 6 auf Debian 7 einfach das PHP 5.3 aus dem LiveConfig-PHP-Repo installieren. Danach das Upgrade von Debian 7 auf 8 ausführen. PHP 5.3 sollte somit installiert bleiben (die Paketabhängigkeiten sind recht überschaubar: libc-client2007e, libcurl3, libfreetype6, libicu48, libjpeg8, libkeyutils1, libmcrypt4, libmhash2, libmysqlclient18, libpng12-0, libsqlite3-0, libssl1.0.0, libt1-5, libxml2, libxpm4, libxslt1.1, zlib1g)
    Ist 'nen Versuch wert. Im "worst case" muss PHP 5.3 während dem Upgrade von Debian 7 auf 8 eben wieder entfernt werden.

    Oha, danke für die Info. Wir haben das bereits geprüft, das betrifft offenbar einige Installationen mit MySQL-Backend. Fehler ist behoben, Update sollte in ca. 40-60min bereit stehen.

    Meine aktuellste Frage betrifft HostingMailboxEdit. Dort kann man keinen Parameter "forward" angeben. Fehlt dieser oder ist er nur nicht in der Doku enthalten?


    Der ist erst ab der aktuellen Version (1.9.1) enthalten und fehlte daher bis eben noch im Handbuch. Wurde eben aktualisiert (https://www.liveconfig.com/de/….HostingMailboxEdit.xhtml)


    Zitat

    Je mehr ich mit der API arbeite, desto mehr habe ich den Eindruck, dass die API nicht dazu gedacht ist, die Verwaltung über ein anderes System zu gestalten, sondern lediglich die einmalige Erstellung von Kunden/Reseller ermöglichen soll.


    Jein; bei der API wurde der Fokus tatsächlich auf den Import bzw. das Anlegen von Objekten gelegt, weil das der Hauptanwendungsfall ist. Die API wird aber regelmäßig erweitert.


    Zitat

    Die Integration der wichtigsten Funktionen (Datenbank, Mail, Passwortschutz, ...) in ein bereits bestehendes Backend oder gar die Entwicklung eines neuen Backends ist mit dieser API absolut unmöglich.


    Backend oder Frontend? Wenn Sie alle Objekte vollständig über die API verwalten möchten klingt das eher nach einem alternativen Frontend.


    Viele Grüße


    -Klaus Keppler