Hi,
I'm currently setting up 389 Directory Server on a server running CentOS 7, and I have a weird and somehow showstopping bug.
All the spaces are suddenly missing in the admin console. Here's a screenshot so you can get the idea :
https://www.microlinux.fr/download/389-admin-console-2020.png
So instead of "Standard branch for configuration information", I get "Standardbranchforconfigurationinformation", "Secure connection" reads "Secureconnection", etc.
I tried to add a user in my directory, with "Nicolas Kovacs" in the "Common Name" field, but instead of "Nicolas Kovacs" I get "NicolasKovacs" and there is no way to add space between the first and the last name.
Last year I made the same setup and even wrote a series of blog articles about 389 DS on CentOS 7, and everything worked perfectly. Here's the screenshot from last year's setup:
https://www.microlinux.fr/download/389-admin-console-2019.png
Any idea what's going on here ?
Cheers,
Niki
On 4/25/20 10:41 PM, Nicolas Kovacs wrote:
I tried to add a user in my directory, with "Nicolas Kovacs" in the "Common Name" field, but instead of "Nicolas Kovacs" I get "NicolasKovacs" and there is no way to add space between the first and the last name.
Are you sure the input lacked a space character, and that this isn't just a font rendering bug?
Le 26/04/2020 à 08:31, Gordon Messmer a écrit :
Are you sure the input lacked a space character, and that this isn't just a font rendering bug?
100 % positive.
I tried it on a different sandbox server without X installed, but only with xorg-x11-xauth.
From my workstation running OpenSUSE Leap 15.1, I connected to my admin console
using the following command:
$ ssh -X microlinux@192.168.2.5 /usr/bin/389-console -a http://192.168.2.5:9830
And I have the same problem here. When I try to fill out the "UserID" field with "cn=Directory Manager", I can't put in a space after "cn=Directory". I can hit the space bar as much as I want, the cursor won't budge.
I'm puzzled.
Le 26/04/2020 à 08:45, Nicolas Kovacs a écrit :
100 % positive.
I tried it on a different sandbox server without X installed, but only with xorg-x11-xauth.
From my workstation running OpenSUSE Leap 15.1, I connected to my admin console using the following command:
$ ssh -X microlinux@192.168.2.5 /usr/bin/389-console -a http://192.168.2.5:9830
And I have the same problem here. When I try to fill out the "UserID" field with "cn=Directory Manager", I can't put in a space after "cn=Directory". I can hit the space bar as much as I want, the cursor won't budge.
I'm puzzled.
I investigated this some more. Here's what I found.
Installed a vanilla CentOS 7 GNOME desktop.
Activated EPEL and installed 389-ds.
Launched the setup script for 389 DS.
Works perfectly bot locally and from my remote workstation with ssh -X.
So far, so good.
Back in 2019 I ran 389 DS on a minimal CentOS 7 installation. Installed 389-ds from EPEL, installed xorg-x11-xauth, and then opened the graphical admin console from my workstation.
But when I do this now, I can't seem to use spaces in the admin console's input fields.
Any suggestions ?
Le 26/04/2020 à 11:43, Nicolas Kovacs a écrit :
I investigated this some more. Here's what I found.
Installed a vanilla CentOS 7 GNOME desktop.
Activated EPEL and installed 389-ds.
Launched the setup script for 389 DS.
Works perfectly bot locally and from my remote workstation with ssh -X.
After some more experimenting, I can confirm this is a serious bug. After updating all packages on the system, it just reappeared.
Here's how you can reproduce it.
1. Install CentOS 7.7 but without updating the system.
2. Activate EPEL.
3. Install 389-ds.
3. Setup 389 DS.
4. Launch 389 Admin console.
5. Login as "cn=Directory Manager"
6. Everything works perfectly.
7. Update the system : yum -y update
8. Launch 389 Admin console.
9. Last entry appears as "cn=DirectoryManager" and there is no way to add a space between "Directory" and "Manager".
I did what I could to investigate this bug. But at this point, I'm clueless.
Cheers,
Niki
Hi Niki,
Not familiar with 389-ds, but I'm curious if the admin console where the spaces are missing is a Java application. If so, I encountered similar problems to an unrelated application I use (an older version of Moneydance) when there was an upgrade to OpenJDK.
If I use: java-1.8.0-openjdk-1.8.0.222.b10-1.el7_7.x86_64.rpm (and devel, headless, etc.), the fonts render correctly.
Anything after that has words run together, so I'm doing "yum --exclude=java* upgrade" (I still haven't added an exclude for it). There were promising looking bugzilla entries for it, but it still looks broken if I upgrade.
-Greg
On 4/26/20 5:33 AM, Nicolas Kovacs wrote:
Le 26/04/2020 à 11:43, Nicolas Kovacs a écrit :
I investigated this some more. Here's what I found.
Installed a vanilla CentOS 7 GNOME desktop.
Activated EPEL and installed 389-ds.
Launched the setup script for 389 DS.
Works perfectly bot locally and from my remote workstation with ssh -X.
After some more experimenting, I can confirm this is a serious bug. After updating all packages on the system, it just reappeared.
Here's how you can reproduce it.
Install CentOS 7.7 but without updating the system.
Activate EPEL.
Install 389-ds.
Setup 389 DS.
Launch 389 Admin console.
Login as "cn=Directory Manager"
Everything works perfectly.
Update the system : yum -y update
Launch 389 Admin console.
Last entry appears as "cn=DirectoryManager" and there is no way to add a
space between "Directory" and "Manager".
I did what I could to investigate this bug. But at this point, I'm clueless.
Cheers,
Niki
Le 26/04/2020 à 15:41, Greg Bailey a écrit :
Not familiar with 389-ds, but I'm curious if the admin console where the spaces are missing is a Java application. If so, I encountered similar problems to an unrelated application I use (an older version of Moneydance) when there was an upgrade to OpenJDK.
If I use: java-1.8.0-openjdk-1.8.0.222.b10-1.el7_7.x86_64.rpm (and devel, headless, etc.), the fonts render correctly.
Anything after that has words run together, so I'm doing "yum --exclude=java* upgrade" (I still haven't added an exclude for it). There were promising looking bugzilla entries for it, but it still looks broken if I upgrade.
Thanks for your response. I can confirm that this is indeed a Java problem.
I followed your suggestion and downgroaded java-1.8.0-openjdk to version1.8.0.222.b10, and fonts rendered correctly.
Now I wonder what would be the sanest way to solve this. As it looks, it's downgrading as described and then put this in /etc/yum.conf:
exclude=java-1.8.0-openjdk*
Correct me if I'm wrong.
Niki
On Apr 26, 2020, at 11:25, Nicolas Kovacs info@microlinux.fr wrote:
Thanks for your response. I can confirm that this is indeed a Java problem.
I followed your suggestion and downgroaded java-1.8.0-openjdk to version1.8.0.222.b10, and fonts rendered correctly.
I wonder if the latest OpenJDK got some of the freetype changes that happened in java 11? Can you set the environment variable: FREETYPE_PROPERTIES=truetype:interpreter-version=35"
... and try again?
(Btw terrible font rendering library changes happened upstream with gnome too, be thankful CentOS won’t see it In C8 for a while)
-- Jonathan Billings
On 4/25/20 11:45 PM, Nicolas Kovacs wrote:
Le 26/04/2020 à 08:31, Gordon Messmer a écrit :
Are you sure the input lacked a space character, and that this isn't just a font rendering bug?
100 % positive. ... I can hit the space bar as much as I want, the cursor won't budge.
(It sounds like you've solved this, but:)
Pressing the space bar and seeing the cursor render in the same place doesn't tell you whether the problem is a rendering issue or an inability to input spaces. I meant to suggest that you save the entry and look at whether or not the resulting LDAP values contained the spaces you couldn't see in the console.
Your description of the problem doesn't suggest that you can't input spaces, just that you can't see that you've input them.
-
Gordon Messmer -
Greg Bailey -
Jonathan Billings -
Nicolas Kovacs