d00p

Das einzige was ich mir vorstellen kann an Änderung die dieses verhalten hervorruft ist diese: https://github.com/froxlor/Froxlor/commit/e06db3d8c5921d2ffdba61fd91eb1ebce8cadba4 Eventuell mal einzeln testen und die entsprechende `Cronjob::inserttask(TaskId::REBUILD_VHOST);` Zeile löschen und sehen ob das Problem weiterhin besteht. Ich kann es leider nicht reproduzieren auf der aktuellen 2.1.8 - ohne zusätzliche info was ggfls eingestellt/geändert wurde und in welchem state sich da alles bei dir befindet kann ich da auch wenig zu sagen

So you already did the web-installation process? And you did specify "dicetales.de" as system fqdn? At the end of the installation, you are prompted a shell command which you have to run as root on your server, did you do that? If everything went through, you just have to visit http://dicetales.de (if that is your froxlor system fqdn) - if not, you might want to check the output of the command you had to run whether there were any issues

DiceTales is a hostname, not a full qualified domain name, that would be "DiceTales.de" (hostname + Tld). Regarding installation, you will have to specify a Full qualified domain name - but of course you cannot just use any domain, you have to own it and the DNS entries need to point to your server. So, if you so not own the domain DiceTales.de you cannot use it

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

Thread from 2022....also, it will be in 2.2 (current git main branch)

https://docs.froxlor.org/latest/admin-guide/cli-scripts/

Einfach Mal Manuell mit --force --debug den Cron laufen lassen und Schauen ob alles ok ist....hab hier bei fast 100 Installation absolut keine Probleme

Einstellungen -> Froxlor Vhost Einstellungen -> Let's Encrypt: nein dann: bin/froxlor-cli froxlor:cron -fd und dann das ganze nur mit Let's Encrypt : ja

let's encrypt deaktivieren, cron laufen lassen, wieder aktivieren, cron laufen lassen

dann lösch doch einfach alle froxlor-generierten vhosts in /etc/apache2/sites-enabled/*froxlor* - und rufe http://{ip}/froxlor auf ...

Wieso sollte die froxlor-webui nicht funktionieren? FQDN würd ich vor dem Umzug in den einstellungen schon ändern, dann die DB und lib/userdata.inc.php migrieren auf den neuen und danach bin/froxlor-cli froxlor:switch-server-ip (siehe https://docs.froxlor.org/latest/admin-guide/cli-scripts/#switch-server-ip) und anschließen einmal die configs neugenerieren: bin/froxlor-cli froxlor:cron -fd und durch biste

Froxlor uses almost nothing. You should rather check for Webserver, Database, etc. Requirements - froxlor in that regard is the least of the "problems"

Well if a Webserver, Database and php is running on it then yes. It's such a bunch of php files, architecture has not really anything to do with it

That's already in 2.2-dev...current main-branch.

You may also switch the update channel to nightly to test/try it now in the current testing version

Wait for v2.2 in the summer, we'll integrate rspamd with a better dkim implementation. The current one is very old and not easy to use (and not without DNS enabled)

Well then you indeed have too many redirects....check a potential .htaccess file or the target page. A redirect is VERY basic, it just tells the client to go to the other page. Most likely the other page redirects back or does a reedirect to itself. You can find out by using `curl` on the shell and inspect the headers (Location: http://TARGET) and then follow these targets and you will see that there is a redirect back to where it came from at some point

There is indeed a bug with this, missing csrf-tokens in some ajax-requests, I will have to make a bugfix release for that (or you would have to build the assets yourself with npm etc. if you want, let me know). Most like on friday this week then

Oh yeah there seems to be an issue with a ajax-request to for this option, need a bit more time for that

This is a per domain setting and should be stored permanently of course. Let me run some checks and get back to you

try the following patch: diff --git a/lib/Froxlor/Cron/Http/Apache.php b/lib/Froxlor/Cron/Http/Apache.php index f3fe3f6b..609f9164 100644 --- a/lib/Froxlor/Cron/Http/Apache.php +++ b/lib/Froxlor/Cron/Http/Apache.php @@ -823,6 +823,7 @@ class Apache extends HttpConfigBase $modrew_red = ' [R=' . $code . ';L,NE]'; } + $vhost_content .= $this->getLogfiles($domain); // redirect everything, not only root-directory, #541 $vhost_content .= ' <IfModule mod_rewrite.c>' . "\n"; $vhost_content .= ' RewriteEngine On' . "\n";

Yup, just checked, there are no log-directives generated when the domain is a redirect

check the vhost, is there a "AccessLog" directive being generated? if yes, does the log file exist and do entries get logged on visit?

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

Are you using the latest v2.1.7? there was a fix: https://github.com/Froxlor/Froxlor/commit/537b274b4c50b6d5a28c140d48e955466173b7dc