Mailinglist Archive: opensuse (1468 mails)

< Previous Next >
Re: [opensuse] Why is Michal Hru šecký Article on openSuS E Announce - Admitting MySQL Upgrade will Break Config?
  • From: Lars Müller <lmuelle@xxxxxxx>
  • Date: Fri, 5 Jun 2009 11:29:29 +0200
  • Message-id: <20090605092929.GA19666@xxxxxxxxxxxxxxxx>
On Fri, Jun 05, 2009 at 02:09:51AM -0500, David C. Rankin wrote:

Where in openSuSE is the disconnect between the mouth and the brain? We
open bug reports on the horrors caused by somebody's decision to move the
mysql socket and

While talking about bugs never ever quote the bug ID. NEVER, EVER! ;)

pid file from /var/lib/mysql to /var/run/mysql and how that
will BREAK every installed database application on openSuSE servers from at
least 9.0 to the present.

How does a different location of the pid directory cause this?

Why I'm asking this? The Debian guys use a different location for the
Samba pid files. And I consider after a dicusssion with them at the
SambaXP conference - yes, that's the place you can go each year if you
like to hit me with the clue stick - to change the current approach to
make the resulting binaries of SUSE, RedHat, Debian, and more common.

I also consider package renames. But I fear them. Not on the same
level as %post and %pre scripts. :)

Think about it... The update is applied to the machine and then within
seconds, the phone line lights up with angry people wanting to know why none
of the web pages work anymore.... Bad news mate!

Please explain how this could happen due to a changed pid file location.
Now I've read more of your posting and am able to follow.

...And, how instead of being (intelligent) and having one packager
change the
default paths back to where they have always been -- we are now going to
require 100,000's of openSuSE mysql database installs to be reconfigured to
accommodate a senseless socket and pid path change. Hello!! Is this still
Earth in the year 2009?

But sure enough, incompetence rears its ugly head again in the form of
openSuSE News Letter where under Tips and Trick (more like "Trick-or-Treat
MF!") it is all explained and a kind link provided to Michal's site.

You still have my loud 'never, ever!' in your ears? points to

This is nothing short of asinine. With full knowledge of the problems
loss of time that *will result*, let's go ahead and render 300,000+ mysql
installs DEAD. For what?... No legitimate reason at all...

If this concerns you this heavily please file a bug. That's what I
would do in this situation and that's what I have done in the past.

Short story: Next you'll get pushed to file a feature request.

Long story: Even this feature request will be ignored, closed, delayed
(add any additional sucking habit). I've seen this quite often in the
last ten years. Even if different tools had been in use. The habit is
allways the same.

But is this laziness or ignorance? Are these dudes only poking their
nose all the time? No, this is simply the result of the work load we
all have.

Heads should roll for this type of utter disregard for the user
community and
the brainless decision to screw over 100,000's instead of fixing "1". Who in
openSuSE signed off on this change? Christian, was that you? maybe Anders...

Is somebody going to start handing out checks to pay all the sysadmins
that will be needed to fix this nonsense?

The very article where they are selling this crap is blatantly wrong as

"With this change you need to remove skip-federated option from your my.cnf
file if you have changed it manually. This option was there by default in
previous versions of MySQL. But if you are installing MySQL for the first
or if you didn't touch your configuration file, everything should be ok."


Even without asking Mary Lou to join the discussion here you state the
first arguments! Cool and thanks dude!

It is irrelevant whether no changes have been made to the /etc/my.cnf
because the default file has the paths to /var/lib set and all apps already
communicating with mysql through the socket in /var/lib/. Even if *no changes
at all* have every been made to /etc/my.cnf by the user, the new config will
render the databases DEAD.

Yes. That's sucking from my point of view as well.

And we have prepared the same perpared for Samba too. The new
_upstream_ default passdb backend is tdbsam. But in the past we used
the smbpasswd file.

AND we never set this in smb.conf. Instead we inherited this setting
from the defaults in the code. Now a customer using this default moves
to newer Samba binaries. Bang!

I'm not sure yet how to handle this adequate. We consider to inform the
customer if no passdb backend is set in smb.conf and warn by this that
the soon installed chnage might cause trouble. Including a suggestion
what to add to the current config.

Then Michal continues:

"First of them is that mysql socket file and pid file were moved by default
from /var/lib/mysql to more reasonable location ( /var/run/mysql ). Second
change is that mysql log file is again back in /var/log. These changes should
make MySQL more LSB friendly and help people with their MySQL administration.
All these changes can be reverted by changing MySQL configuration file so if
you don't like it, you can move them anywhere you want (face-wink.png)"

Yes, that really is a stupid smiley face icon at the end of his
paragraph. An
honest answer would have at least included telling admins that "you *will*
have to manually edit the config files to change the paths back to what they
have been for the past 5 years if you want your databases to work."

As /etc/my.cnf is packaged as %config with_out_ noreplace this change is
calling to cause trouble. :(

Lars Müller [ˈlaː(r)z ˈmʏlɐ]
Samba Team
SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
< Previous Next >