Summary: | koha-remove fails when dropping user | ||
---|---|---|---|
Product: | Koha | Reporter: | Magnus Enger <magnus> |
Component: | Installation and upgrade (command-line installer) | Assignee: | Robin Sheat <robin> |
Status: | REOPENED --- | QA Contact: | Bugs List <koha-bugs> |
Severity: | normal | ||
Priority: | P5 - low | CC: | rainer.stowasser, simon.story, tomascohen |
Version: | 20.05 | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16410 https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26306 |
||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Bug Depends on: | 6684 | ||
Bug Blocks: | 24383 |
Description
Magnus Enger
2011-05-27 10:07:40 UTC
I've had a confirmation of this. FWIW, the removal line is: DROP USER \`koha_$name\`; There is a comment here: http://dev.mysql.com/doc/refman/5.1/en/drop-user.html saying: As of 5.0.37, if the user does not exists, MySQL responds with: 'ERROR 1396 (HY000): Operation DROP USER failed for ...' There could be funny version things happening. Also: http://dev.mysql.com/doc/refman/5.1/en/account-names.html says that '%' is implied if not there, and is treated as a wildcard, so I'd expect it should work. I may have to do more testing at some stage. The '%' wildcard seems to match when mysql is checking the host the connection is being made, not when matching users to delete. I see in koha-create that 'koha_demo'@'localhost' shouldn't have been created. Since the code is: CREATE USER \`$mysqluser\`@'%' IDENTIFIED BY '$mysqlpwd' Perhaps Magnus you are mistaken as to the course of events? Observe the obtuseness of mysql: mysql> create user mysql_is_erratic; Query OK, 0 rows affected (0.00 sec) mysql> select User,Host from user where User like 'mysql_is_erratic'; +------------------+------+ | User | Host | +------------------+------+ | mysql_is_erratic | % | +------------------+------+ 1 row in set (0.00 sec) mysql> create user 'mysql_is_erratic'@''; Query OK, 0 rows affected (0.00 sec) mysql> create user 'mysql_is_erratic'@'localhost'; Query OK, 0 rows affected (0.00 sec) mysql> select User,Host from user where User like 'mysql_is_erratic'; +------------------+-----------+ | User | Host | +------------------+-----------+ | mysql_is_erratic | | | mysql_is_erratic | % | | mysql_is_erratic | localhost | +------------------+-----------+ 3 rows in set (0.00 sec) mysql> drop user 'mysql_is_erratic'; Query OK, 0 rows affected (0.00 sec) mysql> select User,Host from user where User like 'mysql_is_erratic'; +------------------+-----------+ | User | Host | +------------------+-----------+ | mysql_is_erratic | | | mysql_is_erratic | localhost | +------------------+-----------+ 2 rows in set (0.00 sec) mysql> drop user 'mysql_is_erratic'@''; Query OK, 0 rows affected (0.00 sec) mysql> drop user 'mysql_is_erratic'@'localhost'; Query OK, 0 rows affected (0.00 sec) mysql> select User,Host from user where User like 'mysql_is_erratic'; Empty set (0.00 sec) simons@simonskoha:~/src/koha/debian/scripts$ mysql --version mysql Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (x86_64) using readline 6.1 Is this still valid? (In reply to Magnus Enger from comment #0) > I have MySQL running on the same machine as Apache/Koha, and have created a > new library with "sudo koha-create --create-db demo". > > When i do "sudo koha-remove demo" I get this: > > Removing Koha instance demo > ERROR 1396 (HY000) at line 1: Operation DROP USER failed for 'koha_demo'@'%' I cannot reproduce this error in master, so I'm marking it fixed. with the upgrade to Koha 20.5 I had the same problem a Koha-dump (19.11) koha-restore (in 20.5) created a 'user'@'%' in the database that could not be dropped System Debian buster 10.3.22-MariaDB It seems to have something to do with the restore script MariaDB [information_schema]> select * from USER_PRIVILEGES; 'koha_bibzamg'@'localhost' | def | USAGE | NO 'koha_zabibli'@'%' | def | USAGE | NO the user bibzamg was created with koha-create the user koha_zabibli'@'%'with koha-restore (In reply to rainer.stowasser from comment #6) > It seems to have something to do with the restore script > > MariaDB [information_schema]> select * from USER_PRIVILEGES; > > 'koha_bibzamg'@'localhost' | def | USAGE | NO > > 'koha_zabibli'@'%' | def | USAGE | NO > > the user bibzamg was created with koha-create > the user koha_zabibli'@'%'with koha-restore (In reply to Simon Story from comment #2) > The '%' wildcard seems to match when mysql is checking the host the > connection is being made, not when matching users to delete. > > I see in koha-create that 'koha_demo'@'localhost' shouldn't have been > created. Since the code is: > CREATE USER \`$mysqluser\`@'%' IDENTIFIED BY '$mysqlpwd' > > Perhaps Magnus you are mistaken as to the course of events? This is current code (20.05's): mysql_hostname="localhost" # Set up MySQL database for this instance. if [ "$op" = create ] then if [ ! -e /etc/mysql/debian.cnf ]; then MYSQL_OPTIONS="-u root" echo "WARNING: The koha-common.cnf file is a dead soft link!" else MYSQL_OPTIONS="--defaults-extra-file=/etc/mysql/koha-common.cnf" fi mysql $MYSQL_OPTIONS <<eof CREATE DATABASE \`$mysqldb\`; CREATE USER \`$mysqluser\`@'$mysql_hostname' IDENTIFIED BY '$mysqlpwd'; GRANT ALL PRIVILEGES ON \`$mysqldb\`.* TO \`$mysqluser\`@'$mysql_hostname'; FLUSH PRIVILEGES; eof Did some tests installed 20.5 on jessie installed 19.11 on buster and the restore "problem" prevails adding a @localhost user "by hand" and everything works fine ... have not figured out why this is not a common problem checking the settings the "original" system of the dump is one that was steadily upgraded since 16.5 |