-----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 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 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