13

DISCLAIMER: I'm relatively new to Linux. I debated putting this on SuperUser or ServerFault because the answer does require an explanation of Linux as a system (and not a specific programming problem), however I'm interested in this from a Java developer's perspective, and I argue that this is a specific problem because where I install GlassFish greatly impacts my Java configuration, and ultimately, app configuration. Not to mention posting this question on those other sites probably won't garnish any attention from a Java developer, more over system admins, who may not know enough about Java to weigh-in fully on this decision.

I'm trying to decide where to install GlassFish and it seems to me I have (realistically) 4 viable options:

  • /opt/glassfish/
  • /usr/local/glassfish/
  • /home/myUsers/glassfish/ (which is what all the OGS docs show in their examples)
  • /home/ogs/glassfish (as its own user, similar to how Apache web server is sometimes setup)

I'm wondering what the pros (taking into consideration the nature of how Linux treats these directories differently, the FHS, etc.) and cons of each approach are.

I've read that there are mounting/paritioning benefits to installing it under opt/. However, I normally install 3rd party software to usr/local/, so I'm a little unsure about that as a strategy.

The Oracle GlassFish Server (OGS) docs all demonstrate (but never outright recommend) GlassFish being installed under your home directory (home/myUser/).

Then again, I've read that it is fairly common to install daemon-type services (which is what I would imagine I would be using GlassFish as - where I start it once and it only comes down for routine maintenance or crashes) as their own user (home/ogs/glassfish/).

I'm sure this decision is also impacted by how I'm going to use GlassFish, so let me qualify this question with a few constraints:

  • I intend to deploy 4 OGS instances across 4 VMs on the same physical machine and cluster them into the same domain (1 of the 4 server instances will be the admin server for the domain)
  • Several applications will be deployed to this cluster (all 3 non-admin nodes) at the same time, and should be running 24/7/365 except for when they crash (hopefully not often!) or when I need to maintenance or tune them
  • Each application will be farily large and I would like to configure them with real admin, not "bare bones" de minimis, default settings

If these don't provide specific-enough information to help make this choice, please ask and I can be more specific.

I guess, when the dust settles at the end of the day, I'm looking (more or less) for a matrix with each of the four directory options (plus any other obvious ones I've omitted) compared against their respective pros & cons.

IAmYourFaja
  • 55,468
  • 181
  • 466
  • 756
  • The physical location doesn't make any different from a technical standpoint, AFAIK, not sure why it would other than some might require minor tweaking with regards to access rights. – Dave Newton May 19 '12 at 15:37
  • The more interesting question is why you want to use glassfish at all. – bmargulies May 19 '12 at 17:45
  • @bmargulies - I wanted clustering over the glass fish servers and tomcat doesnt make so well with ears – IAmYourFaja May 19 '12 at 19:07

2 Answers2

3

There's also the option of using your Linux distro's package management system to install Glassfish. On Ubuntu for example, you could install it using 

sudo apt-get install glassfish-appserv

and let it get installed to wherever the package owner thought it should be installed.

I myself tend to steer away from the above option, as I like to exert my own control over which exact version of Glassfish (or any other Java server/software) is installed and where, but I just wanted to throw that out there, as it's one of the things you could do.

Now for the individual options you've provided:

/opt/glassfish/ This is the preferred option as far as I'm concerned. It keeps the software on a separate directory outside of the regular Linux installation, and allows the mounting and partitioning benefits you mention.

/usr/local/glassfish/ I don't like this much, because /usr/local is generally used by third-party software that is installed using the distro's package management software (apt/yum/etc), and on most distros has directories like bin, etc and lib under it. Putting a directory for glassfish under it, would make it out of place.

Also I prefer to keep system directories separate from custom software that doesn't use the distro's package management tools.

/home/myUsers/glassfish/ , /home/ogs/glassfish

These 2, I would not recommend.

They are only described in most places, because the author doesn't want to assume that the user has root access on those boxes, in which case the home directory would be the only one you'd be guaranteed to own. If you own the system and are managing it, those restrictions don't apply.

Remember, home directories are for specific users. I always recommend server software being managed with individual users' accounts that have the required privileges. Putting software in someone's home directory would mean that you either

  1. Give everyone who needs to manage Glassfish, the password to that user account
  2. Give multiple users read/write access to the home directory of a specific user.

Either way, that's not good system administration policy.

There's not much of a Java perspective here, but if you ask me, there doesn't need to be.

Rajesh J Advani
  • 5,585
  • 2
  • 23
  • 35
2

Regarding the prior recommendation, some tradeoffs remain:

  • If placed in /opt or /usr/local, you will have to have read/write access to those directories, meaning that you will have to have root access to the box. In some environments (where IT controls the platform), IT will not let you have root access. You would have to delegate to IT the responsibility of installing, patching, and upgrading the GlassFish binaries.
  • If placed in /opt or /usr/local, then you will also have to place the domain directories (--domaindir) in a separate location unless you want them owned by root (unlikely). This was the default in GlassFish 2.x RPM installs on Linux. GlassFish 3.x does not have RPM installs (from Oracle, anyway), but you can still split the two. This isn't a bad tradeoff, but something you should understand.
    • If placed in a "home directory", then you have rights to upgrade the core binaries, install patches, etc, separate from IT. There is good/bad/ugly in this approach depending on organizational responsibilities.

Hope this helps.

John Clingan
  • 3,324
  • 21
  • 13