Beiträge von kk

Der Backup-Service (lcbackup) und unterstützt auch externe Ziele.
Die Leute hier arbeiten an unterschiedlichen Stellen - das führt z.B. dazu dass eine Komponente an sich fertig ist, aber die Integration in die Oberfläche noch hinterher hinkt.

Ab v2.8 prüft LiveConfig übrigens selbst die IPs der Domains (mittels integriertem DNS-Resolver). Wenn einzelne IPs nicht stimmen oder es z.B. ein DNSSEC-Problem gibt, wird gar nicht erst eine Bestellung ausgelöst, sondern eine entsprechende Fehlermeldung angezeigt. Sobald die IP dann stimmt, wird die Bestellung automatisch fortgesetzt.

LiveConfig v2.8 wird Debian 10 direkt unterstützen.
(unsere Tests damit laufen bereits seit Februar)

That navigation tab shouldn't be visible right now
LiveConfig will allow sending report mails (automatically) in the near future, e.g. with important informations on expiring certificates or customers with overuse.

Zitat von bfal

Wenn man bei einer neuen Domain/Subdomain SSL aktiviert wird muss vorher in der SSL Verwaltung der Let´s Encrypt Dienst als Anbieter hinzugefügt sein? Oder aktiviert Liveconfig diesen dann automatisch?

Es muss zuerst ein SSL-Anbieter eingerichtet werden. Sofern dieser auch kostenfreie Zertifikate anbietet (z.B. Let's Encrypt) kann dieser Anbieter dann beim Anlegen einer Domain ausgewählt werden.

Das nachträgliche Aktivieren von SSL für bestehende Domains/Subdomains (durch den Endkunden) wird gerade integriert und dürfte ab Montag in der Preview enthalten sein. Hier sind Änderungen am Berechtigungssystem erforderlich.

Der Endkunde wird letztendlich keinen "eigenen" Let's-Encrypt-Account benötigen, das wird alles über einen vom Admin oder Reseller verwalteten Account abgewickelt.

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.

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

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

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...

Hallo,

unsere PHP-Pakete für Debian & Ubuntu wurden eben auf die Versionen 7.1.30, 7.2.19 und 7.3.6 aktualisiert.
Zudem stellen wir ab sofort für PHP 7.2 und 7.3 die Extensions "igbinary" und "redis" als fertige Pakete bereit.

Viele Grüße

-Klaus Keppler

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.

Was meinen Sie mit "nicht über die API"? Eine API ist ja genau für so etwas da.

Derzeit gibt es aber keine C/C++-API um eigenen Code in LiveConfig einzuklinken. Der einfachste Weg wäre die IFRAME-API.

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.

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).

Hello,

our PHP packages for Debian/Ubuntu have been updated to version 7.2.18 and 7.3.5.

Best regards

-Klaus Keppler

Hallo,

die PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.2.18 und 7.3.5 aktualisiert.

Viele Grüße

-Klaus Keppler

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

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.

Ich schaue mir das mal an.
Bei der o.g. Version handelt es sich aber um das Test-Repository.

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.