Beiträge von kk

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.

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

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.

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

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/

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.

Zitat von informant

FcgidWrapper /var/www/web207/conf/php7/php-fcgi-starter .php
FcgidWrapper /var/www/web207/conf/php7/php-fcgi-starter .php5

Ja, das ist korrekt. Es wird da der "richtige" PHP-Interpreter ausgeführt; das mit dem ".php5" bedeutet nur, dass auch Dateien mit der Endung ".php5" von diesem PHP-Interpreter verarbeitet werden sollen.

So lange PHP in dem Webspace nicht als FPM konfiguriert ist, wird auch kein FPM benötigt - definitiv.

Im Zweifelsfall prüfen Sie bitte mal die vHost-Konfiguration in /etc/apache2/sites-enabled/<Vertrag>.conf und suchen dort nach der Zeile "# PHP configuration for this subscription:".

Wenn es beim Aufruf von ownCloud nur eine weiße Seite gibt, tritt wahrscheinlich ein Fehler während der PHP-Ausführung auf. Mit dem Apache-Errorlog und dem PHP-Errorlog lässt sich der auslesen.
(entweder in /var/log/apache2/error.log schauen, oder unter "Hosting" -> "Webspace" das Fehlerprotokoll für 24Std aktivieren; zudem in den php.ini-Einstellungen des Vertrags die php.ini-Option "log_errors" auf "on" setzen).

Im Zweifelsfall schicken Sie uns bitte mal die vHost-Konfiguration (/etc/apache2/sites-enabled/<Vertrag>.conf) und die Ausgabe von "liveconfig --diag" an support@liveconfig.com

Viele Grüße

-Klaus Keppler

FPM (bzw. php7.0-fpm) muss definitiv nicht installiert sein, um PHP via FastCGI (mod_fcgid) nutzen zu können. Es gab da sicher irgendeinen anderen Grund.
Sie können das Paket "php7.0-fpm" getrost deinstallieren. Starten Sie LiveConfig anschließend neu (um die Modul-Liste zu aktualisieren).

Viele Grüße

-Klaus Keppler

Welche Apache-MPM verwenden Sie? http/2 funktioniert nicht mit dem Prefork-MPM; empfohlen wird das Event-MPM.

Aber: wir haben inzwischen schon mehrfach die Rückmeldung erhalten, dass mod_http2 zumindest bei Apache unter Debian 9 und Event-MPM beim Download von großen Dateien (>300MB) Probleme macht (einige Hoster haben das derzeit bewusst deaktiviert).

Zitat von informant

Habe jetzt mal noch zusätzlich php7.0-fpm installiert, danach scheint es zu laufen, normal das man das zusätzlich noch braucht? Nur libapache2-mod-fcgid ging nicht^^

Ich kann mir eher vorstellen, dass php7.0-cgi gefehlt hatte und über Abhängigkeiten via php7.0-fpm mit installiert wurde.

Zitat

Interessant im Admin Bereich ist, dass fcgid nen grünen Haken hat aber proxy_fcgi (PHP-FPM) nicht, obwohl ich php7.0-fpm installiert habe und es danach nun läuft?!

mod_proxy_fcgi ist ein separates Apache-Modul, das bei Debian standardmäßig nicht aktiviert ist. Man benötigt das, wenn man PHP-FPM nutzen möchte.

Noch etwas: unter "Hosting" -> "Webspace" können Sie die php.ini-Einstellungen bearbeiten. Aktivieren Sie dort die Option "log_errors" (also auf "On" stellen). Damit sollte in /var/www/<Vertrag>/logs/priv/ auch ein php_errors.log o.ä. geschrieben werden. Sofern beim Aufruf von ownCloud dann ein Fehler auftritt, sollte man dort weitere Infos finden.