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.
Regarding the docson page...
- It's a work-in-progress, so if something is vague I apologize (and will fix it)
- The designation of
/optas the choice for 3rd party is not a must - you can instead use
/usr/localif you really want to, as long as it's consistent. We just prefer
- 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.
- Would this model work for you?
- 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.