How to deploy FreeBSD desktops ?
Martin P. Hellwig
mhellwig at xs4all.nl
Mon Dec 27 12:56:51 PST 2004
Jon Drews wrote:
>Hi:
>
> Can anyone give me advice on how I should go about deploying and
>maintaining FreeBSD desktops, in a company setting? I know how to do
>it for my own FreeBSD desktop but how would I manage 30 to 50
>simultaneous installs? Also what would be an effective way to track
>
>
<cut>
Actually it doesn't matter whether these are FreeBSD machines or Windows
machines, the administrative challenge is the same.
So the real question is; How to deploy/maintain software and operating
systems for a X amount of machines in a productivity environment?
In the windows world there are a fast amount of tools which help you
automate this, tools like Ghost (Enterprise version has an remote
package installation) from Symantec and Microsoft's System Manager Server.
I'm sure there are more products but these spring to my mind because I
use them on a daily bases.
I didn't bother to check any comparable tools for unix (although you
should check out ghost for unix g4l at http://www.feyrer.de/g4u/ ) but
it wouldn't be that much of a challenge to write your own scripts what
does the same things as the above mentioned commercial products.
But you still need to know the basics of system administration, the
above tools only help you with that tasks, perhaps talking up with an
experienced SA will help you to be more focused on solving your
problems. However, the following will get you started.
Deploying an OS and third party software on multiple machines and
keeping those systems up to date is the "core" business of the average
SA. To better understand this specific task lets split it more up:
1 Deploying the OS
2 Deploying third party software
3 Machine specific configuration
4 User specific configuration
5 Keeping Software up to date (be it the OS or third party)
6 Document it
For every step of the above a sub step should be made, this would be
"Test if it worked!"
To keep things simple you want everything to be as much as standard as
possible, this doesn't mean that you should buy only "standard" hardware
and software (many SA make that mistake) but to keep those machines as
much as possible the same. This means:
1 Keep processor architecture the same
2 Keep the motherboard chip set the same
3 Keep the graphical chip set the same
4 Prefer the same hard disk type (scsi, IDE or SATA)
5 Prefer the same amount of memory
6 Document it
The manufactor of your mobo or the graphical card isn't that important
as long as the chip set is the same.
For the softer side these thumb-rules will help you along:
1 Keep the OS (version) the same
2 Keep third party software (version) the same
3 Centralize machine specific configuration
4 Centralize user specific configuration
5 Keep backups of configuration files
6 Document it
The above lists are far from complete and only ment as rule of thumb,
how to really do your job is depended on your organization.
But you certainly want (demand) a test network where every major task is
duplicated and can be tested before deploying it on the real network. On
your real network (and test network) you would have 1 non-productivity
machine where all ports used in your organization are build and packaged
to deploy it to the other system.
That machine is your master machine all other machine are mirrored from
that machine, if you have multiple architectures, then you'll end up
with multiple mirrors, if you have multiple OS, well you can do the math
by now.
Transport of these packages (or other software) can be as simple as a
script what tests the local versions and wgets (or
ssh/rsysnc/nfs/whatever) a newer version if appropriate and then
upgrades the package (or other software).
It is often useful to have a separated machine where all user and
machine (template) configuration is stored and documented, perhaps even
something fancy as an LDAP.
But the most important thing is: "Document it" :-) and besides that,
common sense and willingness to experiment.
Eventually you get more familiar with ITIL and the various ISO
certifications but that is not for starters.
If you like more info/idea exchanging, mail me.
HTH
--
mph
More information about the freebsd-advocacy
mailing list