|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] server documentation & configuration
|
On 1/18/07 , Chad Vogelsong < chad@vogelsong.net > wrote:
> I'm looking for software (preferably OSS) that will help me manage
> and document my servers at a new job.
>
> What this software should do:
> 1. Automatically inventory hardware, software & configuration files
> from multiple linux servers.
I setup a central subversion repository and have a directory in the
repository for each server. Within the directory for each server is
a virtual file system for each of the files within that server that I
wanted to have in the repository. This serves as not only a backup of
your important conf files but also as version control so you know what
changes were made by whom and when.
I don't, however, have this set as automatic. I suppose there is
technically nothing keeping you from having the subversion client do
a scripted "autocommit" using a cronjob. I personally like being able
to see the diffs between versions before committing the changes to the
repository -- and more importantly being able to document the revision
with comments when the change is committed.
> 2. It should either use SSH to connect to the servers or have a client
> agent that is run on the servers to report back.
Subversion supports both ssh connections and has a client program
(svn) that would run on each of the servers -- in this case they would
be subversion clients. You could surely script the reporting back
by having 'svn status' scheduled to run and report diffs somewhere.
If you are unfamiliar with subversion's client program, 'svn status' is
used to recurse through a file system which is under version control and
report any changes that have been made to any files since the previous
commit/update.
> 3. Use a browser interface to view information.
Subversion works here too -- it is a very simple process to have your
subversion repository hosted through the WebDAV module in Apache httpd.
By making the repository available through Apache/WebDAV you an link to
your repository and browse the "HEAD REVISION" of each file just as if
you were browsing the files on an FTP server.
> 4. Allow other documentation to be uploaded to the site (i.e.
> spreadsheets, documents, notes about servers, etc.).
Subversion again -- just reserve a directory in the repository for
each server for a place to store server specific documentation. Again,
you have the added benefit of version control here too.
> Sys Admins's should be able to login to the site and be able to go
> into a particular server and see the text from its /etc/hosts file, or
> the output of "ifconfig -a", or "netstat", or the contents of
> /etc/resolv.conf or any other such file or command.
Subversion would again cover files so /etc/hosts and /etc/resolv.conf
would be in there (in fact I have the entire /etc directory for each
server in my repository).
The output from ifconfig -a and netstat is a different story though and
I'm not sure I understand why you would want to do that and not just go
directly to the server over ssh to find the answers to those questions.
If that is really what you want to do then as part of your above mentioned
"automated script" you could certainly add those commands to the script
and have the output redirected to a file in the servers documentation
directory. Then these too would be updated on a daily basis and viewable
through WebDAV. Obviously any command you could run from the command
line and be able to redirect its output to a file COULD be satisfied by
this solution including ACLs and server statistics but I personally have
not gone that far with it.
One issue you don't mention is with regard to disaster recovery.
The subversion repository is ideal for cutting down recovery time because
after building the server it is (for most files) simply a matter of
running an 'svn checkout' in the appropriate directory. All of your
cusomized configuration files are restored/merged with the existing
files without any manual edits just as they were before the disaster.
Though I have been fortunate enough not to have needed this for a disaster
I have used this technique quite a few times with server upgrades after
core configuration files were replaced by the standard files used in
the package management systems. In my case, it happens frequently after
upgrading apache with rpms. The default /etc/httpd/conf/httpd.conf file
is easily restored from the repository and merged with the new settings
from the new version.
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|