I am looking for a check list of things that every person who is setting up a new server should be looking at. I am trying to create an internal process for our IT team and am looking for the basic main list of configuration when rolling out a new server. Anyone know of anything? (I am not looking for a 400 page microsoft document, just a simple complete checklist.)

link|improve this question
5  
Which do you want. Simple or complete? Seems to me that the two are mutually exclusive. – Zoredache Aug 16 '11 at 19:58
5  
This is hugely environment-dependent - I'm afraid it's really something you need to develop on your own. My checklist includes 5 items: Install FreeBSD. Enable SSH. Install radmind. Rack & stack box. Run deployment. – voretaq7 Aug 16 '11 at 20:04
feedback

closed as not constructive by Iain, mfinni, Shane Madden, womble, Chris S Aug 17 '11 at 16:39

This question is not a good fit to our Q&A format. We expect answers to generally involve facts, references, or specific expertise; this question will likely solicit opinion, debate, arguments, polling, or extended discussion. See the FAQ for guidance on how to improve it.

4 Answers

up vote 3 down vote accepted

Nobody can give you a checklist for your environment, but here are some basic items you need to make sure you take care of:

  1. Hardware Test (if applicable, but at least make sure it matches what you bought)
  2. Install the OS
  3. Configure the OS. Pay special attention to:
    • Network configuration
    • Domain or other remote login service
    • Local user accounts
    • Necessary software for the server's role
    • OS Patches
  4. Rack & Stack. Make sure to verify:
    • Adequate power/cooling
    • Network connectivity
    • Adding the machine to any asset management system(s)
    • Adding the machine to any patch deployment system(s)
    • Adding the machine to any monitoring system(s)
link|improve this answer
feedback

A simple checklist:

  • "What does it have to do, and does it do it?"
  • "If it goes wrong, do we have enough documented and backed up so we can fix it?"
  • "Does everyone who needs to know about it, know about it?"

More detailed:

  • Documentation of the setup and passwords
  • Installed properly (i.e. all redundant cablework done, no bodges, etc.)
  • Backed up
  • Restores possible
  • Added to your internal procedures for, e.g. warranty updates, OS updates, scheduled maintenance alerts
  • Added to your monitoring platform
  • Added to your hardware inventory system

"A server" is a bit too vague. What kind of server? What OS? What environment? For what purpose?

link|improve this answer
1  
Keep a printed copy of all documentation. It will come in handy when servers are down or if its just a stressfull situation. – artifex Aug 16 '11 at 21:41
@artifex At least print enough documentation to recover your documentation system. Printing everything could get a bit out of hand. – TessellatingHeckler Aug 16 '11 at 21:49
feedback

Although you don't want a 400 page Microsoft document, what you need is a copy of "The Bible" -- The Practice of System and Network Administration, by Limoncelli et al. It has whole chapters that help you identify what you need on your checklists.

link|improve this answer
This is the book i keep closest to my desk at all times. – artifex Aug 16 '11 at 21:40
Hell, I'm sitting on the couch at the moment and it's still within arm's reach. – womble Aug 16 '11 at 23:38
feedback

I would encourage you to research puppet/chef recipes. The only real way to get servers built correctly is to either automate the build or automate the policy enforcement. A well documented puppet recipe will be both a good aid to someone in telling them how things are configured and provide a way to ensure that configuration is the way all servers are built.

More info on Chef:

http://wiki.opscode.com/pages/viewpage.action?pageId=7274862

Puppet:

http://docs.puppetlabs.com/guides/language_guide.html

link|improve this answer
feedback

Not the answer you're looking for? Browse other questions tagged or ask your own question.