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:
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 . . .
I think these bugs fall under the category of install - we really need the update/upgrade procedure to take care of these issues.
(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.
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.
*** Bug 528274 has been marked as a duplicate of this bug. ***