Beiträge von kk

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.

Nein, owncloud braucht definitiv kein mod_php (davon ist allgemein dringend abzuraten).
Wenn Sie von mod_php auf FastCGI umgestellt haben, dann vermute ich, dass die ganzen Dateiberechtigungen nicht (mehr) stimmen.

Alle Dateien in /var/www/<Vertrag>/htdocs/ müssen dem Vertragsnamen/-Gruppe gehören, also bei "web1" z.B. dem Benutzer "web1" und der Gruppe "web1".
(mit mod_php sah das anders aus, da mussten die Dateien alle dem Webserver-User, also "www-data" gehören).

Um die Rechte anzupassen, führen Sie also z.B. so was aus:
chown -R webX:webX /var/www/webX/htdocs/*

(bzw. falls Sie ownCloud über den AppInstaller instaliert haben: chown -R webX:webX /var/www/webX/apps/*)

("webX" durch den jeweiligen Vertragsnamen ersetzen)

Viele Grüße

-Klaus Keppler

Hallo!
Vielen Dank für das große Interesse. Wir sind erst seit heute wieder "normal" im Büro, und haben leider noch einen Berg Arbeit zu erledigen. Wir sind nun dabei einen Demo-Server mit der v2.8 vorzubereiten und die ganzen Änderungen/Neuerungen zusammenzufassen; bis Ende der Woche sollte das dann online gehen.
Wir arbeiten mit Hochdruck an der Freigabe!

Viele Grüße

-Klaus Keppler

Exakt.
Soweit ich weiß wird in Postfix derzeit an SNI (Server Name Indikation) gearbeitet - damit könnte man dann für jede gewünschte MX-Domain ein eigenes Zertifikat anlegen. Da es ja aber für jede IP auch nur einen Reverse-DNS-Namen geben kann, macht das in der Praxis wenig Sinn.

Evtl. wäre es eine Option, AutoConfigure/AutoDeploy einzurichten (was nicht ganz trivial ist); dann "sehen" die Kunden den Mailservernamen häufig gar nicht mehr.

Ich finde hier kein Support-Ticket zu dem beschriebenen Problem.

Was taucht denn genau alles in /var/log/mail.log auf, wenn eine E-Mail eintrifft?
(vor dem Eintrag von lcsam sollten jeweils die Meldungen von SpamAssasin (spamd) stehen).

Einizige Möglichkeit aktuell: die Änderungen in der FPM-Konfigurationsdatei (in diesem Fall also /etc/php-fpm/php72-fpm.d/test.conf) vornehmen, und die Datei anschließend mit "chattr +i" schreibschützen.

Wir planen aber bereits eine Möglichkeit, die FPM-Einstellungen individuell konfigurierbar zu machen (z.B. auch wenn man einen anderen Prozessmanager verwenden möchte).

Zitat von aho546745

Hallo Herr Keppler,

wann wird die Funktion bereitgestellt?

Wie in Beitrag #16 geschrieben, ist das Feature in v2.8 enthalten. Wir nähern uns der Freigabe mit großen Schritten.

Hallo,

unsere PHP-Pakete für Debian/Ubuntu wurden eben auf die Versionen 7.1.27, 7.2.16 und 7.3.3 aktualisiert.

Viele Grüße

-Klaus Keppler