Home / server / Questions / 15334
In Process
Xerxes
Asked: 2009-05-30 18:34:55 +0800 CST

Extending the Filesystem Hierarchy Standard (FHS) to house Enterprise Software

  • 772

I'm not sure how many people would be interested in this, but I think if you have more than a few hundred servers, it starts becoming an issue.

An applications team/middleware sends a request that they need the next version of an Enterprise software to be installed on this and that app server. What do you do?

  • The vendor does not provide you with an RPM
  • Even if they do, the RPM is a huge mess
    • For example one RPM we had basically installed a tarball into /tmp, and as a post-install, untarred it, and then removed the tarball file. If you don't already see it, that means that it will be impossible to uninstall as it only installed 1 file.
  • Where they provide install scripts, again...
    • You have no visibility of where files will be installed to, other than trusting the docs.

In short, each vendor has their own "rules" and "defaults", and worst, some seem to not have any.

The only way I've found to combat this is to study the installation on a dev machine, and create my own RPM for it - this then brought up the topic of this post - coming up with a standard of where things should go.

The Unix FHS deals with many of the issues, but as it is not it's job - it also misses the ones that are specific to 3rd party software.

Extending the FHS, Standards & Rules for Vendor Products Installation

What a colleague of mine and I have been working on is extending this standard to house vendor software (Oracle databases, Oracle application servers, Teamsite, Informatica, etc., etc.).

I've documented this here, and we've actually been very happy with it...

  • It does not in any way violate the parent FHS
  • It is flexible enough to work around rigid enterprise software installs

If anyone is interested in this matter (i.e., thinks highly of following standards, and setting them where need be, and cares about maintaining a clean system where a newcomer can (almost) intuitively pick up and start walking) - I'd like to know....

  • How have you managed to solve the problem?
  • If this model would work for you, and if not - why not?

My ultimate aim is to make this model something that anyone from any company can pickup and use.

Notes

Regarding the docson page...

  • It's a work-in-progress, so if something is vague I apologize (and will fix it)
  • The designation of /opt as the choice for 3rd party is not a must - you can instead use /usr/local if you really want to, as long as it's consistent. We just prefer /opt.
  • Before you ask, things such as /etc/opt/<vendor>/<product> and similar paths do have a reason for being that way, and are directly inherited from the FHS.

Question

  1. Would this model work for you?
  2. Anything in here that you feel has not been addressed?

Assumption of course is that you have enough servers to warrant using this standard to begin with.

linux unix fhs

1 Answers

  1. I was going to suggest /opt/<vendor>/<product> even before I saw you suggest it in your proposed extension. So, yes, it works for me.

    My rule of thumb is:

    /, /usr: The OS itself; things that use the native packaging system.

    /usr/local: things I've developed myself, or that I've compiled from source.

    /opt: third party products.

    • 2