Rich,
I made some progress. I reran the setup-ds-admin.pl script with the -u option and --debug --continue options.
setup-ds-admin.pl -u --debug --continue.
When I did this, I started getting errors processing files in the /usr/share/dirsrv/data and updates directory. The script was trying to process ldif files but kept bombing out be cause many of the DN it was trying to insert already existed. In order to move on, I modifed each problematic ldif file and then reran the script. i was finally able to get through the update process.
Now, I am able to launch the console and see that the admin server is running version 9.1.0 with build 2013.109.1825.
However, my slapd-config instance still is using the 9.0 jar and reflects version 9.0 with build 2011.312.195.
It would appear to me that the config instance did not get updated correctly.
I made some progress. I reran the setup-ds-admin.pl script with the -u option and --debug --continue options.
setup-ds-admin.pl -u --debug --continue.
When I did this, I started getting errors processing files in the /usr/share/dirsrv/data and updates directory. The script was trying to process ldif files but kept bombing out be cause many of the DN it was trying to insert already existed. In order to move on, I modifed each problematic ldif file and then reran the script. i was finally able to get through the update process.
Now, I am able to launch the console and see that the admin server is running version 9.1.0 with build 2013.109.1825.
However, my slapd-config instance still is using the 9.0 jar and reflects version 9.0 with build 2011.312.195.
It would appear to me that the config instance did not get updated correctly.
Paul M. Whitney E-mail: paul.whitney@xxxxxxx
On Dec 09, 2013, at 12:53 PM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:
On 12/09/2013 10:55 AM, Paul Whitney wrote:Paul M. Whitney E-mail: paul.whitney@xxxxxxx
On Dec 09, 2013, at 11:27 AM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:
On 12/09/2013 09:30 AM, Paul Whitney wrote:Rich,
I deinstalled and reinstalled my DS 9.0 ISO, then ran through the updates:
- DS9-RHBA-2011-1788 (nothing to update/install from here since the ISO is as current in versions)
- DS9-RHBA-2012-1345 (updated the 389-ds-console to 1.2.7-1)
- DS9-RHBA-2013-0960 (updated everything to 9.1)
So now this is what I have installed:
389-ds-base-1.2.11.15-22
389-ds-base-libs-1.2.11.15-22
389-ds-console-1.2.7-1
389-console-1.1.7-1
389-admin-1.1.34-1
389-adminutil-1.1.17-1
389-admin-console-1.1.8-1
redhat-ds-admin-9.1.0-1
redhat-ds-console-9.1.0-1
redhat-idm-console-9.1.0-1
redhat-ds-9.1.0-1
redhat-ds-base-9.1.0-1
redhat-admin-console-9.1.0-1
Did you run setup-ds-admin.pl -u on all of the systems that you upgraded?
I ran it and am getting the following error: Error adding entry 'cn=PAM Pass Through Auth,cn=plugins,cn=config'. Error: Already exists (i tried to remedy this by removing the entry, but still getting the same error).
If setup-ds-admin.pl -u is failing, then the console will fail to find the correct jar files.
"i tried to remedy this by removing the entry" - how did you do this?
idm-console-framework-1.1.7-2
java-1.6.0-openjdk-1.6.0.0-1.65.1.11.1.3
As root (just to eliminate any write permissions issue), I launched the 389-console.
That shouldn't make any difference.
Log in successfully to master on local host. However a couple of things:
- The console window cannot access any of the slapd instances or the admin portion because system "failed to install a local copy of redhat-admin-9.0.jar or one of its supporting files." (The 9.0 jar links were replaced with 9.1). Links in this directory are confusing as all get out. Not sure why so many are needed....
setup-ds-admin.pl -u is supposed to change the versions of the required jar files from 9.0 to 9.1.
Links in which directory are confusing? You should never have to look in the directory.
I agree I should not have to look in the html/java directory. But that is where the jar files come from and wanted to verify that 9.0 jar files were replaced.
You should see 9.1 jar files in that directory (no matter if setup-ds-admin.pl -u worked - the 9.1 jar files are in the rpms).
In the admin-serv error log I am getting error: File does not exist: /usr/share/dirsrv/html/redhat-admin-9.0.jar (the java directory was not overlooked in the path, this is the error in the log, as if it is looking for the 9.0 jar files in html).
Let's see what the console is looking for. Run
redhat-idm-console -D 9 -f console.log
Unfortunately, I cannot capture this information and post here. Info is on intranet with no access to Internet.
I don't it matters if setup-ds-admin.pl -u is failing.
scrub the console.log and email it to me (it will probably be too large to post to the list)
Paul M. Whitney E-mail: paul.whitney@xxxxxxx
On Dec 06, 2013, at 04:59 PM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:
On 12/06/2013 02:34 PM, Paul Whitney wrote:Rich,
I think the problem has to do with the version of JAR files the console I am running is looking for. I see in /usr/share/dirsrv/html/java a lot of symbolic links that cascade back to 389 jar files.
The console downloads these from the admin server and stores them in ~/.redhat-idm-console/jars. It is the latter directory used by the console.
They are all 9.1 and my console is looking for 9.0.
A 9.1 server installation should use the 9.1 jars.
What do you mean by "my console is looking for 9.0"?
While I am ok with creating symbolic links and for 9.0 jar files, why will the console not use the jars already present?
A 9.1 server must use the 9.1 jars, not the 9.0 jars.
Paul M. Whitney E-mail: paul.whitney@xxxxxxx Cell: 410.493.9448
On Dec 06, 2013, at 12:35 PM, Rich Megginson <rmeggins@xxxxxxxxxx> wrote:
On 12/06/2013 10:41 AM, Paul Whitney wrote:I recently upgraded my DS9 instance (RHDS9 RHBA-2013-0960) on both ldap server and my console. This should bring my servers to DS 9.1. Yet, I still see Version 9.0.0. Is this correct or did I miss a step?
There should have been something in the upgrade docs about running setup-ds-admin.pl -u after doing the yum update.
Paul M. Whitney E-mail: paul.whitney@xxxxxxx-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
