From owner-freebsd-stable@FreeBSD.ORG Wed Jun 11 16:17:34 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 28CDB106566B for ; Wed, 11 Jun 2008 16:17:34 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from crivens.kernel32.de (crivens.terrorteam.de [81.169.171.191]) by mx1.freebsd.org (Postfix) with ESMTP id 914D48FC0C for ; Wed, 11 Jun 2008 16:17:33 +0000 (UTC) (envelope-from mh@kernel32.de) Received: from www.terrorteam.de (localhost [127.0.0.1]) by crivens.kernel32.de (Postfix) with ESMTP id 08C08B0290; Wed, 11 Jun 2008 18:17:31 +0200 (CEST) MIME-Version: 1.0 Date: Wed, 11 Jun 2008 18:17:31 +0200 From: Marian Hettwer To: Anton - Valqk In-Reply-To: <484FF461.6000306@lozenetz.org> References: <484FF461.6000306@lozenetz.org> Message-ID: X-Sender: mh@kernel32.de User-Agent: RoundCube Webmail/0.1-rc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Cc: Andy Kosela , freebsd-stable@freebsd.org Subject: Re: CLARITY re: challenge: end of life for 6.2 is prematurewithbuggy 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 16:17:34 -0000 On Wed, 11 Jun 2008 18:50:57 +0300, Anton - Valqk 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