Date: Sun, 8 Dec 2002 14:47:04 -0500 From: "Charles Swiger" <cswiger@mac.com> To: <freebsd-stable@FreeBSD.ORG> Subject: Re: update strategies Message-ID: <00bb01c29ef2$9599bcf0$0301a8c0@prime> References: <2E37135F-0AB4-11D7-B2B7-003065A9024A@ish.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Aristedes Maniatis wrote: > OK. This is where I get confused. I thought that the point of putting > these applications into the base FreeBSD distribution was that they > need to be tightly integrated into the OS. Some applications do, some don't. Perhaps it would be closer to say that it's highly desirable to have critical pieces of shared infrastructure tightly integrated with the OS. For example, lots of things want to do SSL, nowadays. If the OS can provide a well-tuned, tested version of OpenSSL, plus dependencies (let's add /dev/random to the system; let's compile Apache with mod_ssl by default now; etc), that gives you a better starting point. While I find it satisfying to upgrade old versions of software in quick response to security issues, and there are benefits to being proactive about security, the danger in rolling your own versions lies in limited testing compared with OS vendor patches, and maintainability. There's a cost in terms of time, documentation, organization, and so forth with every change you make to a machine; highly customized or interdependent changes tend to cost a lot, unless you're careful to document everything. Perhaps I should say they cost a lot if you're careful to document everything; if you don't document everything, the next person to muck with it is likely to break the system entirely (because they missed some dependency). Installing the latest OS patches, doing a cvsup and recompile the changed parts (or world), running dselect, or apt, or fink, or portupgrade, are all fairly low in terms of cost and risk. > I understand that this is critical for basic system tools like "adduser". > It appears this makes it important to build the whole distribution together > (buildworld) and not get one tool out of sync with the rest. This is a consideration, yes. If you understand how different components and tools depend on each other, you can save time by only rebuilding the stuff that's necessary. On the other hand, make is pretty good doing that as well, and it errors on the side of caution and building more than it needs to. > But if this is not the case, and we are supposed to build portions of > the /usr/src/ without rebuilding the whole thing, why aren't these > tools in /usr/ports? Which tools? You'll find things like apache, BIND, sendmail, openssh, and so forth in ports as well. [ ... ] > * install ports for named, ssh, etc. > * disable the base FreeBSD distributions of these tools > * use cvsup to update these tools whenever I need to because of > security/bugs/features > * use cvsup to update base FreeBSD (src-all) for each tagged release > (every 3 months or sooner in case of problems). Or less often if the > update doesn't look important. Then buildworld to build a consistent > FreeBSD release. The safest approach would be to track the security branch of the installed OS, and upgrade to RELENG_4_7 [or RELENG_4_(STABLE - 1), perhaps], a week or so after a new release comes out and any initial problems have had a chance to be detected. You should be tracking security advisories and may decide to install your own fixes sooner. This tends to be a good idea for services which the machine is offering (examples are sendmail for a mail server, apache for a web server, BIND for a name server, etc), particularly if you've customized the build of something due to your specific application requirements. Perhaps you have your own apache modules or whatever, for example. Anyway, if you feel you can do a better job of tracking a certain piece of software and keeping it secure or better integrated and tested than the OS vendor currently does, congratulations. :-) At least in the case of FreeBSD, you can also contribute your efforts and help make the OS better by doing things like reporting bugs, generating patches, taking over (or making) a port, etc. -Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?00bb01c29ef2$9599bcf0$0301a8c0>