Weird Bug In 389 Directory Server : No Spaces In Admin Console (CentOS 7)

Home » CentOS » Weird Bug In 389 Directory Server : No Spaces In Admin Console (CentOS 7)
CentOS 8 Comments

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

Microlinux – Solutions informatiques durables
7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
Mob. : 06 51 80 12 12

8 thoughts on - Weird Bug In 389 Directory Server : No Spaces In Admin Console (CentOS 7)

  • 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 :

    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.


    Microlinux – Solutions informatiques durables
    7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
    Mob. : 06 51 80 12 12

  • Le 26/04/2020 à 08:45, 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.

    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 ?


    Microlinux – Solutions informatiques durables
    7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
    Mob. : 06 51 80 12 12

  • Le 26/04/2020 à 11:43, Nicolas Kovacs a écrit :

    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


    Microlinux – Solutions informatiques durables
    7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
    Mob. : 06 51 80 12 12

  • 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

  • Le 26/04/2020 à 15:41, Greg Bailey a écrit :

    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


    Microlinux – Solutions informatiques durables
    7, place de l’église – 30730 Montpezat Site : https://www.microlinux.fr Mail : info@microlinux.fr Tél. : 04 66 63 10 32
    Mob. : 06 51 80 12 12

  • (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.

  • 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