d00p

Currently not intended this way. Customers can see logs in the UI if allowed by the admin

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)

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

fixed

wäre eine idee ja - dafür haben wir die ja ursprünglich auch mal gemacht - das frontend kann schlichtweg nicht komplett alle wünsche und anforderungen abdecken

müsste man separat für php-cli generieren, ist so nicht vorgesehen aktuell. Steht dir aber frei mit einem script und API da was zu basteln wenn das notwendig für dich ist

Im zweifel doch immer alles auf github, sorry das ich gestern mitten in der nacht keine zeit für nen foren.-eintrag hatte... https://github.com/froxlor/Froxlor/releases

das sind vermutlich uralte defaults von vor Jahren....die Installation setzt schon seit Ewigkeiten "moderneres" (siehe https://github.com/froxlor/Froxlor/blob/main/install/froxlor.sql.php#L862, entsprechend der bei der installation genutzten Version natürlich). Bestands-Einträge aus früheren Versionen werden hierbei nicht nachträglich aktualisiert, sie könnten ja in Nutzung sein

Du legst eine php-fpm version nur einmal an, php8.3 z.B. - unterschiedliche Konfigurationen (auch pm related) machst du dann mit "PHP Konfigurationen". Hier kannst du so viele anlegen wie du willst und jedesmal als php-fpm version deine PHP8.3 wählen. Wenn du hier die pm-Settings überschreiben willst, musst du das explizit dort angeben ("Überschreibe FPM-Daemon Einstellungen (pm, max_children, etc.)"). Siehe hierzu auch https://docs.froxlor.org/latest/admin-guide/php-versions-and-configuration/

Ganz schlechte Idee, allein schon wegen Berechtigungen (unterschiedliche User, openbase_dir, etc.), mach doch einfach eine globale RewriteRule oder so, wenn du auf jeder Kunden-Domain via /froxlor auf froxlor willst.
Froxlor erkennt, ob es mit "seiner" Domain aufgerufen wurde oder nicht (daher das "Domain not configured"). Das ist auch richtig so und sollte nicht umgangen werden, egal ob privat oder kommerziell.

Domains werden nicht automatisch mit aktualisiert (damit nichts break'd), die verwenden jetzt die bisher zugeordneten Konfigurationen, du musst sie manuell bearbeiten und die neue config auswählen.

Ist seit Jahren default, dass keine Klartextpasswörter gespeichert werden, die entsprechende Einstellung das zu ändern findest du unter Settings -> Security Settings -> Also save passwords of mail accounts unencrypted in database (die bei dir vermutlich aktiviert ist)
Natürlich ist das relevant, welche protokolle dem kunden erlaubt sind. Wenn accounts immer mit imap= und pop3=0 angelegt werden, hast du dem Kunden das wohl nicht erlaubt

https://github.com/froxlor/Froxlor/issues/new/choose - sonst geht sowas unter hier im forum

Müsst ich nachschauen obs da irgendwo ne race-condition gibt wenn der ssl-redirect nach let's encrypt noch aktiviert wird, wäre mir bisher jetzt noch nicht aufgefallen bei unseren systemen. Aber fürs erste, aktivier einfach mal beides gleichzeitig

das ist nur das "einmal konfigurieren" - hängt natürlich alles komplett von deinen einstellungen ab (so auch die doppelten slashes im pfad)
Die Setting heisst "Pfad zu"...er sollte also den Dateinnamen der benötigten Tools nicht enthalten, korrekt ist also:

Pfad zu AWStats 'awstats_buildstaticpages.pl': /usr/share/awstats/tools Pfad zu AWStats 'awstats.pl': /usr/lib/cgi-bin

das wird über sql aus der DB für jedes konto einzeln ausgelesen, das sind nur die "generellen fallback-einstellungen" - wenn du 100% sicher sein willst, re-konfiguriere dovecot mit den config-templates für debian bookworm. Läuft jedenfalls bei uns und vielen anderen auf zig VMs problemlos

Kurze Antwort: dem Kunden war IMAP nutzung nicht erlaubt

Nimm halt die von froxlor generierte "froxlor_settings.conf" aus der settings.conf von rspamd...ist halt blöd wenn deine User was einstellen und sich nix ändert

höchstwahrscheinlich ein zeitproblem, probiere mal folgende Änderung in der index.php:

 
diff --git a/index.php b/index.php index dd3f2673..2bedb9a8 100644 --- a/index.php +++ b/index.php @@ -84,7 +84,8 @@ if ($action == '2fa_entercode') { // verify code set to user's data_2fa field $sel_stmt = Database::prepare("SELECT `data_2fa` FROM " . $table . " WHERE `" . $field . "` = :uid"); $userinfo_code = Database::pexecute_first($sel_stmt, ['uid' => $uid]); - $result = $tfa->verifyCode($userinfo_code['data_2fa'], $code); + // 60sec discrepancy (possible slow email delivery) + $result = $tfa->verifyCode($userinfo_code['data_2fa'], $code, 60); } else { $result = $tfa->verifyCode($_SESSION['secret_2fa'], $code, 3); }  

Es ist einfach fix das die config mit ID=1 nicht gelöscht werden kann, das hat u.a. Fallback Gründe.
Es verbietet dir aber doch niemand diese fpm version anzupassen und eine der von dir eingesetzten PHP Versionen zu setzen (natürlich darf diese dann nicht schon existieren).

Steht alles in den announcements...froxlor hat mit 2.0 das homedir auf /var/www/html/froxlor geändert.
Wenn es nicht gerade Version 0.9 ist dann geht das problemlos 
Müsste man im Zweifel manuell schauen wo das Update hängengeblieben ist 

if you've updated via apt, just login and let the webui handle the database update. Alternatively, test the following fix:
diff --git a/lib/Froxlor/Cli/UpdateCommand.php b/lib/Froxlor/Cli/UpdateCommand.php index d7a255eb..bca38420 100644 --- a/lib/Froxlor/Cli/UpdateCommand.php +++ b/lib/Froxlor/Cli/UpdateCommand.php @@ -58,6 +58,7 @@ final class UpdateCommand extends CliCommand if ($input->getOption('database')) { $result = $this->validateRequirements($output, true); if ($result == self::SUCCESS) { + require Froxlor::getInstallDir() . '/lib/functions.php'; if (Froxlor::hasUpdates() || Froxlor::hasDbUpdates()) { $output->writeln('<info>' . lng('updates.dbupdate_required') . '</>'); if ($input->getOption('check-only')) {  

Die erste Config (id=1) kann nicht gelöscht werden (dient ggfls als Fallbackl). Du kannst die aber natürlich anpassen wie du möchtest, z.B. auf php8.3 setzen oder so

Aktuell handlet das froxlor nicht, denn Let's Encrypt auch in postfix/dovecot zu nutzen ist natürlich möglich, aber admin-Entscheidung - da hat froxlor keine Finger drin. Ändert sich mit 2.2, siehe https://github.com/froxlor/Froxlor/issues/1186

Du hast dem Kunden ein Kontingent von 5000 MB für disk/webspace zugewiesen....wenn es voll ist, macht der FTP dicht