Re: So, anyone knows wtf Apache.pm is? Was: Re: Testing upgrade and consequences
On Thu, Mar 15, 2001 at 02:03:37PM -0600, Nathan E Norman wrote: > On Thu, Mar 15, 2001 at 09:32:23AM +0100, Paul Slootman wrote: > > On Wed 14 Mar 2001, Dimitri Maziuk wrote: > > > > > > Hmm, interesting... Why tf did I install apache-perl in the first place? > > > > Because the combination apache + mod-perl had/has(?) a pretty bad memory > > leak? Which was why apache-perl was created in the first place. > > Is this an issue with certain versions of apache & mod_perl? Do you > know if it's been resolved? It has been 'somewhat' resolved, in both potato and unstable (I -think-). The problem is that a lot of libraries are not good about freeing memory when they expect the program to exit, and thus when they restart they leak a bit. -- Daniel Jacobowitz Debian GNU/Linux Developer Monta Vista Software Debian Security Team "I am croutons!"
RE: Testing upgrade and consequences
#: One thing I now realize I *am* apparently guilty of -- and that is #: having too high an expectation of what Debian is capable of #: delivering #: from upgrades such as testing. I'd say that unfortunately, you are guilty of not realizing the purpose of Testing. Testing exists to make mostly stable packages with no known major bugs available. If you had tracked Testing from the beginning (as I have) then I doubt that you would have many problems. Do things glitch? Of course they do. #: In my defence, I have to say that this expectation is born of five #: years' practical experience of using Debian (stable) as my normal, #: everyday working environment, for commercial purposes -- without any #: problem. I have no experience at all of running unstable -- #: I haven't #: time to play with stuff that is likely to let me down. #: However, I *do* #: have a hell of a lot of experience of running stable -- and #: I obviously #: expected (a lot) more from the half-way house that I thought testing #: would be than it is currently capable of. (Shame about that.) #: Short-sightedness/over-expectation on my part, obviously. Just because a package is in Testing doesn't mean that all of the proper dependencies and helper programs work perfectly. You are even warned about this with the announcement of Testing. With the freeze, all of these things are to be worked out, but the goal for that is an overly optimistic July IIRC. When the next 'Stable' rears it's head, you can be sure the upgrade will be as smooth as the last. Ron Mullins --I don't believe in signature lines. That is why I never do one.
Re: Testing upgrade and consequences
(I'm not subscribed to this list, due to volume of traffic; but was
advised today to follow up the thread via archives. Please cc any
further comments/responses to me personally off-list. Thanks.)
Many thanks to all who responded both on- and off-list; particularly
those who pointed out the problems associated with apache-perl -- of
which I was unaware before attempting this upgrade. (Like others, I've
always used apache + {additional_perl_stuff}.)
[I'm slowly isolating apache-perl as having been the key trigger to the
cascade of major breakages which followed]
One thing I now realise I *am* apparently guilty of -- and that is
having too high an expectation of what Debian is capable of delivering
from upgrades such as testing.
In my defence, I have to say that this expectation is born of five
years' practical experience of using Debian (stable) as my normal,
everyday working environment, for commercial purposes -- without any
problem. I have no experience at all of running unstable -- I haven't
time to play with stuff that is likely to let me down. However, I *do*
have a hell of a lot of experience of running stable -- and I obviously
expected (a lot) more from the half-way house that I thought testing
would be than it is currently capable of. (Shame about that.)
Short-sightedness/over-expectation on my part, obviously.
But for those who seem to think that clients should never be exposed to
upgrading, I would say: "First know your clients" !
Mine range from horrendously technically competent developer /
administrators who are into writing their own printer drivers (from
scratch) by day 4 of their first course (sic); to those who have *never*
used a command-line interface in their entire IT career.
And Debian's ability to upgrade simply, quickly, and without fuss is its
MAJOR advantage over every other distribution going, for those who know
how to handle it. I teach/demonstrate this to over half of my clients.
[Who absorb the information; then instantly regress to the distribution
which gives them the sexiest graphical interface -- 100% predictably
S.u.S.E. + KDE. Developers please take note.]
Does this help y'all to better understand my reaction?
msw
--
Martin Wheeler -StarTEXT - Glastonbury - BA6 9PH - England
[1] [EMAIL PROTECTED] http://www.startext.co.uk/
Re: So, anyone knows wtf Apache.pm is? Was: Re: Testing upgrade and consequences
On Thu, Mar 15, 2001 at 09:32:23AM +0100, Paul Slootman wrote: > On Wed 14 Mar 2001, Dimitri Maziuk wrote: > > > > Hmm, interesting... Why tf did I install apache-perl in the first place? > > Because the combination apache + mod-perl had/has(?) a pretty bad memory > leak? Which was why apache-perl was created in the first place. Is this an issue with certain versions of apache & mod_perl? Do you know if it's been resolved? -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgppWMJzSey7e.pgp Description: PGP signature
Re: So, anyone knows wtf Apache.pm is? Was: Re: Testing upgrade and consequences
On Wed 14 Mar 2001, Dimitri Maziuk wrote: > > Hmm, interesting... Why tf did I install apache-perl in the first place? Because the combination apache + mod-perl had/has(?) a pretty bad memory leak? Which was why apache-perl was created in the first place. Paul Slootman -- home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/ work: [EMAIL PROTECTED] http://www.murphy.nl/ debian: [EMAIL PROTECTED] http://www.debian.org/ isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.org/
Re: Testing upgrade and consequences
On Wed, Mar 14, 2001 at 06:22:28PM -0600, Dimitri Maziuk wrote: > > But I doubt whether any developer could reproduce this system exactly > > without an accurate image of my machine state; so I'll start with the > > big problem (apache) and try to send in a fuller description of all the > > problems encountered once I've sussed how to do 'proper' bug reports, > > and where to send them. > > FWIW, purging apache-perl and installing apache and mod-perl fixed that > for me. Are you loading mod_perl in the apache config? I've been trying to do this (your post made me wonder, but I want to use Mason and mod_perl anyway) ... I can't get this to work using woody packages. What perl version do you have installed? -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpZvCyVMWdCc.pgp Description: PGP signature
Re: So, anyone knows wtf Apache.pm is? Was: Re: Testing upgrade and consequences
On Wed, Mar 14, 2001 at 03:39:53PM -0600, Dimitri Maziuk wrote: > On Wed, Mar 14, 2001 at 02:17:08PM -0600, Nathan E Norman wrote: > ... > > Have you tried running apache (not apache-perl) and loading mod_perl? > > It looks to me like you've got some problem caused by the prel 5.6 > > upgrade. > > Hmm, interesting... Why tf did I install apache-perl in the first place? > > I purged old apache-perl with --force-depends to get a clean slate and > installed apache. Apacheconfig is still b0rken (there's a full output > in one of my previous posts if anyone's interested) so I edited config > files and finally got apache to run. Well, that's good :) Perhaps you want to use RCS or CVS to track config changes ... > The next update that runs apacheconfig will presumably break it again, > but that's way better than rebooting your box and finding out that > apache won't start anymore. So don't let apacheconfig make changes! Always answer "n" to thje prompt. FWIW I can't get stock apache from testing/unstable to play nice with mod_perl. Investigating further ... -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpKJ06YsiPqU.pgp Description: PGP signature
Re: Testing upgrade and consequences
On Wed, Mar 14, 2001 at 11:25:26PM +, Martin WHEELER wrote: > On Wed, 14 Mar 2001, Joey Hess wrote: ... > > And things broke. This is a suprise? > > Yes. > Shouldn't it be? Please explain. > (This is the method I have used to incrementally upgrade my installation > for the past two years -- without problem.) > Why should I expect things to break using this method? > [This is a genuine query. Don't understand your stance. Really.] If it isn't labelled "stable", things may break. If you try to updgrade the whole distribution plus a bunch of 3rd party software to an unstable snapshot of a not-yet-released distro... well, _I_ would expect things to break. All of them. So yes, you should expect thing to break in these circumstances. I was fortunate: I had a clean box so I could load up minimal potato, upgrade to testing and then install the stuff I need. That was painless. > But I doubt whether any developer could reproduce this system exactly > without an accurate image of my machine state; so I'll start with the > big problem (apache) and try to send in a fuller description of all the > problems encountered once I've sussed how to do 'proper' bug reports, > and where to send them. FWIW, purging apache-perl and installing apache and mod-perl fixed that for me. Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) I'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script
Re: Testing upgrade and consequences
On Wed, 14 Mar 2001, Joey Hess wrote: > It's like this. You upgraded to a not-yet-released, beta quality version > of debian. This I *now* know. Before upgrading I was given to understand that testing was a relatively problem-free upgrade to undertake -- not the rat's nest of incompatibilities and error-messages I ran into. > You seem to have done some pretty horrendous hacking to work > around dependancy problems, instead of reporting them: Why horrendous? Stuff broke. I fixed it. (For my own system.) And just how does one report a blanket suggestion that 452 system files be removed in one go? > > This I declined; and proceeded to (re-)install packages individually > > from an apt-get --just-print dist-upgrade list. > > And things broke. This is a suprise? Yes. Shouldn't it be? Please explain. (This is the method I have used to incrementally upgrade my installation for the past two years -- without problem.) Why should I expect things to break using this method? [This is a genuine query. Don't understand your stance. Really.] > This will all get fixed if you file sane bug reports on each item (sane > == including enough information for the developer to reproduce your > problem). If you just rant, you will be ignored. No -- I've already had a response from someone whose judgment and opinions I usually tend to respect :) (And ranting is good for the soul when you've just spent 10 days doing an almost total rebuild of a complex system. Thank your lucky stars you're not Andrew -- as my nearest developer contact, he had to put up with the phone calls every night.) But I doubt whether any developer could reproduce this system exactly without an accurate image of my machine state; so I'll start with the big problem (apache) and try to send in a fuller description of all the problems encountered once I've sussed how to do 'proper' bug reports, and where to send them. msw -- Martin Wheeler -StarTEXT - Glastonbury - BA6 9PH - England [1] [EMAIL PROTECTED] http://www.startext.co.uk/
Re: Testing upgrade and consequences
On Wed, Mar 14, 2001 at 05:40:29PM +, Martin WHEELER wrote: > > > He upgraded > > from a Potato 2.2r2 system to current "testing" and most things broke in > > serious > > ways, such that he swears he will never again move from stable releases. > > And *how*. > > NEVER again. (Certainly not for client-critical systems.) > I don't need to comment on that. Other people already have. > On attempting upgrade to testing, first thing I was presented with was a > decision to >>remove<< 402 Mb of system files (452 packages). > Yup, testing is somewhat messed at present (that's not intentional, needless to say). You should probably have guessed that something was very wrong... you realise that the developers aren't actually out to break your system? > This I declined; and proceeded to (re-)install packages individually > from an apt-get --just-print dist-upgrade list. > See "put package on hold" > Things started to break/dependency-loop almost immediately. > (The persistent offenders I remember most at this stage are exmh and > kdeadmin.) The dependency circus engendered was horrendous. > Yeah, that happens sometime. It's a beta-quality distribution. > Everything that was not "Debian-approved" got blown away. > (I run lots of non-free stuff on my Debian systems. I have no > ideological problems with this.) > Uhhh no. Read the social contract. Debian carries non-free and contrib, there's no attempt to force you into using free packages, only repeated encouragement (see vrms). What happened was that everything which was fulfilling one of these two categories got removed: a) package was dependant on something which was removed due to the testing mess, see above. b) package was =version dependant on something in potato (bad packaging/bug), so you would need to either find an official debian version, or one built for woody (testing) - you can't usually run packages from one release on another safely unless you know exactly what you are doing (recompiling from source into a new .deb will do the trick) > I was no longer able to go online. (diald had been installed -- without > asking -- on top of pppd.) > Oops. That one is probably a bug. > > Mailman configuration broke > -- due to fact that ALL apache confiiguration files/directories were > simply annihilated. Again -- no warning; no explanation. > Never used it myself... possibly another bug (hey, it's not called "stable" for a reason) > > Pine broke > -- discovered that something had reconfigured my smtp server (wasn't > asked; wasn't warned -- just another example of the "Debian-disapproved > -- therefore OK to blow away" syndrome experienced throughout this > whole attempt to upgrade.) > Far more likely is "not supported in debian due to licensing issues". Debian is not permitted to redistribute (modified) pine binaries. This kind of means that developers are disinclined to explicitly test it... although in this case, I'm guessing it wasn't pine related. Did you reconfigure the smtp server manually somehow? I'm guessing that you modified a configuration file directly when you should have used debconf/a source file (see /etc/modules.conf vs. /etc/modutils - suggestions on what could have caused this anyone?) and debian assumed that the changes to the config file were not of your doing, so put it back how you had told it (or not told it) you wanted it. > > Mutt works, but is not his preferred option. > Yeah -- but it's "Debian-approved", innit? > Will you quit with that? Read the social contract already. > > Exim configuration didn't, such that he reverted to smail. > -- conflicted with mailman -- not flagged. > > > He won't believe me > > when I say that Exim works fine. > > [Not for me it bloody well doesn't. Not after *this* upgrade.] > Factoid from apt, a bot on #debian: Look buddy, doesn't work is a strong statement. Does it sit on the couch all day? Does it want more money? Is it on IRC all the time? Please be specific! > > Most seriously of all - "Apache in Debian is seriously broken" > > > > There may be a dependency loop on apache-perl which is inappropriate. > > This is the real crux of the matter. > I CANNOT recommend this type of upgrade to any of my clients. > My existing apache configuration was totally wiped out. > Conflicting and inconsistent dependencies between apache and apache-perl > prevented re-installation. > (I eventually managed it by forcing something -- can't remember what, > now. I ended up with apache-ssl; and a version of apache-perl that > still can't be purged.) > This would be instant death to any of the clients I deal with -- I am > not surprised that some of them ban debian entirely. > dselect is arcane... dependency loops can be broken... or you can use dpkg --set-selections... apache-perl has been known to have problems, but you most certainly can force uninstall it... I am not suprised you have troubles with testing - it's not for those who don't u
Re: Testing upgrade and consequences
On Wednesday 14 March 2001 5:40 pm, Martin WHEELER wrote: > On Tue, 13 Mar 2001, Andrew M.A. Cater wrote: > > He upgraded > > from a Potato 2.2r2 system to current "testing" and most things broke > > in serious ways, such that he swears he will never again move from > > stable releases. > > And *how*. > > NEVER again. (Certainly not for client-critical systems.) This salutory tale has a number of lessons for us all. Firstly _NEVER_ trust the software. Even if it is dselect/apt-get/whatever and Debian. Always RTFM then read the message you're getting back and if you don't like what you see _bail out_. Secondly don't, IMO, expect anything on the bleeding edge to work properly. Debian has two beautiful aspects (speaking as a refugee from NT and RedHat): it is very conservative and hence very stable; and apt-get install is one of the neatest ideas I've seen. The important thing there is the first point, this rather than freedom should be the USP of Debian as far as business is concerned. Systems don't have to chase beta releases of every package, only upgrade if you _need_ to (e.g. if you must have USB support in your kernel). Thirdly, keep a backup. Do one now just to make sure. I've only been using Debian GNU/Linux for a couple of months and early on I tried to do a dist-upgrade or similar. Got a message saying that broadly my whole system was about to be nuked and quickly pressed Ctl-C. Now I accept lagging behind a little, I've upgraded KDE to 2.1, but otherwise very little will change on this box. As regards packages which are imporant but which may not be *Debianized*, I put things like Java, Star Office and Adobe Acrobat in /opt. If you have /opt and /home on different partitions to / then you can keep anything important and unique to you quite safe. The Debian tools are then relatively free to play with _their_ packages without endangering _your_ applications. I mention this because Martin seems to have lost things like SGML DTDs which should never have been placed in unsafe locations. I have two installs on my hard drive, one's a small emergency system so that if my main install gets damaged I can still access /home and /opt _and_ save those areas if I reinstall. Final thought, are these Debain tools suitable for business users? Should any business auto-update anything? Probably not, certainly not on a critical system. Businesses should use stable + security updates + upgrading key software only if it provides vital features. IMO, of course. -- Chris Bates ([EMAIL PROTECTED]) Web Programming: Developing Internet Applications published by John Wiley & Sons, Sept, 2000 http://www.shu.ac.uk/schools/cms/teaching/crb
Re: Testing upgrade and consequences
On Wed, 14 Mar 2001, Chris Bates wrote: > Debian has two beautiful aspects (speaking as a refugee from NT and > RedHat): it is very conservative and hence very stable; agreed -- this is why I have been using it since 1996 > and apt-get install > is one of the neatest ideas I've seen. likewise -- this is the biggest plus point Debian has for me. > I've only been using Debian GNU/Linux for a couple of months and early on I > tried to do a dist-upgrade or similar. -- I've been doing a dist-upgrade every night for the last eighteen months. Any problems have been really minimal. I *trust* it. > As regards packages which are imporant but which may not be *Debianized*, I > put things like Java, Star Office and Adobe Acrobat in /opt. Which is where mine were. Didn't stop StarOffice from being nuked, tho. > I mention this because Martin seems to have lost things like > SGML DTDs which should never have been placed in unsafe locations. No -- didn't lose *any* DTDs. (They're safely catalogued.) Mainly lost apps and above all, configuration files for apps. No idea why the configuration files & directories seemed to be so badly nuked. > Final thought, are these Debain tools suitable for business users? Yes. (Professional sysadmins love 'em. Trainee sysadmins really appreciate the ease of upgrade -- once they've fought with a couple of non-installable RPMs, that is. Workstation *users* should never see them.) > Should > any business auto-update anything? Probably not, certainly not on a > critical system. *Definitely* not on critical systems. Stable only; and nothing else. (I just had a hankering to try testing, is all. ) > Businesses should use stable + security updates + > upgrading key software only if it provides vital features. Absolutely. -- Martin Wheeler -StarTEXT - Glastonbury - BA6 9PH - England [1] [EMAIL PROTECTED] http://www.startext.co.uk/ - Share your knowledge. It's one way to achieve immortality. -
Re: So, anyone knows wtf Apache.pm is? Was: Re: Testing upgrade and consequences
On Wed, Mar 14, 2001 at 02:17:08PM -0600, Nathan E Norman wrote: ... > Have you tried running apache (not apache-perl) and loading mod_perl? > It looks to me like you've got some problem caused by the prel 5.6 > upgrade. Hmm, interesting... Why tf did I install apache-perl in the first place? I purged old apache-perl with --force-depends to get a clean slate and installed apache. Apacheconfig is still b0rken (there's a full output in one of my previous posts if anyone's interested) so I edited config files and finally got apache to run. The next update that runs apacheconfig will presumably break it again, but that's way better than rebooting your box and finding out that apache won't start anymore. Thanks Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) I'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script
Re: Testing upgrade and consequences
It's like this. You upgraded to a not-yet-released, beta quality version of debian. You seem to have done some pretty horrendous hacking to work around dependancy problems, instead of reporting them: > This I declined; and proceeded to (re-)install packages individually > from an apt-get --just-print dist-upgrade list. And things broke. This is a suprise? This will all get fixed if you file sane bug reports on each item (sane == including enough information for the developer to reproduce your problem). If you just rant, you will be ignored. -- see shy jo
Re: So, anyone knows wtf Apache.pm is? Was: Re: Testing upgrade and consequences
On Wed, Mar 14, 2001 at 01:23:02PM -0600, Dimitri Maziuk wrote: > Ok, I'm not in the mood for flamefests today so here's a serious question: > > apache here fails to start with (this is from error.log) > > [Wed Mar 14 12:36:15 2001] [warn] pid file /var/run/apache.pid overwritten -- > Unclean shutdown of previous Apache run? > Apache.pm failed to load!. > > Ok, here's the list of Apache.pm's I have: > > odyssey:/# odyssey:/var/log/apache# grep Apache.pm /var/lib/dpkg/info/*.list > /var/lib/dpkg/info/apache-perl.list:/usr/lib/perl5/5.005/i386-linux/Bundle/Apache.pm > /var/lib/dpkg/info/apache-perl.list:/usr/lib/perl5/5.005/i386-linux/Apache.pm > /var/lib/dpkg/info/perl-modules.list:/usr/share/perl/5.6.0/CGI/Apache.pm > > Questions: > > 1. which of these fails to load? > 2. where is that configured? > 3. where is that documented? (I've already seen /usr/doc/apache-perl thank > you) /usr/share/doc/apache-perl is the documentation for the apache-perl package (apache with perl linked in, not as a module). Have you tried running apache (not apache-perl) and loading mod_perl? It looks to me like you've got some problem caused by the prel 5.6 upgrade. I'll see if apache + mod_perl works here and report back. Luck, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpvvQFMmq1Bt.pgp Description: PGP signature
So, anyone knows wtf Apache.pm is? Was: Re: Testing upgrade and consequences
Ok, I'm not in the mood for flamefests today so here's a serious question: apache here fails to start with (this is from error.log) [Wed Mar 14 12:36:15 2001] [warn] pid file /var/run/apache.pid overwritten -- Unclean shutdown of previous Apache run? Apache.pm failed to load!. Ok, here's the list of Apache.pm's I have: odyssey:/# odyssey:/var/log/apache# grep Apache.pm /var/lib/dpkg/info/*.list /var/lib/dpkg/info/apache-perl.list:/usr/lib/perl5/5.005/i386-linux/Bundle/Apache.pm /var/lib/dpkg/info/apache-perl.list:/usr/lib/perl5/5.005/i386-linux/Apache.pm /var/lib/dpkg/info/perl-modules.list:/usr/share/perl/5.6.0/CGI/Apache.pm Questions: 1. which of these fails to load? 2. where is that configured? 3. where is that documented? (I've already seen /usr/doc/apache-perl thank you) TIA Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) I'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script
Re: Testing upgrade and consequences
On Wed, Mar 14, 2001 at 05:40:29PM +, Martin WHEELER wrote: > On Tue, 13 Mar 2001, Andrew M.A. Cater wrote: > > > I've had to suffer this one - providing telephone support and advice over > > a week plus to an old and valued friend :) [Hi Martin :) ] > > [Hi, Andy! Just about to put this one to the list but you beat me to > it.] > > [ much ranting ] > I CANNOT recommend this type of upgrade to any of my clients. [ more ranting ] _Why_ would you ever suggest to a client that they upgrade to testing? Testing and unstable are intended to be run by people who know what they are doing. It sounds like most of your clients don't qualify. It sounds like you got bit by some perl dependency screwup. If I were you I would have looked at "remove 402 packages" and said "Hmm, think I'll wait on this a bit". As far as the apache configs being overwritten ... I think we are still missing some info here. Apache upgrades have always worked flawlessly here. It sounds to my like you had apache-perl installed, purged it (wiping out your configs - I think I saw this happen once and swore of apache-perl in favor of apache + mod_perl). Then apache was installed, no configs were present so it installed the default bofh configs. I won't comment on the security issues presented by the old config style vs. the new; it's your server. (I can't resist ... I like the new configs. They make sense, but then again I'm a paranoid person). Cheers, -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpMW5Rz4AVvK.pgp Description: PGP signature
Re: Testing upgrade and consequences
On Tue, 13 Mar 2001, Andrew M.A. Cater wrote: > I've had to suffer this one - providing telephone support and advice over > a week plus to an old and valued friend :) [Hi Martin :) ] [Hi, Andy! Just about to put this one to the list but you beat me to it.] > He upgraded > from a Potato 2.2r2 system to current "testing" and most things broke in > serious > ways, such that he swears he will never again move from stable releases. And *how*. NEVER again. (Certainly not for client-critical systems.) System (was) Debian 2.2r2 + proposed-updates + kde.tdyc -- with A LOT of other stuff added. System was used to demo debian to clients -- if client wanted exim, then exim had to be installed and work; if client wanted sendmail, then sendmail had to be installed and had to work -- etc. The system was also set up as a full SGML/XML editing environment (heavy stuff -- EAD and TEI, with a full set of 150+ DTDs). In short, a fully-fleshed-out system for all the different types of work done by any of my clients (document engineering + website development). [On a Celeron 466 with 64M, 4G of hard-disk space, and a Rage128/16M video card + pnp modem card. Typical client kit.] Essentials on system were: apache; perl; php; mysql; postgresql; mailman -- anything you might find on a commercial e-site (Java, Chilisoft ASP, etc) -- also StarOffice, WordPerfect 8 and Netscape/Opera/Amaya/Arena/Mozilla/Chimera/lynx/links/w3m -- plus the inevitable emacs/xemacs, and various HTML/XML-compatible editors. Lots of perl and php scripts for training/demo purposes. On attempting upgrade to testing, first thing I was presented with was a decision to >>remove<< 402 Mb of system files (452 packages). Oh. This I declined; and proceeded to (re-)install packages individually from an apt-get --just-print dist-upgrade list. Things started to break/dependency-loop almost immediately. (The persistent offenders I remember most at this stage are exmh and kdeadmin.) The dependency circus engendered was horrendous. Eventually (after 3/4 days) I got down to just 160 packages left to upgrade -- but so much was already broken that I just left the box upgrading by itself all night. Bad move. Everything that was not "Debian-approved" got blown away. (E.g. StarOffice; Netscape [4.76 from CD-rom, not download]; asWedit; etc.) In all, I lost 20% of my installed system software. Total bummer. (I run lots of non-free stuff on my Debian systems. I have no ideological problems with this.) I was no longer able to go online. (diald had been installed -- without asking -- on top of pppd.) > Mailman configuration broke -- due to fact that ALL apache confiiguration files/directories were simply annihilated. Again -- no warning; no explanation. > Pine broke -- discovered that something had reconfigured my smtp server (wasn't asked; wasn't warned -- just another example of the "Debian-disapproved -- therefore OK to blow away" syndrome experienced throughout this whole attempt to upgrade.) > Mutt works, but is not his preferred option. Yeah -- but it's "Debian-approved", innit? > Exim configuration didn't, such that he reverted to smail. -- conflicted with mailman -- not flagged. > He won't believe me > when I say that Exim works fine. [Not for me it bloody well doesn't. Not after *this* upgrade.] > Most seriously of all - "Apache in Debian is seriously broken" > > There may be a dependency loop on apache-perl which is inappropriate. This is the real crux of the matter. I CANNOT recommend this type of upgrade to any of my clients. My existing apache configuration was totally wiped out. Conflicting and inconsistent dependencies between apache and apache-perl prevented re-installation. (I eventually managed it by forcing something -- can't remember what, now. I ended up with apache-ssl; and a version of apache-perl that still can't be purged.) This would be instant death to any of the clients I deal with -- I am not surprised that some of them ban debian entirely. > The default configuration of apache has changed drastically between Potato > and testing. There was obsolutely NO warning given that existing apache configuration files AND directories (including error log directories) would be obliterated. (I lost everything -- *including* my safe backups of all configuration files) when apache was upgraded. >> The infuriating thing is that I didn't even get an upgrade to Apache 1.3.12 -- which every other distribution has been supplying since mid-2000 -- I got the same old 1.3.9, but this time with a single httpd.conf in place of the previous 3 separate files. << None of my scripting examples worked -- I had to spend three days reconfiguring the whole website. Not funny. > The version in testing is locked down solidly - everything is > denied unless explicitly allowed with apache directives. This is at odds with > the behaviour up to and including potato, which was open. Apache stomped over > his httpd.conf files on upgrade and l
Re: Testing upgrade and consequences
On Tue, Mar 13, 2001 at 03:41:42PM -0600, Chad C. Walstrom wrote: > bash$ at /var/lib/dpkg/info/apache.md5sums | \ ^^ that would be "cat" (missing 'c') > > sed -e 's/usr/\/usr/g' | md5sum -v -c cu Torsten pgpCVF847yyIX.pgp Description: PGP signature
Re: Testing upgrade and consequences
On Tue, Mar 13, 2001 at 03:41:42PM -0600, Chad C. Walstrom wrote: > Redirecting further discussion of this user-based problem to > debian-user... I don't believe it is a user-based problem. It's not the first post saying "perl upgrade broke my apache" -- unless I'm getting e-mail from a parallel universe. I'm not complaining about it either -- I know what "unstable" means. I repeat, I fup'ed because IMNSHO when you see several messages saying "perl upgrade broke my apache", you (no, not you personally) shouldn't answer with "apache in woody is the same version as apache in stable hence [it works fine|it's a luser-based problem|don't bother reporting it]". Follow-ups set as requested, anyway. > > On Tue, Mar 13, 2001 at 02:29:02PM -0600, Dimitri Maziuk wrote: ... Apache failed to start up after that (did you try > > to restart your apache lately? maybe you shouldn't.) > > So... It was working fine, your installation of the "broken" woody > Apache, until your box made a "funny noise"... Sometimes I wonder if I should enroll into an English course. It was working fine, my installation of "working" woody Apache, until I had to reboot the box. Quite a few packages got updated during its (the box's) uptime so I cannot say "I've upgraded this particular package to this particular version on this particular date and Apache crashed right after that". > This doesn't hint to a > larger problem at all, does it? Perhaps you should run fsck.ext2 on > your system's ext2 filesystems and make sure everything is clean and > tidy. Obviously, if I had a fsck'ed up hard drive I wouldn't be blaming apache problems on a woody upgrade. Well, ok, not obviously. Maybe I should start with "... I first installed Debian in -- hmm, what was it, 1994, 1996? -- anyway, around the time of version 1.0. Those were the days..." > Has it occured to you to back up your custom config files in your home > directory, purge the Apache installation, and reinstall? I would not > normally suggest this, as it ignores possible bugs, BUT what you > described above makes it sound like you've got some serious hardware > issues to deal with -- one of them being possible file corruption. No I don't have a serious hardware problem and the filesystem is clean. No I don't have custom config files for apache -- except for my e-mail address everything is as set up by dpkg. I only use apache for dwww and while not having dwww on a local box is annoying, it's not a good enough reason to dig out previous set of tapes, reload the silo, rebuild browse indexes and restore /etc/apache/*.conf that I never really changed in the first place (I'm talking Legato and tape jukeboxes in case you're wondering). > Also, has it occurred to you to actually edit your configuration files > by hand? Yes. Here's what I get with correct conffiles (BTW, why are there 3 of them? I thought everyone's switched to single httpd.conf by now). odyssey:/usr/sbin# ./apachectl start ./apachectl start: httpd started odyssey:/usr/sbin# ./apachectl stop ./apachectl stop: httpd (pid 19342?) not running Log: --- [Tue Mar 13 16:59:17 2001] [warn] pid file /var/run/apache.pid overwritten -- Unclean shutdown of previous Apache run? Apache.pm failed to load!. I think I'll wait for new versions of perl packages before purge/reinstalling. Dima -- E-mail dmaziuk at bmrb dot wisc dot edu (@work) or at crosswinds dot net (@home) I'm going to exit now since you don't want me to replace the printcap. If you change your mind later, run -- magicfilter config script
Re: Testing upgrade and consequences
Redirecting further discussion of this user-based problem to debian-user... On Tue, Mar 13, 2001 at 02:29:02PM -0600, Dimitri Maziuk wrote: > FWIW I installed minimal potato on my box here, upgraded to woody, > _then_ installed apache and it worked fine. I run apt-get every > morning and Apache was still running just fine... until my box made > a funny noise a couple of days ago. I shut it down -- to check the > fans and all that. Apache failed to start up after that (did you try > to restart your apache lately? maybe you shouldn't.) So... It was working fine, your installation of the "broken" woody Apache, until your box made a "funny noise"... This doesn't hint to a larger problem at all, does it? Perhaps you should run fsck.ext2 on your system's ext2 filesystems and make sure everything is clean and tidy. > So, I don't know exactly when/what broke apache. I suspect perl, but > I don't know. I don't have the exact error message either -- > something about Apache.pm -- I thought that something has changed > and I should re-run apache config. I did. Bad move. Has it occured to you to back up your custom config files in your home directory, purge the Apache installation, and reinstall? I would not normally suggest this, as it ignores possible bugs, BUT what you described above makes it sound like you've got some serious hardware issues to deal with -- one of them being possible file corruption. Also, has it occurred to you to actually edit your configuration files by hand? apacheconfig is not a necessity. apachectl(1) will do configuration file tests for you. apachectl - Apache HTTP server control interface configtest Run a configuration file syntax test. It parses the configuration files and either reports Syntax Ok or detailed information about the particular syntax error. e.g. bash$ apachectl configtest Syntax OK Of course, you don't actually have to use apachectl either, try running apache(1) with the test option: -t Run syntax tests for configuration files only. The program immediately exits after these syn- tax parsing with either a return code of 0 (Syntax OK) or return code not equal to 0 (Syntax Error). -T Same as option -t but does not check the con- figured document roots. Have you tried other environments to reproduce the bug, or it simply your current installation that you're having problems with? > Since you asked, here it is: > - > odyssey:~# apacheconfig 2>&1 > > Use of uninitialized value in pattern match (m//) at /usr/sbin/apacheconfig > line 219. > > The icons Alias specifed in srm.conf is non-standard. Fix? [Y/n] > Correcting Alias to /usr/share/apache/icons/ in srm.conf. > > The cgi-bin ScriptAlias specifed in srm.conf is non-standard. Fix? [Y/n] > Correcting ScriptAlias to /usr/lib/cgi-bin/ in srm.con > Your config files will not be modified until you select Y at "save changes." > > Enter the email address of your server administrator. This address > will be used in error messages allowing users to submit reports of > faulty links or misconfigured cgi-programs to you. It should be an email > address that corresponds to a human. > > Who should the ServerAdmin be? [EMAIL PROTECTED] > Use of uninitialized value in concatenation (.) at /usr/sbin/apacheconfig > Use of uninitialized value in concatenation (.) at /usr/sbin/apacheconfig > line 345, line 2. These certainly do look suspect. Perhaps you hould find the md5sums file in /var/lib/dpkg/info/apache.md5sums and check the integrity of the installed files. Perhaps running through something like: bash$ cd /; md5sum -v -c /var/lib/dpkg/info/apache.md5sums or if you don't care to be in /.. bash$ at /var/lib/dpkg/info/apache.md5sums | \ > sed -e 's/usr/\/usr/g' | md5sum -v -c -- Chad Walstrom <[EMAIL PROTECTED]> | a.k.a. ^chewie http://www.wookimus.net/| s.k.a. gunnarr Key fingerprint = B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD pgpqJ12byX3AV.pgp Description: PGP signature
