update strategies
Aristedes Maniatis
a friendly bunch, so I'll ask my question.
It appears that there are two strategies for updating FreeBSD systems:
* cvsup the latest STABLE release on a regular basis
* get the CD release (4.6, 4.7, etc) snapshots periodically and update
from that either with binaries or compiled from source
I am curious about what most people do. For a server where stability is
important, I obviously don't want to buildworld once a week, but it is
also important to keep on top of bug reports and security holes.
I am already using cvsup with the ports tree and it works really
nicely, giving me the choice of what to update and when. Am I right in
saying that the base FreeBSD install can work the same way?
I guess what makes more more confused is figuring out what is part of
"FreeBSD" and what is part of the ports. Some things seem to be both:
eg. perl and bind. Is there a map somewhere that sets this out clearly?
Does everything which is a port get installed in /usr/local?
I'm having some problems getting the kernel to compile (errors in
"/usr/src/sys/modules/linux") and I suspect that the problem may be due
to this lack of understanding about which source trees live where.
Thanks for any help
Ari Maniatis
-------------------------->
ish group pty ltd
7 Darghan St Glebe 2037 Australia
phone +61 2 9660 1400 fax +61 2 9660 7400
http www.ish.com.au | email in...@ish.com.au
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
The Anarcat
On Fri Dec 06, 2002 at 02:32:40PM +1100, Aristedes Maniatis wrote:
> I'm new here, and I've been lurking to look for answers. You seem like
> a friendly bunch, so I'll ask my question.
>
> It appears that there are two strategies for updating FreeBSD systems:
>
> * cvsup the latest STABLE release on a regular basis
> * get the CD release (4.6, 4.7, etc) snapshots periodically and update
> from that either with binaries or compiled from source
>
> I am curious about what most people do. For a server where stability is
> important, I obviously don't want to buildworld once a week, but it is
> also important to keep on top of bug reports and security holes.
I can't speak for most people, however I can say that I mostly use
cvsup + buildworld to maintain my system.
> I am already using cvsup with the ports tree and it works really
> nicely, giving me the choice of what to update and when. Am I right in
> saying that the base FreeBSD install can work the same way?
Similarly, yes.
> I guess what makes more more confused is figuring out what is part of
> "FreeBSD" and what is part of the ports. Some things seem to be both:
> eg. perl and bind. Is there a map somewhere that sets this out clearly?
Yes. I guess you could say that everything that is in /usr/src is part
of *base*, with all source code included, and all that is in
/usr/ports is part of The Ports Collection (c).
Also note that the ports collection doesn't usually carry the source
code of the software in itself, but rather a framework of how to fetch
compile and install that software, in opposition with the base system
that doesn't need to fetch anything since the source code is already
in there.
> Does everything which is a port get installed in /usr/local?
Yes.
> I'm having some problems getting the kernel to compile (errors in
> "/usr/src/sys/modules/linux") and I suspect that the problem may be due
> to this lack of understanding about which source trees live where.
I guess the standard answer here is:
1- re-cvsup and try again
2- I need more details: your cvsup config file, your kernel config,
the complete error message, etc.
Cheers!
A.
--
Imagination is more important than knowledge
- Albert Einstein
Kevin D. Kinsey, DaleCo, S.P.
To: <freebsd...@FreeBSD.ORG>
Sent: Thursday, December 05, 2002 9:32 PM
Subject: update strategies
> It appears that there are two strategies for updating FreeBSD
systems:
>
> * cvsup the latest STABLE release on a regular basis
> * get the CD release (4.6, 4.7, etc) snapshots periodically and
update
> from that either with binaries or compiled from source
>
> I am curious about what most people do. For a server where
stability is
> important, I obviously don't want to buildworld once a week, but it
is
> also important to keep on top of bug reports and security holes.
I cvsup the source 3x/week via cron, ports slightly less often, and
buildworld
when I feel like it (which isn't TOO often) or when there's a
security
announcement made. My servers run at low loads, typically, so
-STABLE works just great on my "production" servers. I'm looking
into portupgrade to update ports, it seems like it's going to be
cool!
>I'm having some problems getting the kernel to compile (errors in
>"/usr/src/sys/modules/linux") and I suspect that the problem may be
due
>to this lack of understanding about which source trees live where.
Usual suggestion is re-cvsup and try again. Sounds like you could
have left something out of your kernel config file, though, with this
error.
G'luck, Kevin Kinsey,
DaleCo, S.P.
Joe Laughlin
Aristedes Maniatis wrote:
> I'm new here, and I've been lurking to look for answers. You seem like a
> friendly bunch, so I'll ask my question.
>
> It appears that there are two strategies for updating FreeBSD systems:
>
> * cvsup the latest STABLE release on a regular basis
> * get the CD release (4.6, 4.7, etc) snapshots periodically and update
> from that either with binaries or compiled from source
>
> I am curious about what most people do. For a server where stability is
> important, I obviously don't want to buildworld once a week, but it is
> also important to keep on top of bug reports and security holes.
I don't think it's necessary to recompile the whole world if you're just
worried about a security hole with one small portion.
Just recompile/install that part. Unless it's a big change, it
shouldn't cause any problems.
Chris BeHanna
>
> I cvsup the source 3x/week via cron, ports slightly less often, and
> buildworld when I feel like it (which isn't TOO often) or when
> there's a security announcement made.
Polite inquiry: why are you cvsup'ing so often when you only
rebuild seldom? You're generating extra load on the cvsup mirror that
you're using to no productive end.
> I'm looking into portupgrade to update ports, it seems like it's
> going to be cool!
It is. Once you have a populated /usr/local/etc/pkgtools.conf,
it can save you a lot of time.
I'm still not willing to do "portupgrade -aF" nightly, but it
still saves me time.
--
Chris BeHanna http://www.pennasoft.com
Principal Consultant
PennaSoft Corporation
ch...@pennasoft.com
Kevin Oberman
> Date: Fri, 6 Dec 2002 08:32:29 -0500
> Sender: owner-free...@FreeBSD.ORG
>
> On Friday 06 December 2002 00:44, Kevin D. Kinsey, DaleCo, S.P. wrote:
> >
> > I cvsup the source 3x/week via cron, ports slightly less often, and
> > buildworld when I feel like it (which isn't TOO often) or when
> > there's a security announcement made.
>
> Polite inquiry: why are you cvsup'ing so often when you only
> rebuild seldom? You're generating extra load on the cvsup mirror that
> you're using to no productive end.
I'm unsure of the validity of this argument.
It is generating load more often, but each update is small as only the
changed files are downloaded. There is some (perhaps significant) load
generated by the test to see which files need to be updated, but
little traffic moves.
If you only update every once in a while, you will do a large download
of a great many files.
The issues is whether the public cvsup servers are more concerned
about I/O and network bandwidth or CPU load. I'll admit that I don't
know.
The real reason I would NOT do this is that I want my sources to match
what is actually running. But many people probably never look at the
sources, so they don't care.
> > I'm looking into portupgrade to update ports, it seems like it's
> > going to be cool!
>
> It is. Once you have a populated /usr/local/etc/pkgtools.conf,
> it can save you a lot of time.
>
> I'm still not willing to do "portupgrade -aF" nightly, but it
> still saves me time.
I do a cvsup of ports on one system nightly, rebuild the database, and
do a 'portversion -vL=' to see what needs to be updated. I do the
actual updates the next morning, sometimes selectively. I only do this
on one system so that I can pre-test before ports are updated on other
systems which I do weekly or (for servers) less often.
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634
Erik Trulsson
> > From: Chris BeHanna <ch...@pennasoft.com>
> > Date: Fri, 6 Dec 2002 08:32:29 -0500
> > Sender: owner-free...@FreeBSD.ORG
> >
> > On Friday 06 December 2002 00:44, Kevin D. Kinsey, DaleCo, S.P. wrote:
> > >
> > > I cvsup the source 3x/week via cron, ports slightly less often, and
> > > buildworld when I feel like it (which isn't TOO often) or when
> > > there's a security announcement made.
> >
> > Polite inquiry: why are you cvsup'ing so often when you only
> > rebuild seldom? You're generating extra load on the cvsup mirror that
> > you're using to no productive end.
>
> I'm unsure of the validity of this argument.
>
> It is generating load more often, but each update is small as only the
> changed files are downloaded. There is some (perhaps significant) load
> generated by the test to see which files need to be updated, but
> little traffic moves.
>
> If you only update every once in a while, you will do a large download
> of a great many files.
>
> The issues is whether the public cvsup servers are more concerned
> about I/O and network bandwidth or CPU load. I'll admit that I don't
> know.
But even if no changes have been made there is still quite a bit of
network traffic necessary to find out that nothing has been changed.
(Mostly small packets in each direction but quite a few of them.)
The actual amount of useful data moved will be the same regardless of
if cvsup every day or every week, but there is some overhead each time
that you cvsup that is more or less independent on how much has
changed.
This means that doing a large update every week put less strain on the
servers and the network than doing one every day.
(Since the amount of changes to be transferred are the same, but you
only get one seventh of the overhead.)
--
<Insert your favourite quote here.>
Erik Trulsson
ertr...@student.uu.se
Mark Hittinger
Doing cvsups without builds/installs gets your source tree out of sync
with your binaries.
On -current this can cause trouble if the tree gets more buggy than
normal and you have to do some debugging work.
On -stable its probably not as large a concern but suppose you build a
kernel that works, do cvsup's for a few weeks, and then build another
kernel that doesn't work. You fall back to kernel.old. Then you find
out it is really important to build a new kernel for some reason, i.e.,
new device or security alert - but you can't because of temporary bogosity
of the -stable/-current tree.
If you are a cvs wizard you can roll back but its certainly a lot easier
to just leave things in sync.
Its also worth thinking about your backups and when you cvsup. I mirror my
system disks prior to cvsup so that the backup has binaries/sources in
sync. Again, this is much more important to do on -current because you
never know. :-) - but still worth doing on -stable.
Later
Mark Hittinger
bu...@pu.net
Jonathan Chen
[...]
> Its also worth thinking about your backups and when you cvsup. I mirror my
> system disks prior to cvsup so that the backup has binaries/sources in
> sync. Again, this is much more important to do on -current because you
> never know. :-) - but still worth doing on -stable.
So true. It's even more important when you find out that the latest cvsup
you have has broken the compiler tool-chain; meaning that your installed
(broken) compiler can't build it's way out of trouble. Recovering means
restoring system binaries from backup, or using another machine's /usr/obj
to make installworld...
Cheers.
--
Jonathan Chen <jo...@chen.org.nz>
-----------------------------------------------------------------------
"I love deadlines. I like the whooshing sound they make as they fly by"
- Douglas Adams
clark shishido
>
> It appears that there are two strategies for updating FreeBSD systems:
>
> * cvsup the latest STABLE release on a regular basis
> * get the CD release (4.6, 4.7, etc) snapshots periodically and update
> from that either with binaries or compiled from source
>
> I am curious about what most people do. For a server where stability is
> important, I obviously don't want to buildworld once a week, but it is
> also important to keep on top of bug reports and security holes.
to answer one of your original questions there's a third option
if you want stability and security. Rse one of the security
branches RELENG_4_[5-7] for your cvsup tag. This way you'll
avoid the major changes in -STABLE but still get the security
and severe bugs fixes.
--clark
Christopher Schulte
>to answer one of your original questions there's a third option
>if you want stability and security. Rse one of the security
>branches RELENG_4_[5-7] for your cvsup tag. This way you'll
>avoid the major changes in -STABLE but still get the security
>and severe bugs fixes.
I might sound like a broken cd, but this really does work. I've been
doing it ever since the security branch was created (RELENG_4_3?)
and have bypassed virtually 100% of -STABLE problems while keeping
secure and up to date. New features come as needed with
RELENG_4_X to RELENG_4_X+1 jumps.
>--clark
--
Christopher Schulte
http://www.schulte.org/
Do not un-munge my @nospam.schulte.org
email address. This address is valid.
Aristedes Maniatis
But I still don't understand why certain applications are both in the
FreeBSD distribution and also in ports. So, now I've got sshd both in
/usr/local/bin and also in /usr/bin. Their respective config files are
in /usr/local/etc/ssh and /etc/ssh. So I've got two daemons, and two
sets of config files which has been really confusing since I've been
editing the wrong ones. rc.conf points to the ports copy and ensures
that one starts up at boot. But I'm obviously doing something wrong to
get into this situation with two copies of the application.
It is easier to keep the port version updated, because that doesn't
require a whole buildworld. Should I throw the other one away?
Thanks
Ari Maniatis
BTW: I solved my kernel compilation problem (I had to "make cleandir"
as well as the usual "make clean"). Thanks.
On Friday, December 6, 2002, at 04:11 PM, The Anarcat wrote:
>> I guess what makes more more confused is figuring out what is part of
>> "FreeBSD" and what is part of the ports. Some things seem to be both:
>> eg. perl and bind. Is there a map somewhere that sets this out
>> clearly?
>
> Yes. I guess you could say that everything that is in /usr/src is part
> of *base*, with all source code included, and all that is in
> /usr/ports is part of The Ports Collection (c).
-------------------------->
ish group pty ltd
7 Darghan St Glebe 2037 Australia
phone +61 2 9660 1400 fax +61 2 9660 7400
http www.ish.com.au | email in...@ish.com.au
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
The Anarcat
base"), and they are therefore tested and adapted to the FreeBSD
environment, they are maintained in FreeBSD's main source code
repository, etc. This gives much more control over the software.
In opposition, software in ports is integrated in FreeBSD only
loosly. A good example is why lukemftpd is not part of base yet: it
lacks complete PAM support, FreeBSD's login.conf support, MAC and such
stuff.
Normally, if you want to upgrade your sshd, you have 3 choices, 2 of
which are really similar:
1- recompile only sshd
2- recompile sshd using buildworld
3- disable the base sshd and install the port
I guess you tried choice 3, but failed to disable sshd in the base
system. Look for NO_SSHD or something like that in make.conf to
disable the building of sshd.
Also their is a OPENSSH_OVERWRITE_BASE knob for the openssh port that
will happily destroy the base system's sshd to replace it with the
port.
A.
--
Mike Hoskins
> It's pretty simple.
Agreed...
> I guess you tried choice 3, but failed to disable sshd in the base
> system. Look for NO_SSHD or something like that in make.conf to
> disable the building of sshd.
I often build things like BIND from ports so I can portupgrade as needed
without building world. In many cases I think using ports makes sense,
and in those cases one must take care to turn the required knobs in
rc.conf. (Using /etc/defaults/rc.conf as a guide...)
David Magda
> I often build things like BIND from ports so I can portupgrade as needed
> without building world. In many cases I think using ports makes sense,
[...]
You don't have to rebuild world:
# cd /usr/src/usr.sbin/named
# make
# make install
should work fine. The resultant binary after the 'make' is in the
/usr/obj hierachy.
--
David Magda <dmagda at ee.ryerson.ca>
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
Mike Hoskins
> # cd /usr/src/usr.sbin/named
> # make
> # make install
Since I already portupgrade things like postfix, handling all upgrades in
a similar manner has prooved useful here... Patching the latest BIND hole
doesn't mean I have to cvsup the FreeBSD sources. (BIND is just one
example, this is not anti-BIND propaganda, Mark. ;)
There's more than one way to skin a cat. :) I used to do almost
everything out of /usr/src, but portupgrade's slowly been working its way
into my daily routine. (Thanks, Musha-san!)
Aristedes Maniatis
these applications into the base FreeBSD distribution was that they
need to be tightly integrated into the OS. 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.
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?
I'm new here, so I'm not telling you how to suck eggs. Perhaps there
are historical reasons for this hierarchy. But I want to make sure I do
the right thing. Is this the safest approach:
* 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.
Cheers
Ari Maniatis
On Sunday, December 8, 2002, at 12:40 PM, David Magda wrote:
> You don't have to rebuild world:
>
> # cd /usr/src/usr.sbin/named
> # make
> # make install
>
> should work fine. The resultant binary after the 'make' is in the
> /usr/obj hierachy.
-------------------------->
ish group pty ltd
7 Darghan St Glebe 2037 Australia
phone +61 2 9660 1400 fax +61 2 9660 7400
http www.ish.com.au | email in...@ish.com.au
PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8
David Magda
> 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. 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.
Well think of it this way. You cvsup to get the up-to-date and do a
buildworld. The next day an advisory comes out for tool XXX. The problem
is that there exists an off-by-one remote buffer-overflow on line Y of
some file in program XXX. A fix is released and incorporated in CVS.
All that's changed between the previous day's source today's where the
diff file would be:
- strcpy( dst, src, MAXDATA);
+ strcpy( dst, src, MAXDATA+1);
(Yes I know, *really* contrived example, but....)
For that one change are you going to do a buildworld? Not really, it
would be easier to go into program XXX's directory and recompile just
it.
Stand alone programs can usually be compiled by themselves. Things that
touch a whole bunch of stuff (libraries, PAM, gcc, etc.) should be
followed with a buildworld.
It all depends on how much has changed since your last buildworld. If
you cvsup weekly but not much has changed in way of functionality are
you going to bother with a buildworld? Not really. However, if one of
the updates is a fix for an exploit, another is a new feature to ls(1),
a third is some documentation fixes to the intro(7) manpage, and the
fourth is some indenation changes (but no functionality changes) to
src/sbin/kget/kget.c what are you going to do? Personally, I would
simply rebuild the fixed program.
> 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?
Many of the utilities (bind, ssh, Kerberos/Heimdal, etc.) already are in
the ports. Just because people want to have more control over how things
are installed than is generally available in the base system. Also for
the people that want to do what you do.
When the advisory for BIND 8 came out a couple of weeks ago I know an
admin who installed BIND 9 for the ports until version 8 was fixed. When
8 was fixed in CVS he updated it and went back to it. Why? Because with
ports you have to fiddle with knobs, and look at CVS logs to see when
things are updated, etc. With the base system the FreeBSD developers do
a good of making sure things (generally) "just work".
Said admin used to use Linux heavily (Slackware). He liked the
simplicity of Slackware that most of the other distributions lacked.
Even Debian which has an awesome way of updating the distribution, but
there is a certain "way" of doing things. He doesn't like that.
Now, every try updating glibc on a Linux distribution? Unless you have
magic utilities (Debian, etc.) that do things for you it's a pain. With
FreeBSD you just, cvsup and re-install: no fuss, no mess. Even when I
went from 4-STABLE to 5-CURRENT on a test box it was simply a matter of
cvsup'ing and re-installing. Do you know what I had to go through when I
was using Linux and went from GNU libc 5 to GNU libc 6? And another
time, from a.out to ELF? Ugly.
> I'm new here, so I'm not telling you how to suck eggs. Perhaps there
> are historical reasons for this hierarchy. But I want to make sure I do
> the right thing. Is this the safest approach:
[...]
I'll let others comment on this procedure: I'm not experienced enough
with admin'ing boxes yet to really say.
--
David Magda <dmagda at ee.ryerson.ca>
Because the innovator has for enemies all those who have done well under
the old conditions, and lukewarm defenders in those who may do well
under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI
To Unsubscribe: send mail to majo...@FreeBSD.org
Charles Swiger
> 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
Wes Peters
>
> 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.
Not in the case of BIND (and Sendmail, for example). Ther were integrated
with the system because "it was always done that way before".
> 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.
>
> 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?
See the mailing list archives for YEARS of discussion on this exact
same topic. The best answer you'll probably find in your research is
because FreeBSD needs SOME sort of resolver library, name services, and
even a network mailer to be generally considered functional, and it was
a lot easier to leave BIND and Sendmail in the distribution than to
adapt sysinstall to forcefully make the average installer choose one of
each.
Yes, this is pretty lame reason. If you're ready to step up to the plate
and do the sysinstall work to overcome this lameness, you'll be welcomed
with open arms.
> I'm new here, so I'm not telling you how to suck eggs. Perhaps there
> are historical reasons for this hierarchy. But I want to make sure I do
> the right thing. Is this the safest approach:
>
> * 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.
Close. Replace the latter with "follow the FreeBSD security advisories
and update both ports and system sources as advised."
Be warned that when security advisories come in to the FreeBSD security
team, they are most likely to focus on getting fixes into the "base"
system, then into ports as needed. If you can offer assistance to the
port maintainers for critical infrastructure pieces like name servers
and/or mailers, that will be welcomed as well.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
w...@softweyr.com http://softweyr.com/
Chris BeHanna
> > I'm new here, so I'm not telling you how to suck eggs. Perhaps there
> > are historical reasons for this hierarchy. But I want to make sure I do
> > the right thing. Is this the safest approach:
>
> [...]
>
> I'll let others comment on this procedure: I'm not experienced enough
> with admin'ing boxes yet to really say.
The safest approach:
1) On production servers, use the RELENG_4_x branch (currently,
x = 7). Deploy first on a test box that as nearly as possible
mimics your production environment. Beat on it until you are
comfortable with it, then deploy *that* *same* *build* on your
production hardware (e.g., export /usr/src and /usr/obj over
NFS, mount on the production box, and do the
installkernel/installworld/mergemaster thing).
Given modern hardware, a full buildworld cycle each time the
patchlevel is bumped is not onerous[1], especially if you kick
the build off when you leave at the end of the day--it's ready
for you the following morning. This is a "just in case there
are changes in a few places in the tree that interact"
anti-foot-shooting measure.
2) Workstations are more forgiving. Follow the -STABLE mailing
list. During a window of time in which no one has reported
serious bugs on any of the hardware you use, or with any of the
software you use, cvsup and do a build/install/mergemaster
cycle. If the workstation serves a critical purpose and can't
brook downtime from the occasional -STABLE hiccup, then track
the RELENG_4_x branch, just as you would for a server, and try
it out on a test box first, just as you would for a server.
3) In all cases, the following steps are prudent:
a) Make sure to back up /usr/src and /usr/obj *before* you cvsup,
so that you can put your system back to a known good state
if something goes really wrong.
b) Make sure to back up, at the least, /etc, /usr/local/etc,
and any critical data you have before updating--this
includes the contents of databases.
c) Prior to updating, copy your kernel config, LINT, and
GENERIC to (e.g.) YOURKERNEL.old, LINT.old, and GENERIC.old.
After the update, running diff -u on LINT and GENERIC will
clue you in to new options that you may or may not want to
apply to your kernel config.
d) When running cvsup, it is prudent to run it twice, with a
gap of five or ten minute between runs. That way, if your
first cvsup occurred in the middle of a large commit, the
second cvsup will pick up any files that the first missed.
This way, a critical system component with many changes
spanning many files won't end up in an intermediate state in
your local source tree. Note that if you see changes being
downloaded in your 2nd cvsup, you should wait five minutes
and then cvsup again. Repeat the cycle until cvsup doesn't
change any more files.
e) Read and obey /usr/src/UPDATING before and during your
upgrade--always.
f) Save the timestamp of your last cvsup. When reporting
problems, make sure you mention this timestamp in the
report--it is the identifier for the snapshot of the source
tree that you are running. Be sure you note the timezone of
the timestamp--if you do something like:
date >> cvsup.log
cvsup -g -L2 my_supfile 2>&1 | tee cvsup.out
date >> cvsup.log
Then the timezone will be your local timezone, so mention
it (by the by, CVS itself stores timestamps as GMT).
[1] On my 1.33 GHz Athlon w/256MB PC2100 ECC, and my source and object
trees living on a vinum-controlled two-disk RAID-0 stripeset (a
pair of old IBM 7200rpm 9GB U2W SCSI drives), I can do a buildworld
in less than 30 minutes. Currently, that build is I/O-bound. If
anyone has done a build with a similar CPU using a malloc disk,
I'd be interested in the results.
--
Chris BeHanna http://www.pennasoft.com
Principal Consultant
PennaSoft Corporation
ch...@pennasoft.com
To Unsubscribe: send mail to majo...@FreeBSD.org