rseffner

Ich dachte "Mach für Dich/Dein Unternehmen doch mal eine Betroffenheitsprüfung nach §28 BSIG. <50 Mitarbeiter und/oder <10Mio Bilanzsumme, dann bist Du keine 'wichtige Einrichtung'". Aber ja, man kann (und das BSI hat das wohl so getan) § 28 Abs 1 Nr. 2 so interpretieren, dass die globale Definition des Geltungsbereiches des BSIG hier "überschrieben" wird. Wir haben "Fachkraft für Datenschutz" und "IT-Sicherheitsbeauftragten". Diese sind mit dem Ergebnis "interviewe mich mal für eine Doku, Handlungsempfehlungen und (wiederkehrenden) Maßnahmenplan zu 'wir sind DNS, Web- und Mail-Hoster' nach NIS 2" gegenüber claude.ai eigentlich ganz zufrieden. Jetzt haben wir irgendwie 15 Kapitel Dokument und ein paar wiederkehrende Aufgaben sowie Mitarbeiter mit erhöhtem Bewusstsein - eigentlich keine Raketenwissenschaft oder grundlegend Neues wenn man mal ein VVZ (alt ;-) nach DSGVO/BDSG gemacht, oder einem Kunden ei TiSAX bzw. ISO 27001 geholfen hat. Mit der Meldung beim BSI hadern wir noch ...

Verstehe. Aus meiner Perspektive wäre das ein bugfix - aber aus Eurer Perspektive weder critical noch important. Ich überlege mir also was update-Resistentes.

Dann liegts an der Systemweiten UMASK vielleicht? Ich habe 027 (/etc/login.defs) und Du sicher 022. Bin ich damit der Exot oder sollte der Code hier auf Nummer sicher gehen und dem Ordner (da "fehlt" ja auch das world-read) und den Dateien explizit Rechte mitgeben?

Hallo, es kommt hier selten vor, dass jemand Verzeichnisschutz nutzt, daher kann ich nicht sagen, wie lange das Problem schon besteht, aber es ist so, dass auf meinen Servern nach Ändern eines Verzeichnisschutzes die Dateien dort root:root und 0640 haben. Damit sind sie für den apache (www-data) nicht lesbar und es kommt zum HTTP 500. Sollte in die lib/Froxlor/Cron/Http/Apache.php hinter Zeile 1402 vielleicht sowas wie: chmod($htpasswd_filename, 0644); - oder - chgrp($htpasswd_filename, 'www-data'); Gruß

Didn't know apt-file search or apt-cache search or aptitude if your distro is debian-like? Other distros may have other tools for searching programs like yast, yum and so far For debian/ubuntu family you'll install "quota" and "quotatool" to get mentioned binaries.

Can see the logs? Sure? Not only the last few lines?

Das scheitet u.a. offenbar daran, dass der/die Verzeichnisse nicht "automagisch" angelegt werden. "/var/www/php-sessions" würde ich ja world rwx noch einmalig anlegen, für die Kunden brauchts dann aber wieder was mit API?

Wenn ich also "session.save_path" in die "php-fpm->php_admin_values" mit aufnehme, sollte ich in den "PHP-Konfigurationen" z.B. "session.save_path = /var/www/tmp/php-sessions/{CUSTOMER}" setzen können?

Im Grunde musste man doch da nur die schon vorhanden Funktion aus dem php-fcgi-Code irgendwie zusätzlich aktivieren? Ich lese zwischen den Zeilen der Antwort, dass das Problem zu "klein" ist, um jetzt zentrale Berücksichtgung zu finden. Mal sehen ob mein "Schmerz" groß genug wird eine Lösung um zusetzen, statt mit dem Provisorium manueller ini's zu leben. Hätte ja auch sein können, ich denke zu eingeschränkt.

Ich habe von php-fcgi auf php-fpm umgestellt. Vermutlich damit einher kommt der cronjob froxlor:php-sessionclean. Auf dem Webserver laufen vereinzelt nextcloud-Instanzen mit collabra-office als appimage. Letzteres wird offenbar über fuse unter dem Froxlor-Kunden eingehangen und der Mountpoint landet im /var/customers/tmp/Kunde. Dort will auch der sessionclean als root durch und stößt sich an dem nicht lesbaren Dateisystemobjekt: find: ‘/var/customers/tmp/KUNDE/.mount_CollabLB2oWZ’: Keine BerechtigungIn der /etc/cron.d/froxlor brauche ich nicht mit grep und Ausgabeumleitung rumpopeln. Könnte ich denn tmp und sessions in verschiedene Ordner legen (session_save_path ./. {TMP_DIR}) oder ist das sessionclean hardcodiert an den {TMP_DIR}? Vielleicht gibts ja auch ne ganz andere Idee (außer den office-Server in docker oder als deamon aufzusetzen)?

Kein Grund sich zu entschuldigen. Wie immer lieber "Vielen Dank für die rege Arbeit am Projekt". Drum habe ich ja auch einen "Lösungsvorschlag" in meiner Feststellung mitgeliefert.

Egal ob nextcloud, wordpress, matomo, mautic, ... - viele Webanwendungen empfehlen cronjobs. Bisher lief bei mit php-fcgi und ich habe die cronjobs mit "php -c /war/www/php-fcgi-scripts/KUNDE/DOMAIN" konfiguriert um die gleichen PHP Einstellungen zu nutzen, wir für den VHost im Froxlor vorgesehen. Jetzt unter php-fpm gibts die Pool-Konfigurationen, die sich nicht mittels "php -c" als INI nutzen lassen. Man müsste händisch irgendwo INIs anlegen und bei Änderungen der PHP-Einstellungen im UI dann auch manuell anpassen. Könnte Froxlor nicht für diesen Anwendungsfall weiterhin php.ini's generieren und irgendwo ablegen - oder übersehe ich gar eine einfache Lösung?

Nicht kriegsentscheidend, aber ich z.B. schaue gern vorm Einspielen der Updates nach, was sich ändert. In diesem Fall macht man dass dann eben etwas aufwändiger über github.

So sieht momentan der generierte VHost zur IP Port 80 aus. Was mir da fehlt ist eine "Referenz" zu Froxlor (sowohl ServerName oder ServerAlias sowie Pfade): Listen IPv4:80 <VirtualHost IPv4:80> DocumentRoot "/var/kunden/webs/its/nopage" <Directory "/var/kunden/webs/its/nopage/lib/"> <Files "userdata.inc.php"> Require all denied </Files> </Directory> <DirectoryMatch "^/var/kunden/webs/its/nopage/(bin|cache|logs|tests|vendor)/"> Require all denied </DirectoryMatch> <Directory "/var/kunden/webs/its/nopage/"> <FilesMatch \.(php)$> <If "-f %{SCRIPT_FILENAME}"> SetHandler proxy:unix:/var/lib/apache2/fastcgi/3-froxlor.panel-froxlor.DOMAIN.de-php-fpm.socket|fcgi://localhost </If> </FilesMatch> Require all granted AllowOverride All </Directory> </VirtualHost> Der VHost für HTTPS sieht nicht grundlegend anders aus, bis auf die SSL* Zusätze

Listen und VHost-Container sind an. ServerName-Eintrag ist aus. Das wird schon ein Teil der Eklärung sein. Allerdings überschreibe ich dort momentan den DocRoot (mit einer generischen Fehlerseite) - das kollidiert wohl mit der froxlor-VHost-config?