Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
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 [EMAIL PROTECTED] 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. 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. 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... 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
Robert, Thank you for your insights. I think that this agreement between users and developers does occur. The proper balance between rapid development vs long term stability is the platform through which such agreement can be achieved. It's up to the Core Team to reasonably steer the Project in such a way as to achieve the greatest results. FreeBSD has always been focused on creating simple, stable and reliable operating system for system administrators and let's keep it that way. Longer term support for -RELEASE gives many companies a stable platform to develop and maintain their infrastructure. I think 5 years support for major FreeBSD release (like major 6 or 7) would be really perfect for many of us. On Wed, Jun 11, 2008 at 1:26 PM, Marian Hettwer [EMAIL PROTECTED] wrote: 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 think Anton raised a valid and reasonable point here by analyzing my previous statements. Every data center environment test the upgrade process before deploying it on production machines, but my point circulated around the whole different theme. Backporting Backporting security and bug fixes to *STABLE* versions of ports would definetly render the whole ports framework infrastructure more solid and trustworthy for organizations that need mission critical stable and reliable environment to work in. Creating -SECURITY branch of ports tree with support *just* for common server applications like apache, postfix, mysql or vsftpd (definetly not for all available ports) would very well encourage more companies now stuck with the only alternative (redhat/centos or debian) to trust this ports tree branch in deploying their applications which very often needs specific versions of the software to run properly. Right now it's sometimes very risky to jump to the latest available upstream version as it very often breaks compatibility with older versions. I've been toying with the idea to create such -SECURITY branch, at least just for ports I use extensively. I'm not aware of no such project (open source, commercial) that is doing that. I'm curious how many people out there would be also interested in such an idea. 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. Redhat/CentOS is more reliable here as backports involves both security and bug fixes, plus even new hardware enhancements. -- Andy Kosela ora et labora ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
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 [EMAIL PROTECTED] 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
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
On Wed, 11 Jun 2008, Andy Kosela wrote: Redhat/CentOS is more reliable here as backports involves both security and bug fixes, plus even new hardware enhancements. In the FreeBSD environment, we call the place that gets a blend of security and bug fixes, plus new minor feature and driver enhancements -STABLE, and the releases that pick up these changes point releases. They happen more requently and with less risk than major releases, but still see enough development to represent functional improvements. I guess here's my concern: we offer a spectrum of choice for I want the most bleeding edge to I want no feature changes, just security fixes, and several points in between. We can argue about the exact placement of this points, but the reality is that the balance we have today seems to work well for many developers and users, and reflects a fairly carefully planned use of the available revision control and distribution technology. The place for volunteers to come in is where they see an obvious niche for improvement -- for example, a few years ago this guy named Colin Percival turned up with a binary update system. After a couple of years of enhancement, breaking it in, etc, it's now a standard tool for maintaining FreeBSD systems, and he's our security officer. Similar opportunities exist for offering easier updates to packages, etc, but require people who have a clear need and the technical ability to do the work to turn up and do it. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
--On Wednesday, June 11, 2008 16:54:02 +0100 Robert Watson [EMAIL PROTECTED] wrote: On Wed, 11 Jun 2008, Andy Kosela wrote: Redhat/CentOS is more reliable here as backports involves both security and bug fixes, plus even new hardware enhancements. In the FreeBSD environment, we call the place that gets a blend of security and bug fixes, plus new minor feature and driver enhancements -STABLE, and the releases that pick up these changes point releases. They happen more requently and with less risk than major releases, but still see enough development to represent functional improvements. I guess here's my concern: we offer a spectrum of choice for I want the most bleeding edge to I want no feature changes, just security fixes, and several points in between. We can argue about the exact placement of this points, but the reality is that the balance we have today seems to work well for many developers and users, and reflects a fairly carefully planned use of the available revision control and distribution technology. The place for volunteers to come in is where they see an obvious niche for improvement -- for example, a few years ago this guy named Colin Percival turned up with a binary update system. After a couple of years of enhancement, breaking it in, etc, it's now a standard tool for maintaining FreeBSD systems, and he's our security officer. Similar opportunities exist for offering easier updates to packages, etc, but require people who have a clear need and the technical ability to do the work to turn up and do it. From a security standport, backporting fixes to previous versions of ports creates a difficulty. It's much harder to tell, for example, if a RedHat port is vulnerable or not, because RedHat uses their own proprietary versioning system to define where a particular port is at. So, while your system might *say* it's running php version 5.2, it's really *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm just making that up.) If this idea ever gets off the ground, I *hope* the folks involved with find a rational, logical way to define the versioning so that it's not hieroglyphics to the average person. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
On Wed, 11 Jun 2008, Paul Schmehl wrote: From a security standport, backporting fixes to previous versions of ports creates a difficulty. It's much harder to tell, for example, if a RedHat port is vulnerable or not, because RedHat uses their own proprietary versioning system to define where a particular port is at. So, while your system might *say* it's running php version 5.2, it's really *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm just making that up.) If this idea ever gets off the ground, I *hope* the folks involved with find a rational, logical way to define the versioning so that it's not hieroglyphics to the average person. I hope not to offend the ports folks in saying this, but it seems clear to me that the narrower scope and better-defined components of the base system have (over time) lead to a much easier incremental upgrade path than ports and packages. It's not clear to me how you could apply the same level of attention to something as large as the ports collection, except perhaps to select a subset of ports you care more about, and provide a higher quality of service for them. In effect, try to find a semantically richer middle ground between it's someone else's problem, our role is primarily to bundle and it's entirely our problem and in revision control. We already do this for some ports, in that the people involved in adapting and maintaining some of the larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others, spend vast amounts of time ensuring that things work well, but largely without the help of revision control in the ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we could better present the choices reflected there. That doesn't help users of random tiny software packages, and I'm not sure anything can, but perhaps we can provide a smoother incremental maintenance path for some key packages. Mind you, ports really isn't my area, so I am at significant risk speculating in this area. Experience with the base system shows that the real work is always in the details, and hardly ever in the big ideas, and so only by truly implementing a system and trying it out can you determine whether it really works in practice. It's easy to wave ones hands at a high level (as I've done), but it's the proof-of-concept that matters. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
On Wed, Jun 11, 2008 at 07:36:28PM +0100, Robert Watson wrote: On Wed, 11 Jun 2008, Paul Schmehl wrote: From a security standport, backporting fixes to previous versions of ports creates a difficulty. It's much harder to tell, for example, if a RedHat port is vulnerable or not, because RedHat uses their own proprietary versioning system to define where a particular port is at. So, while your system might *say* it's running php version 5.2, it's really *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm just making that up.) If this idea ever gets off the ground, I *hope* the folks involved with find a rational, logical way to define the versioning so that it's not hieroglyphics to the average person. I hope not to offend the ports folks in saying this, but it seems clear to me that the narrower scope and better-defined components of the base system have (over time) lead to a much easier incremental upgrade path than ports and packages. It's not clear to me how you could apply the same level of attention to something as large as the ports collection, except perhaps to select a subset of ports you care more about, and provide a higher quality of service for them. In effect, try to find a semantically richer middle ground between it's someone else's problem, our role is primarily to bundle and it's entirely our problem and in revision control. We already do this for some ports, in that the people involved in adapting and maintaining some of the larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others, spend vast amounts of time ensuring that things work well, but largely without the help of revision control in the ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we could better present the choices reflected there. That doesn't help users of random tiny software packages, and I'm not sure anything can, but perhaps we can provide a smoother incremental maintenance path for some key packages. Mind you, ports really isn't my area, so I am at significant risk speculating in this area. Experience with the base system shows that the real work is always in the details, and hardly ever in the big ideas, and so only by truly implementing a system and trying it out can you determine whether it really works in practice. It's easy to wave ones hands at a high level (as I've done), but it's the proof-of-concept that matters. I think a large part of the shortcomings of the ports infrastructure when it comes to security releases could be mitigated if there was a rapid building and availability of packages on FTP mirrors to prevent everyone from doing portupgrade -P and then having to wait for the build as the packages don't show up for x days, and people can't wait that long for the fix. I know a discussion was recently started about package distribution and how to address its shortcomings and hopefully the need for rapid security package distribution will be taken into account Regards, Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
CLARITY re: challenge: end of life for 6.2 is premature withbuggy 6.3
On Wed, Jun 11 2008, Robert Watson wrote: On Wed, 11 Jun 2008, Paul Schmehl wrote: From a security standport, backporting fixes to previous versions of ports creates a difficulty. It's much harder to tell, for example, if a RedHat port is vulnerable or not, because RedHat uses their own proprietary versioning system to define where a particular port is at. So, while your system might *say* it's running php version 5.2, it's really *not* vulnerable because in RedHatese it's version 5.2.1.6.92000.p-2.1 (I'm just making that up.) If this idea ever gets off the ground, I *hope* the folks involved with find a rational, logical way to define the versioning so that it's not hieroglyphics to the average person. Egyptian hieroglyphics was a very noble system the secret of which was, in the days of old, in the possession only of the Hierogrammatists, or initiated Egyptian priests. Many occult alphabets and ciphers derived its origin from egyptian sacred ciphers, as also everything we know as cryptography today. I guess our english alphabet would be equally strange and uknown to them. But reading widely available documentation on Redhat's versioning system would definetly help in understanding its details. Everything after second - (dash) like in ftp-0.17-33 is Redhat's release version. In this case this is thirty third release or patch. It is similar to FreeBSD's naming convention. You can check changelog and see what has changed since release 1 by issuing: $ rpm -q --changelog package So the system is very clear and precise, just like FreeBSD system. The only difference is that upstream version of the package changes a lot more often than on redhat/centos. We already do this for some ports, in that the people involved in adapting and maintaining some of the larger/more critical parts, such as X.org, KDE, Gnome, and quite a few others, spend vast amounts of time ensuring that things work well, but largely without the help of revision control in the ports tree. I'm not proposing we incorporate X.org into CVS (SVN?) or the like, but perhaps there is a way we could better present the choices reflected there. That doesn't help users of random tiny software packages, and I'm not sure anything can, but perhaps we can provide a smoother incremental maintenance path for some key packages. I think that most system administrators who maintain many FreeBSD servers in data center environments do not really care about X.org, KDE, Gnome and other desktop applications having those -SECURITY patches backported. The real concern here is about common server applications. I think that cutting edge users who run FreeBSD on their workstations are perfectly aware that things can sometimes break, and to a degree they accept that risk. But system administrators running mission critical nonstop systems 24/7 cannot accept such risk with the server ports they are using. So if anything can be improved in ease of upgrading, backporting etc. this is the main area to investigate, so as to make FreeBSD the most stable and reliable Unix operating system out there. -- Andy Kosela ora et labora ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
