title: Sun DS 5.2 Patch 6 on RHEL link: https://onemoretech.wordpress.com/2009/09/17/sun-ds-52-patch-6-on-rhel/ author: lembobro description: post_id: 247 created: 2009/09/17 17:32:29 created_gmt: 2009/09/17 17:32:29 comment_status: open post_name: sun-ds-52-patch-6-on-rhel status: publish post_type: post

Sun DS 5.2 Patch 6 on RHEL

I was never a big fan of either Sun hardware or software. After almost a decade getting to know the ins-and-outs of their flagship LDAP directory server product (which in many ways is still best-of-breed) I’m still not.

Today’s task was to do a quick install of Sun Directory Server 5.2 (DS 5.2) on a Red Hat Enterprise Linux (RHEL) virtual machine and then apply Patch 6 (ID# 117668-05) to it. And yes, before we go any further the RH release is 4 U7. It would be 8, but my Unix infrastructure guys haven’t gotten there yet.

I had some previous experience installing this patch on some Sun Sparc boxes running Solaris 8 and 10, so I already knew that having the install owned by anyone other than root was going to require changing the LDAP port to something over 1000.

Oh, you’re probably wondering why would that be an issue. Well, as we all know only root can run anything below TCP port 1000. Now patch 6 requires that it be installed by the server owner, and does a restart of the directory as part of the install process. For most of us who give a hoot about security the server owner is not going to be root, and so the install is going to fail. Another example of something working very nicely in the lab overseas, but not going quite as expected once out in the field with paying customers.

In my case I’d already changed the server port to 1389 temporarily so as to avoid the above problem. But, of course, I ran into another issue.

tar: bin/slapd/install/ldif/roledit.ldif: Cannot change ownership to uid 865, gid 10: Operation not permitted

ad infinitum, until tar: Error exit delayed from previous errors.

After checking Sun’s support site (not a mention) and then the Internet (nothing relevant), I checked the error messages again and tracked the problem down to:

tar xof directory-5.2_Patch_6-us.i686--linux.tar

That comes from line 417 of the upgrade.pl script at the root of the patch directory. The script text is actually:

cmd "tar xof $dspkg_file";

The fix in this case was to just edit the offending line to omit the stupid ‘o’ switch, so it then read:

cmd "tar xf $dspkg_file";

What seems to happening is that executing tar with the “-o” switch confuses the utility into thinking it needs to restore the original permissions in the archive during extraction. This is very odd behavior because, at least for GNU tar, when coupled with “-x” the “-o” switch is supposed to prevent tar from trying to do this. Of course not restoring ownership when extracting is the default behavior for non-root users, since they wouldn’t have the privileges to perform a “chown” operation in any case.

If anyone over at Sun wants to discuss this, I’ll be happy to walk them through it. For now, I’ve got a directory to configure …

Copyright 2004-2019 Phil Lembo