KB Article #181235

API Portal upgrade issue: [ERROR] Can't upgrade apiportal-7.7.20200730-1.x86_64.rpm!

Problem

Updating API Portal 7.7.00400105 to 77 July is prevented with:

[ERROR] Can't upgrade apiportal-7.7.20200730-1.x86_64.rpm!

API Portal upgrade failed!

[ERROR] - An error occured while upgrading apiportal-t3-7.7.20200730-1.x86_64.rpm.

[ERROR] - An error occured while upgrading apiportal-purityiii-7.7.20200730-1.x86_64.rpm.

[ERROR] - An error occured while upgrading apiportal-easydiscuss-7.7.20200730-1.x86_64.rpm.

[ERROR] - An error occured while upgrading apiportal-easyblog-7.7.20200730-1.x86_64.rpm.

[ERROR] - An error occured while upgrading apiportal-allvideos-7.7.20200730-1.x86_64.rpm.

[ERROR] - An error occured while upgrading apiportal-7.7.20200730-1.x86_64.rpm


Resolution

Troubleshooting done on DEBUG level showed that the apiportal user in the mysql db had multiple entries:

mysql> show grants for 'apiportal'@'host.one.server.com';

+----------------------------------------------------------------------------------------------+

| Grants for apiportal@host.one.server.com |

+----------------------------------------------------------------------------------------------+

| GRANT USAGE ON *.* TO 'apiportal'@'host.one.server.com' |

| GRANT ALL PRIVILEGES ON `apiportal`.* TO 'apiportal'@'host.one.server.com' WITH GRANT OPTION |

| GRANT ALL PRIVILEGES ON `apiportal`.* TO 'apiportal'@'%' WITH GRANT OPTION |

+----------------------------------------------------------------------------------------------+

The presence of those lines prevented the upgrade to complete

'USAGE' privilege for a user means that user cannot create triggers and stored procedures required by the upgrade (this has been seen in DEBUG)


The solution is:

- (for testing purposes) it has been created a test user with all privileges:


CREATE USER 'test'@'%' IDENTIFIED BY 'password';

GRANT ALL PRIVILEGES ON *.* TO 'test'@'%' IDENTIFIED BY 'password' ;


- this user has completed well the upgrade

- the current db user has been adjusted by removing the un-necessary lines in the mysql db


When everything was ready, the user grants showed one single line:

GRANT ALL PRIVILEGES ON *.* TO 'apiportal'@'%' IDENTIFIED BY PASSWORD 'yourpasswordhere'

Thus, the update script was successful.


3 observations:

- the presence of 2 or many lines in the mysql privileges table may be caused by the tools (i.e. wamp) which create users that default keep the old user with the old privileges;

- 'USAGE' rights for a mysql user means the user is created, it exists, but it has no rights at the table level.

https://dev.mysql.com/doc/refman/8.0/en/privileges...

"This privilege specifier stands for “no privileges.” It is used at the global level with GRANT to specify clauses such as WITH GRANT OPTION without naming specific account privileges in the privilege list. SHOW GRANTS displays USAGE to indicate that an account has no privileges at a privilege level."

- "--skip-name-resolve' used in mysql config file for start or in the command line used to start the engine

https://dev.mysql.com/doc/refman/5.6/en/server-sys...

prevents your 'REVOKE' when try to run something like:

REVOKE USAGE ON *.* FROM 'apiportal'@'host.one.server.com';



Note:

This API Portal installation link may guide you with Mysql commands to create users:

https://docs.axway.com/bundle/axway-open-docs/page...