Date: Thu, 12 Jun 2008 11:59:35 +0300 From: Anton - Valqk <lists@lozenetz.org> To: Marian Hettwer <mh@kernel32.de> Cc: Andy Kosela <andy.kosela@gmail.com>, freebsd-stable@freebsd.org Subject: Re: CLARITY re: challenge: end of life for 6.2 is prematurewithbuggy 6.3 Message-ID: <4850E577.4000503@lozenetz.org> In-Reply-To: <a22e5deeb86ee078be756aadf90499b5@localhost> References: <484FF461.6000306@lozenetz.org> <a22e5deeb86ee078be756aadf90499b5@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the answer, so lets tell what I think :) Marian Hettwer wrote: > On Wed, 11 Jun 2008 18:50:57 +0300, Anton - Valqk <lists@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. > > the problem is that I don't have enought time to setup a testing server and find out when the problem occurs, because it's random seen, on 10-15th build of the new port this happens, I've noticed that if I make #> make deinstall distclean install pakcage-recursive the problem occurs much more rare compared to just #> make deinstall ditsclean package-recursive I simply currently don't have time for test setup ;( >> 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). > > I understand that, that's why I didn't posted again because, as I said i don't have time to sitdown and setup and try to reproduce it. >> 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 :) > > agree with that, just my effort with debian is much smaller than fbsd ports. >>>> 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?! > deb-src ;-) that's why I like debian when using standartized .debs and prefer fbsd when need custom stuff. > >> 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). > > agree :) >> 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 gentoo :) YES YES YES ~:) they are VERY proud to build everything from src... :) about fbsd - the most opinions I've heard are argumented with that you get 3-12% percents performance from building srcs with cpu and machine optimizations. That's why I said it. >> 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 ;) > > agree but when you host VPSes you can't beat the devs... :( >> 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). > > right, everything depends on the situations. >>> 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. > > pretty often? I'm testing almost everytime when portaudit (resp. jailaudit) says there are vluns in some ports, and never get new fixed versions, anyway, I understand that there is not enough manpower that's why I simply say that I'm not satisfied with the current situation, but yes, the ports crew is making a great job. I'm not forcing anyone to do anything, I rescue myself how I can, simply telling my opinion. :) >> 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. > I've just got my 3ware raid, I'll get 2 more spare ones and I'm migrating to hw raids too. :) I think the same now. > > >> 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. > same problem here, much less effort to migrate to apache22-prefork instead debugging :( - simply no time, I've posted a thread about cron but got stuck, because ktrace doesn't work for the debugging and that's a production and can't compile with debugging symbols.... > > Cheers, > Marian > > > cheer, valqk. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4850E577.4000503>