Tealk

sehr interessant, ich habe jetzt mariadb neu installiert, dann zuerst das kennwort geändert dann de server gestoppt und die daten kopiert und nach dem start klappt es jetzt

Die Datei hatte ich davor noch nie offen, daher ist mir das gerade nur aufgefallen vor der migration hatte ich das problem mit dem befehl nicht, da konnte ich per root alles machen werd wohl den mariadb server nochmal purgen und dann wohl mit dumps arbeiten müssen. also hab schon 3 Server auf Container umgezogen ganz ohne Probleme. Der größte unterschied ist halt wie auf die Systemressourcen zugegriffen wird, das sollte ja die db nicht stören.

hmm den user sehe ich jedenfalls nirgends in der config debian.cnf alter server # Automatically generated for Debian scripts. DO NOT TOUCH! [client] host = localhost user = root password = socket = /var/run/mysqld/mysqld.sock [mysql_upgrade] host = localhost user = root password = socket = /var/run/mysqld/mysqld.sock basedir = /usr debian.cnf neuer server; backup der config dateien # THIS FILE IS OBSOLETE. STOP USING IT IF POSSIBLE. # This file exists only for backwards compatibility for # tools that run '--defaults-file=/etc/mysql/debian.cnf' # and have root level access to the local filesystem. # With those permissions one can run 'mariadb' directly # anyway thanks to unix socket authentication and hence # this file is useless. See package README for more info. [client] host = localhost user = root [mysql_upgrade] host = localhost user = root # THIS FILE WILL BE REMOVED IN A FUTURE DEBIAN RELEASE.

Also folgendes habe ich übertragen auf den neuen Server rsync -avz /var/lib/mysql/ rsync -avz /etc/mysql mit a sollte ja alles 1:1 übergeben werden ja mariadb hab ich davor gestoppt das interessante ist das das wohl nicht auf alle datenbanken und user zutrifft; die froxlor db funktioniert problemlos z.B. ja kennwörter sind alle gleich, ziehe eigentlich nur von einer vm in einen container um; das backup im container kann einzelne dateien wiederherstellen.

ich komm grad nicht drauf warum das mi dem db umzug nicht klappen will A database error occurred SQLSTATE[HY000] [1045] Access denied for user 'root'@'127.0.0.1' (using password: YES) auchwenn ich mich per root in der konsole anmelde habe ich keine rechte select User,host,plugin from mysql.user; ERROR 1356 (HY000): View 'mysql.user' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them jemand ne idee?

bei mir zeigt froxlor aber leider nicht die „alten“ werte an; also kunden, domains, zertifikate, etc fehlt alles im webinterface //Edit Oh ok anscheinend ein Cache Problem.

static soll angeblich ja noch ein wenig mehr Leistung rausholen, also subjektiv konnte ich das jetzt nicht feststellen Was mir bei Ondemand aufgefallen ist, der erste Aufruf einer Seite dauert immer sehr lange. Ist das normal? Weil wenn ich das richtig verstanden habe muss der doch nur den vorhandenen Prozess klonen?

nutzt du auch static oder nur dynamic sonst?

ich habe jetzt noch nie eine software gesehen die diese angaben vorgibt, also für jede domain eine eigene php-fpm config? hab mir überlegt die standart einstellung für alle auf ondemand zu stellen, dann für lastintensiveres auf dynamic oder gar static

Hi, ich wollt mal fragen wie ihr die Einstellung angeht. Stellt ihr das global für alle ein oder für jede PHP-Konfiguration einzeln? Und wie errechnet/entscheidet ihr über dei Werte?

Hi, muss ich bei Froxlor eine eigene Domain erstellen wenn von der subdomain www. auf ohne sudomain weiterleiten möchte? Oder übersehe ich eine Option?

Like I said I have to give the user executive permissions. Why don't I know and currently don't know where to start investigating.

With the following file: /etc/cron.d/froxlor # automatically generated cron-configuration by froxlor # do not manually edit this file as it will be re-generated periodically. PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # */5 * * * * root /usr/bin/nice -n 5 /usr/bin/php7.2 -q /var/www/froxlor//scripts/froxlor_master_cronjob.php --tasks 1> /dev/null 0 0 * * * root /usr/bin/nice -n 5 /usr/bin/php7.2 -q /var/www/froxlor//scripts/froxlor_master_cronjob.php --traffic 1> /dev/null 5 0 * * * root /usr/bin/nice -n 5 /usr/bin/php7.2 -q /var/www/froxlor//scripts/froxlor_master_cronjob.php --usage_report 1> /dev/null 0 */6 * * * root /usr/bin/nice -n 5 /usr/bin/php7.2 -q /var/www/froxlor//scripts/froxlor_master_cronjob.php --mailboxsize 1> /dev/null */5 * * * * root /usr/bin/nice -n 5 /usr/bin/php7.2 -q /var/www/froxlor//scripts/froxlor_master_cronjob.php --letsencrypt 1> /dev/null 10 0 * * * root /usr/bin/nice -n 5 /usr/bin/php7.2 -q /var/www/froxlor//scripts/froxlor_master_cronjob.php --backup 1> /dev/null

I raised froxlor to 0.10 before the Debian update. Renamed the old folder and restored the config file. Since then I haven't changed anything in the settings. After the Debian Update I have removed old cipher and noticed that the cron doesn't work anymore. When I make the file "froxlor_master_cronjob.php" executable it runs as usual again. I had installed Froxlor before as a package, that was uninstalled during the update of Debian.

ok interesting, only since I made it executable the crons works again.

In the package "froxlor-0.10.0-rc2.tar.gz" the "froxlor_master_cronjob.php" is not executable. Couldn't this be stored in tar.gz? I only came across it because I had to update it manually and the crons didn't run through.

ok then we leave that as unresolved

I believe you already. But where does it come from if I didn't execute anything? that wasn't even possible because the problem occurred in the middle of the update process.

i had it installed before as a package can there be a problem when the package was uninstalled and i uploaded the data via ftp?

but then that would have to been done automatically.

No I diddn't

I just upgraded my main system to buster and an error occurred with "bind". In the "named.conf.local" the include of Froxlor was included twice. // // Do any local configuration here // // Consider adding the 1918 zones here, if they are not used in your // organization //include "/etc/bind/zones.rfc1918"; include "/etc/bind/froxlor_bind.conf"; include "/etc/bind/froxlor_bind.conf";

So there were no problems with the update (Debian 9) I could also create and edit subdomains as well as delete them. 2FA also works I also installed it on a test server without any problems. (Debian 10) On the server I'm still testing

Are there any points I can test? After that, your pages went back?