Beiträge von antondollmaier

    Klappts nun?


    kk: evntl. einen entsprechenden Hinweis ins Handbuch aufnehmen ... mir kam es jetzt schon öfter unter, der Server in dem Schema ("example.com" statt "server.example.com" o.ä.) benannt wurden.

    Du darfst als Hostname nicht "vserver.es" setzen - weder im LiveConfig noch im OS. Verwende dort überall "server.vserver.es", "mail.vserver.es" oder sonstwas ("vader.vserver.es", "trick.vserver.es", ...).


    Postfix mag es nicht, wenn der eigene Hostname ("myhostname") auch für die Virtual Users verwendet wird.

    Bitte beachten, dass MS Exchange nur einen SMTP-Relayhost verwalten kann.


    Wir haben aktuell eine Prüfung, ob die Domain des Absenders im Vertrag des Kunden enthalten ist und rejecten, falls das nicht der Fall ist.


    Die Exchange-User haben damit Probleme, sobald auf einem Exchange-Server Domains aus mehreren Verträgen genutzt werden sollen.


    Ähnliches gilt für David von Tobit.



    Bitte dann berücksichtigen!

    nun ja ...


    [Fri Mar 07 21:37:01 2014] [warn] VirtualHost 93.180.154.171:80 overlaps with VirtualHost 93.180.154.171:80, the first has precedence, perhaps you need a NameVirtualHost directive


    DAS sollte behoben werden ;)


    Zitat

    VirtualHost configuration:
    93.180.154.171:80


    ihr habt in den VirtualHosts exakte IP-Definitionen vermischt mit Wildcard-Angaben.


    ALLE "<VirtualHost *:80>" umändern auf die tatsächlichen IP-Adressen - oder direkt alles ins LiveConfig ziehen, so dass damit alle Apache-VirtualHosts mit exakter IP-Definition (ohne Wildcard) angelegt sind.



    Zitat

    Sobald einer der vHost Einträge nicht mehr auf das Apps Verzeichnis zeigt, wird wieder der Inhalt des Root Verzeichnis angezeigt.


    Ja, da der Apache die erste passende Konfiguration aus "IP/Port" wählt, kann das zu solch lustigen Phänomenen kommen.

    Und weil ich gerade dabei bin: wir haben noch ein anderes Tool entwickelt, mit dem Logfiles (u.a. auch das Postfix-Log) ausgewertet werden können, um Statistiken über den Versand und Empfang von E-Mails pro E-Mail-Adresse erzeugen zu können.


    Mit Anzeige, wann eine Mail warum angenommen oder abgelehnt wurde?


    Dann hat LC gerade ">6 Mannjahre" Arbeitszeit, die ein Berliner Unternehmen in die Entwicklung eines Mail-Nachfolge-Tools gesteckt hat, im (für mich/uns) relevanten Teil ersetzt.

    Selbst Confixx hatte das vor ~8 Jahren schon drauf. Und wie gesagt in der Featurebeschreibung steht es schon seit Ewigkeiten.


    Confixx kann Out of the Box kein "Greylisting" und wird es auch nie mehr können.
    Dass man es in Postfix einbinden kann bzw. die GUI (2004 von mir ...) modifiziert wurde, ändert nichts daran, dass LC hier weiter ist.


    Es wäre nur schön, wenn man die main.cf ergänzen/ändern könnte, ohne dass die Änderungen bei Updates wieder gelöscht werden. Plesk ist da leider auch nicht weiter.

    Ergänzung:


    Nach einem "HostingSubscriptionEdit" mit einem neuen Plan wird neben den Cronjobs auch FTP nicht berücksichtigt. Das der Abschnitt "FTP-Benutzer" fehlt, bis per GUI erneut der Hosting-Plan gesetzt wird.


    Etwas ungünstig, eine Automatisierung per SOAP ist somit nicht möglich. Schade.



    VG,
    Anton

    Guten Abend,


    muss mich leider erneut mit Fehlern in der SOAP-API melden.


    Diesmal leider keine Ablaufschwierigkeiten, sondern ganz klare Bugs.


    Betrifft komplett die SOAP-API-Funktion "HostingSubscriptionEdit()" bzw. "HostingSubscriptionAdd()".



    Am oben skizzierten Ablauf hat sich nichts geändert.


    Bei den Demo-Accounts gibt es nur Webspace. Keine Mailadressen, keine Datenbanken, kein FTP, keine Cronjobs. Kunde kann sich im LiveConfig einloggen, dort zwar Daten einsehen und bisschen rumklicken, aber ansonsten somit nichts machen.



    Über die iFrame-API gibt es nun die Möglichkeit, einen Tarifwechsel durchzuführen.



    Per SOAP wird, wenn der Kunde alle Daten angegeben hat, dann folgendes durchgespielt:


    - ContactEdit mit den Daten aus dem Formular (das läuft)
    - HostingSubscriptionEdit: gemäß API reicht es, neben der Auth den Subscriptionname sowie den neuen "plan" mitzugeben. Theoretisch tut das auch.


    Praktisch sieht es aber wie folgt aus:


    - da im Demo-HostingPlan keine Mailadressen und keine DBs mit dabei sind, fehlt nun die Zuordnung zum entsprechenden Server. Die SPalten in der DB ("HC_MAILSERVERID", "HC_DBSERVERID") sind einfach auf "null" gesetzt und bleiben nach dem HostingSubscriptionEdit auch auf null! Es ist außerdem nicht möglich, die entsprechenden Hostnames zusätzlich mitzugeben, da das beim Edit schlichtweg nicht vorgesehen ist. Der Bug tritt also schon beim HostingSubscriptionAdd auf, da ich dort die Server-Namen tatsächlich übergebe. Für die GUI ist das kein Problem, weil das Dropdown ja eh keine leere Auswahl zulässt.
    - im neuen HostingPlan sind auch Cronjobs sowie LiveConfig-Benutzer mit dabei. Beides wird NICHT übernommen. Der Benutzer kann diese Leistungen erst nutzen, wenn ich manuell(!) in der GUI den Hosting-Tarif NOCHMAL zuweise.


    Nach dem SubScriptionEdit wird noch die gebuchte Domain sowie die www-Subdomain angelegt, die bisher außerhalb von LC angelegte DB hinzugefügt ("create=0") und eine Mail verschickt.
    Der Teil klappt aber ohne Bugs.



    Wäre super, wenn bei diesen doch exotischen, aber realen und für uns nervigen, Bugs zeitnah ein Fix käme.


    PHP-Skripte kann ich notfalls zur Verfügung stellen.



    Viele Grüße,


    Anton Dollmaier

    mdbox ist ein alternatives Speicherformat, das statt dem "üblichen" Maildir verwendet werden kann. Es ist keine Erweiterung o.ä.!


    Zur Datensicherung:


    Wir sichern alles mit Bacula auf Dateiebene. Somit können einzelne Mails oder ganze Ordner wieder problemlos zurückgesichert werden.


    In kleineren Umgebungen gehen BackupPC oder rsnapshot sicher genauso.

    Die iFrame-API ist "nur" eine PHP-Klasse, die die Parameter aus $_REQUEST an die SOAP-API schickt. Kann man sich also auch selbst programmieren.


    Alternativ einfach über "$LC->soap" auf den SOAP-Client zugreifen:


    Code
    $action = 'CustomerGet';
    $params = array(
            'auth' => $LC->createToken($action),
            'cid' => $LC->getCustomerId(),
    );
    $response = $LC->soap->$action($params);

    Danke für die umfangreiche Antwort :)


    Ist etwas übersichtlicher in zwei Zeilen; außerdem ist mit dem "cd" sichergestellt, dass man keinen Tippfehler im Pfad hat.


    Dank Copy'N'Paste sollten Tippfehler egal sein. Aber stimmt schon, wichtig ist es jetzt nicht :)


    Zitat

    Bei Webspace ist technisch bedingt immer ein Systemaccount (und somit implizit ein "FTP-User" im weitesten Sinne) erforderlich.


    Klar, ist mir bewusst.


    Mir geht es nur um die Darstellung in der Web-GUI:


    - wird der Kunde mit einem Hosting-Angebot ohne FTP im Panel angelegt, wird kein FTP-Account angezeigt (System-Account existiert natürlich)
    - wird der Kunde mit einem Hosting-Angebot ohne FTP via SOAP-API angelegt, wird dem Kunden ein FTP-Account angezeigt, obwohl nur 0 FTP-Accounts inklusive sind.


    Zitat

    Ich verstehe aber Ihr Einsatzszenario; ich denke es dürfte keine große Sache sein, in so einem Fall einen gesperrten FTP-Account einzurichten. Wird aufgenommen.


    Perfekt.


    Zitat

    Das ist auch das normale Vorgehen: erst CustomerAdd(), dann UserAdd(). Accounts ohne LiveConfig-User sind bislang nicht vorgesehen.


    Ok.


    Dann würde ich darum bitten, dass das Handbuch an diesen Stellen ergänzt wird: CustomerAdd() erfordert offenbar zwingend den darauf folgenden Aufruf von UserAdd.


    Zitat

    CustomerDelete() und ConactDelete() stehen bereits auf der ToDo-Liste. Diese setzen aber noch den Abschluß der Kontaktverwaltung vorraus (LC muss schließlich vor dem Löschen eines Kontaktes erst noch prüfen, ob dieser noch in irgendeinem Objekt (z.B. Vertrag oder Kunde) verwendet wird).


    Yeah :)



    Dann hoffe ich auf die nächsten Versionen :)



    VG,
    Anton Dollmaier