• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Resolved Question to Plesk Backups

MartinT

Basic Pleskian
Server operating system version
Debian 10.13 Buster
Plesk version and microupdate number
Plesk Obsidian Version 18.0.51
Hi,

I got some Problems with the Plesk DB.

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

I followed the intructions at https://support.plesk.com/hc/en-us/articles/12377966359319

and now it is

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: No)

So I thought to Dump and Plesk Backup form August, I sure there everything was fine and Backup just the Server configuration and Admin configuration, not anything about the subscriptions and domain-files.
Backup entire System just the checkboxes
Server settings
Administrator account configuration
and if needed License key

Could this work and solve the problems?

By following the instructions to solve the "access denied" at the the server gave back the db answers blabla executed. 0 lines affected. I guess the admin there is no line admin@localhost somwhow, it is gone and I guess that's the problem, why I want configuration etc form the old Backup.

OS Debian 10.13
Product Plesk Obsidian
Version 18.0.51 Update #1, last updated on April 10, 2023 11:10 PM

 
Please first check if the "admin" user is really gone. Why should anything delete that user dataset but leave others active?

# plesk db
> use mysql;
> select * from user where User LIKE 'admin'\G

should normally yield this output:

Code:
                  Host: localhost
                  User: admin
              Password: *<password hash shows here>
           Select_priv: Y
           Insert_priv: Y
           Update_priv: Y
           Delete_priv: Y
           Create_priv: Y
             Drop_priv: Y
           Reload_priv: Y
         Shutdown_priv: Y
          Process_priv: Y
             File_priv: Y
            Grant_priv: Y
       References_priv: Y
            Index_priv: Y
            Alter_priv: Y
          Show_db_priv: Y
            Super_priv: Y
 Create_tmp_table_priv: Y
      Lock_tables_priv: Y
          Execute_priv: Y
       Repl_slave_priv: Y
      Repl_client_priv: Y
      Create_view_priv: Y
        Show_view_priv: Y
   Create_routine_priv: Y
    Alter_routine_priv: Y
      Create_user_priv: Y
            Event_priv: Y
          Trigger_priv: Y
Create_tablespace_priv: Y
   Delete_history_priv: Y
              ssl_type:
            ssl_cipher:
           x509_issuer:
          x509_subject:
         max_questions: 0
           max_updates: 0
       max_connections: 0
  max_user_connections: 0
                plugin: mysql_native_password
 authentication_string: *<auth string shows here>
      password_expired: N
               is_role: N
          default_role:

If the dataset is missing, you can insert it using SQL insert syntax.
 
Checked, dataset is there. Good one ponit done others to go. I'll try out later not today. I'm glad the server runs so far and domains are all reachable.
 
Did not started a second tryout so far.

Maybe somewhen at night with some time with some time buffer to do most of a Backup, so I could reduce time of possible unreachable Domains and sites.
 
Oh your looking for Flushing and stopping at point 9 or so. So far I did all im a row, that's why I'm a bit affraid do do again. So far the server runs, and I will take a bit of time the redo it. The original intention was to delete some dead nginx entries in db. via CLI. As I read in the plesk solution it is something not really hurting the plesk system, just an error message. I wanted to clean up and get this mess. Maybe I did one step wrong. But in moment let it run.
 
And the user 'root' indicates that KB might not be the way to fix it. 'admin' obviously works, otherwise the server wouldn't run.

@MartinT

As a result of the post of @mow, I have another question : are you perhaps using PhPMyadmin to make changes to the database?!??

In essence, if the server runs (properly or not so properly), then admin@localhost (and root@localhost) are working and admin should be specificied in the DB, as has been described by @Peter Debik in his previous post.

If the server does not run properly and the admin@localhost is specified (properly) in the DB, then you can have a look at socket related issues : in most cases, one can stop and start the MySQL server (read: not restart, but stop-wait-start sequence).

If the socket file in /var/run/mysqld/mysqld.sock is still present after stopping the MySQL server, then there is a socket related issue ......

If there is no socket related issue and the server does not run properly and admin@localhost is specified (properly) in the DB, then you certainly have messed up the database in such a fashion that ........... we either need more information OR you are best of by creating a fresh installation of Plesk (always a good option!).

As a final remark, please note that you are mentioning all kinds of "external" factors, like "BIND broken, Nginx down, Networking down. Site unreachable" and that can also boil down to a simple explanation : connectivity issues related to network cards, hosting provider related issues, DNS related issues etc.

In summary, there is a nexus of issues that cannot be resolved if you do not tackle the problem systematically and if you do not provide sufficient information that allows Plesk Staff or Plesk Experts to help you.

Kind regards.....
 
It was starting with error massanges in the Webserver Configuration troubleshooter. The solution was explained here:
At step 2 it gave me this Access dined fpr admin @localhost Password Yes. then I got the solution do this with taht 12 steps and my journey begun.

I only wanted to clean up.
 
And now I'm aware of doiing again to get the issue again. Except that error messanges the server and everthing else doing fine. I normally do nothing at the DB of plesk. Only if I have to following any instructions of a plesk solution. Maybe I did something wrong last weekend.

And thanks for all advices and help. When I redo it and succeed I will comment here.
 
So as I promised. I did a redo. This time it went through without any issues. The only thing I changed was to connect via cable instead WLAN. So my educated guess is that in april the WLAN connection was intererupted at the critical stage of the DB work (where the flush of the user and the new implementation has to be done).
 
So as I promised. I did a redo. This time it went through without any issues. The only thing I changed was to connect via cable instead WLAN. So my educated guess is that in april the WLAN connection was intererupted at the critical stage of the DB work (where the flush of the user and the new implementation has to be done).

@MartinT,

I am pretty sure that the "educated guess" is not correct, in the sense that there have been (micro) updates to Plesk that deal with these particular situations.

Nevertheless, it does not matter anymore, since you have succeeded!

Kind regards....
 
Back
Top