CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3

[Anton - Valqk]

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

now on topic:

Marian Hettwer wrote:
> Hi there,
>
> some thoughts to your problem in regards to Debian administration time
> needed vs. FreeBSD administration time needed.
> I believe I can make a point there, since I have 600 debian boxes under my
> hood but still am a FreeBSD advocate ;-)
>
>
> On Wed, 11 Jun 2008 12:53:02 +0300, Anton - Valqk <lists at lozenetz.org>
> wrote:
>   
>> My main drama with FreeBSD is that ports don't have -SECURITY patches,
>> and if I there is a bug in php
>> I have to rerbuild and populate the latest version.
>>     
> 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.
I've had to rebuild that kind of port so I can install it again (after 
pkg_delete) to have the port working.
This happens most often when I do make install package-recursive (so I 
can get all needed ports installed).
I've tried to tell this in ports@ and I was answered that "everything is 
working for us" or kind of. no one tried to investigate...
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 have another complain from fbsd but I'll tell about it at the end.
>> 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 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.
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).
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) :).


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


>  
>   
>> Just a simple example:
>> I have 4-5 fbsd machines and about 15-20 debian stable machines.
>> To administer fbsd machines when there are ports bugs(bugs in ports I
>> use) it takes me at
>> least about 4times more time than update _all_ debian machines...
>>     
> depends on the way you go.
> Genereally speaking, you really really want a build and test machine before
> you deploy a security update or even a new version of your software (in
> this case: php).
> Even with Debian boxes you really shouldn't just "apt-get upgrade &&
> apt-get update" but test before!
>
>   
>> Well...I have other things to do too, too many... now guess what I will
>> choose?
>> I'll use debian, and that's not because I don't have will to use
>> freebsd, it's simply because I do my tasks 4 times slower than when I
>> choose debian.
>>     
> 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 :(
>> Someone will say "FreeBSD is not for you, then back off". That's not the
>>     
> I wouldn't say that :)
>
>   
>> Once I've told that there is no binary support (but I didn't expressed
>> myself correctly). There is no ports VULNS binary support.
>> If there is (and I've never heard of it), I'll be very happy someone to
>> point me out this, because I'll continue running fbsd.
>>
>>     
> If you take a close look onto how the debian project is backporting
> security fixes you would probably agree that pretty often it's more
> desireable to jump to a newer version of that software than instead just
> security fixing it.
> Examples needed?
> MySQL 4.1.11 was the "stable" MySQL 4.1 in Debian Sarge. Of course it got
> security fixed, but not bugfixed. You get a secure version of MySQL 4.1 in
> Debian but not a stable one, because important bugfixes are missing.
> I'd rather upgrade to the latest MySQL 4.1.xx instead.
> And of course, do your testing before jumping version numbers.
>  
> I hope that my impressions will help you in working with FreeBSD in a
> server environment.
>
> Cheerio,
> Marian

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

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

too long mail, that's enough :)

cheers,
valqk.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.