rseffner
-
Joined
-
Last visited
Posts posted by rseffner
-
-
-
-
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ß -
-
-
-
-
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)?
-
-
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?
-
-
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
-
-
Hallo,
ich kümmere mich gerade mal etwas intensiver um meine gewachsene und portierten syscp-froxlor. Ich habe u.a. von php-fcgi auf php-fpm umgestellt. Dabei musste ich mir Gedanken um die Erreichbarkeit meines froxlor machen.
- der FQDN wird mit dem bind auf dem Server, aber manuell, verwaltet
- der hostname weicht vom FQDN, mit dem ich froxlor erreichen will ab
- ich habe in der froxlor-VHost-Konfiguration "unter hostnamen erreichbar" an und einen weiteren Alias (anderer FQDN) gesetzt
- egal ob php-fpm an oder nicht ...
=> ich kann nicht erkennen, dass froxlor nach dem cron Lauf (-f) einen VHost mit ServerName und/oder ServerAlias wie erwartet erstellt
ich habs jetzt manuell gemacht, um überhaupt wider ran zu kommen
Was kann der VHost-Erstellung alles dazwischenfunken? Was habe ich falsch konfiguriert oder übersehen?
Danke im Voraus, Ronny
... und schöne Wintersonnenwendfeier -
On 12/15/2025 at 4:57 PM, d00p said: Müsste froxlor tatsächlich korrrekt berücksichtigen, wenn "email only" gewählt ist, auch keine A/AAAA records zu erstellen sofern nicht manuell angegeben
Nach RFC genügen wohl SOA und minde ein NS rrecord. Da ein anderes RFC aber sagt, dass ohne MX ein Rückfall auf A/AAAA stattfindet, sollte der Patch dafür sorgen (ich habe nicht reingeschaut, möchte nur anmerken), dass entweder A/AAAA oder MX zusätzlich zur "Minimalausstattung" vorhanden sind, wenn der Froxlor-Admin die Mailfunktion aktiviert.
-
Durch das Aktivieren von System -> Einstellungen -> PHP-FPM -> Aktiviere PHP-FPM ist doch irgendwie PHP -> PHP-FPM Versionen -> $VERSION (in meinem Fall PHP8.4) entstanden. Und darin waren eben als restart command "php-fpm" statt wie Du schreibst "php-fpm8.4" sowie /etc/php-fpm.d" gesetzt. Irgendwo kommt das doch her.
Ich habe Froxlor 2.3.0; Du sagst das ist schon Jahren nicht mehr so -> da frage ich mich doch, wo kommen die Werte bei mir her nach Aktivierung von FPM? Das wäre ggf. das Thema in Richtung bugtracker. -
Ich habe an einem kleinen Server mal den Schritt gewagt von php-fcgid auf php-fpm umzustellen.
Dazu habe ich
- die Schritte unter System -> Konfiguration -> SYSTEM -> PHP-FPM manuell durchgeführt
- unter System -> Einstellungen -> FCGID -> ganz oben deaktiviert
- unter System -> Einstellungen -> PHP-FPM -> ganz oben aktiviert UND unten Verwende mod_proxy aktiviert, da ich Debian 13 Trixie nutze
( - ich frage mich was soll der Alias-Ordner /var/www/php-fpm, der wird nicht angelegt)
- unter PHP -> PHP-FPM Versionen -> $VERSION musste ich das restart command von "/etc/init.d/php-fpm restart" auf "/etc/init.d/php8.4-fpm restart" ändern
- in /etc/php/8.4/fpm/php-fpm.conf musste ich "include=/etc/php-fpm.d/*.conf" hinzufügen
- dann (und auch zwischendurch ;-) habe ich die System -> Configs neu schreiben Funktion genutzt
Effektiv bin ich also über die Vorgaben in der FPM Version gestolpert:
- das binary muss wohl die Versionsnummer enthalten "php-fpm8.4"
- die Idee mit dem Pfad für die pool configs muss man dem php-fpm über include mitteilen oder den Pfad eben auf den Debian Standard (/etc/php/8.4/fpm/pool.d/) setzen
- was ist hier besser?
Habe ich was falsch gemacht?
Sollte die Feststellung mit den 2 Defaults der FPM Version Konfiguration in den bugtracker?
Wo sollten die pool configs besser hin, in den von Froxlor vorgeschlagenen eigenen Order (dann brauchts den Hinweis mit dem include) oder in den Debian Std-Ordner?
Gruß, Ronny -
Ich sammle Informationen:
- es trifft augenscheinlich EINEN Kunden
- ein Trockenlauf mit goaccess --log-format=COMBINED liefert über 80GiB
- ich habe ein error_log() neben den Aufruf von goaccess in der TrafficCron.php gesetzt, so sieht der Aufruf für eine der Kundendomains aus:grep 'Feb/2025' '/var/www/logs/XXX-xxx-gruppe.com-access.log' | goaccess --persist --restore --db-path='/var/www/webs/XXX/goaccess/xxx-gruppe.com/' -o '/var/www/webs/XXX/goaccess/xxx-gruppe.com/.tmp.json' -o '/var/www/webs/XXX/goaccess/xxx-gruppe.com/index.html' --html-report-title='xxx-gruppe.com' --log-format=COMBINED --no-parsing-spinner --no-progress -
- es gibt in dem Fall eine zweite Domain unter diesem Kunden mit viel weniger traffic (127MiB)
- für den Kunden wurde eine 0 in die panel_traffic geschrieben - goaccess kennt aber durchaus die 80GiB
-
Hallo,
Ich bekommen Warnungen von Traffic über Schwellwert (selbst festgelegt um verdächtiges Verhalten zu bemerken) vom RZ. Auf dem Server läuft "pmacct" und protokolliert ein paar mir bekannten Ports mit, so auch TCP 80/443. Oft ist es ja ein fetchmail, das wieder und wieder die gleiche Mail abholen will - diesmal aber der Webserver. Also will ich schauen welcher meiner Kunden das ist - nichts liegt näher wie ins Froxlor zu schauen.
Da habe ich 7,70GB HTTP in den letzten 7 Tagen. Schicke ich cat /var/kunden/logs/*access.log | goaccess --log-format=COMBINED los, erhalte ich:496955 5.74% 8665 4.61% 109.73 GiB 17/Feb/2025 |||||||||||||||||||||||||
allein für den 17.02. - der Tag, an dem das RZ warnte. COMBINED ist auch der Wert in den Froxlor-Settings beim Webserver. Wo kann diese riesige Abweichung herkommen? -
Ich zähle zuerst mal kurz auf, wie ich glaube verstanden zu haben, wie froxlor zu seiner Traffic-Statistik (HTTP) kommt:
- /etc/con.d/froxlor lässt täglich um 0:00 Uhr den traffic task los
- dieser grept nach Monat und Jahr (nicht Tag) durch die Logs, so wie sie im VHost auch hinterlegt sind und piped das zu goaccess
- dieses wiederum kann dann ja u.a. nur eine Summe für den Monat, aber nicht den Tag liefern
- ein Rückschluss daraus ist, dass froxlor in der Trafficnutzung, die auf einzelne Tage auflöst, Differenzen der einzelnen goaccess-Summen verwenden muss
So weit so gut.
Jetzt beobachte ich aber an jedem Monatsersten einen gewaltigen Peak in der Tagesleistung, der sich bei Stichproben auch NICHT NUR nur aus der Summe des Vormonats spießt (er ist deutlich größer). Kann es sein, dass durch falsche Reihenfolge von traffic-task und logrotate die Monatssummen jeweils in den Monatsersten fakultativ aufbauen?
- im Januar mit 0 begonnen und 1GB gemacht
- 1. Februer mit 1GB gebucht und im Rest des Monats ein weiteres GB gemacht
- 1. März mit den 1+1GB aus Feb gebucht und wieder 1GB gemacht
- Jahressumme bis hierher 1 (Jan) + 2 (Feb) + 3 (Mär) = 6 !
Genau so sieht leider auch der Jahresgraph aus ;-(
Ich wollte mir unter Debian 12 bookworm nun logrotate anschauen. Das findet sich in cron.daily, dessen Skripte 6:25 Uhr getriggert werden. in logrotate.d habe ich ein file froxlor, welches sich monatlich um alles unter /var/customers/logs kümmert. Erstaunlich, dass die Rotationen aber eher gegen 0 Uhr stattfinden, denn 6:25 Uhr. Das syslog belegt, dass es einen logrotate.timer und -.service gibt, die gegen 0 Uhr gestartet und beendet werden.
Da meine "Kunden" gern weiter in die Vergangenheit schauen, unterscheidet sich meine logrotate-Konfiguration in daily->monthly und rotate 7->13. Das sollte doch aber nicht ursächlich sein.
btw.: die Funktion "Logdateien einsehen" gewährt vermutlich mit einem "tail" auch nur Zugriff auf die letzten paar dutzend Zeilen - richtig?
Wenn logrotate 0 Uhr läuft, aber auch goaccess durch den traffic-task 0 Uhr getriggert wird, findet letzteres am Rotationstag doch entweder ein leeres Log vor oder ihm wird es beim Lesen unterm Hintern weggezogen. Nicht?
- Was verursacht bei mir diese Peaks immer am Monatsersten? Wie verhindere ich das?
- Sollten die Zeitpunkte von traffic-task und/oder logrotate überdacht werden?
- Wie könnte man den Kunden "mehr Log" als nur die paar letzten Zeilen dauerhaft zugänglich machen (skript mit symlinks in deren home?) -
Was für Magie.
Beides gleichzeitig ging hier noch nie, und so sieht der erste cron-Lauf auch aus:
[information] Requesting 1 new Let's Encrypt certificates [warning] Skipping Let's Encrypt generation for hem-architektur.de due to an enabled ssl_redirect [error] Could not find certificate-folder for domain 'hem-architektur.de' [information] Let's Encrypt certificates have been updatedIch habe den cron dann gleich nochmal laufen lassen und nun habe ich den ssl_redirect auf "1". Muss ich meine interne Doku anpassen, die "immer erst LE, dann cron, dann Redirect, dann cron" besagte.
Bleibt der "bug" mit dem nachträglichen redirect. -
Da sehe ich das leider nicht.
Im 1. Schritt deaktiviere ich die SSL-Weiterleitung und LetsEncrypt - dann cron - ssl_redirect ist "0"
Im 2. Schritt aktiviere ich LetsEncrypt - dann cron - es wird erfolgreich ein Zertifikat abgelegt, ich kann die Seite dann auch ohne Browserwarnung mit https aufrufen - ssl_redirect ist weiter "0"
Im 3. Schritt aktiviere ich wieder die SSL-Weiterleitung - dann cron - ssl_redirect ist wieder die "3" / es wird kein redirect angelegtDas Problem habe ich der "3" zu Folge mit 4 Domains.
[information] Running Let's Encrypt cronjob prior to regenerating webserver config files [information] Checking for LetsEncrypt client upgrades before renewing certificates:_[Do 28. Nov 15:51:07 CET 2024] Already up to date!_[Do 28. Nov 15:51:07 CET 2024] Upgrade successful!_[Do 28. Nov 15:51:07 CET 2024] Installing cron job_20 0 _ _ _ LANG_en_US.UTF-8_ /root/.acme.sh/acme.sh --cron --home /root/.acme.sh _ /dev/null_[Do 28. Nov 15:51:07 CET 2024] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory [information] Updated Let's Encrypt certificate for *****rchitektur.de [information] Let's Encrypt certificates have been updated [information] apache::createIpPort: creating ip/port settings for [2a01:4f8:***:****::101]:80 [debug] [2a01:4f8:***:****::101]:80 :: inserted listen-statement [notice] [2a01:4f8:***:****::101]:80 :: namevirtualhost-statement no longer needed for apache-2.4 [information] apache::createVirtualHosts: creating vhost container for domain 337, customer *****rich [information] apache::createVirtualHosts: creating vhost container for domain 338, customer *****rich [information] apache::createVirtualHosts: creating vhost container for domain 336, customer *****rich [information] apache::createVirtualHosts: creating vhost container for domain 335, customer *****rich [information] apache::createVirtualHosts: creating vhost container for domain 334, customer *****rich [information] apache::createVirtualHosts: creating vhost container for domain 333, customer *****rich [information] apache::createVirtualHosts: creating vhost container for domain 506, customer *****rich [information] apache::createVirtualHosts: creating vhost container for domain 504, customer *****rich [information] apache::createVirtualHosts: creating vhost container for domain 331, customer *****rich [information] apache::writeConfigs: rebuilding /etc/apache2/sites-enabled/ [information] apache::writeConfigs: rebuilding /etc/apache2/htpasswd/ [information] apache::writeConfigs: rebuilding /etc/apache2/sites-enabled/ [information] Froxlor\Cron\Http\ApacheFcgi::reload: reloading Froxlor\Cron\Http\ApacheFcgi
-
INSERT INTO `panel_domains` (`id`, `domain`, `domain_ace`, `adminid`, `customerid`, `aliasdomain`, `documentroot`, `isbinddomain`, `isemaildomain`, `email_only`, `iswildcarddomain`, `subcanemaildomain`, `caneditdomain`, `zonefile`, `dkim`, `dkim_id`, `dkim_privkey`, `dkim_pubkey`, `wwwserveralias`, `parentdomainid`, `phpenabled`, `openbasedir`, `openbasedir_path`, `speciallogfile`, `ssl_redirect`, `specialsettings`, `ssl_specialsettings`, `include_specialsettings`, `deactivated`, `bindserial`, `add_date`, `registration_date`, `termination_date`, `phpsettingid`, `mod_fcgid_starter`, `mod_fcgid_maxrequests`, `letsencrypt`, `hsts`, `hsts_sub`, `hsts_preload`, `ocsp_stapling`, `http2`, `notryfiles`, `writeaccesslog`, `writeerrorlog`, `override_tls`, `ssl_protocols`, `ssl_cipher_list`, `tlsv13_cipher_list`, `ssl_enabled`, `ssl_honorcipherorder`, `ssl_sessiontickets`, `description`) VALUES (333, '*****rchitektur.de', '*****rchitektur.de', 2, 25, NULL, '/var/www/webs/*****rich/*****rchitektur.de/', 1, 1, 0, 0, 0, 1, '', 1, 185, '-----BEGIN RSA PRIVATE KEY-----\nMIIEp*****zBn+de5lQ=\n-----END RSA PRIVATE KEY-----\n', 'MIIBI*****AQAB', 1, 0, 1, 1, 0, 1, 3, '', '', 1, 0, '2024112809', 1521111357, '2018-03-15', NULL, 59, 0, 0, 1, '0', 0, 0, 0, 1, 0, 1, 1, 1, 'TLSv1.2,TLSv1.3', 'EECDH+AESGCM:EDH+AESGCM', '', 1, 1, 1, '');
NIS-2 Umsetzung - Infos gesucht
in German / Deutsch
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 ...