asset management tools?

Paul Lussier p.lussier at comcast.net
Wed Mar 1 08:54:01 EST 2006


Neil Joseph Schelly <neil at jenandneil.com> writes:

> I'm looking to replace a spreadsheet listing all our servers with a
> web-based asset management tool. I'm wondering what experience all
> of you may have with the available tools out there.

I've never found anything decent.  We're in the (very slow) process of
writing our own.  Part of the problem with an asset management system
is that it's a shame to stop there :)

What we're doing is builing what I called the "Grand Unified Database
of Everything" (I need a better name so I can have a snazy acronym :)

It started out as a means to track hard drive temperature over time.
But since we needed to have all systems and all drives in all systems
in the database, we decided to make it a general asset management
system.  From there we decided to add tables to manage users.  From
the database, once we get the scripts written, we're planning on generating:

  - /etc/netgroup
  - /etc/sudoers
  - /etc/ssh/ssh_host_keys
  - DNS zone files
  - LDIF for an LDAP server
  - ~<special user>/.ssh/authorized_keys(2)
  - a (dynamic) web based phone/pager contact list

Eventually, our hope is to allow HR and IT to create and (en|dis)able
accounts and priviledges via a web based interface to the database as
well, which will require creating and managing Kerberos principals,
VPN access, Active Directory entries, etc.

Did I mention this is very slow going? :)

> Essentially, I want to be able to list servers and specify arbitrary 
> attributes for those servers as we have a number of inventory attributes we 
> keep track of that are rather specific to our use and I'm sure won't be in 
> any preselected group of attributes.

I'd love to see the list of things you care about.  Feel free to mail
me privately if you don't want to discuss this on list.

> It would be nice to be able to attach files to server records, add an 
> inventory of spare parts (or effectively non-server items), track changes to 
> servers, and a make use of a user authentication system.  Those aren't 
> requirements, but would be pretty cool to have.

We've allotted for free form notes to be attached to each system,
eventually we expect this to be used mostly via a web driven
interface, but we're building up a bunch of commandline tools which
may automagically insert data into these fields as well.

I'd love to say I can give you what I have, but a) it's so immature I
don't think I could get it all running again in new location, b)
there's nothing generic about our setup with the exception of the
database schema itself, which can easily be re-created ad hoc.

Btw, for those who are interested or care and may want to carry on
further discussion of design choices (read: start a flame war ;)
we're doing this all in Postgres and Perl because:

   a) Postgres has a lot of features we need that MySQL is lacking.
      Oracle was never considered for the obvious reasons.  (as an
      aside, we know both MySQL and Postgres, and use MySQL for other
      stuff in-house.)

   b) Perl has an extremely robust database framework already built
      for it which is lacking in other languages. Additionally, we
      have hundreds of thousands of lines of Perl code here, so
      writing a few more things in perl is a no-brainer for us.

PHP was never considered, since we're doing so much with command line apps.

PHP will probably not be used for any web stuff either, since we're
mostly a perl shop filled with people who already eat, sleep, and
breathe perl.

Python may well be a great fit for this type of application, but a)
see above point about eating perl here, and b) I don't think Python
has the database infrastructure perl has quite yet (though I'd love to
learn otherwise).  Other languages mentioned were: Ruby, and Lisp.
Both rejected because a) no one here know Ruby well enought, though we
all think it's a really neat language, and Lisp, well, mostly for the
same reasons as already mentioned for all the other languages :)

-- 

Seeya,
Paul



More information about the gnhlug-discuss mailing list