CLARITY re: challenge: end of life for 6.2 is prematurewithbuggy 6.3

[Marian Hettwer]

On Wed, 11 Jun 2008 18:50:57 +0300, Anton - Valqk <lists at lozenetz.org>
wrote:
> Thanks for the answer!
> I'm glad someone answered me a human way,
> because two times before, I wasn't answered that way
> (well... my posts were angry and incomplete but...that's why i didn't
> continued to post...my bad).
>
Well then, lets continue answering in a human way. Which is, funnily
enough, usually the more productive way too ;-)
 
> now on topic:
>
yeah!
 
>> Thats unfortunatly true.
>> But there is a way around. As soon as you have several FreeBSD boxes,
> I'd
>> advise you to install your own FreeBSD box for packages building.
>> So if you need to update your php installations, go to your build box
>> (which has the very same versions of programs installed as your
> production
>> boxes), update your ports tree and do a "make package" of your new php
>> port.
>> If the new php package works fine on your build box, roll it out via
>> "pkg_add -r $NEWPHPTHINGY" and off you go.
>>
>>
> I do have a build server(well a jail but works for me), also I have test
> eviornment (jailed too).
> I use this jail to build all my pkgs and use pkg_add -r (sweeet!!).
> For most of the ports this works, but sometimes something in make
> package breaks and i get a port installed partially
> (last case - apache22 got installed but no /usr/local/etc/rc.d/apache22
> rc script, previous - pg_ctl never got installed)
> and in +CONTENTS file the missing files claimed to be there.
hm... sounds like a bug to me. On the other hand, you have to try to get it
to be reproducable. If it's a one timer then yes, it's annoying, but really
really hard to reproduce and therefor to fix.

> I've had to rebuild that kind of port so I can install it again (after
> pkg_delete) to have the port working.
yeah, annoying.

> This happens most often when I do make install package-recursive (so I
> can get all needed ports installed).
If you can reproduce it step by step, it may be worth posting to ports@
again with what you did and what happened.
Either you're doing something wrong, or something is broken.
However, it needs to be reproducable. At least in your environment. As a
starter, so to say :)
The more detailed your steps are written down, the more likely someone will
either follow those steps or give you a direct hint on "humm, could be
something bad over there... hm hm).

> Another strange thing is that when I use php-extensions to build all
> that I need (this takes most of my time when build/install new php)
> breaks because of the ?'bug'? described few lines above. as I said noone
> got interested in this problem...
I can't say anything specific about the php problem you said. I'm not using
php, or well, very rarely. I'll give it a try to update it the make package
way next time.
Unluckily this is a one-box only system. hmmm... If I find the time to
test, I'll drop you mail. But time is rare (admin life vs. normal life).

To cut that short: Yeah, I can understand that this is annoying. But I'm
sure as hell:
- if it's a bug it can be fixed
- if it's a user error, it can be changed
- and all this has happened to me when trying to build my own debian
packages too ;)
And it happened to me with Gentoo, too.
Nothing new at all. Just the regular annoyances in sysadmins life. IMO :)

>>> Another _very important_ thing is that there is no binary support to
>>> packages that has vulns,
>>> and you have to rebuild them from ports.
>>>
>>>
>> Well, its one time doing a make package...
>> Even debian has no plus point there (at least in our environment at
> work).
>> We pretty much always need our Apache 2 custom build, not the way the
>> Debian projects build it. Thus we have a Debian build box around and
> build
>> our own Apache 2.2 package.
>> This is, indeed, the same amount of effort you would have when using
>> FreeBSD.
>> IMO the overhead in Debian to build a package is higher than in FreeBSD,
>> but YMMV.
>>
> If you build packages from source then debian just sux (much more
> complex and long procedure), but there is a tell - "if you do it with
> debian - do it THE DEBIAN WAY"...  :-).
I am doing it the debian way. Using the debian source package and try to
update from there. Still its a more complex procedure then upgrading a
FreeBSD port.
I just can't use the prebuilt debian packages. So where's the Debian way
from that point?!

> I totally agree with that, but on all debian machines I use packages
> provided from debian, because they've made it very modular,
> and I was able to config them the way I need and everything is working
> for me.
You're lucky then :)

> In 99.99% of the cases when I do apt-get dist-upgrade the machine works
> like a charm after it, and that's a fact (in fbsd when make installworld
> too, but not for ports - which is the focus here).
Right. One should never mix up, that Debian is, well, a kernel and a whole
lot of software, whereas in FreeBSD you really have a line between the base
OS and later installed software (ports).

> Actually that's what *BSD prouds with - building everything from source
> (like gentoo), well it's a must to be simplified then (debian where
> everything is supposed to be used from bin .deb) :).
>
I really don't think that *BSD is proud about building everything from
source. Since we now even have freebsd-update to binary update FreeBSD
itself. And you usally find prebuilt packages too.
No, No. IMO FreeBSD isn't proud about building everything from source :)

I do have that feeling about Gentoo users, though *g* 

> 
> About the bug fixes, I think if that's a SECURITY backport it shouldn't
> fix bugs, because I've saw few devs deploying an app and the were using
> 'known bug' in ruby to work with.
> so they were unable to use higher version of ruby that got this bug
> fixed. (we'll obviously a developer mistake in design but if it's in a
> production will take months to redesign - not an option).
hhhmm... but then you're really in trouble. This is a situation... well,
hell no. I don't wanna be in this game.
A bug in a peace of software can lead to uncontrolled shutdown or could
even evolve into a security whole.
If possible I don't want bugs.
If there's an application which just runs with the buggy version of ruby
(perl, python, whatever), then lets start beating the devs. Literally
speaking ;)

> Which is why maybe it's better not to fix bugs but just vulns in
> SECURITY backports (according to me of course) - if you need that bug
> fixed, then install new version.
>
Opinions really will vary on this topic.
In my MySQL example, we want to have the bugfixed version, 'cause those
bugs are really bad.
Same counts for Apache (not as often as MySQL, though).
 
>> hhmm... I really can't agree on that statement.
>> If you do your admin work in a clean and sane way, most of the time
> spend
>> for updating boxes is spent on testing the change before upgrading. The
>> difference between a "debuild" for building a new package, and then
> apt-get
>> upgrade / update them on your box vs. "make package" and pkg_add -r them
> on
>> your box is really slim...
>>
>>
> If you build from src on debian - yes, but as I explained i use debian
> .debs and for me it's much faster, because on fbsd ports I have the
> problem described before,
> and is very common case to rebuild and rebuild port until it puts all
> the files in the .tgz :(
Well yes, thats true.
However, take a look at the Latest packages on FreeBSD's ftp mirror. There
are new versions available pretty often.
On the other hand, you said, you want to have the same version, just
security fixed.
Well, I bet the FreeBSD ports team just can't do that, due to a lack of
manpower.
Really. Throw in a whole lotta money to employ a few people, or do it your
own.
The existing team is doing a wonderful job in keeping the ports tree up to
date and trying to keep the pr-database as low as possible.
But from what I know the existing team really doesn't look like it can
handle -security branches of the ports tree.

> 
> So, a story happened recently:
> I've had a disk down (ad2) of course it was in gmirror and the situation
> was 'ah, damn, but it's ok'...
> but... when I rebooted the server it occured that ad2 was ACTIVE and
> maybe last fresh and ad0 was DIRTY,
> ad2 didn't failed at 100% it was responding and found by the bios (and
> kernel) but when files were requested it timed out.
> The problem occured when tried to boot from the second disk (ad0)
> attached with ad2 (at this moment i didn't know that it fails when disk
> io occurs).
> because the ad2 was fresh and ad0 was dirty the gmirror failed to mount
> and boot OS because it was trying to sync data from partly failed disk,
> and it wasn't able to.
> I've shutdowned the machine, plugged out the ad2 disk and fired up again
> hoping gmirror will be smart enough to boot from ad0... but no luck,
> I was forced to mount root filesystem with no mirror (ad0s1a) and run
> the server in no mirror mode so I can have this critical machine running
> while I find a new disk (few hours later I got it).
> And the nightmare's just began... when I placed the new disk, the
> gmirrored volume was still trying to sync from ad2, ofcourse, the ad2
> had no info on it (thanks god gmirror was smart enough to not copy the
> empty disk).
> I've had to rebuild the whole gmirror partiions, copy the info from a
> non-mirrored disk (ad0) and etc.etc... you know the procedure... this
> took me more than 10 hours and about 5hours downtime on a critical
> machine....
Shocking story. huuu...
I can't comment on that story though, because
- at work, we're on Debian with hardware raids, no software raid even there
- my own experiments with gmirror never lead to such a scenario. I should
try to beat the disk to death, next time I test gmirror ;)

> I suppose this has something to do with the priority in gmirror but I
> don't have the broken disk to test - it's being replaced because it's in
> warranty.... but anyways... 10 hours lost and 5hours downtime...
> now I'm purchaseing a 3ware hw raid because I know that I can't trust
> gmirror...
>
We don't trust LVM and co either.
But don't ask me why. I believe it's more like a "feeling" than real facts.
So I better don't start to discuss this matter.
 
> Another strange thing, I've used to use apache22-worker cutom compiled
> and thread_safe perl, the apache-worker stopped working on a jail (only
> on one!) and I had to add replacements ot pthread.so in /etc/libmap,
> I've been adviced not to use worker (as I did) but why the heck after
> upgrading from 6.3-STABLE to 6.3-STABLE-p3 I got my apache broken and
> also cron stopped working.
To few facts. Never happened to me and without details I really can't
comment.

> strange uh? and all this is in only one jail (I'm using ez-jail to
> update the world)... if anyone can help me to fix my cron without
> reinstalling this jail I'd be thanksful!
>
You should open another mail thread on that topic and try to gather as much
facts as you can.
 
Cheers,
Marian