Beiträge von kk

  • Domain auf anderen Kunden übertragen / verschieben

    Das ist derzeit leider nicht ohne Aufwand zu machen, da die E-Mail-Postfächer quasi den Vertragsnamen enthalten (/var/mail/<Vertrag>/<Postfach>/).
    Wir haben das Verschieben von Domains inkl. Postfächern in andere Verträge bereits auf der ToDo-Liste für LiveConfig 2.9.
    Bitte melden Sie sich unter support@liveconfig.com, dann klären wir ab inwiefern ein manuelles Verschieben (durch Eingriff in die Datenbank) möglich ist.

  • Preview: v2.8.0

    Zitat von Stricted
    Code
    +    if LC.fs.is_file(opts.path .. "/conf/fastcgi_params.conf") then
+      fh:write("\t\t# Include customer-specific configuration options:\n")
+      fh:write("\t\tinclude ", opts.path, "/conf/fastcgi_params.conf;\n")
+    end


    Man kann in ~/conf/nginx.conf auch fastcgi_params hinterlegen, die dann bei jedem vHost per include eingebunden werden.
    Ab v2.8 kann man zudem in ~/conf/<domain>.nginx.conf Domain-spezifische Einstellungen hinterlegen.
    (normalerweise werden die fastcgi_params ja ohnehin über /etc/nginx/fastcgi_params verwaltet)


    Zitat von Stricted
    Code
    +              fh:write("\t\tproxy_set_header\tHost\t$host;\n")
+              fh:write("\t\tproxy_set_header\tX-Real-IP\t$remote_addr;\n")
+              fh:write("\t\tproxy_set_header\tX-Forwarded-For\t$proxy_add_x_forwarded_for;\n")
+              fh:write("\t\tproxy_set_header\tX-Forwarded-Proto\t$scheme;\n")


    Das haben wir mit einigen Modifikationen übernommen. Es gibt nun eine neue Variable "nginx.PROXY_PARAMS", welche bei allen Proxy-Hosts angewendet werden; über die custom.lua oder /etc/liveconfig/lua.d/ kann man diese beliebig anpassen. Ist in der nächsten v2.8-Preview enthalten.
    Die o.g. Einstellungen sind dann standardmäßig gesetzt.


    Viele Grüße


    -Klaus Keppler

  • Preview: v2.8.0

    Hallo,


    ab sofort steht eine allererste Preview von LiveConfig v2.8.0 zum Download bereit.
    Wie im Changelog zu sehen ist, gab es eine ganze Menge Änderungen. Die wichtigsten Neuheiten sind:

    • komplett neue SSL-Integration:

      • beim Anlegen einer Domain kann nun gleich SSL mit nur einer Checkbox mit aktiviert werden. LiveConfig prüft im DNS ob die Domain konnektiert ist und hält die Zertifikatsbestellung ggf. so lange zurück.
      • Let's Encrypt wird nun über die ACMEv2-API (RFC8555) angesprochen. Längerfristig sollen damit auch WildCard-Zertifikate möglich sein.



    • stark vereinfachte (Sub-)Domain-Konfiguration:

      • ab sofort werden neue Domains/Subdomain in einer vereinfachten Darstellung konfiguriert (die bisherige separate HTTP/HTTPS-Konfiguration ist in der Expertenansicht weiterhin möglich)
      • <Domain> und www.<Domain> können somit gleichzeitig konfiguriert werden
      • Einstellung der Ziele (Ordner, Weiterleitung, Anwendung) vereinfacht



    • verbesserte Webspace-Konfiguration:

      • Anweisung "SetHandler" ist nun wieder in .htaccess-Dateien erlaubt (ohne dass es Sicherheitsprobleme bei PHP-FPM gibt)
      • Domain-Validierung erfordert nun keinen Server-Reload mehr (entlastet den Server und beschleunigt die Zertifikatsausstellung)



    • LiveConfig ist nun nicht mehr per TLSv1/TLSv1.1 erreichbar (erfüllt somit die Empfehlungen des BSI, siehe TR-02102-2)
    • Unterstützung des WebAuthn-Standards zur sicheren Zwei-Faktor-Authentifizierung (abwärtskompatibel mit FIDO U2F, bestehende Token funktionieren also weiterhin, ab sofort aber mit allen großen Browsern)


    ... sowie viele weitere (kleinere und größere) Verbesserungen. Das ist auch noch nicht alles - ein paar Features kommen noch.


    Während des Upgrades auf v2.8 ist zu beachten:


    • in Multi-Server-Installationen sollten der LiveConfig-Server und alle -Clients möglichst zeitnah aktualisiert werden. Die Reihenfolge dabei (erst Server oder erst Clients) ist egal. Wichtig ist aber, dass nur wenn Client und Server beide auf v2.8 laufen, die erstellte Webspace-Konfiguration zuverlässig funktioniert (insbes. bei Bestellung von SSL-Zertifikaten)
    • die Apache/NGINX-Default-vHost-Konfigurationen werden während des Upgrades automatisch neu generiert


    Aktuelle Showstopper sind noch:

    • SSL-Objekte können teilweise noch nicht gelöscht werden (z.B. automatisch wenn ein Kunde gelöscht wird)
    • Verlängerung von SSL-Zertifikaten sowie SSL-API via NGINX sind noch nicht vollständig getestet, können also noch fehlerhaft sein
    • etliche Übersetzungen fehlen noch (viele Phrasen sind noch auf Englisch)
    • der neue Backup-Service (lcbackup) ist noch nicht in die GUI integriert


    Wir empfehlen daher DRINGEND, die Preview-Version noch nicht auf Produktivsystemen einzusetzen (davon raten wir ja ohnehin grundsätzlich ab, aber wir möchten unsere Ressourcen nicht in die nachträgliche Reparatur womöglich gestörter Produktivsysteme stecken). Statt dessen werden die die LiveConfig-Demo voraussichtlich morgen Mittag auf die aktuelle Preview aktualisieren.


    Am kommenden Montag, 17.06.2019, planen wir die Preview erneut zu aktualisieren, bis dahin kümmern wir uns um alle offene Punkte und bekannte Probleme.
    Trotz Erlanger Bergkirchweih wird hier durchgearbeitet! ;)


    Bis dahin schon mal vielen Dank für die Geduld!


    Viele Grüße


    -Klaus Keppler

  • Neue Version 2.8

    Wir planen heute gegen 14:00 die v2.8 als Preview bereitzustellen. Aktuell gibt es vor allem noch folgende drei Showstopper vor dem Release:

    • Löschen von SSL-Objekten ist noch nicht abgeschlossen (z.B. wenn ein Kunde gelöscht wird, sollen dessen SSL-Accounts mit gelöscht werden, oder beim Löschen einer Domain auch die damit verbundenen SSL-Zertifikate)
    • Übersetzungen sind noch nicht abgeschlossen (einige Phrasen sind eben noch auf Englisch)
    • Backup-Service (lcbackup) ist noch nicht in GUI integriert


    Am kommenden Montag (17.06., ebenfalls gegen 14:00) ist dann ein Update der Preview geplant ("Release Candidate").
    Von einem produktiven Einsatz der Preview-Version raten wir bis dahin noch ab!


    Alle weiteren Details dann später...

  • How to enable SOAP API for resellers and set API password?

    It is not intended that resellers / end users can access the SOAP API.
    However, the admin login can be used to invoke SOAP methods as a reseller, this is mostly used for importing multi-layered customer structures from other control panels into LiveConfig.


    On our wishlist is already a configurable API access for resellers and end users, but currently no implementation timetable.

  • Grundlagen bei der Verwendung von LiveConfig

    Zitat von Hustensaft

    Wenn ich das richtig verstanden habe, ist LiveConfig ein komplett eigenständiges Linux Programm. Wie Apache z.B. auch. Basiert der Webserver auf Apache, NGINX oder so oder ist der komplett selbst geschrieben?


    Die Weboberfläche von LiveConfig ist durch eine eigene Software realisiert (ist also weder Apache noch NGINX).


    Zitat

    Wenn eine Portsperre bei manchen Unternehmen drinne ist, kann man LiveConfig dann noch über einen ProxyPass z.B. auch auf Port 443 nutzen?


    Natürlich, das ist kein Problem.


    Zitat

    Wo werden die Eingaben der Benutzer in LiveConfig gespeichert? Gibt es da eine interne Datenbank?


    Standardmäßig in einer SQLite-Datenbank (/var/lib/liveconfig/liveconfig.db), man kann aber auch eine MySQL-Datenbank dafür einrichten.


    Zitat

    Muss ich LiveConfig auf einer frischen Serverinstallation installieren oder erkennt LiveConfig auch vorhandene Konfigurtionen?


    LiveConfig liest keine vorhandenen Konfigurationen ein - das ist quasi unmöglich. Es besteht aber die Möglichkeit, über API-Aufrufe vorhandene Webspaces anzulegen (wenn alle Vorraussetzungen passen).


    Zitat

    Wie erfolgt der Austausch zwischen Konfigurationen bei einer Multiserverinstallation?


    Über ein eigenes (proprietäres) Protokoll. Im wesentlichen sind das JSON-Objekte, die über eine TLS/SSL-Verbindung ausgetauscht werden.

  • sporadische "Error 500 / Internal Server-Error" Fehler

    Zitat

    ap_pass_brigade failed in handle_request_ipc function


    Zu (genau) dieser Fehlermeldung gibt es hier eine plausible Erklärung:
    https://stackoverflow.com/ques…ndle-request-ipc-function


    Die Verbindung könnte also schlicht vom Client (Browser) aus getrennt werden. Firewalls machen bei NAT irgendwann auch die TCP-Verbindung zu, wenn da zu lange keine Daten drüber laufen.
    Um das zu testen, müsste man z.B. einen lokalen HTTP-Aufruf auf dem Server machen (mit wget oder curl); vorher ggf. noch prüfen auf welchen Wert der TCP-Timeout des Servers konfiguriert ist (/proc/sys/net/ipv4/tcp_keepalive_time - Standard ist meist 7200 sec = 2 Stunden).

  • Ist auto_prepend_file für mehrere Wordpress-Installationen möglich?

    Einziger Workaround der mir eben noch einfällt: Ihr Webhoster könnte Ihnen die Einstellung user_ini.filename freischalten. Damit könnten Sie theoretisch (je nach PHP-Ausführungsart) eigene php.ini-Anweisungen pflegen. Gleichzeitig bringt das aber ein gewisses Sicherheitsrisiko mit sich (nicht umsonst ist diese Einstellung von LiveConfig aus standardmäßig deaktiviert).


    Viele Grüße


    -Klaus Keppler

  • Ist auto_prepend_file für mehrere Wordpress-Installationen möglich?

    Sie können im LiveConfig keine verschiedenen php.ini-Einstellungen innerhalb des selben Vertrags vornehmen. Oder anders formuliert: Sie können auto_prepend_file lediglich global (für alle .php-Dateien des Vertrags) auf den selben Wert setzen.


    Ansonsten müssten Sie die WordPress-Installationen auf separate Verträge aufteilen.


    Eine zusätzliche php.ini ist an sich kein Hexenwerk, aber in LiveConfig eben nur pro Vertrag und pro PHP-Version möglich, nicht aber noch pro Verzeichnis.
    Bei FastCGI müsste sonst mindestens ein eigener PHP-Prozess pro .ini-Datei laufen. Das geht schlicht auf Kosten der Ressourcen.

  • SSH FTP-Account

    Zitat von os24

    Diese Kameras unterstützen leider nur die einfachen FTP-Zugänge (ohne SSL/TLS) ... diese unterstützt ja so gut wie kein Anbieter und nur noch SFTP-Zugänge.


    Aaalso, es gibt hier offenbar ein Mißverständnis.


    Wenn die Kameras nur "normale" (unverschlüsselte) FTP-Zugänge unterstützen, dann ist das an sich kein Problem. Allerdings kann es sein, dass der Serveradministrator in LiveConfig festgelegt hat, dass nur verschlüsselte Verbindungen erlaubt sind. Streng genommen muss der Provider das sogar so einrichten (Stichwort: DSGVO). Für unverschlüsselte Verbindungen bräuchte er sonst Haftungsfreistellungen von allen Kunden - das ist dann doch eher etwas praxisfremd.
    Das selbe Problem ergibt sich anders herum beim Einsatz solcher Kameras (bei jedem Datenschutz-Audit würde die dann durchfallen).


    Einzige Lösung also: mit dem Provider sprechen, ob unverschlüsselte FTP-Verbindungen erlaubt sind bzw. erlaubt werden können.


    Dann zum nächsten Thema: FTP, FTPS und SFTP.
    FTP und FTPS sind fast das selbe (FTPS ist eben FTP mit SSL, wahlweise implizit (über einen separaten Port) oder explizit (STARTTLS, also auch auf Port 21).
    SFTP ist aber etwas grundsätzlich anderes (der Name ist leider sehr unglücklich gewählt, weil das mit FTP nicht mehr viel zu tun hat). SFTP ist vielmehr mit SCP zu vergleichen, da hierfür auch SSH als Transportkanal genutzt wird. Das bedeutet: es kann nicht ohne weiteres virtuelle SFTP-Benutzer geben (zumindest nicht so lange das über Port 22 = SSH läuft). mod_sftp setzt die Konfiguration eines eigenen Ports dafür vorraus (was man den Anwendern dann auch erst einmal erklären muss).


    Unsere Empfehlung daher: FTPS (FTP+SSL/TLS) verwenden - das unterstützen alle aktuellen FTP-Programme, und da sind keine Bastelarbeiten notwendig.

  • Neue Version 2.8

    Ach so, ich meinte natürlich "Lunch" und nicht "Launch" ;)


    Spaß beiseite. Am Montag nach dem Cloudfest (01.04.) wurden wir auf eine weitere Problematik in der Apache-Konfiguration aufmerksam (die im übrigen praktisch alle Controlpanels betrifft) und haben dafür eine Lösung erarbeiten müssen. Mehr kann ich aktuell noch nicht sagen, außer, dass sich deshalb leider alles noch ein wenig verzögert und das Thema wirklich ernst ist. :-/

  • E-Mail-Whitelist

    Zitat von antondollmaier

    Wann gibt's das Release denn? :)


    Wenn's fertig ist. :p


    Diese Frage ist leider nicht wirklich einfach zu beantworten. Wir arbeiten mit Hochdruck daran, die Fertigstellung rückt von Tag zu Tag näher. Last but not least ist uns letzte Woche noch ein Thema im Zusammenhang mit der SetHandler-Sache (v2.7.4) dazwischen gekommen - ausführliche Details dazu können wir aber erst mit dem Release bekanntgeben.

  • E-Mail-Whitelist

    ... noch ein Nachtrag: die Blacklist/Whitelist wird über SpamAssassin realisiert. Alles was "davor" passiert, also insbesondere DNS-Blacklists, ist davon nicht betroffen. Wir werden in den Eingabemasken noch darauf hinweisen.


    Wenn ein Absender also auf einer DNS-Blacklist steht, dann kann man ihn hierüber nicht whitelisten; das hat damit zu tun, dass Postfix die SMTP-Verbindung bei DNS-Blacklisting bereits beendet noch bevor überhaupt der Name des Mailempfängers übermittelt wurde.
    Man kann das ändern, indem man Blacklisting seitens Postfix deaktiviert und das über SpamAssassin machen lässt (/etc/spamassassin/local.cf). Allerdings steigt damit die Last auf SpamAssassin, da der wesentlich mehr Mails zu scannen hat.

  • E-Mail-Whitelist

    Zitat von kroerig

    Der Absender das aber nicht erfährt, weil die Mail mit noreply@ als From geschickt wird, dann macht mein Kunde mich dafür verantwortlich


    LiveConfig konfiguriert Postfix/SpamAssassin so, dass die Mails ggf. zum SMTP-Zeitpunkt abgewiesen werden. Die "From"-Adresse spielt hier also keine Rolle, da seitens LC kein Bounce erzeugt wird. Wenn der Absender eine Mail nicht zustellen kann und aber auch keine Fehlermeldungen dazu erhält, dann ist das nicht das Problem das Empfängers (auch wenn man den gerne als Schuldigen hernehmen möchte).


    Aber um die Diskussion zu beenden, hier eine kurze Vorschau auf eine Bildschirmmaske von v2.8: ;)
    forum.liveconfig.com/cms/attachment/16/

  • Default SSL Certificate abgelaufen

    Dieser Fehler ist in v2.8 bereits beseitigt.
    Aber noch mal: dieses Zertifikat bekommt normalerweise niemand zu sehen, es ist in allen Fällen ungültig. Es macht daher auch wenig Sinn, das zu aktualisieren.