Re: [Koha] Difficulties getting 17.05.01 to talk with MariaDB under Mint 18.1

[Pablo Bianchi]

2017-06-29 14:56 GMT-03:00 Tim Young :

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


If I  plugin='mysql_native_password'  (Todor answer
) I could get rid of those
[Warning] 'user' entry 'root@localhost' has both a password and an
authentication plugin specified. The password will be ignored.
when `sudo systemctl status mysql.service`. But have a side-effect:
  $ sudo koha-remove library
  Removing Koha instance library
  ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
password: NO)
So I move back to plugin='unix_socket' and koha-remove now works fine.
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Difficulties getting 17.05.01 to talk with MariaDB under Mint 18.1

[Tim Young]

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  
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 

Re: [Koha] Difficulties getting 17.05.01 to talk with MariaDB under Mint 18.1

[Fridolin SOMERS]

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  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







--
Fridolin SOMERS
Biblibre - Pôles support et système
fridolin.som...@biblibre.com
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [Koha] Difficulties getting 17.05.01 to talk with MariaDB under Mint 18.1

[C.J.S. Hayward]

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  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]  *Christos
Jonathan Seth Hayward *, an Orthodox Christian
author (*main site * • *bookshelf
*).

If you'd like to just barely sample my writing, I invite you to read The

Re: [Koha] Difficulties getting 17.05.01 to talk with MariaDB under Mint 18.1

[Tim Young]

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

Re: [Koha] Difficulties getting 17.05.01 to talk with MariaDB under Mint 18.1

[Lamb Joseph]

I have successfully used ubuntu server 16.04 and mariadb and installed Koha 
following the wiki:Koha on ubuntu - packages - Koha Wiki


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Koha on ubuntu - packages - Koha Wiki


 |

 |

 |

×   




Joseph Lamb


On Thursday, June 29, 2017, 8:11:20 AM PDT, 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,

-- 
[image: Christos Jonathan Seth Hayward]  *Christos
Jonathan Seth Hayward *, an Orthodox Christian
author (*main site * • *bookshelf
*).

If you'd like to just barely sample my writing, I invite you to read The
Angelic Letters  and Doxology
.

I am seeking to reach Mount Athos to enter monastic repentance for the rest
of my life: see
GoFundMe.com/the-holy-mountain 
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha

[Koha] Difficulties getting 17.05.01 to talk with MariaDB under Mint 18.1

[C.J.S. Hayward]

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,

-- 
[image: Christos Jonathan Seth Hayward]  *Christos
Jonathan Seth Hayward *, an Orthodox Christian
author (*main site * • *bookshelf
*).

If you'd like to just barely sample my writing, I invite you to read The
Angelic Letters  and Doxology
.

I am seeking to reach Mount Athos to enter monastic repentance for the rest
of my life: see
GoFundMe.com/the-holy-mountain 
___
Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
https://lists.katipo.co.nz/mailman/listinfo/koha