Beiträge von kk

    Ja, Feiertage sind vorbei, wir sind hier im Büro auch wieder vollzählig (sofern die "Hacker-Pest" hier nicht für weitere Ausfälle sorgt ;)).
    Beim nächsten Update (1.7.1/1.7.2) wird diese Funktion leider noch nicht mit drin sein können, dafür sind zu viele Änderungen an der Oberfläche und DB-Struktur notwendig (nicht daß das sooo irre aufwendig wäre, aber es stecken aktuell noch zu viele andere Sachen in der Pipeline). Ich nehme diesen Feature-Request aber ins den Issue-Tracker mit auf (sollte spätestens morgen mit auftauchen), damit bleibt das ganze auf dem Radar.


    Gaaanz vorsichtig würde ich als Zeitpunkt für dieses Feature mal etwa März 2014 (in ca. 8 Wochen) in Aussicht stellen.

    Per SQL ist das leider nicht möglich, da bei der Umstellung eine ganze Menge Datenbankeinträge (pro Domain) erzeugt werden müssen.
    Wäre jedoch über die SOAP-API machbar (HostingDomainEdit() - kommt in den nächsten Wochen)


    Viele Grüße


    -Klaus Keppler

    Fehler wurde mit v1.7.1-r2714 behoben (im betroffenen SQL wurden nur unterschiedliche Subdomain-Hostnamen berücksichtigt). Der "leere" Hostname sowie "www" werden übrigens nicht mitgezählt (das ist so beabsichtigt).

    Laut Doku darf das Feld quota nur aus bis zu 6 Ziffern bestehen - der zu importierende Wert hat aber 7 Stellen (1048576 - entspricht 1024 GB). Bitte prüfen Sie mal im Confixx, welcher Wert dort als Postfach-Quota hinterlegt ist und setzen diesen wahlweise herunter (z.B. auf "nur" 100 GB) oder auf "unbegrenzt".

    Hallo,


    löschen Sie im LiveConfig den angelegten Vertrag (web0) einfach und importieren diesen danach noch einmal. Rufen Sie das Importscript dabei aber mit dem Parameter "--fixmailquota" auf.


    Ich tippe darauf, dass der als res0 importierte Resellervertrag das gewünschte Postfachquota nicht erlaubt - mit "--fixquota" passt LiveConfig das ggf. an.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    wir haben ja schon vor längerer Zeit Änderungen im AppInstaller versprochen, damit man z.B. sein eigenes Repository nutzen kann (um z.B. eigene Apps anbieten zu können). In anderen Threads wurde zudem vorgeschlagen, die Pflege des App-Repos zu entkoppeln oder "offener" zu gestalten.


    Wir möchten das nun als Nächstes in Angriff nehmen. Unsere Idee wäre, das komplette AppInstaller-Repository bei GitHub zu veröffentlichen und die Update-URL (also die Adresse, bei der LiveConfig nach Änderungen im Repo fragt) konfigurierbar zu machen.
    Auf diese Art schlagen wir mehrere Fliegen mit einer Klappe: wer möchte, kann sich dann einfach "unser" Repo klonen und beliebig anpassen. Über Pull-Requests wiederum können Änderungswünsche schnell und kurzfristig berücksichtigt werden. Nicht zuletzt können wir auch weiteren "eingefleischten" LC-Usern Schreibrechte für das Repo geben.
    (zur Qualitätssicherung würden wir in diesem Fall aber für jede einzelne App eine Testinstallation durch unser Jenkins-CI durchführen lassen).


    Fragen/Meinungen/Anregungen?


    Mit der Umsetzung werden wir voraussichtlich Mitte Februar starten (bis dahin sind noch viele andere Punkte zu erledigen).


    Viele Grüße


    -Klaus Keppler

    Hallo,


    der Fehler konnte inzwischen schon gefunden und beseitigt werden. Sie nutzen doch die 32bit-Version, oder? Dann spielen Sie bitte dieses Update ein: liveconfig_1.7.0-r2713_i386.deb


    Das Problem tritt bzw. trat auf, wenn die Konfiguration eines Vertrags zu "groß" wurde (hatte etwas mit der Kommunikation mit dem Client-Prozess zu tun), daher traf es bislang nur vergleichsweise wenige Nutzer.


    Viele Grüße


    -Klaus Keppler

    Hallo,


    die SOAP-API wurde (bislang) hauptsächlich zur Unterstützung beim Import sowie zum automatisierten Anlegen von Objekten (z.B. nach einer Domainbestellung durch das Backend des Anbieters) genutzt. Eine vollwertige "Fernsteuerung" per SOAP-API ist sicher eine Ideallösung, wird aber noch etwas dauern da der Entwicklungsfokus aktuell in der Funktionalität und der GUI liegt.
    (die meisten Anwender nutzen nunmal die Oberfläche)


    Derzeit steckt die nächste Preview (v1.7.1) in den Startlöchern, da gibt es bereits einige weitere SOAP-Funktionen; mit dem Preview-Release möchten wir dann auch die inzwischen hinzugekommenen Feature-Requests noch ordentlich in den Issue Tracker mit aufnehmen und so für etwas mehr Übersicht sorgen. Idealerweise noch bis Ende dieser Woche. :)


    Vom schreibenden Zugriff auf die Datenbank raten wir wärmstens ab, da das Schema recht komplex ist und man schnell etwas "kaputt" (inkonsistent) machen kann. Viele Sachen lassen sich ohnehin nicht über einen Datenbankeintrag alleine antriggern, da LC eventbasiert arbeitet (anders als in Confixx laufen hier keine Cronjobs alle fünf Minuten und gucken ob's was zu tun gibt).


    Viele Grüße


    -Klaus Keppler

    "LiveConfig unterstützt einen Administrator, es ersetzt ihn nicht."


    Wenn Sie tatsächlich eine Scriptlaufzeit von z.B. 40 Sekunden oder mehr brauchen, dann tragen Sie diese (wie überall beschrieben und auch hier in diesem Thread schon vorgeschlagen) einfach in die Datei /etc/apache2/mods-available/fcgid.conf ein (z.B. "FcgidIOTimeout 120").


    LiveConfig kann beim besten Willen nicht wissen, wie lange Ihre Scripte laufen können sollen. Es macht auch keinen Sinn, pauschal gleich immer einen höheren Wert als den ohnehin schon recht großen Wert von 40 Sekunden vorzukonfigurieren, da man so eine tolle DoS-Möglichkeit auf den eigenen Server öffnet (die Anzahl der möglichen FastCGI-Instanzen und offenen HTTP-Verbindungen in Apache sind natürlich begrenzt - mit dem Aufruf eines "langsamen" Scripts können Sie so prima einen Server in die Knie zwingen).

    The only way to disable 2FA is to initiate a password reset using the LiveConfig frontend ("forgot password").


    However, we can extend the SOAP API to allow such operations in automated environments.


    Best regards


    -Klaus Keppler

    Das lässt sich als Ursache ausschließen. Der Fehler liegt konkret darin, dass die Nachricht zur vHost-Konfiguration vom LiveConfig-Server-Prozess (Weboberfläche) an den LiveConfig-Client-Prozess (Konfigurationsdatei erzeugen) unerwartet "abgeschnitten" war. Das führte dazu, dass der Clientprozess die empfangene Nachricht nicht parsen und somit nicht weiterverarbeiten konnte.


    Immerhin wissen wir nun schon mal, an welcher Ecke wir suchen müssen. :)