Server Administration

Best Practice: Maintain up-to-date documentation.

The documentation should include server specifications, location, and installed packages.

Best Practice: The Administrator/root account should normally be locked. 

Use "sudo/run as" to perform admin level functions whenever possible.

Best Practice: Deny all, then allow for remote administration access only to authorized accounts.

When configuring a system for remote administration, it's best to start from a completely locked down configuration and then allow in only those hosts/accounts that are needed.  That way there is less of a chance that you might inadvertently open up access to locations/people you shouldn't.

Best Practice: Properly source your administration accounts.

Use LDAP for authentication where possible.  This allows quick provisioning/de-provisioning of accounts as needed.  Use local accounts if access is needed and LDAP is unavailable or if there's a need to separate the privileges of an admin account from the users normal account.

Best Practice: Backups are a must.  Off site backups are better.

While this may appear to be pretty obvious, it is not always done.  This process must be a part of the support plan for any new server roll out.

Best Practice: Create and use service specific aliases for access separate from the server name.

Provide a name for a server that is not used in any way except for the administration of that server.  All applications/services running on the server should have their own unique name that points to the real server name and is used for accessing that application/service. This allows for the seamless transfer of the application/service to another server.

Best Practice: Inclusion of system in the HAM system

All production systems need to have their information entered into the IS Hardware Asset Management system (IS HAM).

Best Practice: Use site specific config files on Apache web servers hosting multiple sites.

If an Apache web server is hosting multiple sites instead of putting all virtual host configurations into one large configuration file put each site's virtual host configuration into its own separate configuration file. Collect these site specific configuration files into a sub-folder (e.g., virtual.d). In the main configuration file (httpd.conf) add a line to include the other configuration files (e.g., Include virtual.d/*.conf). Within the sub-folder place the site specific configuration files (e.g., site1.conf, site2.conf, etc). Future changes to a given site's configuration can now be done with minimal impact to the other sites. This set up also allows for separation of control of the site configuration from the Apache server default configuration.