Bug 520493 - Upgrade from fedora-ds-1.2.0 to 389-ds-1.2.2 breaks 389-console and the admin server
Summary: Upgrade from fedora-ds-1.2.0 to 389-ds-1.2.2 breaks 389-console and the admin...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Install/Uninstall
Version: 1.2.1
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Viktor Ashirov
URL:
Whiteboard:
: 528274 (view as bug list)
Depends On:
Blocks: 389_1.2.3
TreeView+ depends on / blocked
 
Reported: 2009-08-31 18:52 UTC by Frank Delahoyde
Modified: 2015-12-07 17:05 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 17:05:29 UTC
Embargoed:


Attachments (Terms of Use)
A more detailed description of the problems and solutions. (2.20 KB, text/plain)
2009-08-31 18:52 UTC, Frank Delahoyde
no flags Details

Description Frank Delahoyde 2009-08-31 18:52:03 UTC
Created attachment 359308 [details]
A more detailed description of the problems and solutions.

Description of problem:
Upgrading from fedora-ds-base-1.2.0 to 389-ds-base-1.2.2
broke 389-console and the admin-server console. I'm offering
my solution as an attachment.

Version-Release number of selected component (if applicable):

389-admin-1.1.8-4.el5
389-admin-console-1.1.4-1.el5
389-admin-console-doc-1.1.4-1.el5
389-console-1.1.3-3.el5
389-ds-1.1.3-4.el5
389-ds-base-1.2.2-1.el5
389-ds-console-1.2.0-4.el5
389-ds-console-doc-1.2.0-4.el5
389-dsgw-1.1.4-1.el5

How reproducible:

Very. I've now performed 4 upgrades, they all initially have the same
problems.

Steps to Reproduce:
1. yum --enablerepo=389-ds upgrade 389-ds
2. setup-ds-admin.pl -u
3.
  
Actual results:

Please see the attachment.

Expected results:


Additional info:

Comment 1 Rich Megginson 2009-08-31 19:22:59 UTC
1) We use Sun's jre. Using java-1.6.0-openjdk on our platform is
   problematic. 389-console performance is abysmal, especially over
   slow network connections. Sun's jre by default can't find the jss4
   jars or libraries. Consequently, we patched 389-console to include:

   CLASSPATH=/usr/lib/java; export CLASSPATH
   LD_LIBRARY_PATH=/usr/lib64; export LD_LIBRARY_PATH

Is poor performance the only problem that openjdk has?

2) After the yum upgrade and running setup-ds-admin.pl -u,
   389-console started but didn't set up ~/.389-console/jars
   (I had an existing ~/.fedora-idm-console). So I manually copied them
   from /usr/share/dirsrv/html/java. I could now open the directory
   server console (but the admin server console couldn't open the 
   Configuration tab). Also, my old Fedora directory and admin servers
   also showed up under "Server Group" in the 389 Console.

The console will not set up ~/.389-console/jars when it starts.  You must first select a directory server or an admin server to open - it will then download the appropriate jar files from the admin server corresponding to the server you have selected to manage.  You should not have had to manually copy the jar files.

The problem with the old servers showing up in the console is a known bug.

3)

We are working on enhancing the update scripts to take care of this situation.  Sorry about the mess.  This will hopefully be the last time we ever have to rename the package . . .

Comment 2 Rich Megginson 2009-08-31 19:31:55 UTC
I think these bugs fall under the category of install - we really need the update/upgrade procedure to take care of these issues.

Comment 3 Frank Delahoyde 2009-08-31 19:37:12 UTC
(In reply to comment #1)
> 1) We use Sun's jre. Using java-1.6.0-openjdk on our platform is
>    problematic. 389-console performance is abysmal, especially over
>    slow network connections. Sun's jre by default can't find the jss4
>    jars or libraries. Consequently, we patched 389-console to include:
> 
>    CLASSPATH=/usr/lib/java; export CLASSPATH
>    LD_LIBRARY_PATH=/usr/lib64; export LD_LIBRARY_PATH
> 
> Is poor performance the only problem that openjdk has?
>

There also seems to be toolkit issues relating to mouse click detection. I
didn't spend much time looking and quickly reverted to Sun's jre.

> 
> 2) After the yum upgrade and running setup-ds-admin.pl -u,
>    389-console started but didn't set up ~/.389-console/jars
>    (I had an existing ~/.fedora-idm-console). So I manually copied them
>    from /usr/share/dirsrv/html/java. I could now open the directory
>    server console (but the admin server console couldn't open the 
>    Configuration tab). Also, my old Fedora directory and admin servers
>    also showed up under "Server Group" in the 389 Console.
> 
> The console will not set up ~/.389-console/jars when it starts.  You must first
> select a directory server or an admin server to open - it will then download
> the appropriate jar files from the admin server corresponding to the server you
> have selected to manage.  You should not have had to manually copy the jar
> files.
> 

I DID select the directory server (the 389 directory server, not fedora)
and the console gave me an error. No jar files were downloaded.

> The problem with the old servers showing up in the console is a known bug.
> 
> 3)
> 
> We are working on enhancing the update scripts to take care of this situation. 
> Sorry about the mess.  This will hopefully be the last time we ever have to
> rename the package . . . 

Not a problem. Trying to help. This is an excellent product and we use it
9 different locations, including 4 ships.

Comment 4 Rich Megginson 2009-09-21 19:27:13 UTC
An update framework has been added to the DS code base.  setup-ds-admin.pl -u has been changed to use this new update framework, and should be able to convert/fix up the old Fedora config entries to be 389 instead.

Comment 5 Rich Megginson 2009-10-12 15:20:01 UTC
*** Bug 528274 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.