David C. Rankin - 2:09 5.06.09 wrote:
Listmates,
Where in openSuSE is the disconnect between the mouth and the brain? We have open bug reports on the horrors caused by somebody's decision to move the mysql socket and 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.
MySQL 5.1 in server:database is disabled for SLES9.
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!
Well, using bleeding edge packages (server:database) on production system is IMHO bad idea. On my servers I'm really careful about every update and certainly wouldn't add any bleeding edge repo unless I really need new feature which is in there. One of the advantages of the openSUSE is that serious or security bugs gets fixed even for older already released versions. So you don't have to be afraid of having old well tested versions.
...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?
In the comment of your bugreport you can see, that I moved default socket location back for all already released distributions.
But sure enough, incompetence rears its ugly head again in the form of the 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.
Well I didn't put it in Tip and Tricks section but I wrote article about it so people would know that there are going to be some changes. And that they will know about possible problems.
This is nothing short of asinine. With full knowledge of the problems and loss of time that *will result*, let's go ahead and render 300,000+ mysql installs DEAD. For what?... No legitimate reason at all...
As for reasons: http://www.pathname.com/fhs/2.2/fhs-5.13.html It may break some default configurations of some packages. But I don't think that there will be so many people testing bleeding edge package.
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...
It was my decision and it is in server:database repo. So it is not official update and as I said before, using bleeding edge packages has some risks. They are not as tested as released distributions.
Is somebody going to start handing out checks to pay all the sysadmins time that will be needed to fix this nonsense?
Any sane sysadmin wouldn't run bleeding edge packages IMHO.
The very article where they are selling this crap is blatantly wrong as well:
"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 time or if you didn't touch your configuration file, everything should be ok."
WRONG - O - MARY LOU
It is irrelevant whether no changes have been made to the /etc/my.cnf file 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.
Wrong. If you made some manual changes to your my.cnf you may end up with such a configuration that MySQL will refuse to start. For example if you leave there skip-federated option. Without any changes/with distribution configuration file database will start and work, see comment bellow.
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."
Your database *will work* without changing anything. And every application configured to use network connection *will work* too. If you are installing new application which will use MySQL it *will work* if you configure it correctly.
Doesn't the burning question just leap from the page??? Why the F do it when you know you are going to screw thousands of people over and your best suggestion of why is just that it "should make MySQL more LSB friendly". Like MySQL cares....
MySQL don't care (as stated in the article, you can move these files anywhere you want), but users cares. Some users needs files in locations according to the LSB. And frankly, where would you search for pid file or socket first if you are not working with them daily?
Do the people that are package software with these numbnut changes ever actually use the software they are changing or are these folks just compiler rats whose job it is to build package A, B, C & D without ever running/administering an actual group of database apps before?
I'm using MySQL. Commandline utilities works in default installation and connecting to MySQL over network works too. I admit that all applications I'm using are connecting to MySQL over network though (if I don't count commandline utilities). And if I install some other application and configure it properly, connection through socket works too. -- Michal Hrusecky Package Maintainer SUSE LINUX, s.r.o e-mail: mhrusecky@suse.cz