Beiträge von kk

    Nein, diese Möglichkeit wird es leider nicht geben - ausschließlich aus Gründen der Usability.


    Ein Anwender geht bei der Navigationsleiste (links) davon aus, dass man sich damit innerhalb LiveConfig bewegt. Würde nun einer dieser Links auf ein externes Ziel führen, dann ist das inkonsistent und verwirrend. Ja, ich weiß, in Confixx geht das - aber das heißt nicht, dass das "gut" ist.


    Wenn Sie externe Links gesammelt anbieten möchten, legen Sie bitte irgendwo eine statische HTML-Seite ab, welche Sie mittels der IFRAME-API einbinden. Sie könnten dafür z.B. einen Abschnitt "Service" mit einem Link "Anwendungen" anlegen und da eine Seite einbinden, auf der Sie (mit Logos und kurzen Beschreibungen) auf all die o.g. URLs verweisen (praktisch ähnlich wie in der LiveConfig-Demo mit dem Link "Service" -> "Downloads").


    Viele Grüße


    -Klaus Keppler

    Kurz zur Domainbestellung: unser Fokus liegt ganz klar auf dem Control Panel im Sinne von "Server konfigurieren". Wie bereits angedeutet, bedeutet eine Domainregistrierung auch eine entsprechende Info an die Buchhaltung. Aus diesem Grund wird bereits an einem WHMCS-Plugin für LiveConfig gearbeitet (damit sollte sich das dann bequem automatisieren lassen, die Domainbestellung würde aus WHMCS heraus erfolgen).
    Mittelfristig (Q2 2013) soll es aber prinzipiell auch die Möglichkeit geben, Domains aus LC heraus zu registrieren - weitere Details dazu aber erst wenn's soweit ist.


    Zum DNS: für einen Zonentransfer zu einem beliebigen anderen DNS-Server sollte eigentlich ein üblicher AXFR bzw. IXFR reichen. Wichtig ist ja nur, dass der Secondary "weiß" für welche Domains er zuständig ist; dafür ist eine eigene SOAP-Funktion in Arbeit, mit der ein Secondary-DNS seine Zonenliste abrufen und mit einem einfachen Script in eine entsprechende Konfigurationsdatei konvertieren kann. Die Absicherung des AXFR/IXFR erfolgt wahlweise über die IP-Adresse des Secondary-DNS oder vorzugsweise über TSIG-Schlüssel, die in LiveConfig hinterlegt werden können.


    Ich denke mal dass wir Anfang kommender Woche die ersten Screenshots der DNS-Verwaltung präsentieren können, das sollte dann hoffentlich viele Fragen klären.
    Zeitrahmen (unverbindlich): ab Ende nächster Woche sollten die ersten Tests möglich sein.


    Viele Grüße


    -Klaus Keppler

    Nein, ist natürlich nicht vom Tisch, nur noch nicht im Issue Tracker (werde ich später noch mit aufnehmen).
    Greylisting ist hier in einem Entwicklerzweig auch schon implementiert (kann pro Postfach aktiviert/deaktiviert werden), an einer intelligenten SpamAssassin-Integration arbeiten wir noch (würden wir am liebsten auch pro Postfach konfigurierbar und eventuell auch in der Pre-Queue-Phase machen, so dass als Spam klassifizierte Mails noch während der SMTP-Verbindung abgelehnt werden).
    Der Teufel steckt - wie immer - im Detail; wir arbeiten daran. :)

    Zitat

    SSL read error (OS): Connection reset by peer


    Dieser Fehler wird durch die OpenSSL-Bibliothek erzeugt und zu LiveConfig "durchgereicht" - eigentlich ist das irrelevant, wir werden das künftig ausfiltern.
    Mit dem Webapp-Updateserver (update.liveconfig.com) bzw. dem Zugriff darauf hat das nichts zu tun - dies betrifft nur Verbindungen zu Browsern.


    Zitat

    Can't get system informations: (null)


    Dieser Fehler tritt auf, wenn LiveConfig versucht, Serverinformationen via DMI (also aus dem BIOS) auszulesen. Auf einigen virtualisierten Plattformen wie u.a. auch Xen ist dieser Mechanismus nicht verfügbar.
    Eigentlich ebenfalls eine überflüssige Fehlermeldung, also auch ein Fall für den Filter. :)

    Hab doch noch mehr gefunden, in der postfix master.cf fehlt dieses:

    Code
    smtps     inet  n       -       -       -       -       smtpd
      -o smtpd_tls_wrappermode=yes
      -o smtpd_sasl_auth_enable=yes
      -o smtpd_client_restrictions=permit_sasl_authenticated,reject
      -o milter_macro_daemon_name=ORIGINATING


    Wie bereits diskutiert - das "fehlt" nur, wenn man SMTPS (Port 465) braucht/will. Wir schauen mal ob oder wie wir das als optionale Konfiguration mit aufnehmen.


    Zitat

    Und in der main.cf müssten die TLS Parameter wie folgt lauten:


    Code
    smtp_use_tls = yes
    smtpd_use_tls = yes
    smtp_tls_note_starttls_offer = yes
    smtpd_tls_cert_file=<pfadzumsslzert>
    smtpd_tls_key_file=<pfadzumsslkey>
    smtpd_tls_CAfile=<pfadzumsslca>
    smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
    smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache


    Diese Befehle sind bereits alle vorhanden - wenn auch in anderer Reihenfolge. smtp(d)_use_tls wird seit Postfix 2.3 durch smtp(d)_tls_security_level ersetzt.

    Die Preview wurde eben wieder aktualisiert.


    Die Änderungen in dieser Version sind:

    • externe Website-Links vom App-Installer werden nun in neuem Tab/Fenster geöffnet
    • interne Zeitzonen-Datenbank aktualisiert
    • Fehler in Zeitzonen-Abfrage beseitigt (zeigt nun auch Zeitzonen ohne Sommerzeit)
    • Einstellung der Zeitzone für neue Benutzer, die via SOAP-Funktion UserAdd() erstellt werden
    • php.ini-Einstellung für mod_php korrigiert
    • Konfigurations-Anweisungen "http_canonical_host" und "http_canonical_redirect" hinzugefügt, um einen "offiziellen" Servernamen für das Web-Interface zu konfigurieren
    • Hosting-Verträge können nun komplett gelöscht werden ohne vorher alle Postfächer/Datenbanken/usw. einzeln löschen zu müssen


    Die Anleitung zur Konfiguration von AutoDiscovery/Autoconfig steht als eigener Artikel in der Wissensdatenbank (KB#13) bereit.


    Derzeit liegt der Entwicklungsschwerpunkt auf der Konfiguration von BIND (um DNS-Zonen direkt zu verwalten) sowie in der Verwaltung von php.ini-Einstellungen.


    Viele Grüße


    -Klaus Keppler

    Das haben wir bewusst weggelassen, da Apache auf 127.0.0.1 in den allermeisten Fällen* keinen Sinn macht.
    Für die o.g. Fälle legen Sie einfach einen eigenen vHost an (z.B. /etc/apache2/sites-available/local.conf) und schreiben dort alle notwendigen Anweisungen ("Listen 127.0.0.1" usw.) hinein - da kommt LiveConfig auch nicht in die Quere.


    *) mit "allermeiste Fälle" meine ich alle Fälle, die über die LiveConfig-Oberfläche konfiguriert werden können - wenn sich jemand z.B. einen Reverse-Proxy vor den Apache schalten will, macht er das ohnehin von Hand.

    Da die Vertragsnamen völlig frei gewählt werden können, erfolgt die Sortierung - wie üblich - durch die dahinterliegende SQL-Datenbank (ORDER BY). Und diese sortiert (in diesem Fall "leider") alphanumerisch, somit ist die o.g. Reihenfolge aus Sortier-Sicht richtig. Daran werden wir wohl mittelfristig auch nichts ändern können.

    Ab Version 1.6.0-r1976 gibt es zwei neue Konfigurationsanweisungen für diesen Zweck:
    http_canonical_host -> legt den "offiziellen" Servernamen fest, und
    http_canonical_redirect -> legt eine URL fest, auf die ein Besucher weitergeleitet wird, der nicht den offiziellen Servernamen angegeben hat. Wird http_canonical_redirect nicht ausdrücklich gesetzt, findet automatisch eine Weiterleitung auf den in http_canonical_host angegebenen Servernamen statt.
    So kann man Besucher wahlweise auf die "offizielle" LiveConfig-URL oder z.B. auch auf die eigene Website weiterleiten.


    Viele Grüße


    -Klaus Keppler

    Hallo Herr Niebergall,


    den Webspace können Sie relativ einfach ändern - legen Sie die Datei /usr/lib/liveconfig/lua/custom.lua mit folgendem Inhalt an:

    Code
    -- Webspace-Startverzeichnis umbiegen (ab LiveConfig r1805):
    function LC.web.getWebRoot()
      return "/var/web"
    end


    Je nach Distribution müssen Sie aber darauf achten, dass auch sonstige Software (insbes. suExec) mit diesem anderen Verzeichnis zurecht kommt. Außerdem muss vermutlich auch die suphp.conf angepasst werden.
    Diese Änderung betrifft außerdem auch nur neu angelegte Verträge - bestehende Verträge bleiben im "alten" Verzeichnis.


    Das Mail-Verzeichnis kann aktuell noch nicht umgebogen werden - bei Bedarf können wir aber einen Workaround wie beim Webspace vorbereiten.


    Viele Grüße


    -Klaus Keppler

    Hallo Herr Groh,


    führen Sie in der LiveConfig-Datenbank bitte folgenden Befehl aus:
    UPDATE MAILBOXES SET MB_STATUS=1 WHERE MB_STATUS >3;


    Damit wird das "gelöscht"-Flag zurückgesetzt; Sie können die betroffenen Postfächer dann erneut löschen. Die Tatsache, dass die Verzeichnisse bereits gelöscht sind, stört dabei nicht.


    Viele Grüße


    -Klaus Keppler

    Zitat

    Das Löschen eines Kunden ist überhaupt sehr umständlich - es müssen ja zuvor Domains und Verträge manuell gelöscht werden. Soweit so gut - hat der Kunde aber auch z.B. ein EMail-Konto angelegt, muss auch dieses manuell gelöscht werden. Das kenne ich so von keinem Panel...


    Dieser Punkt ist bereits in Arbeit, voraussichtlich am Anfang nächster Woche sollte das auch erledigt sein. Die Herausforderung war, das Löschen aller einzelnen Objekte ggf. auf verschiedenen Servern zu organisieren - Mail-Accounts können ja auf einem ganz anderen Server sein als der Webspace-Account; der Vertrag darf schlussendlich erst dann vollständig gelöscht sein, wenn alle einzelnen Ressourcen gelöscht sind. Wir haben das aber nun in einem asynchronen Job gelöst, der so lange im System bleibt bis die Löschung aller Objekte bestätigt ist.


    Zitat

    Das Löschen eines Kunden funktioniert zudem nicht sauber - so bleibt das Web-Verzeichnis /var/www/webXXX bestehen.


    Das wurde mit der aktuellen Preview (r1957) bereits behoben, bis auf...:


    Zitat

    Dieses kann auch nicht simpel mittels 'rm -fR /var/www/webXXX' gelöscht werden, da bei der Datei /var/www/webXXX/conf/php5/php-fcgi-starter erst mittels 'chattr -i /var/www/webXXX/conf/php5/php-fcgi-starter' die Attribute geändert werden müssen...


    Ja, das wurde leider übersehen. Nun (ab r1959) beseitigt das zuständige Lua-Script auch eventuelle php-fcgi-starter und löscht anschließend das Webspace-Verzeichnis.


    Zitat

    1) Es scheinen noch einige grundlegende Funktionen (z.B. Benutzer löschen, sperren) zu fehlen - gibt es für die Implementierung einen Zeitplan ?


    Ich schaue mal dass wir die einzelnen fehlenden Funktionen kommende Woche mit in die Roadmap aufnehmen; die meisten Punkte sind bereits in Arbeit, da wir hier nebenher ein WHMCS-Plugin entwickeln, welches all diese Funktionen auch benötigt.


    Zitat

    2) Ich konnte in der SOAP-Referenz keinen Befehl für die Zuweisung einer IP-Adresse finden - wie kann ein Vertrag mit dedizierter IP-Adresse (z.B. ein Kunde mit eigenem SSL-Zertifikat) via SOAP angelegt werden ? HostingDomainAdd() gibt zwar eine IP-Adresse (webip) als Antwort zurück - wo lässt sich diese aber definieren ?


    Das ist ziemlich kompliziert, da LiveConfig an dieser Stelle auf IP-Gruppen abstrahiert. Ich würde eine ausführliche Antwort gerne noch ein paar Tage verschieben - bis dahin: über SOAP hat man derzeit leider noch keinen Einfluss auf die IP. Kommt aber natürlich noch - aktuell wird die GUI angepasst, so dass man Kunden/Reseller auch so einstellen kann, dass sie keine "gemeinsamen" IP-Gruppen nutzen dürfen, sondern nur die ihnen exklusiv zugeordneten IP-Gruppen. Das wiederum ist dann Voraussetzung dafür, die SOAP-API entsprechend zu erweitern.


    Zitat

    Derzeit ist bei über SOAP angelegten Kunden die Zeitzone auf 'Afrika/ABidjan', also den ersten Eintrag der Liste, eingestellt. Schöner wäre es, automatisch die Zeitzone des Administrators oder des Resellers zu erhalten.


    Ist natürlich suboptimal, ich mach' da gleich ein Bug-Ticket auf.


    Zitat

    Hinweis: Es fehlt auch die Zeitzone 'Asia/Hong Kong' - diese würden wir bitte benötigen.


    Das hab ich eben beseitigen können - es gab hier einen Fehler in dem SQL, der die Zeitzonen-Liste zusammenstellt: Hong Kong hat keine Sommerzeit mehr, und fiel daher aus der Liste heraus (neben einigen anderen Zonen). Ist ab r1960 beseitigt.


    Zitat

    Es wäre gut, wenn bei den Config-Dateien der einzelnen Dienste eigene Einstellungen möglich wären (z.B. über eine apache2.local.conf), die nicht überschrieben wird. Hintergrund ist, dass einige Einstellungen für uns nicht praktikabel sind (z.B. das SnakeOil-Zertifikat - wir möchten ein eigenes verwenden). Alternative wäre, dass die Live Config-Templates, die für die Erstellung verwendet werden, angepasst werden können - konnte im Handbuch dazu leider nichts finden.


    Es gibt ab nächster Woche einen neuen Handbuch-Abschnitt "Fortgeschrittene Konfiguration", in dem all das ausführlich beschrieben wird (insbesondere für Apache und Postfix, bei denen die meisten "Spezialeinstellungen" vorgenommen werden).


    Zitat

    Gibt es ein Logfile, in dem die Aktionen der SOAP-Schnittstelle protokolliert werden ? Im Admin-Log finde ich keine der Aktionen.


    Kommt auf die Aktionen an - die meisten Vorgänge sollten eigentlich schon in dem Log (Menü: LiveConfig -> Protokoll) auftauchen. Sollte konkret etwas nicht protokolliert werden, geben Sie bitte kurz Bescheid; wir können das sonst auch noch mal irgendwann manuell durchgehen und prüfen.


    Zitat

    Danke für Ihre Mühe !


    Und vielen Dank für Ihre ausführliche Rückmeldung! :)


    Viele Grüße


    -Klaus Keppler

    NEU: ContactAdd -> CustomerAdd -> UserAdd -> HostingSubscriptionAdd -> HostingDomainAdd


    Das ist auch die "richtige" Reihenfolge, und würde auch erklären, warum wir den Fehler hier bislang nicht reproduzieren konnten (unsere Testscripte verwenden eben genau diese Reihenfolge).


    Wir werden die Beschreibung der SOAP-API entsprechend erweitern, und außerdem eine Prüfung einbauen, dass man keinen Vertrag anlegen kann so lange noch kein Benutzer existiert.