Thank you; worked like a charm! I quoted your email in a comment for breadacrumb purposes. Stupid question: In Bugzilla, if a defect is essentially resolved by stated workaround, what is the appropriate resolution? None of the suboptions for "Resolved" seemed to match giving a workaround. On Thu, Jun 29, 2017 at 8:56 PM, Tim Young <Tim.Young@lightsys.org> wrote:

Hi,

This sounds like it is because of an odd "feature" of mysql which is not always present.

This page: https://askubuntu.com/questions/766334/cant-login-as-mysql- user-root-from-normal-user-account-in-ubuntu-16-04

with the answer from "Todor", explains that mysql will change over to using an auth_socket "plugin." So, instead of using password authentication, part of the permission is blocked by unix file-level permissions.

The simple solution:

sudo mysql -u root update mysql.user set plugin = 'mysql_native_password' where User='root'; FLUSH PRIVILEGES;

Then you should be able to connect up as root even if you are not a root user.

After that, you should be able to run the script.

- Tim

On 6/29/2017 10:10 AM, C.J.S. Hayward wrote:

...

I posted https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18852 and Katrin encouraged me to post to the list where it might get more attention.

My bug description, very lightly reformatted, is:

As of 17.05.01, I was told there were reports of successful installations. However, I have not been able to reproduce such.

I had earlier made a couple of attempts to add Koha to a multipurpose appliance, and that remains my end goal. However, when I tried to back up, I saw the same issue verbatim.

What I have done today was:

Download a fresh Linux Mint 18.1 ISO.

Build a VirtualBox VM with the ISO, with mostly default features and with third-party addons, and also enabling auto-login, but in general intended to be a plain vanilla install.

Rebooted; installed Chrome and touched /etc/sudoers, ran "aptitude update"; ran "aptitude upgrade", installed MariaDB, and rebooted again.

Followed the steps, including a couple of a2enmod enablings, and created a virtual site.

I was able to edit passwords in /etc/koha/.../koha-conf.xml, and enter the web setup wizard.

However, I experienced identical output from the installer: at a certain point, it says:

Software error:

DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: Access denied for user 'root'@'localhost' at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1492. at /usr/share/koha/lib/Koha/Database.pm line 100

For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error.

I am having difficulties with MariaDB and my difficulties may be contributing to the problem.

My understanding, as inherited from MySQL, is that "mysql -uroot -p", for any account that will run it, will check a password and, if you have root's password set, will let you into the MySQL root command line if and only if you type the password exactly.

The behavior I have observed is that as root "mysql -uroot" does not prompt for a password, but just logs you in, and "mysql -uroot -p" prompts for a password, but will accept any password, the empty password included. However, from an unprivileged account, "mysql -uroot -p" prompts for a password, but none of the passwords I've tried have worked; I've tried and used values as set in my customized koha-conf.xml, and every single password is rejected.

I believe that this command line behavior is a symptom of the same problem quoted above: permission is being denied for user 'root'@'localhost' where the action in question would be permitted for any account with UID 0 and no account with any other UID.

Again, this is after the 17.05.01 release, where it was reported to me that some people have had success. The system setup shows a couple of my personal idiosyncracies, but is meant to be awfully close to a procedure of "Step 1: Create a new Linux Mint VM. Step 2: Install Koha." The behavior is the same between the fresh new VM running 17.05.01, and an "everything but the kitchen sink" multitool of an appliance.

What can I do to let Koha talk to MariaDB as 'root'@'localhost'?

Thanks,

_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha

-- [image: Christos Jonathan Seth Hayward] <https://cjshayward.com/> *Christos Jonathan Seth Hayward <https://cjshayward.com/>*, an Orthodox Christian author (*main site <https://cjshayward.com/>* • *bookshelf <https://cjshayward.com/bookshelf/>*). If you'd like to just barely sample my writing, I invite you to read The Angelic Letters <https://CJSHayward.com/letters/> and Doxology <https://CJSHayward.com/doxology/>. I am seeking to reach Mount Athos to enter monastic repentance for the rest of my life: see GoFundMe.com/the-holy-mountain <https://gofundme.com/the-holy-mountain>

And, it is fairly unwise to have a blank root password on a production server. The rood user should actually only be used for administration. You should have a different mysql user for each database (one for wordpress, one for Koha, one for Moodle, etc.) I do not know if the issue below gets rectified if there is a root password, or what. But, if you do use a user other than root as your Koha mysql user, then it also solves the problem. And it is much more secure and better practice. And, as Fridolin Somers wrote, we should not be using root as the mysql user. His answer should be marked as the correct one. All my answer did was to allow you to set up an insecure setup, though it had the side-effect of getting your stuff working. That is what happens when you focus more on answering the question as-stated instead of giving the correct answer. (Thanks, Fridolin) So, the question is whether or not the Koha documentation (or the process you were following) specifies that you should use a user other than root. It might imply that, but it might be good to state that directly. "In some distros, the root user is also protected against being used unwisely by using plugins, thus encouraging the use of an alternate mysql user. While you can disable the plugin and allow root access by non-root users, it is still best practice to create a mysql user specifically for Koha." Something along those lines, and then having instructions for setting that information when koha is instantiated. It has been a bit since I did that last, but if I remember correctly, you need to put all that in the "alternate password" file? - Tim On 6/30/2017 8:32 AM, Fridolin SOMERS wrote:

You should not use MariaDB root user for Koha but create a dedicated user, usually kohaadmin. Indeed, MariaDB root user has no password, like system root user as no password in Linux Mint/Ubuntu

Regards,

Le 30/06/2017 à 13:22, C.J.S. Hayward a écrit :

...

Thank you; worked like a charm!

I quoted your email in a comment for breadacrumb purposes. Stupid question: In Bugzilla, if a defect is essentially resolved by stated workaround, what is the appropriate resolution? None of the suboptions for "Resolved" seemed to match giving a workaround.

On Thu, Jun 29, 2017 at 8:56 PM, Tim Young <Tim.Young@lightsys.org> wrote:

...

Hi,

This sounds like it is because of an odd "feature" of mysql which is not always present.

This page: https://askubuntu.com/questions/766334/cant-login-as-mysql- user-root-from-normal-user-account-in-ubuntu-16-04

with the answer from "Todor", explains that mysql will change over to using an auth_socket "plugin." So, instead of using password authentication, part of the permission is blocked by unix file-level permissions.

The simple solution:

sudo mysql -u root update mysql.user set plugin = 'mysql_native_password' where User='root'; FLUSH PRIVILEGES;

Then you should be able to connect up as root even if you are not a root user.

After that, you should be able to run the script.

- Tim

On 6/29/2017 10:10 AM, C.J.S. Hayward wrote:

...

I posted https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18852 and Katrin encouraged me to post to the list where it might get more attention.

My bug description, very lightly reformatted, is:

As of 17.05.01, I was told there were reports of successful installations. However, I have not been able to reproduce such.

I had earlier made a couple of attempts to add Koha to a multipurpose appliance, and that remains my end goal. However, when I tried to back up, I saw the same issue verbatim.

What I have done today was:

Download a fresh Linux Mint 18.1 ISO.

Build a VirtualBox VM with the ISO, with mostly default features and with third-party addons, and also enabling auto-login, but in general intended to be a plain vanilla install.

Rebooted; installed Chrome and touched /etc/sudoers, ran "aptitude update"; ran "aptitude upgrade", installed MariaDB, and rebooted again.

Followed the steps, including a couple of a2enmod enablings, and created a virtual site.

I was able to edit passwords in /etc/koha/.../koha-conf.xml, and enter the web setup wizard.

However, I experienced identical output from the installer: at a certain point, it says:

Software error:

DBIx::Class::Storage::DBI::catch {...} (): DBI Connection failed: Access denied for user 'root'@'localhost' at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1492. at /usr/share/koha/lib/Koha/Database.pm line 100

For help, please send mail to the webmaster ([no address given]), giving this error message and the time and date of the error.

I am having difficulties with MariaDB and my difficulties may be contributing to the problem.

My understanding, as inherited from MySQL, is that "mysql -uroot -p", for any account that will run it, will check a password and, if you have root's password set, will let you into the MySQL root command line if and only if you type the password exactly.

The behavior I have observed is that as root "mysql -uroot" does not prompt for a password, but just logs you in, and "mysql -uroot -p" prompts for a password, but will accept any password, the empty password included. However, from an unprivileged account, "mysql -uroot -p" prompts for a password, but none of the passwords I've tried have worked; I've tried and used values as set in my customized koha-conf.xml, and every single password is rejected.

I believe that this command line behavior is a symptom of the same problem quoted above: permission is being denied for user 'root'@'localhost' where the action in question would be permitted for any account with UID 0 and no account with any other UID.

Again, this is after the 17.05.01 release, where it was reported to me that some people have had success. The system setup shows a couple of my personal idiosyncracies, but is meant to be awfully close to a procedure of "Step 1: Create a new Linux Mint VM. Step 2: Install Koha." The behavior is the same between the fresh new VM running 17.05.01, and an "everything but the kitchen sink" multitool of an appliance.

What can I do to let Koha talk to MariaDB as 'root'@'localhost'?

Thanks,

_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha

I am moving our library to a new server with Ubuntu 16.04. Following the instructions at https://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_packages, I installed MariaDB instead of MySQL. When I run: sudo koha-create --create-db koha_library The result is: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO) I'd been wrestling with this problem for awhile before I got to this point because I got similar messages when trying to configure phpmyadmin. I can run "mysql -u root -p". However, just "mysql -u root" fails with the above message as well. Is there a way to tell koha-create to run using a password? Or am I missing something? I am hoping someone has a quick solution. Daniel