Beiträge von arnoldB

  • LiveConfig über die Kommandozeile steuern

    Ich grab das Thema mal aus, sorry wenn schon erledigt.


    Über die CLI könntest du selbstgeschriebene Skripte/ Programme (PHP/LUA?/[ba]sh?/etc.) ausführen, die mit dem SOAP API auf den LiveConfig-Server zugreifen.


    Ich spiele mit dem Gedanken ein Skript/ Programm zu schreiben, dass aus *mehreren* verschiedenen Control-Panels die Daten zum LiveConfig-Server migriert und auch Datensätze aus CSV-Dateien u.ä. importiert. Für ein bisschen Komfort warte ich allerdings noch auf einige API-Funktionen (*Edit, *Delete) die derzeit noch fehlen.

  • Usability: Webspace aktivieren/ Webspace deaktiviert

    Bei den Domaineinstellungen gibt es die Checkbox "Webspace aktivieren" unter unter der untergeordneten Checkbox "HTTP-Zugriff" nochmal die Checkbox "Webspace deaktiviert".


    In der englischen und deutschen Fassung beißen sich diese Checkbox-Titel (und deren Funktionen?) etwas. Würde mich freuen wenn dies geringfügig angepasst wird. :)

  • HostingDatabaseAdd(): String 'xyz' is too long for user name

    Ich lege über HostDatabaseAdd() (SOAP API) eine Datenbank an. LC-Server und LC-Client arbeiten in der Version 1.6.3 (r2383).


    LC-Server akzeptiert Anfrage und liefert positive Rückmeldung.
    Datenbank (14 Zeichen) wird beim LC-Client-Server angelegt.
    Benutzer(name) (18 Zeichen ) wird beim LC-Client-Server nicht angelegt.


    liveconfig.log@LC-client:


    Code
    Error while creating new database 'zyx' (user 'susercalldistribut'): String 'xyz' is too long for user name (should be no longer than 16)



    Der RegEx für den Parameter 'login' bei HostingDatabaseAdd() ist '^[\w_]{1,64}$'.


    Gemäß der Info in http://www.liveconfig.com/de/f…?highlight=long+user+name müsste man den RegEx aktualisieren.

  • iframe API: Positionierung + Icons + i18n

    Drei Vorschläge für das super funktionierende iframe API:


    • Positionierung für die Abschnitte und den zugewiesenen Links untereinander
    • Icons für die Link-Titel
    • i18n für Abschnitte und Links: Ggf. mit benutzerdefinierten *.po-Dateien die in /var/lib/liveconfig/.. liegen und beim LC-Start kompiliert + geladen werden?

  • Usability: FTP-Standard-Startverzeichnis festlegen

    Ich habe Benutzer die sich mit der LiveConfig-Oberfläche noch etwas schwer tun.


    Hier geht es z.B. darum das einige Kunden nicht wissen welches Start-/Home-Verzeichnis für einen FTP-Account zugewiesen "muss". Das dieses nicht gesetzt werden "muss" wurde bereits kommuniziert.
    Wird jedoch kein explizites Startverzeichnis festgelegt, landen sie beim nächsten FTP-Login in /var/www/webx/ und müssen sich dann in htdocs/ klicken. Die ganzen anderen Ordner stiften verständlicherweise für Verwirrung.


    Vielen wird bewusst sein, dass sich das ausreichend dokumentieren lässt. Leider ist es aber so das Dokumentationen oft unzureichende Aufmerksamkeit gewidmet wird und stattdessen der Benutzersupport bemüht wird. :)


    Vorschlag: Da sich Kunden m.M.n. in den meisten Fällen nur unterhalb htdocs/ bewegen wollen, wäre es schön wenn man dies standardmäßig (<input value="">) im entsprechenden Eingabefeld (FTP-Account hinzufügen) vorbelegen kann. Wichtig wäre natürlich das das über eine boolsche Einstellung server-weit aktivieren/ deaktivieren lässt und benutzerdefinierte htdocs-Verzeichnisse (gibt es das bei LC eigentlich?) beachtet werden.


    Vielleicht finde ich ja Anhänger für diesen Feature-Request?



    Apropos Dokumentation: Ich werde demnächst ein Online-Handbuch für LC-Endkunden/Reseller verfassen und nach aktuellem Stand unter einer freien Lizenz veröffentlichen. Falls jemand hierzu Anregungen hat, bitte mailen.

  • Postfix-Blacklist

    Absenderadressen sollten nicht gesperrt werden, da sie gefälscht werden [können]. Besser wäre die IP-Adresse des jeweiligen Mail-Servers. Und noch besser eine geeigneter Spam-Filter-Lösung. :)


    Du könntest Greylisting installieren und LiveConfig aktivieren. Damit hältst du dir derzeit die meisten Spammer vom Hals..

  • Mail-Handling von Endkundenvertraegen / Suexec-Usern

    Nachtrag: Wäre natürlich vorteilhaft wenn der Kunde den Mail-Alias auch deaktivieren kann, sonst hätte ich mächtig Probleme. :)
    Den LUA-Part könnte ich auch selber machen. Nicht aber die Arbeit in der LC-GUI.


    Eine Motivation für die Aliase ist auch die Kunden auf Probleme in den eigenen Webapplikationen hinzuweisen. Wenn die Webapplikationen E-Mails verschicken, der MTA die E-Mail aber 5XX rejected, wird eine Bounce-Mail generiert. Diese Mail landet aktuell im Nirvana und nochmal im Postmaster-Postfach als Fehlermeldung. Ich hab hier mehrere Fälle wo es wirklich sinnvoll ist den Kunden auf seine kaputte Webapplikation hinzuweisen..

  • Mail-Handling von Endkundenvertraegen / Suexec-Usern

    Wenn du Webhosting-Kunden die PHP mail()-Funktion nicht deaktivierst, werden die UNIX-Accounts dieser Kunden (webNNN) genutzt um die Mails via Postfix-sendmail bzw. pickup an den MTA zur Weiterverarbeitung übergeben.
    Die entsprechende Belege dafür findest du in den Mail-Headern und dem Logfile deiner Wahl. :)


    Der IP-Adressreputation zuliebe wäre es mir natürlich am liebsten diese Accounts am MTA zu sperren, aber Kunden erwarten nun leider PHP mail().

  • Mail-Handling von Endkundenvertraegen / Suexec-Usern

    Würde das Thema gerne noch einmal zum Leben erwecken. Wäre schön wenn die Aliase automatisch erstellt/geändert/gelöscht werden können. Notfalls hat man eben dem MTA ein separates Verzeichnis mitzuteilen (http://www.postfix.org/postconf.5.html#mail_spool_directory), was nun nicht die schönste Lösung wäre. :)


    Code
    Final-Recipient: rfc822; webXXX@hostname
Action: failed
Status: 5.2.0
Diagnostic-Code: X-Postfix; cannot update mailbox /var/mail/webXXX for user
    webXXX. cannot open file: Is a directory

  • HTTPS-Weiterleitung für LC bei HTTP-Aufruf mit "HTTPS"-Port

    Hallo Ralf,


    mit dem gesicherten Port 8443 meinte ich den Port von LiveConfig. Also tatsächlich http://liveconfig:8443/ (ich verwende 8484 aber das tut nichts zur Sache). Rufst du (oder ein Kunde :) ) aus Faulheit im Browser liveconfig:8443 auf (statt eine fertige Domain die korrekt weiterleitet) landest du auf einer Seite von LiveConfig mit einer HTTP 4XX Seite.


    Wenn mich gerade nicht alles täuscht kann ich den Hosting-Webserver (Apache/Nginx) doch nicht auf einem bereits belegten Port horchen lassen. Da müsste dann schon der Webserver von LiveConfig ran.

  • HTTPS-Weiterleitung für LC bei HTTP-Aufruf mit "HTTPS"-Port

    Es würde den Aufwand für Kundensupport etwas minimieren, wenn LiveConfig beim HTTP-Aufruf auf dem gesicherten Port (Standard 8443) automatisch weiterleitet.


    http://liveconfig:X/ => https://liveconfig:X/


    Wäre das möglich? Bspw. zur URL/ URI in http_canonical_redirect?




    EDIT:


    Schön(er) wäre es natürlich, wenn man optional einstellen kann das http://meinliveconfig.de:${irgendeinport}/ immer nach https://meinliveconfig.de:${präferiertersslsocketport}/ weitergeleitet wird.

  • PHP Versionen




    Hallo Herr Keppler,


    zum einen: Vielen Dank für den Fix ([LC#2013062734000011]).


    Zum anderen:


    Wie kann ich aktuell verschiedene Pfade zum php-cgi-Binary für die php-fcgi-starter-Skripts setzen? Ich meine mal irgendwo im Forum eine kleine Anleitung gesehen zu haben, finde sie aber leider nicht mehr.


    Notfalls würde ich dann im LUA-Skript (web.lua) einen Workaround einrichten.

  • Liveconfig Login uuuunglaublich langsam

    LiveConfig läuft. Wenn das Neustarten über das init-Skript nicht möglich ist, müssen existierende Prozesse manuell beendet werden und LiveConfig anschließend gewöhnlich gestartet werden.


    Was steht denn im Logfile /var/log/liveconfig/liveconfig.log? Gewöhnlich ist dies ja nicht.