managing applications

[Ben Scott]

On Jan 7, 2008 4:31 PM, Bill McGonigle <bill at bfccomputing.com> wrote:
> What's the best way to maintain installs of applications?

  Pay somebody else to do it.  ;-)

>    This would be easier if there were /etc/sysconfig/iptables.d/mysql
> and /etc/sysctl.d/mysql.conf, but there aren't (yet).

  Patches welcome.  ;-)

>  All I know to do is to move things manually, hope
> I've done documentation well (pfft) and test/pray.

  I honestly think that documentation and discipline are just
essential for this.  "You can't comb a hairy ball smooth."  If you
carefully document everything you do, recreating it is
straight-forward.  If you don't document it, well...  you reap what
you sow.  One of those harsh truths.  FWIW, after 15+ years of doing
IT, I still find myself relearning this lesson.  Life is a persistent
teacher.

> The RPM database (could be deb, doesn't matter) knows about many
> of these files.

  "rpm -Va" can be a tremendously useful command (though it can't tell
you about new files, not owned by any package).  You can do things
like filter for only config files.

  AIDE/tripwire/etc can also be adapted to a similar purpose, i.e.,
identifying everything that's changed or new.  Might be useful for the
migration scenario.  Though it only helps if you remember to make a
baseline, and keep it current.

  Saving the output of "ls -lR" over time can also help in a similar way.

> Sun has favored /opt, but that's a bit of an admission of defeat,
> at least from an LSB perspective.

  It isn't really compatible with package management, either.  I
suppose you could just copy everything into /opt/, but then you're
loosing all the benefits of package management.  I suppose you could
find/build a distro that puts everything under /opt/, but I suspect
that's a dumb idea.  And it won't help with shared files like
/etc/sysctl.conf or whatever.

> A tree of symlinks into /opt might be a compromise.

  Ewww.  What would that get you (aside from a headache)?  :)

> Some kind of runtime patching (e.g. sysctl.conf-patch-mysql) might
> be appropriate.

  I've done this before, sort of, when designing a standard base
config for deployment on all manner of different customer systems.
But it only did initial config to our internal standard; it didn't
keep track of changes past that.

>    There's some tool (which understands pipes, of course) that will
> gather up the important bits of my install and put them in an archive.

  There's all sorts of tools designed to help with this, but from what
I've seen, they're all fairly heavyweight, invasive, and insular.  I
suspect that's an inevitable consequence of what they're trying to do
(control everything).

> Any thoughts?

  I like fudge.

-- Ben