How to deploy FreeBSD desktops ?

[Martin P. Hellwig]

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