From owner-freebsd-stable@FreeBSD.ORG Wed Jun 11 15:51:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C48871065670 for ; Wed, 11 Jun 2008 15:51:09 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from mail.webreality.org (mailserver.webreality.org [217.75.141.5]) by mx1.freebsd.org (Postfix) with ESMTP id 227058FC1D for ; Wed, 11 Jun 2008 15:51:08 +0000 (UTC) (envelope-from lists@lozenetz.org) Received: from [10.0.1.101] (unknown [87.121.18.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.webreality.org (Postfix) with ESMTP id 933BD1522C59; Wed, 11 Jun 2008 18:51:06 +0300 (EEST) Message-ID: <484FF461.6000306@lozenetz.org> Date: Wed, 11 Jun 2008 18:50:57 +0300 From: Anton - Valqk User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Marian Hettwer References: <484FA07E.60103@lozenetz.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-HostIT-MailScanner-Information: Please contact the ISP for more information X-HostIT-MailScanner: Found to be clean X-HostIT-MailScanner-From: lists@lozenetz.org Cc: Andy Kosela , freebsd-stable@freebsd.org Subject: Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2008 15:51:09 -0000 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 > 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.