Want your input on any install document for new server

[Sebastien Masson]

Hi all,

Few days ago, I replace someone who install server, here. I saw that the document generated by the project manager and/or architect is so badly written.

Before reinventing the wheel, I want to check we all of you if you can share your standard in new server installation document.

For sure, some generic guideline like:

-Hardware
-Operating System
-File system (internal/external)
-Software/3rdparty
-User account/Security aspect

Thanks

[Steven E. Protter]

Shalom Sebastien,

Kind of vague question.

First you specify the hardware,but base this on what the server is going to do. Oracle, so many instances, etc.

OS should be the latest version of HP-UX supported by the applications.

Then you secure the server after OS instalaltion.

Then you work on Third party of software and user issues. What you do is dependent on what the server is going to do.

SEP

[Sebastien Masson]

Yes, it's a big vague question. Let me clarify a bit.

1.Everything start from a need :-)
2.Architect think about how to fullfil the need
3.Architect design the system (Size the hardware, FS layout, Oracle instance, etc..)
4.Architect send all that to a project manager who order stuff and coordonate action between unix admins for server installation and application infrastructure.
5.At the end, the server is in production.

The problem is the information that pass between the point 3 and 4. Here, people use excel sheet, putting all servers in it, use ton of tab, freeze pan, etc... Overall, very hard to impossible to read. Also no process on change in the document.

In other word, I want to know what to do and not how to do it.

[Geoff Wild]

A lot of this is process and standards.

You must set standards on how a system is configured.

After that, re-install is a breeze.

Also, run some self documenting programs - things like cfg2html

http://come.to/cfg2ghtml

Have a standard build document - states things like file system sizes, swap, kernel parameters, number of nics, etc.

Rgds...Geoff

[Chan 007]

Seb,

1. Planning is more important.
2. Gathering information from varios teams like who support what (DB, 3rd Party, Application)
3. Agreed Manitenance Window (Outage can be taken) for any team.
4. SLA
5. Hardware - This should system sr.no and HANDLE for raising calls
6. OS and patch
7. Disk Root, mirror layout & SAN/Other Disks layout
8. Batch Jobs (Cron + 3rd Pty)
9. Maintenance Contract Details
10. BC/DR details
11. Any OS/3rd PT License Details

Hope you will have lot more than this...
Best of luck

007

[Darrel Louis]

Hi Sebastian,

First question.
What will be the purpose of the document and who will be using it.

- Purpose of server
- Infrastructure (hardware + Network + OS)
- Software requirements
- Hardware requirements
- Configuration items
- Middleware / Database
- Backup
- Monitoring
- Disaster Recovery
- Maintenance

GoodLuck

Darrel Louis

[Mark Ellzey]

Sebastien,

There is no default answer to your question. You will need to study and document the servers yourself.

In my case, each server is different, having unique software or hardware requirements. I've done disaster recovery documents for my servers, and each one of them is different.

There are a couple of software packages that can help you gather information about your servers, tho. Try cfg2html or sysaudit

cfg2html:
http://freshmeat.net/projects/cfg2html/

sysaudit:
http://www.backupcentral.com/sysaudit.html

Regards,
Mark

[Sebastien Masson]

Hi all,

I know my question can have multiple answer and mostly related on what you need to build. But bottom line, every server as the same purpose: running one or multiple software.

I have a lot of tool to document a server after it's installed like sysinfo, cfg2html, etc.. The problem is not there.

The problem is I waste a lot of time to understand document given by project manager and/or architect because they never install any server in their life.

The server installation document is written by those people and very very hard to read or understand. They take as default a lot of things.

At the end, our team always give badly installed server to infra application team because document is badly written so badly understand by us.

So do you have any generic standard, regardless if the server will be a database, need DR, etc.

As example, let said, your receive a document to install a server to run 1 DB instance on Oracle 9i, no DR. What do you need to build it correctly ?

Thanks

[OldSchool]

As noted by Geoff, this is mostly standards and procedures related.

You state that the documents assume defaults. If so, return the document to the originator and ask them to define what they have assumed. This can, if necessary, become the basis of a standard used for installation.

Also, someone on your team probably needs to be involved early on in the system architecture stages, to help clarify these issues.

The problem is that there currently appear to be some "bad" practices in place that cannot be corrected without rethinking the process.

[Sebastien Masson]

:-) You touch the problem, the process is mostly inexistant. This is why I want to start one and asking input from other folks.

Most of the time, we got the request after everything is decide and most of the time the decision are discutable.

Thanks

[Geoff Wild]

I attached a HP Install checklist doc that you can use/modify.

Hope it helps!

Rgds...Geoff

[Olivier Masse]

Depending on how much servers you intend on installing, Ignite/UX (and perhaps a golden image) can be of great help. Once you Ignite one server, you can reuse and tweak the configuration file for the next that follow.

You still need to document what you did to build your depot or Golden Image -- but it will make the installation much faster.

In my case we have a lot of servers and a lot of people involved, so I have three documents and the three are written for different people. Yours could be a combination of the three.

1. Security and bastion guide
2. Golden Image, Ignite/UX and depot configuration
3. Installation guide.

Guide #1 is a joint effort between me and the security department, and it can be reviewed by any external security auditors.

Then I build a simple secure golden image using guide #1, with every non security-related add-on documented in guide #2.

Guide #3 documents the whole step-by-step install process with screenshots, and can be used by junior sysadmins.

Olivier

[Sebastien Masson]

:-)

Again, the issue is now on how to do things. We know how to do everything. It's what we need to do.

Whatever the server will be, for sure those items are in common:

1-FS Layout (mountpoint, owner, size)
2-Required users
3-List of 3rd party (compiler, tools, etc)
4-Data that we should take in backup, retention, etc

This is what I have in mind, now I want to have your output on what other is missing. Even if it's not generic, let me know, I want to covert all aspect of requirement.

Also, if you have any document example. It will be nice if you can share it too.

Thanks