Resolved Question to Plesk Backups

[MartinT]

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

​

 

[scsa20]

I am not sure what you're trying to do other then something to do with backups. Are you trying to restore from a backup? Create a backup?

In either case, have you tried following this article to make sure a root user is created? https://support.plesk.com/hc/en-us/...ed-for-user-root-localhost-using-password-NO-

 

[MartinT]

Restore Admin Configuration. I think the admin@localhost in db is gone.

 

[Peter Debik]

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:

                  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.

 

[MartinT]

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.

 

[Peter Debik]

Just in case someone sees this thread when looking for a way to reset the databsae admin user or its password in the mysql table of the database, this would be the right KB article to turn to: https://support.plesk.com/hc/en-us/...-for-user-admin-localhost-using-password-YES-

 

[MartinT]

Be careful, my issue/trouble caused after follwing step by step that KB. I don't know why.

 

[mow]

Be careful, my issue/trouble caused after follwing step by step that KB. I don't know why.

Which steps did you follow?

 

[MartinT]

All the steps 1-12 for Password unkonwn, without interruption.

The result was

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

Then BIND broken, Nginx down, Networking down. Site unreachable, Plesk login not working.

And my Backup journey at the weekend.

 

[MartinT]

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.

 

[Peter Debik]

@MartinT your initial post indicates with the "using password: No" part that not all steps were done.

 

[MartinT]

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.

 

[trialotto]

@MartinT

This caught my eye :

The original intention was to delete some dead nginx entries in db. via CLI.

and the question is : why?

There is no need at all to mess with the database in order to do something with Nginx.

Kind regards....

 

[mow]

@MartinT your initial post indicates with the "using password: No" part that not all steps were done.

And the user 'root' indicates that KB might not be the way to fix it. 'admin' obviously works, otherwise the server wouldn't run.

 

[trialotto]

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.....

 

[MartinT]

It was starting with error massanges in the Webserver Configuration troubleshooter. The solution was explained here:

Blog

The Plesk Blog AllBusiness and industryEventsFeaturedFun and gamesGuidesLearningPartner NewsPartnersPeople ArticlesPlesk news and announcementsPodcast Season 1Podcast Season 2Podcast Season 3Podcast Season 4Product and technologySecurity alertsTips and easy-readingVarious WordPress 500 Internal...

www.plesk.com

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.

 

[MartinT]

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.

 

[MartinT]

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).

 

[trialotto]

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....