glpi-9.1.6-1.mga7 uploaded for Cauldron by Guillaume.

Whiteboard: MGA6TOO => (none)
Version: Cauldron => 6

9.1.6 pushed in mga6 updates_testing ( using guillaume cauldron's commit )
src.rpm:  glpi-9.1.6-1.mga6

Assignee: guillomovitch => qa-bugs
CC: (none) => mageia

Advisory:
========================

Updated glpi package fixes security vulnerabilities:

The glpi package has been updated to version 9.1.6, which fixes several
security issues and other bugs.  See the upstream release announcements for
details.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11183
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11184
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11329
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11474
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11475
http://glpi-project.org/spip.php?page=annonce&id_breve=370&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=373&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=376&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=378&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=379&lang=en
========================

Updated packages in core/updates_testing:
========================
glpi-9.1.6-1.mga6

from glpi-9.1.6-1.mga6.src.rpm

MGA6-32 on Asus A6000VM MATE
No installation issues.
Found tutorial at http://www.supinfo.com/articles/single/95-tutoriel-installation-glpi
But I run into a mysql issue
# mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 3
Server version: 10.1.25-MariaDB Mageia MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database dbbglpi character set utf8;
Query OK, 1 row affected (0.28 sec)

MariaDB [(none)]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

I tried
MariaDB [(none)]> uninstall plugin validate_password;
ERROR 1305 (42000): PLUGIN validate_password does not exist
MariaDB [(none)]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements

No time anymore today to investgate this further. Come and see later.

CC: (none) => herman.viaene

To get around the mysql validation problem I had to comment out the line
plugin-load-add=cracklib_password_check.so
in /etc/my.cnf.d/cracklib_password_check.cnf and the restart mysqld
Then pointing Firefox to localhost/glpi just draws a blank screen. I found an error in /var/log/httpd/error_log :
[Wed Aug 02 10:26:08.045403 2017] [:error] [pid 4043] [client ::1:48288] PHP Fatal error:  require_once(): Failed opening required '/usr/share/php/ezc/Base/autoloader.php' (include_path='.:/usr/lib/php/:/usr/share/pear/:/usr/share/php/') in /usr/share/php/ezc/Graph/autoloader.php on line 138
Checked and of course /usr/share/php/ezc/Base/autoloader.php does not exist, but there was a file base_autoload.php.
I took a chance and copied that file in /usr/share/php/ezc/Base/ and named it autoloader.php.
Then pointing Firefox to localhost/glpi brings me to http://localhost/glpi/install/install.php and gives me the glpi starting screen where to select the language. But after clicking "OK" I get "No connection" and var/log/glpi is empty.
Giving up on it. Maybe someone can shad some light onthis php issue.

Fedora has issued an advisory for glpi 9.1.6 on August 2:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/CL44XMRTDZRRPNINXWREOTMEJ3HERUD7/

Congratulations on the detective work Herman and kudos for experimenting.

I am trying to get this working on mga6::x86_64 but have not got very far.
Managed to get past the password hurdle using your tip about commenting out the cracklib_password_check line.

I found the tutorial very confusing.  Could not figure out if everything had to be done as root.  Do you have to create this user www-data?  I guessed not and assigned ownership of /var/www/glpi/ to myself lcl:lcl.  Pointing firefox to http://localhost/glpi raised an "Object not found!" message and there was nothing corresponding to your error in the error_log.  /usr/share/php/ezc/ does not exist.  In fact /usr/share/php/ is empty.  /var/www/glpi/ is empty because the instruction to download the glpi tarball resulted in Connection timed out and a series of retries.

Went back a bit and reassigned access rights to /var/www/glpi to root.  And there it stands.  Where to go from here?

CC: (none) => tarazed25

Checking the prerequisites I saw that php was missing.  Installed php-cgi and php-suhosin but that made no difference.  Error 404 again.

www-data is a Debian user.  The package already contains the files, so it shouldn't be downloading the tarball.  You shouldn't be changing the ownership of the files in the package.

Check /etc/httpd/conf/sites.d/glpi.conf for the Alias to see what the URL should be and where the files are stored (it looks like they're in /usr/share/glpi).

Thanks David for the pointer.  I really am so far out of my depth here that I was going to chuck it in.

I am still unclear about who the operator is in all this; is it me, is it root, or  ....?

I don't know anything about glpi, but hopefully it's like any other webapp where you make a database and visit the URL through localhost.  It looks like the URL is /glpi from what Herman said, but it also looks like there may be a packaging issue.

CC'ing the packager, Guillaume, since he forgot to CC himself when assigning to QA.

CC: (none) => guillomovitch
Whiteboard: (none) => feedback

Len, BTW I'm not sure what you mean by operator.

Who is regarded as the user?  Who should be given access to glpi?
I know virtually nothing about databases and web interfaces.

I tried this:
And yes, I did wonder what the tarball might contain that was not already installed.  Contents of usr/share/glpi moved to /var/www/
Gave myself full access rights to /var/www/glpi/

mysql:
MariaDB..> create database dbbglpi character set utf8;
ERROR 1007 (HY000): Can't create database 'dbbglpi'; database exists
MariaDB [(none)]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit
Bye

Tried http://localhost/glpi/ and hit error 404.

> drop database dbbglpi;
Query OK, 0 rows affected (0.00 sec)

> create database dbbglpi character set utf8;
Query OK, 1 row affected (0.00 sec)

> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

Back to localhost/glpi/  =>  Error 404

(In reply to Len Lawrence from comment #13)
> Who is regarded as the user?  Who should be given access to glpi?
> I know virtually nothing about databases and web interfaces.

What user?  What do you mean given access?

> I tried this:
> And yes, I did wonder what the tarball might contain that was not already
> installed.  Contents of usr/share/glpi moved to /var/www/
> Gave myself full access rights to /var/www/glpi/

Why are you doing that?  Don't do that.  I imagine the Alias I told you about refers to /usr/share/glpi so it's already looking for it there, as installed by the package.  From what Herman said it sounds like that much does work, so I'm not sure why you're seeing a 404.  Anything useful in /var/log/httpd/access_log or error_log?

Sorry David, I only just noticed what you said about not changing ownership.  Have reverted that.

It also struck me as very odd that the tutorial instructed the user to move the whole lot from /usr /to /var/www.  I shall put things back the way they were and see if it goes as far as Herman drove it.

Re comment 14.

I was confused about who actually owned the database, root, the user, ...?
$ sudo updatedb
$ locate dbbglpi
/var/lib/mysql/dbbglpi
$ ls -l /var/lib/mysql/dbbglpi
ls: cannot open directory '/var/lib/mysql/dbbglpi': Permission denied

It is owned by mysql:mysql and I am not a member of the mysql group.  Should I be?

access_log contains nothing useful, just repeated

127.0.0.1 - - [27/Aug/2017:17:09:42 +0100] "GET /glpi/ HTTP/1.1" 404 1037 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"

and nothing at all in error_log around the time of the experiments.

I think you're over thinking this Len.

For most webapps, assuming you already have task-lamp installed and services running, you then install the package(s), configure a database for it to use - simplest way is to use phpmyadmin - then visit the url http:/localhost/<package>.

There are nothing related to any desktop user, in the same way as creating an account at Mageia doesn't require any desktop settings.

Typically, installing the package also restarts/reloads apache to re-read the new apache configuration files for the package - kept in /etc/httpd/sites.d/

There may be an web based installer which will request database details, etc to follow, and occasionally it's a manual process. To find the configuration files look in the apache packae config file to see where the "Alias" is linked to. It'll typically say something like:

Alias glpi /usr/share/glpi

Which means when you visit http://localhost/glpi apache instructs your browser to display the web stuff in /usr/share/glpi

It's really just a glorified symlink with a database attached.

might be /etc/httpd/conf/sites.d for the conf files actually, off the top of my head.

Len, database users and Linux users are two completely different things.  You shouldn't be manually messing with the files in /var/lib/mysql.  As Claire alluded to, in mysql you create a database user to own the database and then you have to give those details to the webapp some how.

Thanks Claire and David.  Databases and web applications are another country for me.  However from what you have said there appears to be no reason why the configuration interface should not display in a browser.  Everything seems to be in order, except perhaps the lamp stack.  Since I had to install php manually there is a good chance something else might be missing.

Right.  Installed task-lamp, restarted httpd and tried the link.  This time it simple hangs on a blank page.  mysqld is running.

glpi.conf has a stanza for the glpi directory:

<Directory /usr/share/glpi>
    Require all granted
    Options -FollowSymLinks
    # recommanded value
    php_value memory_limit 64M
</Directory>

but further down "Require all denied" for files, locales, mysql etc.

There is a 404 error buried in the access error log:
$ tail /var/log/httpd/access_log
.....................
192.168.1.156 - - [27/Aug/2017:18:28:10 +0100] "GET /glpi/ HTTP/1.1" 500 - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
127.0.0.1 - - [27/Aug/2017:18:28:59 +0100] "GET /glpi HTTP/1.1" 301 230 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
127.0.0.1 - - [27/Aug/2017:18:28:59 +0100] "GET /glpi/ HTTP/1.1" 500 - "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
127.0.0.1 - - [27/Aug/2017:18:28:59 +0100] "GET /favicon.ico HTTP/1.1" 404 1037 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"
127.0.0.1 - - [27/Aug/2017:18:28:59 +0100] "GET /favicon.ico HTTP/1.1" 404 1037 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0"

Went on to try Herman's neat little trick of renaming the autoloader file and up came the interface!!!

Traversed a couple of screens but refrained from either installing or upgrading glpi.  It works as far as that.  The puzzle now is why Herman cannot reach the GPL Licence page (step 2).  /var/log/glpi/ is empty here too so that is probably OK.

Good for 64-bits once the autoloader business is fixed.

A 404 on the favicon.ico is OK.

And now for the update. :p

The package installed fine.  Dropped the two databases created previously and checked the autoloader fix in /usr/share/php.  Installation restarts the httpd server.

Pointed firefox at localhost/glpi/ to invoke the configuration page.  Working perfectly.

OK for 64-bits.  Do we raise a bug on the PHP autoloader issue?  Is it a separate issue or something in the glpi packaging?

Maybe we should wait for Guillaume's response to this.

Pushing the cauldron package directory into stable release was not a great idea, for at least two reasons:
- first, it is a major version update, triggering a database schema change, which is largely unexpected given our update policy
- second, the new package relies on every PHP package dependencies to ship an autoloader with an expected filename, which is not the case in mageia 5

The correct fix here is to port the following commits to GLPI 0.84:
https://github.com/glpi-project/glpi/pull/2492/commits/7b7051fe42d36f53270b943b1a3c238c9ed503b5
https://github.com/glpi-project/glpi/pull/2481/commits/1a1e9e15f0dd52d68f18e0d64ab1ded199f3c263
https://github.com/glpi-project/glpi/pull/2481/commits/9619f0235615f14e088d31edc7a0ac3c5f30ac9a

I'll try to do it during the week, unless someone else manage to do it first.

None of those commits apply, because the corresponding code doesn't exist in 0.84. Which could perfectly mean than 0.84 is not concerned by the problem. 

Also, those commits only correspond to the security issues fixes with 9.1.6 release, we also have similar issues in 9.1.5, 9.1.4, etc... That's way too much work, for dubious benefits. Especially given the lack of authoritative information (CVE number, and vulnerability statement).

For all those reasons, I'd rather not push any update for mageia 5, unless someone want to handle this work properly. We may eventually provide backports of glpi 9, if current infrastructure allows it, for interested users.

Moving 'feedback' from whiteboard to keywords now that madb has been updated to handle that keyword.

Whiteboard: feedback => (none)
Keywords: (none) => feedback

Assigning to Guillaume to make sure we have a good update for this package before we assign it back to QA.

Keywords: feedback => (none)
CC: (none) => qa-bugs
Assignee: qa-bugs => guillomovitch

I'm not sure about what kind of feedback you expect from me.

Shipping GLPI 9.1.6 for mageia 6, as an update to GLPI 9.1.1, should be OK.
Shipping GLPI 9.1.6 for mageia 5, as an update for GLPI 0.84 is not. Moreover, GLPI doesn't qualify for mageia 5 extended support.

Guillaume, this bug isn't, and never was, about Mageia 5.  It's only for Mageia 6.  We did update it to 9.1.6, and the QA team tried to test it and couldn't get it to work.  Can you provide some feedback on that?  Is the package broken or are they doing something wrong?

The GLPI update candidate is fine.

What is wrong in the php-zetacomponent-base package shipped in mageia 6, because it was not rebuild with bootstrap macro disabled (chicken-and-egg problem: in order to generate bootloader with fedora phpab tool, you need php-zetacomponent-base, and in order to build php-zetacomponent-base, you need phpab...). I'm the culprit, I probably forgot to do it before the release. I just submitted php-zetacomponents-base-1.9-1.1.mga6 in update_testing, that should fix the issue.

Small hint for the QA team: when update package foobar doesn't work, just check if the same package in the base distribution does, in order to identify regressions from problem than already existed in the release.

Thanks Guillaume!

Advisory:
========================

Updated glpi package fixes security vulnerabilities:

The glpi package has been updated to version 9.1.6, which fixes several
security issues and other bugs.  See the upstream release announcements for
details.

An issue in the php-zetacomponents-base package which prevented GLPI from
working has also been fixed.

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11183
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11184
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11329
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11474
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11475
http://glpi-project.org/spip.php?page=annonce&id_breve=370&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=373&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=376&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=378&lang=en
http://glpi-project.org/spip.php?page=annonce&id_breve=379&lang=en
========================

Updated packages in core/updates_testing:
========================
php-zetacomponents-base-1.9-1.1.mga6
glpi-9.1.6-1.mga6

from SRPMS:
php-zetacomponents-base-1.9-1.1.mga6.src.rpm
glpi-9.1.6-1.mga6.src.rpm

Assignee: guillomovitch => qa-bugs
CC: qa-bugs => (none)
Status comment: Need feedback from maintainer if update candidate is OK => (none)

Mageia 6 :: x86_64

Installed the update packages.
Installed mysql and started mysqld.

# mysql -u root -p
Enter password: 
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Consulted https://www.tutorialspoint.com/mysql/ to find out how to set the root password.
# mysqladmin -u root password .........
mysqladmin: 
You cannot use 'password' command as mysqld runs
 with grant tables disabled (was started with --skip-grant-tables).
Use: "mysqladmin flush-privileges password '*'" instead

# mysqladmin flush-privileges password '............';
mysqladmin: 
You cannot use 'password' command as mysqld runs
 with grant tables disabled (was started with --skip-grant-tables).
Use: "mysqladmin flush-privileges password '*'" instead

# mysqladmin flush-privileges password '*';

So, no way to set a password.
Trying without:

# mysql -u root
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 12
MariaDB [(none)]> create database dbbglpi character set utf8;
Query OK, 1 row affected (0.00 sec)
MariaDB [(none)]> quit

As user:
$ mysql -u root
MariaDB [(none)]> use dbbglpi
Database changed
MariaDB [dbbglpi]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
MariaDB [dbbglpi]> quit

That confirms that mysql needs a password.  That is as far as it goes.  Cannot test glpi.  Handing over to anybody else.

Addendum to comment 33:

Last ditch attempt - went to /etc/my.cnf and inserted the password there but was still denied access.

Len, apparently as of Mageia 6, you need to run a script, I think called mysql_secure_installation or something like that, to set the password.  I think it is also documented on our wiki somewhere.

OK thanks.  I shall see if I can find it - not tonight though.

It even has a man page: mysql_secure_installation.

OK, can login now.  Continuing tomorrow.

For the uninitiated - glpi is an "IT asset and inventory management" system.

$ mysql -u root -p
Enter password: 
MariaDB [(none)]> use dbbglpi
Database changed
MariaDB [dbbglpi]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
Query OK, 0 rows affected (0.00 sec)

MariaDB [dbbglpi]> flush privileges;
Query OK, 0 rows affected (0.01 sec)


Pointed browser at localhost/glpi which displayed the glpi setup screen.
Agreed to the licence terms and selected upgrade.
That displayed the environment compatibility chart, step 0.  One red comment:
"fileinfo extension is missing"
and four orange warnings about missing extensions, which can be ignored.
Looks like the user cannot get past this point without the fileinfo plugin.
Did some browsing and came across this message in a forum:
"Fileinfo extension of your parser PHP is not installed"

$ sudo urpmi php-fileinfo
$ sudo systemctl restart httpd

Back to glpi, continued to step 1 and tried to connect to a database (does not give a database name option, just a login).  Tried root and the mysql password and the connection attempt timed out. Users like cactus, and joebloggs were presented, fossils from an earlier time, and a new user suzy.  Went back to the login step and entered dbbglpi in the SQL server field, replacing mysql.  Timeout with "The action you have requested is not allowed".  Blundering on, restarted the interface and placed mysqld in the server field then logged in as 'root'.  Timeout again.

I think it is time to give up on this.  Seven hours work and nothing to show for it.

This trained monkey has just spotted what looks like a silly mistake.
Trying to mend it.
MariaDB [dbbglpi]> grant all privileges on dbbglpi.* to root@localhost identified by 'root';
Query OK, 0 rows affected (0.00 sec)

But no, it still times out in glpi setup.

Added 'flush privileges;'

Still times out.

And now I have screwed things completely.  Locked out of mysql - no longer responds to the 'root' password.  That was after trying to run mysql_secure_installation again.  Looks like it can be used only once.  Just wanted to run through the options to see if I had done something wrong because there seems to be no solution to the database problems here.  I have always regarded databases as a nightmare - should have left the whole subject alone.

Moved to another machine, installed task-lamp, php-fileinfo and started mysqld.
Ran mysql_secure_installation to set the password for mysql.  No apparent problem.
$ mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 12
Server version: 10.1.30-MariaDB Mageia MariaDB Server
MariaDB [(none)]> create database glpi character set utf8;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> grant all privileges on glpi.* to root@localhost identified by 'root';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements


???

MariaDB [glpi]> drop database glpi;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> create database ddbglpi character set utf8;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> grant all privileges on dbbglpi.* to root@localhost identified by 'root';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> use dbbglpi
ERROR 1049 (42000): Unknown database 'dbbglpi'

MGA6-32 on Lenovo B50 Plasma
Installed packages plus mysql (was not there before
Ref to comments 4 and 5 for the installation of the database, thus
# mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 9
Server version: 10.1.30-MariaDB Mageia MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database dbbglpi character set utf8;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
Query OK, 0 rows affected (0.00 sec)
But then, pointing to http://localhost/glpi gave me error 404. I checked the http conf files but could not find anything wrong,and logs had noinfo either.
I wanted to see if the CLI would give anything away, so I closed firefox, started it from the CLI as normal user and now I get the setup screen from http://localhost/glpi.
Inveestigating further.

Co,tinuing setup goes on, in the end report all is OK, except "APCu extension is not present"
Continuing, logging in with glpi/glpi, selecting database created above, and setup finishes successfully.
Displaying:
De installatie is voltooid

Standaard gebruikersnaam/wachtwoord zijn:

    glpi/glpi voor de beheerder/administrator account
    tech/tech voor de technische gebruiker
    normal/normal voor het normal account
    post-only/post-only voor het 'alleen posten'-gebruikersaccount

U kunt deze gebruikers verwijderen of wijzigen, net als de intiële waarden in de databank

Installation iscompleted etc.....
So seems OK, but I do nt understand why I had to restart firefox to get going.

Whiteboard: (none) => MGA6-64-OK

Drawing a line under this for x86_64.  The update is not about mysql and  the update enables the glpi interface to work up to the point of failing to connect to the database, which means that glpi cannot be exercized.  It is probably OK; just needs somebody who knows what they are doing in mysql to confirm that.

@herman - re comment 45
Did you have to create the glpi user and if not, how did you set a password for it?  I had already tried the glpi user and hit a brick wall at the password in the web interface.

@ Len
First AFAICS in your last try you missed the editing of /etc/my.cnf.d/cracklib_password_check.cnf, that causes the password issue in the beginning.
Second is - no offence meant - that I think you are grappling with system (Linux)-users and database users. They have nothing to do with each other. But for ease of use (and apparently confusion) they often have the same name.
So the system user glpi is created with the installation of the package, but it never comes into play in the rest of the configuration.
The statement in mysql: grant all privileges on dbbglpi.* to glpi@localhost identified by 'glpi';
puts you on the wrong foot: it seems to create the database user "glpi" on the fly, so after that, you have nothing to do with it. "Identified by" is in mysql-ese setting the password, the identity is glpi@localhost. In phpmyadmin, you would see a user "glpi".

Thanks for the comments.  
I thought that the mysql_secure_installation was supposed to take care of the password problem but I shall try the cracklib business.

No offence taken.  Claire explained to me long ago that mysql users have nothing in common with desktop users.  However I found that by default the mysql user is called 'root'.
If any other mysql name is used the mysql password does not work.

Yes, I suspected that the database user glpi was created on the fly but thought 'identified by' would have the rational meaning.  I certainly did not realize that it meant password.  Thanks for the insight.  I have not found a good tutorial for mysql yet.

Testing mga6 64 Fresh-ish Vbox

tl;dr; Seems to be missing a require on php-fileinfo, otherwise ok.

Installed task-lamp, uninstalled proftpd (just unwanted). Restarted mysqld and httpd services. Ran mysql_secure_installation and set a (mariadb/mysql) root password, etc.


Before
------
# mysql -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 10
Server version: 10.1.30-MariaDB Mageia MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create user glpi@localhost identified by 'glpi';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
MariaDB [(none)]> create user glpi@localhost identified by 'glpiglpi';
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
MariaDB [(none)]> create user glpi@localhost identified by 'glpi1234';
Query OK, 0 rows affected (0.09 sec)

MariaDB [(none)]> create database glpi;
Query OK, 1 row affected (0.00 sec)

MariaDB [(none)]> grant all on glpi.* to glpi@localhost;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit;
Bye


# urpmi glpi

Browsing to http://localhost/glpi presents a blank screen.


After
-----
# urpmi glpi php-zetacomponents-base

$MIRRORLIST: media/core/updates_testing/glpi-9.1.6-1.mga6.noarch.rpm
$MIRRORLIST: media/core/updates_testing/php-zetacomponents-base-1.9-1.1.mga6.noarch.rpm 
...etc


Browsing to http://localhost/glpi redirects to the installer at http://localhost/glpi/install/install.php

The installer fails when checking requirements..
"fileinfo extension is missing"

Unable to continue the installation without first installing php-fileinfo, so seems a missing require.

Also seemed to need to manually restart httpd before it could proceed.

Gave database connection details..
SQL Server - localhost
SQL User - glpi
SQL Password - glpi1234

Selected to use the glpi databse earlier created and clicked through the rest of the setup.

Noted the default users.

Default logins / passwords are:

    glpi/glpi for the administrator account
    tech/tech for the technician account
    normal/normal for the normal account
    post-only/postonly for the postonly account

Logged in a glpi/glpi and ignored the request to change password.Created a computer on the system and logged out.


Removed datase/user and tidied up.
# mysql -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 50
Server version: 10.1.30-MariaDB Mageia MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> drop database glpi;
Query OK, 245 rows affected (0.02 sec)

MariaDB [(none)]> drop user glpi@localhost;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> exit;
Bye

# urpme glpi

Whiteboard: MGA6-64-OK => MGA6-64-OK feedback

$ mysql -u root -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 26
Server version: 10.1.30-MariaDB Mageia MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> grant all privileges on ddbglpi.* to glpi@localhost identified by '........';
Query OK, 0 rows affected (0.01 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.00 sec)

MariaDB [(none)]> 


Back to the web interface -> install
settings were mysql, glpi, <password>
Failed to connect.

Sigh!  24 hours and counting...

@ Len
You seem to have missed the "create database ......" That database should appear in the list.

Re comment 50:

A bit of extra information there.  So the server is 'localhost'.  I used 'mysql' thinking it meant the server type.

Corrected that to localhost and glory be - an immediate connection.
Continued to the management interface with the personal view.  It looks functional.

Thanks for testing Claire.  Giving this the OK for 64 bits.

@Herman.  No, the database was created earlier.  All is well now; gradually learning the language.

Welcome. I am trying to still keep an eye on you all :)

There seems to be a missing require on php-fileinfo. If that can be added, a quick check with urpmq would suffice.

Guillaume, I know it can generate a lot of e-mails, but please leave yourself CC'd for your packages.  The package is missing a requires on php-fileinfo, so your help is needed.

CC: (none) => guillomovitch

glpi-9.1.6-2.mga6 submitted in updates_testing, with php-fileinfo dependency added.

Thanks!  I think we can validate this one.

Whiteboard: MGA6-64-OK feedback => MGA6-64-OK

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0135.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED