All Activity
- Today
-
froxlor 2.3 – SSH-key management, API upgrades, HTTP/3 & Debian 13 support
Security release 2.3.7 [Security] secured regex for Dns LOC entries validation CVE: CVE-2026-41237 More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-j6fm-9rfm-j5hx [Security] remove invalid control characters in every dns content-field see above [Security] ensure given shell exists in Ftps.add/update CVE: CVE-2026-41235 More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-gcv3-5v9q-fmhh [Security] ensure authorized_keys file for SshKeys is within the customers documentroot CVE: CVE-2026-41236 More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-mq5v-pxpm-8jw2 [Security] ensure a given symlink is resolved and validated correctly in FileDir::makeCorrectFile() see above [Security] secure api-key generation by asking user for current password More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-f9rx-7wf7-jr36 [Security] ensure ownership of email/emailsender in frontend when deleting emailserver More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-mr9h-45p9-fg8h [Security] ensure given dbserver value for Mysqls.add() is within the list of allowed mysql-servers for the customer More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-q4rm-m6xh-5pv7 [UI] add missing label for REBUILD_NSSUSERS task by @lukasbableck in https://github.com/froxlor/froxlor/pull/1402 [i18n] Add Slovak language (sk) by @martinbernat in https://github.com/froxlor/froxlor/pull/1404 The security-advisories will be published on 29th of May in order to give people enough time to update.
- Last week
-
Lock FTP when exceeding limits
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.
-
- Earlier
-
Lock FTP when exceeding limits
Hello! Thank you for all the assistance so far! Today, I modified a user to have 3MB of stored, then uploaded a 414MB file. I adjusted the Web- and Traffic- Reports cronjob to run every 8 hours instead of once a day. After a few hours, the cron ran and the traffic bar updated to 416.69 MiB / 3.00 MiB. However, the user can still upload more files. Although not tested, this makes me wonder if exceeding the traffic limit allows the user's website to keep getting more hits past the limit. I noticed the Quota option in System > Settings > Quota, however the directories listed there (/usr/bin/quotatool and /usr/sbin/repquota) do not exist (Even after activating Quota and rebuilding configuration files). I found a GitHub repository with a similar name (https://github.com/ekenberg/quotatool), but could not find any documentation that connects it to Froxlor. Does Froxlor has a way to suspend uploads and file creation activity when account quotas are reached and deactivating the user when traffic limits are reached? Thank you!
-
Accessing Error Logs over FTP
For future reference, I managed to resolve this by setting error_log = {CUSTOMER_HOMEDIR}error_logs/php_errors.log in php.ini and chown <user>:www-data the error_logs folder.
- Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
-
Accessing Error Logs over FTP
it's currently only the last 1000 lines iirc, depending on the customer, these logs can get HUGE and froxlor won't be able to load them (or php timeouts etc.). Maybe we will think of a better solution for froxlor3, this is unlikely to change in 2.x
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
Nochmal danke für deine Hilfe! Hier noch ein paar zusätzliche Queries die ich vorher ausführen musste: UPDATE panel_domains SET ssl_protocols = '' WHERE ssl_protocols IS NULL; UPDATE panel_domains SET ssl_cipher_list = '' WHERE ssl_cipher_list IS NULL; UPDATE panel_domains SET tlsv13_cipher_list = '' WHERE tlsv13_cipher_list IS NULL;Die neuen Columns description waren schon da. Ich weiß natürlich nicht, ob du alles mitgenommen hast. AABER! ES HAT FUNKTIONIERT! 🥳🥳🥳🥳 Danke vielmals. Ich bin im Dashboard drin!
-
Accessing Error Logs over FTP
Can see the logs? Sure? Not only the last few lines?
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
Ja okay, jetzt weiss ich was los is. Du hast ja nicht mal die neueste 0.10.x version, die letzte war die 0.10.38.3 und nur mit der kommst du auch in die 2er updates. Das wird jetzt etwas frickelig, aber du musst halt die "db-updates" für 0.10.25 -> 0.10.38.3 durchführen: ALTER TABLE panel_domains CHANGE `ssl_protocols` `ssl_protocols` varchar(255) NOT NULL DEFAULT ''; ALTER TABLE panel_domains CHANGE `ssl_cipher_list` `ssl_cipher_list` varchar(500) NOT NULL DEFAULT ''; ALTER TABLE panel_domains CHANGE `tlsv13_cipher_list` `tlsv13_cipher_list` varchar(500) NOT NULL DEFAULT ''; ALTER TABLE panel_domains ADD `description` varchar(255) NOT NULL DEFAULT '' AFTER `ssl_sessiontickets`; ALTER TABLE mail_virtual ADD `description` varchar(255) NOT NULL DEFAULT '' AFTER `iscatchall`; INSERT INTO `panel_settings` SET `settinggroup` = 'panel', `varname` = 'imprint_url', `value` = ''; INSERT INTO `panel_settings` SET `settinggroup` = 'panel', `varname` = 'terms_url', `value` = ''; INSERT INTO `panel_settings` SET `settinggroup` = 'panel', `varname` = 'privacy_url', `value` = ''; INSERT INTO `panel_settings` SET `settinggroup` = 'system', `varname` = 'domaindefaultalias', `value` = '0'; INSERT INTO `panel_settings` SET `settinggroup` = 'panel', `varname` = 'logo_image_header', `value` = ''; INSERT INTO `panel_settings` SET `settinggroup` = 'panel', `varname` = 'logo_image_login', `value` = ''; UPDATE `panel_settings` SET `value` = 'letsencrypt' WHERE `settinggroup` = 'system' AND `varname` = 'letsencryptca'; INSERT INTO `panel_settings` SET `settinggroup` = 'panel', `varname` = 'logo_overridetheme', `value` = '0'; INSERT INTO `panel_settings` SET `settinggroup` = 'panel', `varname` = 'logo_overridecustom', `value` = '0'; INSERT INTO `panel_settings` SET `settinggroup` = 'system', `varname` = 'createstdsubdom_default', `value` = '1'; DELETE FROM `panel_settings` WHERE `settinggroup` = 'panel' AND `varname` = 'no_robots'; INSERT INTO `panel_settings` SET `settinggroup` = 'system', `varname` = 'froxlorusergroup', `value` = ''; INSERT INTO `panel_settings` SET `settinggroup` = 'system', `varname` = 'froxlorusergroup_gid', `value` = ''; INSERT INTO `panel_settings` SET `settinggroup` = 'system', `varname` = 'powerdns_mode', `value` = 'Native'; INSERT INTO `panel_languages` SET `language` = 'Česká republika', `iso` = 'cs', `file` = 'lng/czech.lng.php'; INSERT INTO `panel_settings` SET `settinggroup` = 'system', `varname` = 'acmeshpath', `value` = '/root/.acme.sh/acme.sh'; UPDATE `panel_settings` SET `value` = '202112310' WHERE `settinggroup` = 'panel' AND `varname` = 'db_version'; UPDATE `panel_settings` SET `value` = '0.10.38.3' WHERE `settinggroup` = 'panel' AND `varname` = 'version'; (keine Garantie das ich grad auf die Schnell wirklich alles erwischt hab)
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
Danke, logs tauchen auf. ich habe leider nicht viele Log-Meldungen: [2026-05-01 17:11:24] froxlor.NOTICE: viewed admin_updates {"source":"admin","action":"30","user":"admin"} [] [2026-05-01 17:11:24] froxlor.INFO: [API] checking for updates {"source":"admin","action":"30","user":"admin"} [] [2026-05-01 17:11:35] froxlor.NOTICE: viewed admin_updates {"source":"admin","action":"30","user":"admin"} [] [2026-05-01 17:11:35] froxlor.WARNING: -------------- START LOG -------------- {"source":"admin","action":"30","user":"updater"} [] [2026-05-01 17:11:35] froxlor.WARNING: Checking database integrity {"source":"admin","action":"30","user":"system"} [] [2026-05-01 17:11:35] froxlor.WARNING: Success {"source":"admin","action":"30","user":"system"} [] [2026-05-01 17:11:35] froxlor.WARNING: --------------- END LOG --------------- {"source":"admin","action":"30","user":"system"} [] [2026-05-01 17:11:35] froxlor.INFO: [API] checking for updates {"source":"admin","action":"30","user":"admin"} [] [2026-05-01 17:11:39] froxlor.NOTICE: viewed admin_index {"source":"admin","action":"30","user":"admin"} [] [2026-05-01 17:11:39] froxlor.INFO: [API] checking for updates {"source":"admin","action":"30","user":"admin"} []Und vor allem keine Fehlermeldungen. Das sind die vollständigen Logs bei einmal aufrufen der Website -> Anmelden -> Durchführen der Upgrade settings in der GUI -> Proceed
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
Da sollte garkein ajax.php eine Rolle spielen wenn du noch im Update-Prozess bist. Aktivere doch mal das File-Logging: (Mysql, manuell): UPDATE `panel_settings` SET `value` = '1' WHERE `settinggroup` = 'logger' AND `varname` = 'enabled'; UPDATE `panel_settings` SET `value` = 'syslog,file' WHERE `settinggroup` = 'logger' AND `varname` = 'logtypes'; UPDATE `panel_settings` SET `value` = '2' WHERE `settinggroup` = 'logger' AND `varname` = 'severity'; UPDATE `panel_settings` SET `value` = 'froxlor.log' WHERE `settinggroup` = 'logger' AND `varname` = 'logfile';die log 'froxlor.log' sollte dann im Ordner /logs/ auftauchen
- Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
Schon mal danke, ich habe da auch einen Fehler entdeckt: meine panel_customers Tabelle wollte nicht altered werden. Ich habe deshalb zusätzlich ALTER TABLE panel_customers ROW_FORMAT=DYNAMIC; ausgeführt, danach konnte ich dann die neue Spalte hinzufügen. Leider ist das Ergebnis soweit das selbe: keine neuen Logs im froxlor/logs Directory und auch nur der bereits erwähnte ajax.php Fehler weil $result['last_update_check'] = $uc_data['ts']; nicht ausgeführt werden konnte.
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
ah okay, ja von 0.10.x ist aber auch wirklich...puh....also deine datenbank hat auf jedenfall noch den stand von 0.10.25 und deine dateien sind 2.3.5 - d.h. da ist noch genau kein Datenbank-Update gelaufen, weil ein 2.x featuer (gui_access) dich davon abhält. Am besten machst du nun Folgendes: 1) MySQL, manuell: ALTER TABLE `panel_admins` ADD `gui_access` tinyint(1) NOT NULL default '1'; ALTER TABLE `panel_customers` ADD `gui_access` tinyint(1) NOT NULL default '1';2) Damit das Update nicht versucht, die Felder anzulegen: 2.1) Öffne ./install/updates/froxlor/update_2.2.inc.php 2.2) Lösche diese vier Zeilen (Zeile 98-101 müsste das sein): Update::showUpdateStep("Enhancing admin and user table"); Database::query("ALTER TABLE `" . TABLE_PANEL_ADMINS . "` ADD `gui_access` tinyint(1) NOT NULL default '1';"); Database::query("ALTER TABLE `" . TABLE_PANEL_CUSTOMERS . "` ADD `gui_access` tinyint(1) NOT NULL default '1';"); Update::lastStepStatus(0);Dann probier das Update noch mal
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
Ich komme dann nur wieder auf die Update-Seite: Ich setze die Checkmarks die ich gerne hätte, aktiviere unten dass ich die Upgrade Notes gelesen habe und klicke auf Proceed, dann komme ich auf die Database Integrity Seite wo alles gut ist: Und komme wieder aufs Dashboard das aussieht wie oben. Keine Fehlermeldungen in der Browser Netzwerkkonsole, nur die genannte ajax.php Fehlermeldung im Apache Log und keine neuen Fehlermeldungen im Froxlor Log. Eine Sache habe ich nur noch gefunden: im Froxlor Log sehe ich |CODE 42S22 |MSG SQLSTATE[42S22]: Column not found: 1054 Unknown column 'gui_access' in 'field list' |FILE /var/www/html/froxlor/lib/Froxlor/Database/Database.php |LINE 122 |TRACE #0 /var/www/html/froxlor/lib/Froxlor/Database/Database.php(122): PDOStatement->execute() #1 /var/www/html/froxlor/lib/Froxlor/Api/Commands/Admins.php(759): Froxlor\Database\Database::pexecute() #2 /var/www/html/froxlor/admin_index.php(270): Froxlor\Api\Commands\Admins->update() #3 {main}Die Log-Zeile wurde wohl beim Start von Froxlor geschrieben, zumindest passt die Uptime zusammen.
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
irgendwas lässt dein froxlor glauben, dass die Dateien neuer sind als die (froxlor) Datenbank. Mit Sicherheit ist hier bei so einem massiven Versions-Sprung irgendwo was hängengeblieben. Was genau wird denn angezeigt, wenn du links im Menü auf "froxlor update" klickst, ggfls lässt sich hier einsehen wo er aufgehört hat und wo der Updater dann ggfls crashed
-
-
Update nach Jahren unberührter Installation - kann Upgrade nicht abschließen
Hi! Ich habe von meinem Hoster bei der Installation vom V-Server Froxlor vorinstalliert gehabt und Froxlor genutzt um mir einen Mail-Account einzurichten und danach das ganze Teil so ziemlich in Ruhe gelassen. Das hat ewig lang funktioniert und auch jetzt scheint es noch weiter zu laufen, meine E-Mails kommen immer noch auf die damals eingerichtete E-Mail Adresse an. Ich wollte nach all den Jahren dann aber doch mal wieder gucken: Was kann Froxlor eigentlich alles so und bin auf die Seite gegangen. Dort wurde ich dann nach Admin-Login gefragt um das Update das mit meinen Server-Updates wahrscheinlich ohne dass ich es bemerkt habe im Hintergrund eingespielt wurde zu vollenden. Soweit so gut. Das Update geht über 4 Minor Versionen: von 0.10.25 auf 2.3.5. Wahrscheinlich von Debian 9 auf Debian 12 wenn man alles zusammenzählt. Nun, ich klicke die Einstellungen an, die ich gerne hätte, Froxlor geht einen Schritt weiter und zeigt mir einen grünen Haken bei Database Integrity. Ich klicke aufs Dashboard und sehe das Dashboard. Anzahl E-Mails, anzahl User etc. Alles korrekt dargestellt. Nur das Update beendet sich nicht. Links in der Seite sehe ich nur weiterhin das "froxlor update" und auch nach etwas Warten falls die Cron-Tasks etwas machen, passiert nichts. Ich finde auch keine wirklich hilfreichen Logs, weder in /var/www/html/froxlor/logs, noch anderswo. Nur in den Apache2 Error Logs sehe ich Trying to access array offset on value of type null in /var/www/html/froxlor/lib/Froxlor/Ajax/Ajax.php on line 202, referer: https://<<Domain>>/froxlor/admin_settings.php?page=phpinfo Wie ihr wahrscheinlich schon gelesen habt: ich bin total unerfahren was Froxlor angeht und habe keine große Ahnung wie ich weiter debuggen kann, um mein Panel wieder lauffähig zu bekommen. Bin deshalb über jede Hilfe dankbar.
-
Accessing Error Logs over FTP
Currently not intended this way. Customers can see logs in the UI if allowed by the admin
-
Accessing Error Logs over FTP
Hello, I am trying to give customers access to the PHP error log from their FTP account. I have been experimenting with the error_log statement in the php.ini setting under PHP > PHP Configurations > [User PHP Config], however it only seems to work if the destination file has already been created. Obviously, this is not ideal as users could accidentally delete the file or the process I would have to setup to create the file could fail. Leaving the statement blank sends the data to Froxlor's error logging system. Since I passed 1 for the option "speciallogfile", the user seems to have their own dedicated log file in the system (Please correct me if either of these statements are wrong). Is there a way to get this log file accessible to the user over FTP without manually creating systemlinks? I want the customer to be able to access their php error logs via FTP. Where that file is stored I don't really have a preference as long as it is easily accessible. I took a look at past forum posts and the documentation, but did not see anything relevant. Thank you!
-
GR9 started following Accessing Error Logs over FTP
-
Blocking Admin Panel Access via IP
DocRoots and settings in froxlor cannot change this behaviour. Your server listens to this IP and of course answers accordingly. You may add rewrite rules or similar to redirect to a domain if the request is not the domain itself, e.g. RewriteEngine On RewriteCond %{HTTP_HOST} !^panel\.example\.tld$ [NC] RewriteRule ^ https://panel.example.tld%{REQUEST_URI} [R=301,L]Alternatively, create a custom vhost file, e.g. 000-fallback.conf and do something like <VirtualHost *:80> ServerName panel.example.tld Redirect permanent / https://panel.example.tld/ </VirtualHost>depending on your needs
-
d00p started following Blocking Admin Panel Access via IP
-
Blocking Admin Panel Access via IP
Hello! I recently setup my first Froxlor instance and have been trying to prevent the froxlor login UI from showing on the server's IP address. I would like all logins to happen through hostname.tld. Over the past few hours, I have unsuccessfully been modifying the settings under IPs and Ports to try and achieve this. I tried DocRoots, and a whole bunch of different V-Host settings but everything that worked for preventing the IP logins also affected client sites in some negative way. I was unable to find any other related topics by searching the forum, but I may have just been using the wrong keywords. How would I go about configuring the system to reject any direct-IP requests? Thank you!
-
GR9 started following Blocking Admin Panel Access via IP
-
GR9 joined the community
-
Julian05 joined the community
-
GuGuan123 joined the community
-
Install fails due to PHP 8.3.29
agreed
-
Install fails due to PHP 8.3.29
Thanks so much to doop. The critic error was not referring to the php version. The manual reads PHP 7.4 to 8.2 which should be updated. The critic error was related to the permissions. Despite being applied correctly, the install failed due to the SELinux Security Context, which needed: Thanks again for your help and incite.
-
Install fails due to PHP 8.3.29
dont know any specialties about AlmaLinux...this usually is no issue at all. the check in lib/Froxlor/Install/Install.php is: // check whether we can read the userdata file if (!@touch(dirname(__DIR__, 2) . '/.~writecheck')) { // get possible owner $posixusername = posix_getpwuid(posix_getuid())['name']; $posixgroup = posix_getgrgid(posix_getgid())['name']; $this->criticals['wrong_ownership'] = ['user' => $posixusername, 'group' => $posixgroup]; } else { @unlink(dirname(__DIR__, 2) . '/.~writecheck'); }it should ensure the folder lib/ within the froxlor root-directory can create/write the userdata.inc.php file later on in the installation process
-
Install fails due to PHP 8.3.29
I wrote a short php script to touch and check the folder: touch.php : froxlor modification time has been changed to present time froxlor folder is writable: bool(true) Yes I realize I may have modify some files but that won't be necessary if I can't get it installed I do appreciate your efforts.