[opensuse] Why is Michal Hrušecký Article on openSuSE Announce - Admitting MySQL Upgrade will Break Config?
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. 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! ...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 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. 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... 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 time that will be needed to fix this nonsense? 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. 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." 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.... 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? Something is definitely rotten in the decision making process and I haven't heard or seen a single person from the developer side of the house stand up for the community on theses issues. Perhaps this will provide an opportunity for the first. Who among the folks with an opensuse.org or novell.com email address will have the moxy to do it? -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
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 have 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 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.
You still have my loud 'never, ever!' in your ears? http://en.opensuse.org/OpenSUSE_Weekly_News/74#Tips_and_Tricks points to http://michal.hrusecky.net/index.php/blog/show/MySQL-5.1-and-openSUSE-6.html
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...
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 time that will be needed to fix this nonsense?
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
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 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.
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 -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Fri, Jun 05, 2009 at 11:29:29AM +0200, Lars Müller wrote: [ 8< ]
As /etc/my.cnf is packaged as %config with_out_ noreplace this change is calling to cause trouble. :(
In newer versions - 11.0 and newer - /etc/my.cnf is packaged as %config(noreplace). And therefore the question is now: How many peopele use mysql without touching /etc/my.cnf? Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2009-06-05 at 11:42 +0200, Lars Müller wrote:
And therefore the question is now: How many peopele use mysql without touching /etc/my.cnf?
Me. Unless it stops working; I let yast do the update when updating the entire system (say, 10.3 to 11.0). - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoptioACgkQtTMYHG2NR9XO6QCfd/+mA8jgt+4g5+L6lllEEDS5 xjEAn0dHgW0MxXgsauyBxKfa4iJxxgK1 =NSUz -----END PGP SIGNATURE-----
On Fri, Jun 05, 2009 at 11:42:41AM +0200, Lars Müller wrote:
On Fri, Jun 05, 2009 at 11:29:29AM +0200, Lars Müller wrote: [ 8< ]
As /etc/my.cnf is packaged as %config with_out_ noreplace this change is calling to cause trouble. :(
In newer versions - 11.0 and newer - /etc/my.cnf is packaged as %config(noreplace).
And therefore the question is now: How many peopele use mysql without touching /etc/my.cnf?
Quite many, IMO. I guess that mostly anyone using the MyISAM engine and not using the Innodb engine won't touch the file, and runs with defaults. Reasons for touching the file would be tuning for high perfomance, or setting up synchronisation to a slave. Not something that many do. Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development
Lars Müller - 11:29 5.06.09 wrote:
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 have 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! ;)
bnc#496196: https://bugzilla.novell.com/show_bug.cgi?id=496196
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?
It's because of different location of socket file.
"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. :(
This report was about mysql from server:database repository and /etc/my.cnf is there packaged as %config(noreplace) -- Michal Hrusecky Package Maintainer SUSE LINUX, s.r.o e-mail: mhrusecky@suse.cz
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David C. Rankin 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.
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!
...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?
Firstly, thanks for the heads up... Secondly, senseless?? having these files under /var/lib does not really make much sense, (I must admit the current PID and socket location is something which did not quite scan for me, the /var/lib structure ideally should contain libraries not runtime and socket info). If this part of general move of such files to a /var/run structure then this is a very logical change (and hopefully is continued to other applications if they are using such locations)... However, if this is also being implemented in an upgrade update to an existing install (which I infer from above) I can see it being potentially problematic especially if one has customised the relevant paths, if the paths have not been customised one would hope the update would include a script to update defaults. If a security update is introducing the change then something is awry... This is not really a big problem unless you find out about it the hard way on an extant service (which would look likely from your annoyance, but it would be a big surprise to me if you actually applied upgrade update that way). I personally usually only apply upgrade updates to things like databases if and only if it solves a current issue with the version being run that is actually causing a problem. I would usually wait until the next major OS release unless I wanted or needed some functionality supplied by a newer version. In my experience applying upgrades to stable and functioning services frequently generates more problems than it actually solves.
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." i
?!? Eh! I would have thought problem is to change the paths to reflect the new paths for old config files.. (which to be honest should not be too hard to do even you have rather a lot of installs, just a bit of a nuisance hacking for hour or so with Perl, Python or whatever your script poison happens to be). If you have web scripts that have such values hard wired you have little sympathy from this quarter, (never write code that hard wires values that are not in your control, pass such values by config files or by reading relevant application config files...)
Something is definitely rotten in the decision making process and I haven't heard or seen a single person from the developer side of the house stand up
I am *not* a mysql developer but the decision as described above makes a lot of sense to me... - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkoo6MUACgkQasN0sSnLmgIhLgCgvkvLqpBYwRRcKFlLYmnuPkvz DqYAoMJiDW/pmypdYFA5nbCzw2mGb4NS =E+xn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2009-06-05 at 10:43 +0100, G T Smith wrote:
I personally usually only apply upgrade updates to things like databases if and only if it solves a current issue with the version being run that is actually causing a problem. I would usually wait until the next major OS release unless I wanted or needed some functionality supplied by a newer version. In my experience applying upgrades to stable and functioning services frequently generates more problems than it actually solves.
And of course you always test updates before applying them to production systems; therefore you never get caught by such things. Because that is that is sound administrative practices, applying updates directly to production systems is *not* (unfortunately apt/yum/zypper have poisoned allot of people's practices). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 05 June 2009 09:09:51 David C. Rankin wrote:
Who in openSuSE signed off on this change? Christian, was that you? maybe Anders...
First of all, no one "signs off" on packages in the build service. The maintainer of the repository can do more or less what he wants with the packages there, it is by definition experimental, and as others have pointed out, you install them on an important production machine at your peril. These repositories are there to provide early access to new package versions, experimental builds with non-standard compile options, packages not otherwise included in the distribution, and other such things. It is meant to be community driven, so you should consider yourself part of the process - talk to the maintainer of the repo in case of problems, or perhaps even become a maintainer of your own repo. Secondly, even if there were a signing-off process, I couldn't sign off on anything anyway. You're mistaking me for someone with influence Anders -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 05/06/09 03:09, David C. Rankin wrote:
, the phone line lights up with angry people wanting to know why none of the web pages work anymore.... Bad news mate!
I assume the "breaking" web pages use PHP right ? then your are doing it wrong, you must update PHP as well... there is no explicit default socket in php configuration, so it is taken from what mysql reports at build time...
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...
Oh dear god, there we go again... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2009-06-05 at 09:07 -0400, Cristian Rodríguez wrote:
On 05/06/09 03:09, David C. Rankin wrote:
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... Oh dear god, there we go again...
The heads (and jobs) that *should* role are those of admins you apply updates without testing. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 05/06/09 09:25, Adam Tauno Williams wrote:
The heads (and jobs) that *should* role are those of admins you apply updates without testing.
Exactly. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Friday 05 June 2009 02:09:51 David C. Rankin wrote:
Listmates, <snip> 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.
The purpose of this entire thread wasn't to throw rocks (although a stone or two were cast), the purpose was to shed a little light on the way in which openSuSE currently approaches them. If LSB changes are being made (which is a good thing), the changes should be forward looking changes from an openSuSE release standpoint (starting with 11.2 and going forward), *not* a package version standpoint (mysql 5.1) with the core config changes then backported to releases not originally released in that manner. From an implementation standpoint, core changes that cause problems should not be backported when it is simple to just leave the cnf and spec files for older releases "as is." Understandably, there will be some situations where this isn't possible, but in the cases where it is, like the present situation with mysql, hundreds of thousands of reconfigs can be avoided. The issue isn't a "well then don't use buildservice", that is a strawman argument that does nothing to address the issue or correct the way build service is handled. We want (and need) people to use buildservice and to test and report problems so that issues can be addressed before problems end up in a boxed set. If packages are packaged correctly and if dependency checking is properly working, then in theory, you should be able to have every build service repo enabled, update, and not have any configuration or package incompatibility issues. The current issue brought to light with the mysql 5.1 pid and socket directory changes is the issue of "backporting core configuration changes that break running systems". It doesn't matter whether you are testing the 5.1 packages or need functionality provided by 5.1, the results are the same. You update, and your databases die. Let's not forget, this problem was discovered and a bug report written many days *before* the first bit of information was released advising about the directory changes through the announce list. The following is exactly what happened in this case: The package update ran last week on one of my openSuSE 10.3 servers with a completely default /etc/my.cnf. Pointing a browser at the server to access a web page returned: "Couldn't connect to server" Which is the error message generated by the php script: [05:15 ecstasy:/srv/www] # cat secure/mysql-log.php http://'.$_SERVER['HTTP_HOST'].$_SERVER['PHP_SELF']; $referer = $_SERVER['HTTP_REFERER']; // Connect to database and Insert Information $connection = mysql_connect($host,$user,$password) or die ("Couldn't connect to server"); <snip> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The cause of the problem? [05:19 ecstasy:/etc] # nc my.cnf [client] port = 3306 socket = /var/run/mysql/mysql.sock [mysqld] port = 3306 socket = /var/run/mysql/mysql.sock datadir = /var/lib/mysql <snip> The fix (root of course): rcmysql stop ## If you forget this, you will have more problems... perl -p -i -e "s/\/var\/run\/mysql/\/var\/lib\/mysql/" my.cnf rcmysql start 'F5' Ok, my web server will now allow a connection. Again, the point being made is, "why break 9.0 - 11.1 servers by backporting changes that reorganize core system files to directories completely different from the way 9.0-11.1 were released and are currently functioning?" It is a one-to-many relationship. Instead of maintaining the working configuration for prior releases, changes like this force every single user or admin that runs mysql to go through the process of fixing it. Highly inefficient and unnecessary if avoidable. (5-20 min. fix) X (# of people that update) ----------------------------- = a whole lot of lost time If it is a LSB compatibility change scheduled for 11.2 release -- fine, then I think the better approch is to roll it out in 11.2, but don't backport the problems it will cause to prior releases through build service. Just don't change the cnf and spec files in packages built for prior releases. Why can't that be the policy? I'm not picking on Michal or anyone else. I'm glad the changes are being made to get the distro (and all distros) LSB compliant which will really help SW development of packages for Linux in general. I just want to rethink the way we release these type of updates through buildservice. My hope is that after the issue is analyzed, we set a standard that protects the core configuration for prior releases from these type of changes that cause reconfiguration of all existing boxes that update if the reconfiguration can be simply prevented by not backporting changes that break existing configurations. If not, then at least there has been a reasoned decision made by the current decision makers that standardizes or clarifies what we can expect from buildservice packages and buildservice repositories. After all we have "factory" repositories where "we know what to expect." But there is no "factory/server" or no "factory/KDE/Backports" repository, and there hasn't needed to be. I can only think of 3 or 4 times in the past 5 years of updating where this has been an issue. But the issues have been big. Thankfully, this change is easy (after you learn how to accommodate it) to fix. But in the exact same vein, kde3 now has a broken kdiff3 that no longer integrates with konqueror because somebody built the 10.3 packages against the kde4 runtime and apparently that bug is just going to be left unfixed. KDE4 was just a twinkle in somebody's eye when 10.3 was released, why packages are built against the kde4 runtime for 10.3 repos just escapes reason. There needs to be some standard for buildservice to prevent this destruction of functionality on prior releases. It just seems a bit more logical to not do things that we know will break packages for prior releases. If these type of changes are going to be made in the next release, then don't backport the changes. Seems simple enough. Thanks for the good discussion on the issue and hopefully packaging for prior releases can be standardized as a result. -- David C. Rankin, J.D.,P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 09/06/09 11:19, David C. Rankin wrote:
perl -p -i -e "s/\/var\/run\/mysql/\/var\/lib\/mysql/" my.cnf
rcmysql start
No, you have to install an updated PHP version or change the default_socket in php.ini. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (9)
-
Adam Tauno Williams
-
Anders Johansson
-
Carlos E. R.
-
Cristian Rodríguez
-
David C. Rankin
-
G T Smith
-
Lars Müller
-
Michal Hrusecky
-
Peter Poeml