management

mike at lanline.com mike at lanline.com
Thu Jan 12 22:11:43 PST 2006


sorry, just to be a little more specific.  when i say i'm looking for
server farm management stuff, i just mean freebsd specific stuff.  i'm not
a new admin, i just have to do a migration fairly quickly and i'm trying
to get a feel for the best way to handle patches and upgrades for freebsd
in this type of environment.  as you already know freebsd's upgrade and
patch system is fairly unique among the *nix's.  this last e-mail was
helpful with the info. about some of the customizable variables and such.

thanks and don't go crazy, just what ever you guys suggest, then i'll
pick what seems best for my setup.

-mike


Date: Thu, 12 Jan 2006 23:51:45 -0600
From: Matthew D. Fuller <fullermd at over-yonder.net>
To: mike at lanline.com
Cc: freebsd-isp at freebsd.org
Subject: Re: management

On Thu, Jan 12, 2006 at 05:49:32PM -0500 I heard the voice of
mike at lanline.com, and lo! it spake thus:
> 
> I posted a question recently about upgrades (having one server w/
> the source and NFS mounting the source dirs to all the other
> machines and building that way), but I feel like some minor details
> are missing.  Like, can I or should I redirect the obj code to a
> directory on the local machine so I don't have to do a make clean as
> I go from server to server (and if so, can I do this through
> make.conf)?

Well, if the machines are all roughly the same architecture-wise, you
don't need to do any cleaning; just do the buildworld/buildkernel on
one machine, and the installworld/installkernel individually on each
(you could even build different kernels for each machine if you
wanted, with a little scripting to make it easier on your fingers).
If they were different archs, you'd probably want to just share
/usr/src and leave /usr/obj locally on the other machines.


> Same thing with ports.

I've NFS-shared /usr/ports before.  You have to either be careful to
build only on one machine at a time and always `make clean`, or set a
local $WRKDIRPREFIX.  I tend to go for the former most of the time,
just 'cuz it's easier.  Particularly when you're dealing with smaller
(<15 machines, say) situations, and you're the only one doing
admin-type stuff, simple can often be better than exhaustively-robust.


> Also, I know about portupgrade, but is that the best way to manage
> ports?

I managed ports for years without portupgrade.  I'm told the scars
heal eventually, though.  There are some other tools that do similar
things (portmanager is one, I believe); I've been pretty happy with
portupgrade in general.  It's no substitute for understanding ports a
bit to solve occasional edge cases, but very handy.


> [ports] but there doesn't seem to be any documentation about what
> variables can be set or anything (e.g. can I force the binary to get
> installed in a certain dir?) I know I could look in the makefiles
> and stuff, but I really don't have

See some vars like PREFIX and LOCALBASE and X11BASE.  There's a lot of
documentation of various variables in comments at the top of
/usr/ports/Mk/bsd.port.mk; a lot of them are mostly variables you'd
use in writing/editing a port, but it covers things like PREFIX that
you might set on the command-line when installing.

Usually, I've found it best to leave those sort of things alone in
most cases.  The more you customize, the more you end up HAVING to
customize, until it all blows up at 3am.


> I mean the handbook is great for general config. questions, but I'm
> more interested in server farm management and maintenance.

A lot of it is just general admin experience (i.e., not FreeBSD
specific).  It's hard to distill one person's experience into an email
(or a 5-volume reference manual, for that matter).  It's often
relatively easy to give at least some advice on a specific question,
but trying to handwave an entire gestalt of admin philosophy is
impossible.



-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.



More information about the freebsd-isp mailing list