Home » forums » Luminis Platform / System

Luminis 4 Install issue with most recent Solaris 10_Recomended

Submitted by cfriend on Mon, 2009-06-22 23:53

Has anyone had any issues or attempted to install Luminis 4 Resource Tier with either the most recent ISO of Solaris 10, or any 10_recomended patch cluster since March 20th 2009?

We are in the process of installing a fresh instance of Luminis 4 and have done it successfully a number of times on project machines using Solaris 10 ISO 10/08 with a 10_recomended patch cluster from 3-20-2009 (believe that is the correct date, give or take a day).  I attempted to install Luminis 4 in mid May using a Solaris 10_recomended patch cluster from late April and received an error when the installer was configuring the LDAP server.  I reverted back to the previous known working Solaris patch revision I had on hand to complete the install.  The error is as follows:

Error: [E315] The 'perl' external program failed (exit code = 49):  Welcome to the Directory Server preparation tool for Sun Java(tm) System communication services. (Version 6.3 Revision 2.03)  This tool prepares your directory server for use by the communications services which include Messaging, Calendar and their components.  The logfile is /var/tmp/dssetup_20090522095300.log.  The entered password for DN cn=Directory Manager is incorrect.  Please correct the problem and re-run this script.  Remedy: [F000] Contact Sungard Higher Education Support

This error also was present using the most recent 10_recomended patch cluster from 6-18-09.

The log files don't have any insight into the cause of the problem and the only error messages state that the password entered is incorrect.  The same install.conf file was used from previous successful Luminis 4 Installs, except for hostname changes.

Also, if I install the Luminis 4 resource tier first then patch, it seems to break the directory server.  I did not check the logs for that attempt due to project deadlines to have a working system in place and just reverted to what worked before.

Our SCT support ticket was closed when I stated I was installing using a previous patch cluster and no mention was given that they would investigate.

Anyone else ran into a similar issue?

‹ RSS FEed of Portal ANnouncements Issue with logins during Registration ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Most Recent Solaris_10 install

Submitted by hwilly007 on Tue, 2009-06-23 15:03.

I did one using the March 2009 release, sysadmin says the patches, that iPatch said all were up-to-date (re-loaded in May sometime)

The only issue I had was with the install binary being read correctly when mounted in a zone as zfs vs ufs - the error wasnt plain and was during the initial JES install. Once I remounted all went as usual. I script as much as possible of the pre-install "Known Issues" so very little is left to chance.

Sounds like the 10_rec patches are breaking things, I'd go with U7 : my uname >

Generic_139555-08 sun4v sparc SUNW,Sun-Blade-T6300

good luck

Solaris patch 119213-19 is the culprit

Submitted by mjskif on Tue, 2009-06-23 21:55.

We ran into this problem and it is caused by Solaris patch 119213-19.  This patch can removed or You can set the following environment variable in /etc/profile.

NSS_STRICT_NOFORK=DISABLED

It is documented in the Luminis Platform IV known issues doc but it is hard to find.

Mike

 

 

 

Thanks, that was it.  The

Submitted by cfriend on Thu, 2009-06-25 10:38.

Thanks, that was it.  The Known issues document that I have doesn't have anything about that issue there.  Searched Sungard's site and finially found the updated one.

Thanks again,

Chris

Interesting...

Submitted by rcshishe on Wed, 2009-07-01 13:10.

I had come to the conclusion it was something breaking SSHA passwords.  The problem I had was all authentication to LDAP breaking.  In troubleshooting I edited the dse.ldif file and changed the Directory Manager password from a {SSHA} to a {CRYPT} hash to see if it would enable that user's password.  It did indeed work, resetting the value to another {SSHA} generated value did not.  I suspected and confirmed this patch was the culprit after reviewing the installed patches and noting this one was the only one remotely having anything to do with Sun Directory Services.

 

Here's a good thread on Sun about the issue:

http://forums.sun.com/thread.jspa?threadID=5388655

 

Also from here the patch notes themselves:

https://sunsolve.sun.com/search/document.do?assetkey=119213

This seems suspicious:

 

6821612 NSS 3.12.x series
6821617 cert name matching: RFC 2818 vs. backwards compatibility (wildcards)
6782276 Error override "trust flags" don't override invalid CA certs in NSS 3.12
6821618 Stop honoring digital signatures in certificates and CRLs based on weak hashes
6799382 CERT_AsciiToName incorrectly parses a name in which an RDN has two or more AVAs separated by '+'
6821620 add environment variable to disable/enable hash algorithms in cert/CRL signatures
6767341 Need to add RPATH to 64-bit libraries on HP-UX
6764022 Using NSS 3.12 makes Directory Server daemon ns-slapd dump core on some Unix platforms
6821630 In prlink.c errStrBuf is not thread-safe.
6821631 ForkAndExec is crashing on Solaris 8/9 due to environ being NULL
6821633 support HmacSHA256, HmacSHA384, and HmacSHA512
6821634 add support to JSS to initialize NSS with more options
6821638 Wrong OIDs for SHA-256, SHA-384, and SHA-512.
6821640 Add SEED support to JSS.
6821643 Expose the TLS session ticket extension (STE)
6821645 JSS doesn't support AES Key unwrapping

Perhaps the changes to support higher levels of SHA encoding broke salted sha?

 

Nope, don't think so

Submitted by novosirj on Wed, 2010-03-24 02:36.

It sounds like you may not have read the bottom of the patch description:

IMPORTANT NOTE:
** This version of NSS is known to be incompatible with certain versions of Sun Directory Server version 5.2. **
** Installing it without corrective action will result in directory service stopped. **
** Newer versions of Directory Server are not affected by this incompatibility issue. **
** Please see http://docs.sun.com/source/820-3003/index.html for detailed information on this issue, including the availability
of a related Directory Server version 5.2 patch.**
** This behavior can also be changed by setting an environment variable (details below).**

 

It is by design that LDAP doesn't work right after this patch. The only thing that is a little unfortunate is that there is no patch to the directory server that fixes the behavior, only a workaround (unless anyone else reads this differently than I).

FYI, I got around this by setting the parameter in my .cprc file, not /etc/profile -- I really didn't want everything bypassing that rule, if possible, only necessary products.

Syndicate content