Date: Mon, 27 Dec 2004 21:56:51 +0100 From: "Martin P. Hellwig" <mhellwig@xs4all.nl> To: Jon Drews <jon.drews@gmail.com> Cc: freebsd-advocacy@freebsd.org Subject: Re: How to deploy FreeBSD desktops ? Message-ID: <41D07713.2080907@xs4all.nl> In-Reply-To: <8cb27cbf04122708111005f3eb@mail.gmail.com> References: <8cb27cbf04122708111005f3eb@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41D07713.2080907>