Search results

Did you check your config files and make sure you removed the innodb_force_recovery line as well?

What is the innodb_force_recovery level that allowed you to start mariadb? Your database is readonly with the innodb_force_recovery mode and you shouldn't try to write to it, it's only meant to create a dump if your backup is incomplete. Did you move back all the files to their original...

Since the file is .gz mariadb < zcat /var/lib/psa/dumps/mysql.pre-rdbms-upgrade.*.dump.gz

mv /var/lib/mysql /var/lib/mysql.bak apt install --reinstall mariadb-server mariadb < /var/lib/psa/dumps/mysql.pre-rdbms-upgrade.*.dump

You can run `mysqlcheck --all-databases` to see the corrupted tables, btw did you use the GUI updater? Because it does say it will create a dump in /var/lib/psa/dumps So look there as you may have a full dump preupgrade already, maybe fully purge mariadb and reimport the dump and run plesk...

You can exclude the failing tables (which are the corrupted ones) from the dump, you can exclude the whole 'apsc' database and ask plesk to repair it later or restore it from the daily dump of plesk (this db only contains some small info for prestashop installs). It does mean you will need to...

If you don't have a full backup and get it to start with the above config, dump everything with `mysqldump --all-databases > backup.sql`, remove the innodb_force_recovery config, stop mariadb, run ``` mv /var/lib/mysql/ibdata1 /var/lib/mysql/ibdata1.bak mv /var/lib/mysql/ib_logfile0...

Note that if you do this, you will be able to recover and start mariadb, but you won't have any data. You should restore it from the backup before the upgrade that you will find in /var/lib/psa/dumps/mysql.preupgrade.*.dump.gz (look up based on your version) There is ways to recover from this...

There is now a public key issue E: The repository 'Index of /repos/Kolab:/16/Ubuntu_20.04_Plesk_17 InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default.

Seems it is, the content is the let's encrypt CA.. But the CA also has it's own file where it's the only entry. Really no idea what's going on there

The certificate file contains multiple `-----BEGIN CERTIFICATE-----` in it.. The default certificate also contains two and one of them is shared between the two.. Is this normal?

Netstat looks something like this: There is 16 ips from docker (though there isn't that many containers) and even when docker is stopped those ips don't disappear and they are still listening. I wonder if this could be the cause of the issue

I have a similar issue where a subdomain starts randomly using the wrong certificate (it uses the plesk default certificate), but in the nginx config it's the correct certificate.. And when I mean randomly I mean randomly, if I resave the certificate it will sometimes resolve it, but then come...

Any good way to do that or configure plesk to use a smtp when doing that? Main issue is that by using the email of the admin directly in php, it doesn't DKIM sign the email or respect DMARC when sending and the email gets rejected

I concurr, this webmail didn't receive any update in 7 years GitHub - horde/webmail: Horde Groupware Webmail Edition It has more than 11 serious and unfixed published CVE's CVE - Search Results Do not use it under any circumstance. Plesk should remove it from it's offering or fork it...

The fact that this can just start happening by itself on autoupgrade is a huge security vulnerability Users can download all the sensitive files once apache is in this broken state including .env, wp-config.php

Guys, you just need to go into "Service plan > Unlimited > PHP settings" change it there and sync

I found a solution after digging through the inner workings of the plesk apache and nginx config It's pretty straightforward, configure your nodejs application like it was your main app, enable php Thrn in the Web hosting settings of Apache, for https add this (replace yourpath_to_wp_dir and...

In your case you need to use a supervisor to keep the node process running as a service. As it doesn't seem you want to handle a public path on the node server correct?

I guess we can just add `collections_remove_stale` to the ignoreregex