title: Installing Sun DSEE 6.3 on RHEL 5.3 link: https://onemoretech.wordpress.com/2009/09/29/installing-sun-dsee-63-on-rhel-53/ author: lembobro description: post_id: 238 created: 2009/09/29 06:15:49 created_gmt: 2009/09/29 06:15:49 comment_status: open post_name: installing-sun-dsee-63-on-rhel-53 status: publish post_type: post

This actually turned out to be less involved that I anticipated, although it was still somewhat time consuming the first time around.

One good thing: no issues with libraries, etc. Although still officially unsupported (latest supported is RHEL 4), there are no major barriers to running DSEE 6.3 on RHEL 5.3. The main thing you have to remember to do is install the usual compat libraries.

The only prerequisite worth mentioning is a Java application server for the new DSCC (Directory Service Control Center). Currently Sun’s own Java System Application Server 8.2 and Apache tomcat 5.5 are supported. For obvious reasons I chose to deploy Tomcat.

One major point going in is that the present version of DSCC requires that the directory and application servers run as the same system user.

As a best practice I always install server products as a non-privileged user, although in this case that will complicate things a bit since the developers seem to have assumed everything would be installed and run as root (you’ll see why later on).

For my test install I created a system user named “sunds” and made its home directory /opt/sun/dirsrv6, hereinafter “$DH” (for “Directory Home”). I then did a fresh install of tomcat 5.5 to $DH/tomcat5 as sunds. The following environment was set through the .bash_profile for this user:

`

JAVA_HOME=/usr/java/default
DH=/opt/sun/dirsrv6
CATALINA_HOME=$DH/tomcat5
CATALINA_BASE=$CATALINA_HOME
PATH=$JAVA/bin:$PATH
export JAVA_HOME DH CATALINA_HOME CATALINA_BASE PATH

`

One thing I want to stress is that, like other Sun products, during installation symlinks will be resolved to their actual paths no matter what — although not consistently. So don’t install to /u01/app/sun/dirserver if /u01 is really just a symlink to /nas10. While this could seriously cramp your style during Disaster Recovery and can make automated maintenance tasks more difficult, it’s a hard fact of life you might want to complain about to your Sun rep next time you see them.

I used the full “zip” distribution of DSEE 6.3 for x86 Linux (not the patch) for my initial install. This is a tar.gz that explodes out into several subdirectories, a readme, a license file and the actual setup executable called dsee_deploy, which is located under the subdirectory named DSEE_ZIP_Distribution. In my test install, for example, I su’d to sunds and used the following syntax:

DSEE_ZIP_Distribution/dsee_deploy install -i $DH

The install script is pretty self-explanatory, and I won’t go into detail here. Be sure to give the Installation Guide a thorough read before beginning.

One thing you won’t be able to do when installing the zip distribution as a non-privileged user is configure the various pieces to start and stop automatically when the host system is rebooted. Of course any sysadmin worth his/her salt is going to know how to write a simple init script for the platform in question, so this isn’t really an issue. I’ll provide an example init script in a future post.

My recommendation is to set up the DSCC and use it to perform initial administration tasks like creating directory server instances. While the documentation gives command line examples for these kinds of things, in this case the web-based admin console will probably be a little faster. Spend some time getting acquainted with the console. There’s no substitute for hands-on experimentation before deploying something that others are going to use.

Creating directory servers should be painless enough, so long as you follow this simple rule: always initially configure to listen on a port above 1000 so that it can be managed by your non-privileged user.

I used a variation on the default path for each instance, $DH/var/ds-user (it’s my practice to name instances for their purpose).

When adding a new context I usually follow the standard “dc=example,dc=com” convention, but renamed the database to “user” (it defaulted to “example”, as the first domain component value).

Logfile permissions should be set to 660, so that they can be read by the system user owner and any member of its group (I typically add my fellow admins that group for just this purpose — the default of 600 will only allow the system user to read them).

The core directory server daemon is still written in C, and continues to be configurable through editing of the dse.ldif file found under $DH/var/ds-user1/config like its predecessors. Most configuration parameters can also be modified over LDAP. Being a “Netscape family” directory, there continue to be many things stored in the directory database itself that make it nearly impossible to restore to a server that doesn’t have the exact same configuration as the source (as with many database products greater portability may be obtained by exporting data to a text file, in this case in LDIF format, where the host specific data can be removed before importing into a new database).

The main utility for getting things done at the command line are dsadm and dsconf, both found under $DH/ds6/bin. The docs contain some examples showing how to create, configure and load data into a directory instance with these tools, something I’ll cover in a future post on operations matters.

Whether using the console or the command line, the basic steps to create a directory server instance will be the same:

1. Create the server, providing the desired installation path (e.g. $DH/var/ds-user), and start it up. If running as a non-privileged user set the listening port to something over 1000, you can change this to standard ports 389 and 636 later on through the DSCC;

2. Set up a new suffix (e.g. “dc=example,dc=com”), and import your data into it.

Setting up the DSCC takes a few steps. The following is taken from the install doc:

1. Initialize the DSCC Registry using $DH/dscc6/bin/dsccsetup ads-create, and answering the questions asked (e.g. what to set the admin password to);

2. Set your tomcat environment (if you have not done so already through the .bash_profile for sunds);

3. Deploy the DSCC war file to tomcat. Copy dscc.war to $CATALINA_BASE/webapps/dscc and unzip it there.

4. Insert the bold text into $CATALINA_BASE/conf/web.xml where indicated:

`

**        <init-param>
            <param-name>enablePooling</param-name>
            <param-value>false</param-value>
        </init-param>**
    <load-on-startup>3</load-on-startup>
</servlet>

`

5. Startup tomcat with $CATALINA_HOME/bin/startup.sh;

6. Access the console at http://localhost:8080/dscc.

Keep in mind that other Java applications may already be using the standard server and connector ports that your new tomcat server defaults to, so you may have to edit server.xml to change some of those values (e.g. you might need to change server port 8005 to something like 8105).

Once the DSCC is up and running you can go in and register new or existing directory server instances and arrange them into server groups. The full range of operational tasks can be performed through the console, including backup and restore, importing and exporting data, changing parameters like logfile permissions, listening ports, schema elements and access controls.

Copyright 2004-2019 Phil Lembo