Seconday server ispc update (mysql user question)

Discussion in 'Installation/Configuration' started by Chris_UK, Jul 24, 2021.

  1. Chris_UK

    Chris_UK Active Member HowtoForge Supporter

    Okay this might seem like a strange question but I seem to have just had a really weird experience in updating one of my servers.

    Upgrade 3.2.5
    I completed the primary servers root access details and this user has sufficient privileges as expected. However as soon as i hit the reconfigure mysql in the primary server part of the update i was bombarded with a load of no grant option messages.

    So my question is this, does this part of the update use the primary servers remote root user or does it switch over to the secondary servers remote ispcsrv user.
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    The primary server's root user for this ip/hostname is used to update the privileges of the ispcsrv* users. if you received grant errors, then the root for this ip/hostname user lacks grant privileges.
     
  3. Chris_UK

    Chris_UK Active Member HowtoForge Supporter

    Something seemed really off so here is what I did.

    Added user
    ispcsrv<number> @ % with grant
    result, no change so I will shortly be removing this.

    Updated the ip address in the master user table (it was using an old ip address)
    result, upgrade and permissions succeeded.

    I guess the problem here was actually that the user with the ip host that the upgrade attempted to reconfigure didn't exist because of the old user configs. However that was not what the warnings stated. Here is an excerpt from the failed upgrade.
    Code:
    WARNING: Unable to set rights of user in master database: dbispconfig
     Query: GRANT SELECT ON ?? TO [email protected]?
     Error:
    
    Looking at this now and knowing there was no user to modify the message actually makes a little sense but without that knowledge it appears to be telling you that the root user lacks sufficient privileges to complete the task, obviously not the case.

    I wonder if a user exists check may be added into the upgrade procedure with a more useful warning.
    A simple warning like, ispcsrv* user in primary database appears to be missing would point us in the right direction if this ever occurred. That said this is the reconfig section, if the check fails you could simply drop any existing users for the instance and generate new ones eliminating the issue entirely.

    Anyway, this is resolved and I hope this helps somebody in the future. Bottom line if you move a server or give it a new ip then you had better remember to change the ispcsrv user in the primary database.
     
    Last edited: Jul 24, 2021
    ahrasis likes this.
  4. YbeddyJ

    YbeddyJ New Member

    I am having a similar problem except with a fresh install.

    Is Till suggesting that the root user on the primary server is missing the grant privileges?
    on the primary server I'm seeing these errors in the mysql error log "[Warning] Access denied for user 'ispcsrv0'@'x.x.x.x' (using password: YES)".

    What are you suggesting to be done in this scenario @till ?
     
  5. YbeddyJ

    YbeddyJ New Member

    I think I might have fixed my issue.
    on the primary I did the following
    Mysql GRANT ALL PRIVILEGES on dbispconfig.* to 'ispcsrv0'@'X.X.X.X' identified by 'HASH' with grant option; flush privileges;

    I got the information for the DBuser from "/usr/local/ispconfig/interface/lib/config.inc.php" on the secondary server.
    //** Database settings for the master DB. This setting is only used in multiserver setups
    $conf['dbmaster_user'] = 'ispcsrv0';
    $conf['dbmaster_password'] = 'HASH';
    I then do the following on the secondary server
    ispconfig3_install/install# php -q update.php --force

    MySQL master server database name [dbispconfig]:

    Checking ISPConfig database .. OK
    Unable to read server configuration from database. <-------------------- I got this ERROR

    I tested the interface but clearly things didn't work
    SO I did this on the secondary

    rm -rf /usr/local/ispconfig/
    rm -f /usr/local/bin/ispconfig*
    Mysql "drop database dbispconfig"
    [email protected]:/tmp/ispconfig3_install/install# php -q install.php
    Installation completed without any errors this time around despite the DBuser information changing in the new install.

    I'm not seeing the DNS entries replicated on the secondary server but I'll keep checking.
     
  6. till

    till Super Moderator Staff Member ISPConfig Developer

    Really bad idea, you opened up a bunch of potential security holes, this must be undone as it is not needed at all. ispcsrv* users may never have grant option and they may never have permissions to all tables. You just allowed a hacker to take over your master server and all other slave systems if he gets access to one slave system.

    ispcsrv* user errors typically happen when you did not set up server hostnames properly before you install ISPConfig. See multiserver installation guides for proper setup of hostnames and the /etc/hosts files on all nodes.
     
  7. YbeddyJ

    YbeddyJ New Member

    I did remove those privileges later on.
    The hostnames were actually properly setup.
    I've actually done these in the past and they worked first go. Not sure what with this later version.
    I've noted too that whereas in earlier versions I could go to the server option on the secondary servers and select to be a mirror of the other servers and would be able to also use the resync tool to get both systems synchronized but now those dont seem to work.
    I have a feeling something still didnt get settled properly.
     

Share This Page