Monday, January 26, 2009

Solaris ldap naming - Part 1 Directory Server Enterprise Edition

Now that we've decided to go with an LDAP directory server, the question is - which one?

The major players appear to be:
Apache Directory Server
OpenDS
OpenLDAP
Sun Java System Directory Server

I'm pretty sure that Solaris clients can be made to work with pretty much any LDAP server (even Windows 2003 r2 these days), but in the interests of K.I.S.S, I'll stick with the SUN product for this guide. I expect this will be the most common approach taken by most administrators.

The current full name for the Sun directory server is "Sun Java Server Directory Server Enterprise Edition", a REDICULOUS mouthful - come on SUN, seriously!.
I shall refer to it simply as DSEE everywhere going forward.

DSEE needs to be installed in the global zone, or a full-root zone. A sparse-root zone doesn't work unfortunately. Technically you could install the common components only in the global zone, and the rest can be installed in a sparse zone, but that messes with my global zone and is just generally messy For the installation of DSEE, I have created a full-root zone on persephone, my x86 SXCE 105 VMware ESX guest. The zone is called ds1.

Installation steps:

  1. Download and install the native pkg version of DSEE. The main product appears to be "java ES 5.0u1" which comes with DS 6.2, and there is an update patch which takes that up to 6.3. I have it on good authority that 6.2 is evil - make sure you download the 6.3 update too!
  2. I used ssh X11 forwarding to run the installer via ./installer. I assure you - this is much nicer than installing over the command line! I seleted DSEE 6.2 and it's subcomponents only.

  3. The shared components upgrade screen was a bit of a surprise, and it highlights a bug when installing on recent SXCE builds. It listed some upgrades to Cacao that are actually downgrades. On my system it wanted to "upgrade Cacao 2.2.0.1 to 2.0::PATHCHES:12384". You have to continue anyway, but the unfortunate reality is that you are going to end up with a broken cacao that will need to be reinstalled from original media :(Next I failed the OS resources check because I didn't have SUNWpl5u installed, which turns out to be a perl package.
    This turned into an even bigger problem as it turns out that sxcr 105 doesn't even ship with SUNWpl5u on the DVD any longer (that will be why the resource check was moaning!). I seems that in modern SXCE builds the SUNWperl584core pkg is used instead.
    Fortunatly I still had a sxcr95 DVD around, which did have the package but it turns out that SUNWpl5u can only be installed in a global zone....ack!Boy this is fun isn't it!
    So I had to install the sxcr95 SUNWpl5u package in the sxcr105 global zone to proceed with the install, all the while crossing my fingers hoping that this won't break my perl for all my existing and future zones on persephone.

  4. The install continued, and I chose to configure the server now, including creating a default DS instance. It used the default path "/var/opt/SUNWdsee/dsins1", which didn't seem all that intuative to me, but I left it as is.
    I changed the Suffix to dc=solnet,dc=com to suit my test environment here, but otherwise left everything as default, including running everything as root. (I'll try to come back to that!). The install proceeded smoothly after that.
  5. Next I tried to install the upgrade patch to get up to DS 6.3. As I'd almost come to expect by now, this too led to cursing. The patchadd folder contained two packages that I didn't have installed on the system, which in turn caused the whole patch to fail. I didn't install the ldap-proxy, but it appears the pactch fails it if can't patch it regardless.This is actually my first time installing a proper solaris patch, since I've always lived a bit on the edge running sxcr or higher. I found that if I deleted the two offending folders from the patchadd folder, it would proceed.
    rm -rf 125278-07/SUNWldap-proxy, and rm -rf 125278-07/SUNWldap-proxy-man did the trick, and the patch installed cleanly.
  6. Ok, actually on to configuring the product at last!
    I connected to the webconsole over https://ds1:6789. Normally I disable the webconsole by default due to it's memory usage, check that svc:/system/webconsole:console is enabled.
    You can connected with your standard non-root user initially and the DSCC will give you the following (helpful) error: the Directory Service Control Center requires a one-time initialization process to be run before it can be used. You then log in an root, and after following the DSCC wizard it will helpfully tell you that
    Authentication As root No Longer Required.
  7. Once logged in again as my non-root user, I saw that I didn't have any directory servers registered. This came as a bit of a surprise, as I know we created one during the install in /var/opt/SUNWdsee/dsins1!

    After a quick bit of digging around, I quickly realised that cacaoadm wasn't working and that I was hitting this bug again. This is the bit that I mentioned earlier about Cacao needing to be re-installed.The fix is to un-install SUNWcacaowsvr, and SUNWcacaort and to revert back to the OS provided versions of these packages (2.2x rather that 2.0x).
    SUNWcacaomn doesn't come with ON, so I left that package at the older 2.0 version.

    After being re-installed the dscc and cacao aren't talking properly:
    # /opt/SUNWdsee/dscc6/bin/dsccsetup status
    *** DSCC Application is registered in Sun Java (TM) Web Console
    *** DSCC Agent is not registered in Cacao
    *** DSCC Registry has been created Path of DSCC registry is /var/opt/SUNWdsee/dscc6/dcc/ads
    Port of DSCC registry is 3998

    You must reregister the Cacao agent in the dscc using the cacao-reg command
    # /opt/SUNWdsee/dscc6/bin/dsccsetup cacao-reg
    Registering DSCC Agent in Cacao...
    Checking Cacao status...
    Stopping Cacao...
    Enabling remote connections in Cacao ...
    Starting Cacao...
    DSCC agent has been successfully registered in Cacao.
    At this point I thought I'd check in on the resourcse usage of the zone. DSEE and the webconsole are real memory hogs!How much RAM is used by an idle DSEE server (zone) with no data yet?

    ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
    4 44 388M 568M 21% 0:01:07 0.4% ds1 
    Over half a gig already! cripes!

  8. For reasons beyond me, the default behaviour for both the DSCC registry/management system and your DS instance both won't start by default. You must use the dsadm command to register them both within SMF to get them starting by default with the following command:
    ds1:~# /opt/SUNWdsee/ds6/bin/dsadm enable-service --type SMF /var/opt/SUNWdsee/dsins1/
    Registering 'Directory Server' as 'application/sun/ds' in SMF ...
    Registering '/var/opt/SUNWdsee/dsins1' as 'ds--var-opt-SUNWdsee-dsins1' in SMF ...
    Instance /var/opt/SUNWdsee/dsins1 registered in SMF
    Use 'dsadm start '/var/opt/SUNWdsee/dsins1/'' to activate the service 

    And then run the suggested command to actually start you instance.Repeat again for the DSCC registry:ds1:~# dsadm enable-service --type SMF /var/opt/SUNWdsee/dscc6/dcc/ads/

    Now your DS instance (and management service) are installed and ready for configuration!Phew!Note to Sun: This really needs some better polish in a BIG way!
  9. Bonus step: Have yourself a coffee, there is lots more to come.

No comments: