A little tip: deploying a war file on different containers / application servers can lead to different results. Although their scope widely differs, Sun has 2 offerings when it comes to deploying a war file: Sun Java System Web Server (SJWS) and Glassfish.

Well, it turns out that Glassfish replaces the entire content of the directory where the application is deployed while Sun JSWS will simply overwrite the existing files, thus leaving all other files in place. In a recent case, I had copied some properties file in that directory (after a first deployment) and was surprised to find them there after a re-deploy.

Now, I know that I’m not really supposed to mess around with files of a deployed war but I find it to be a good reminder of the sometimes not so subtle differences between containers.

Advertisements

As you all know, Directory Services are key to OpenSSO. We support many of them but, beside OpenDS which we use for our embedded configuration store, one of the best LDAP Directory server out there is Sun’s Directory Server Enterprise Edition (DSEE for short). In a typical deployment you will want to store user data on a separate Directory Service.

I always thought that, starting from a freshly installed Solaris 10 box, the deployment of DSEE is everything but smooth. This post lists the initial steps one has to take to perform such deployment and follow the DSEE Administration guide (your sole reference on the matter) . This was also strongly inspired by some excellent posts (listed at the end).

First a few assumptions:

  • Our starting point is a machine that runs  Solaris 10. I used the latest release (Sept. ’09) available here. All updates were applied after the installation.
  • I’ll assume the installation is done as root. This might not be the optimal approach, security-wise, but I’m keeping it simple here.
  • I’m installing DSEE via the JES 5 installer. JES (Java Enterprise System) is our main delivery system for lots of Sun’s software. The neat thing about JES is that it bundles applications together (e.g. Access Manager 7.1 and DSEE). In the present case I only installed DSEE and DSCC, the DS Control Center (a useful interface to administer DSEE deployments).

Now onto the steps:

  1. The first step to be done is to configure DSCC by performing:
    <dsee install dir>/dscc6/bin/dsccsetup initialize
    Doing so results in an error from cacao: Cannot find property: [cacao embedded].
    The problem here is that JES reverted the version of cacao (Solaris’ Common Agent Container (more info here) to a previous one.
  2. We need to reinstall cacao from the Solaris 10 CD. Look for the 2 following packages: SUNWcacaort, SUNWcacaodtrace To install them, change to the packages directory and enter:
    pkgadd -d . SUNWcacaort
    pkgadd -d . SUNWcacaodtrace
  3. Start cacao: /usr/sbin/cacaoadm start
    You can verify it’s running fine with: cacaoadm status
  4. You can now re-attempt to run the initialization (step 1). You should see a message saying that the DSCC Registry has been created successfully.
  5. If you want to make sure cacao starts upon reboot, enter:
    /usr/sbin/cacaoadm enable
  6. The the admin guide says to access DSCC through the Java Web Console in your browser. Well, we need to make sure it is running first:
    /usr/sbin/smcwebserver status

    Most likely it’s not…
  7. Start the Java Web Server with:
    smcwebserver start
    Now you can access it with your browser and … Oops… it only listens on your localhost (127.0.0.1).
    To fix this, use svccfg:
    # /usr/sbin/svccfg
    # svc:> select system/webconsole
    # svc:/system/webconsole> setprop options/tcp_listen=true
    # svc:
    /system/webconsole>quit
    You’ll have to restart the Java Web Console at this point:
    /usr/sbin/smcwebserver restart
  8. The Java Web Console is now accessible on the standard port 6789 (using https) and VoilĂ , the configuration of DSEE as specified in the Administration guide can now proceed unhindered.

Was this useful? Did you have a different DSEE install experience? If so, please let me know!

Some very useful links I used for this post:

  1. http://oldmangriffous.blogspot.com/2008/10/centralised-authentication-on-solaris_26.html
  2. http://www.tjhsst.edu/admin/livedoc/index.php/Sun_Java_System_Directory_Server

While deploying OpenSSO on Glassfish (I used v2ur2), I ran in an interesting situatation:
Although deployment goes well, OpenSSO’s configurator (that is the process OpenSSO goes through the very first time you launch it after deployment) failed with a rather laconic LDAP operation failed message. Searching into the Glassfish server log, I could see that indeed LDAP had a problem:

Message:The LDAP operation failed.
--------------------------------------------------
The lower level exception message
error result
The lower level exception:
netscape.ldap.LDAPException: error result (68); The entry
ou=BasicUser,ou=CreationTemplates,ou=templates,ou=default,
ou=GlobalConfig,ou=1.0,ou=DAI,ou=services,dc=opensso,dc=java,
dc=net cannot be added because an entry with that name already exists
at netscape.ldap.LDAPConnection.checkMsg(LDAPConnection.java:4866)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2864)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2879)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2829)
/.../

After consulting experts on the matter, I had the solution to my issue:
Modify Glassfish’s domain.xml configuration file of the domain OpenSSO is deployed in (most of the time it will be the default: domain1).
The change is fairly simple:
Replace
<jvm-options>-client</jvm-options>
with
<jvm-options>-server</jvm-options>

Good to know…