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.
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.
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 ?@? 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.
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 ?
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" root@host:/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.
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.
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.
