Re: tracking -stable in the enterprise
Andy Kosela wrote: On Jun 25, 2008, at 3:46 AM, Peter Wemm wrote: I think we still have FreeBSD-3.x machines in production. I know we have FreeBSD-4.3. 99.9% of security issues don't affect us. We have our own package system built on top of FreeBSD's pkg_add format and have the ability to push packages to machines. If circumstances warrant it, we can push a fix for something. It'll either push a new binary or be a source patch that is compiled directly on the machines in question. The machines run a custom software stack. More often we push fixes for driver or performance fixes or things like timezone updates. Ports infrastructure do not support such old FreeBSD versions, so how do you deal with that? Do you maintain your own CVS branches of selected packages and backports necessary security patches? I guess it demands considerable effort to compile the latest apache on FreeBSD 3.x or 4.x. It would be easy to maintain 4.x compatibility in Yahoo's package system. They probably only need a relatively small number of ports, and there is no need to stay in sync with changes to the ports infrastructure. Those changes are almost all completely gratuitous from the point of view of deploying packages within a site since they are changes to the *ports* infrastructure. The FreeBSD *package* infrastructure has changed almost not at all over time (but yahoo have their own package system anyway). To the extent that the vendor applications still support old versions, the model would be the same: vendor source + patches -- binary. You can do that with a system based on the ports collection from last century if you like :) I would guess that Yahoo actually forked the ports system long ago (in the 2.x days?) or never used it directly, and either port their changes directly or by taking patches from freebsd ports. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tracking -stable in the enterprise
On Mon, Jun 30, 2008 at 12:26:05PM +0200, Kris Kennaway wrote:
It would be easy to maintain 4.x compatibility in Yahoo's package
system. They probably only need a relatively small number of ports, and
there is no need to stay in sync with changes to the ports
infrastructure. Those changes are almost all completely gratuitous from
the point of view of deploying packages within a site since they are
changes to the *ports* infrastructure. The FreeBSD *package*
infrastructure has changed almost not at all over time (but yahoo have
their own package system anyway).
To the extent that the vendor applications still support old versions,
the model would be the same: vendor source + patches -- binary. You
can do that with a system based on the ports collection from last
century if you like :)
I would guess that Yahoo actually forked the ports system long ago (in
the 2.x days?) or never used it directly, and either port their changes
directly or by taking patches from freebsd ports.
It's pretty easy to use current ports system with RELENG_4,
I do this sometimes. Just have following lines in /etc/make.conf:
# 4.x stuff
PTHREAD_CFLAGS= -D_THREAD_SAFE
PTHREAD_LIBS= -pthread
# may be, ln -s /usr/local/etc/rc.d/rc.subr /etc/rc.subr too
RC_SUBR=${LOCALBASE}/etc/rc.subr
# only if we force port to use base system's port 5.005
PERL_VERSION= 5.00503
PERL_VER= 5.005
PERL_ARCH= ${ARCH}-freebsd
PERL5= ${DESTDIR}/usr/bin/perl${PERL_VERSION}
PERL= ${DESTDIR}/usr/bin/perl
Then, for perl, one needs small patch to bsd.ports.mk:
--- bsd.port.mk.origWed Oct 17 18:12:24 2007
+++ bsd.port.mk Sun Feb 24 00:33:48 2008
@@ -1420,8 +1420,8 @@
SITE_PERL_REL?=lib/perl5/site_perl/${PERL_VER}
SITE_PERL?=${LOCALBASE}/${SITE_PERL_REL}
-PERL5= ${LOCALBASE}/bin/perl${PERL_VERSION}
-PERL= ${LOCALBASE}/bin/perl
+PERL5?=${LOCALBASE}/bin/perl${PERL_VERSION}
+PERL?= ${LOCALBASE}/bin/perl
.endif # !defined(_PERL_REFACTORING_COMPLETE)
This way, I continue to update small standalone mail servers
with new versions of security/clamav (those consoleless 4.11 boxes
have no hope to be upgraded to something newer).
Sometimes there is a need to patch port's Makefile a little,
f.e. when if redefines PTHREAD_LIBS unconditionally (bad, bad habit).
Eugene Grosbein
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tracking -stable in the enterprise
On Jun 25, 2008, at 3:46 AM, Peter Wemm wrote: No. Why on earth would we do that? if we wanted to cause ourselves that much pain for no good reason, we'd go get a pencil and stab ourselves in the eye. We don't upgrade machines that have been deployed unless there is a good reason to. This makes sense. But for personal curiosity sake, what if Yahoo needed to stick with supported FreeBSD releases? How would you deal with updating that many machines every 12 months? Would that be possible in your business? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
tracking -stable in the enterprise
On Jun 25, 2008, at 3:46 AM, Peter Wemm wrote: I think we still have FreeBSD-3.x machines in production. I know we have FreeBSD-4.3. 99.9% of security issues don't affect us. We have our own package system built on top of FreeBSD's pkg_add format and have the ability to push packages to machines. If circumstances warrant it, we can push a fix for something. It'll either push a new binary or be a source patch that is compiled directly on the machines in question. The machines run a custom software stack. More often we push fixes for driver or performance fixes or things like timezone updates. Ports infrastructure do not support such old FreeBSD versions, so how do you deal with that? Do you maintain your own CVS branches of selected packages and backports necessary security patches? I guess it demands considerable effort to compile the latest apache on FreeBSD 3.x or 4.x. -- 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: tracking -stable in the enterprise
On Wed, Jun 25, 2008 at 12:21 PM, Jo Rhett [EMAIL PROTECTED] wrote: On Jun 25, 2008, at 3:46 AM, Peter Wemm wrote: Correct. We roll our own build snapshots periodically, but we also keep a pretty careful eye on what's going on in the -stable branches. Okay, that makes sense to me ;-) I mean, I guess Yahoo has enough resources to literally run every commit to -stable through a full test cycle and push it out to every machine, but my No. Why on earth would we do that? if we wanted to cause ourselves that much pain for no good reason, we'd go get a pencil and stab ourselves in the eye. Yes, we are definitely on the same page. Thanks for the clarification ;-) We don't upgrade machines that have been deployed unless there is a good reason to. Do you deploy machines for longer than 1 year? How do you deal with security patches in the longer term? I think we still have FreeBSD-3.x machines in production. I know we have FreeBSD-4.3. 99.9% of security issues don't affect us. We have our own package system built on top of FreeBSD's pkg_add format and have the ability to push packages to machines. If circumstances warrant it, we can push a fix for something. It'll either push a new binary or be a source patch that is compiled directly on the machines in question. The machines run a custom software stack. More often we push fixes for driver or performance fixes or things like timezone updates. The important thing is that we don't disturb machines that are running happily. Hardware vendors are constantly messing with firmware, bugs in silicon, etc etc. This is an issue for NEW installs, usually not existing machines. Usually. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; KI6FJV All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
tracking -stable in the enterprise
On Jun 23, 2008, at 7:51 AM, John Baldwin wrote: FWIW, Yahoo! tracks -stable branches, not point releases. I'm curious about this (and stealing the dead thread). How does one track -stable in an enterprise environment? I assume that what you mean is we pick points in -stable that we believe are stable enough and create a snapshot from this point that we test and roll out to production ...? Am I wrong? I mean, I guess Yahoo has enough resources to literally run every commit to -stable through a full test cycle and push it out to every machine, but my mind boggles to imagine the manpower cost of doing so. (and to justify the manpower cost versus the gain from doing so...) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tracking -stable in the enterprise
On Wed, Jun 25, 2008 at 2:23 AM, Jo Rhett [EMAIL PROTECTED] wrote: On Jun 23, 2008, at 7:51 AM, John Baldwin wrote: FWIW, Yahoo! tracks -stable branches, not point releases. I'm curious about this (and stealing the dead thread). How does one track -stable in an enterprise environment? I assume that what you mean is we pick points in -stable that we believe are stable enough and create a snapshot from this point that we test and roll out to production ...? Am I wrong? Correct. We roll our own build snapshots periodically, but we also keep a pretty careful eye on what's going on in the -stable branches. When I say we, I mostly mean John does it. :) Quite often the biggest factor that tells us when to roll a new internal release is when there's something that has gone into -stable that we want. We have many local modifications, so freebsd.org's concept of a release is pretty much meaningless to us. However, we do quietly help in freebsd.org's release process. We make a point of trying to run some recent snapshots in production in the leadup to a freebsd.org release. This helps shake out silly problems that might not get noticed in time. I mean, I guess Yahoo has enough resources to literally run every commit to -stable through a full test cycle and push it out to every machine, but my mind boggles to imagine the manpower cost of doing so. (and to justify the manpower cost versus the gain from doing so...) No. Why on earth would we do that? if we wanted to cause ourselves that much pain for no good reason, we'd go get a pencil and stab ourselves in the eye. We don't upgrade machines that have been deployed unless there is a good reason to. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 If Java had true garbage collection, most programs would delete themselves upon execution. -- Robert Sewell ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tracking -stable in the enterprise
FWIW, Yahoo! tracks -stable branches, not point releases. I'm curious about this (and stealing the dead thread). How does one track -stable in an enterprise environment? I assume that what you mean is we pick points in -stable that we believe are stable enough and create a snapshot from this point that we test and roll out to production ...? Am I wrong? I mean, I guess Yahoo has enough resources to literally run every commit to -stable through a full test cycle and push it out to every machine, but my mind boggles to imagine the manpower cost of doing so. (and to justify the manpower cost versus the gain from doing so...) I only have a handfull of web-servers so I do a 'make buildworld' and -kernel on one server and then nfs-mount it from the other servers (remember mount-root-option if doing this). I don't have any problems running stable if it works. So I usually just upgrade one server to whatever stable is at that moment and if it runs without problems for a while I upgrade the remaining servers a few days apart. When it comes to our db-server I usually track release, but since my web-servers and db-server is the same hardware I'm somewhat confident that an upgrade to stable will work if the need to do so arises. -- regards Claus When lenity and cruelty play for a kingdom, the gentlest gamester is the soonest winner. Shakespeare ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tracking -stable in the enterprise
On Wed, Jun 25, 2008 at 4:07 AM, Claus Guttesen [EMAIL PROTECTED] wrote: FWIW, Yahoo! tracks -stable branches, not point releases. I'm curious about this (and stealing the dead thread). How does one track -stable in an enterprise environment? I assume that what you mean is we pick points in -stable that we believe are stable enough and create a snapshot from this point that we test and roll out to production ...? Am I wrong? [snip] I only have a handfull of web-servers so I do a 'make buildworld' and -kernel on one server and then nfs-mount it from the other servers (remember mount-root-option if doing this). I don't have any problems running stable if it works. So I usually just upgrade one server to whatever stable is at that moment and if it runs without problems for a while I upgrade the remaining servers a few days apart. That's pretty much what we do as well, here in the local school district. We track the -stable and -current mailing lists, read all the Head's Up messages, and read through cvsweb logs for the devices/apps we're interested in. When there's a commit that interests us, we update the source tree to after that commit, run through the buildworld cycle on a test box, make sure everything works over a few days/weeks, and then export /usr/obj and /usr/src to the systems we want to upgrade. It's not all that time consuming, even though it's just me doing the work. When it comes to our db-server I usually track release, but since my web-servers and db-server is the same hardware I'm somewhat confident that an upgrade to stable will work if the need to do so arises. We keep all our server hardware as identical as possible, which greatly simplifies things. We have four hardware profiles that run FreeBSD, and only two of those track -STABLE. -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: tracking -stable in the enterprise
On Jun 25, 2008, at 3:46 AM, Peter Wemm wrote: Correct. We roll our own build snapshots periodically, but we also keep a pretty careful eye on what's going on in the -stable branches. Okay, that makes sense to me ;-) I mean, I guess Yahoo has enough resources to literally run every commit to -stable through a full test cycle and push it out to every machine, but my No. Why on earth would we do that? if we wanted to cause ourselves that much pain for no good reason, we'd go get a pencil and stab ourselves in the eye. Yes, we are definitely on the same page. Thanks for the clarification ;-) We don't upgrade machines that have been deployed unless there is a good reason to. Do you deploy machines for longer than 1 year? How do you deal with security patches in the longer term? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
