Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
There doesn't seem to be a question in this 'question'. –  Zoredache May 30 '09 at 3:12
    
You are correct, but it is a relevant discussion. If such things are not taken into consideration, in a dynamic environment where new projects come and go on an almost daily basis - the systems that house them will soon turn into an unmanageable kitchen sink, and there's nothing (standard-wise) out there to combat it - which means we're at the mercy of enterprise software vendors writing clean software - which is about as likely as fat man's sweat smelling like perfume. –  Xerxes May 30 '09 at 3:20
1  
Sure, but isn't the point of Server Fault question/answer, rather than announce/comment? –  Alex Jurkiewicz May 30 '09 at 8:24
    
Note taken - I've added my questions to the post now. –  Xerxes May 30 '09 at 9:05
    
From the Serverfault FAQ: "Avoid asking questions that are subjective, argumentative, or require extended discussion. This is not a discussion board, this is a place for questions that can be answered!" –  Brian De Smet May 31 '09 at 5:35

1 Answer 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.

share|improve this answer
    
Thankyou for your feedback. –  Xerxes Jun 1 '09 at 4:01
    
I also think this is pretty much the best way to go. It also doesn't require any "extension" to the FHS. Isn't this already the standard? –  Kamil Kisiel Jun 9 '09 at 17:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.