Bug 32118

Created attachment 13925 [details]
compressed report.bug

Assigning to the registered maintainer for mariadb.

Looks like the simplest solution is to add the command "true" at the
end of the preinstall scriptlet so force the return code to be zero
so that it works whether mariadb is currently running or not.

CC: (none) => davidwhodgins
Assignee: mageiatools => mageia

yeah, that is buggy / broken packaging... 
it assumes passwordless write access to databases

The database must have a clean shutdown, because there might be incompatible changes of the redo logs. Otherwise the database might be destroyed.

I saw many crashes of the user owned Akonadi database in the forums.

During an upgrade the script must not assume the service is running or
can be started as an upgrade using the classic iso does not allow it.

Database servers such as mariadb may or may not have a password and may be
for user level usage or system level usage (or both from one server).
/usr/share/doc/mariadb/README.urpmi strongly encourages setting a password
to protect the database, especially when used for web applications.

akonadi may use a postgresql or SQLite database, and mariadb is used by web
applications, not just kde/akonadi.

Ensuring a clean shutdown of any database can only be done by the users.

Clear instructions on how to do a clean shutdown must be given to the users
for upgrading using an iso. For users upgrading using mgaapplet, that can be
handled by a script, but only if the database service is already running, with
each type of database backend handled appropriately.

Note that any such script should be part of akonadi, so it doesn't break things
for apache/php.

> Clear instructions on how to do a clean shutdown must be given to the users
for upgrading using an iso.

I did a normal shutdown, from plasma launch menu. 
Normal shutdowns are not clean?


> For users upgrading using mgaapplet, that can be handled by a script, 
> but only if the database service is already running,
> with each type of database backend handled appropriately.

And we also need instructions for CLI; urpmi and dnf...


Setting for errata; explain the error popup if we do not fix it
Maybe for release notes, if we can add not too complicated instructions.
-If we fix it: neither above :)

Keywords: (none) => FOR_ERRATA8

https://wiki.mageia.org/en/Mageia_9_Errata#Upgrade_issues

Keywords: FOR_ERRATA9 => IN_ERRATA9

There is no prein script in mariadb package. I don't know where this comes from. Maybe this is a rpm-macro?

See https://svnweb.mageia.org/packages/cauldron/mariadb/current/SPECS/mariadb.spec?revision=1961318&view=markup#l915

argh. I hate systems that name things differently.

there is no simple solution to that. It would be best integrated into mysql_upgrade. but most setups fail to install tz info which results in faulty time values.
We assume, that root is able to use/write the system database which should be true.

But I think it must be moved to the post section - pre is wrong.

(In reply to Marc Krämer from comment #11)
> argh. I hate systems that name things differently.
> 
> there is no simple solution to that. It would be best integrated into
> mysql_upgrade. but most setups fail to install tz info which results in
> faulty time values.
> We assume, that root is able to use/write the system database which should
> be true.

you cant assume that, as any security minded admin will lock down mariadb, making the script fail...

Also, this part is not really correct:

%pre common-core
# enable plugins
if [ -f %{_sysconfdir}/my.cnf ]; then
	perl -pi -e "s|^#plugin-load|plugin-load|g" %{_sysconfdir}/my.cnf
	perl -pi -e "s|^#federated|federated|g" %{_sysconfdir}/my.cnf
	# switch to federatedx provider
	perl -pi -e "s|;ha_federated\.so$|;ha_federatedx\.so|g" %{_sysconfdir}/my.cnf
fi


if a sysadmin disables any of those, this will quietly re-enable them causing behaviour change on a working customized setup...

Keep in mind. The mysql root user is not the same as the linux root user.
The may (should) have different passwords.

The unhashed password is not available anywhere on the system. It is not
available to any scripts, let alone rpm scriplets.

I really hate those blaming sessions.

That perl code is written by "alien"; I've never touched it. And it is really OLD. Maybe it is incorrect, but no one ever complained.

And even this bug was introduced by the end of march. So I guess most people have a .my.cnf file which connects to the database.

The idea with this script was, to make timezone data available to mariadb, which we do for almost all other package. I guess most people forget about this, as I did. And mariadb really makes wrong computations on timestamp data, if timezones are not available. So I thought it would be best to include this in our installation/update process.

Everyone makes mistakes - but anyway not setting the data is a mistake too. I could include a hint after the installation - but to be honest, who really reads those hints after updating 2000 packages from mga8 -> 9?

its not a blaming session...

this tend to happend in bugreports when rpm scripts fails, then people start looking closer at the scripts in the affected packages, and point out the issues they see...

no blaming, just pointing out issues that should be looked at / fixed some way...

the pointed perl scripts don't have any effect, as the my.cnf file is almost empty, because of the configuration directory /etc/my.cnf.d

removed the perl scripts and the timezone script. Changed the readme file.
New package can be moved.

changes can be moved.

Assignee: mageia => qa-bugs

files are in updates_testing.

CC: (none) => mageia

Sorry, ignore comment 20 as that was installing while m9 was running, and
picked up the release version. Will retest doing a full upgrade.

Just realized. It can not be tested properly while it's in qa testing.

Will test that it's working in an m9 install, but the upgrade portion can not
be tested until it's pushed to core release, as the classical installer doesn't
allow using core updates testing, and testing while doing an upgrade using
urpmi doesn't test the problem properly.

Confirmed mysqld.service is working ok using phpmyadmin with
# rpm -qa|grep mariadb|sort
lib64mariadb3-10.11.4-2.mga9
lib64mariadbd19-10.11.4-2.mga9
mariadb-10.11.4-2.mga9
mariadb-client-10.11.4-2.mga9
mariadb-common-10.11.4-2.mga9
mariadb-common-core-10.11.4-2.mga9
mariadb-connect-10.11.4-2.mga9
mariadb-core-10.11.4-2.mga9
mariadb-extra-10.11.4-2.mga9

So ask for the freeze push, and then an upgrade can be testing using the
classical installer.

except for the popup, the error would be thrown the same way.

I think we are in freeze phase, so it must be pushed here.

Freeze pushes for cauldron are still handled in the dev ml, not via bug reports.
Some testing (usually by the packager) is required in advance, but not to the
same level as on a stable release.

I thought the purpose of this update was to fix the script failed message.
If not, then this update must be rejected, and m9 will remain on hold until
it is fixed.

it was removed.

If it is tested here, why not pushed via qa? I don't get it.

With a stable release, each update is handled by an advisory such as
https://svnweb.mageia.org/advisories/31997.adv?revision=14824&view=markup

The srpm list in the advisory is used by the script that pushes updates to
move the srpm and associated rpm packages from updates testing to updates.

In cauldron, even in the freeze period the updates are move from the
updates testing repos to the release repos, based on a request in the dev ml.

When the final iso images are created, normally it only includes packages from
the release repos.

As https://svnweb.mageia.org/packages/cauldron/mariadb/current/SPECS/mariadb.spec?revision=1961318&view=markup#l915
is still trying to install the tz data into the mysql database, which will
fail during an upgrade due to being in a chroot, and will fail during
install of a normal update in a stable release if the admin has followed
the readme to create a mysql password for the mysql root user.

An update must not assume the service is running or ready to be started.
The proper way to handle getting the tz data installed is to inform the user
it's needed, and tell them what commands are needed so that they can manually
install the tz data, after the login to mysql with the proper password.

If it's needed for a per user copy of mysqld, then the admin must be
informed that they need to inform all users, not just the one who installed
the update.

Once the final iso images pass testing, then cauldron is forked and a new stable
release is created. Only then do updates start getting moved from updates testing
to the updates repos. Until then packages are moved from updates testing to
release.

that is really nonsense.
Ok. Then I wait until release.

(In reply to Dave Hodgins from comment #27)
> With a stable release, each update is handled by an advisory such as
> https://svnweb.mageia.org/advisories/31997.adv?revision=14824&view=markup
> 
> The srpm list in the advisory is used by the script that pushes updates to
> move the srpm and associated rpm packages from updates testing to updates.
> 
> In cauldron, even in the freeze period the updates are move from the
> updates testing repos to the release repos, based on a request in the dev ml.
> 
> When the final iso images are created, normally it only includes packages
> from
> the release repos.
> 
> As
> https://svnweb.mageia.org/packages/cauldron/mariadb/current/SPECS/mariadb.
> spec?revision=1961318&view=markup#l915
> is still trying to install the tz data into the mysql database, which will
> fail during an upgrade due to being in a chroot, and will fail during
> install of a normal update in a stable release if the admin has followed
> the readme to create a mysql password for the mysql root user.
> 
> An update must not assume the service is running or ready to be started.
> The proper way to handle getting the tz data installed is to inform the user
> it's needed, and tell them what commands are needed so that they can manually
> install the tz data, after the login to mysql with the proper password.
> 
> If it's needed for a per user copy of mysqld, then the admin must be
> informed that they need to inform all users, not just the one who installed
> the update.

the update uses rev 1964111

Free push requested on the dev ml

moved to release ~1 week ago

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

Removed from errata

Keywords: IN_ERRATA9 => (none)