Application: "389 Administration Server v.1.3.7", "Java v8/11", "389 Console".
В процессе перевода панелей управления LDAP-серверов "389-AS/DS" столкнулся с невнятной проблемой - GUI-утилита "389-console" не могла подключится к доступному только через SSL серверу администрирования.
Включение режима отладки немногим помогло - подтвердилось лишь то, что проблема в способе связи через SSL-соединение:
$ 389-console -D 9
....
389-Management-Console/1.1.14 B2015.184.1123
....
CommManager> New CommRecord (https://ldap0.example.net:9830/admin-serv/authenticate)
....
Unable to create ssl socket
org.mozilla.jss.ssl.SSLSocketException: SSL_VersionRangeSetDefault() for variant=0 with min=768 max=770 out of range (769:772): 0: (0) Unknown error
....
389-Management-Console/1.1.14 B2015.184.1123
....
CommManager> New CommRecord (https://ldap0.example.net:9830/admin-serv/authenticate)
....
Unable to create ssl socket
org.mozilla.jss.ssl.SSLSocketException: SSL_VersionRangeSetDefault() for variant=0 with min=768 max=770 out of range (769:772): 0: (0) Unknown error
....
При том, что java-утилита заявляла о невозможности установить SSL-соединение, фактически она даже не пыталась обращаться к удалённому сетевому узлу - проверено с помощью "Wireshark".
Замена версии "Java" с v11 на v8 никак на положение дел не повлияло.
Поиск информации по аналогичным проблемам дал ссылку на трекер ошибок, где описывалась смежная с моей проблема и как проверенное решение предлагалось обновить версию "(Java) Console Framework" со сбойной v1.1.14 до содержащей нужные исправления v1.1.17.
Действительно, в моей рабочей станции на "Linux Ubuntu 18 LTS" в дистрибутиве поставлен java-фреймворк, в котором обнаружены проблемы работы с SSL/TLS-соединениями:
# aptitude show libidm-console-framework-java
....
Version: 1.1.14-1
....
Version: 1.1.14-1
....
Поиск на сайте "https://packages.ubuntu.com/" показал, что нужная версия "фреймворка" есть в следующей версии дистрибутива - "Linux Ubuntu 19.04 (Disco Dingo)". Пришлось подключить её репозиторий и настроить приоритеты загрузки пакетов:
# vi /etc/apt/source.lists
....
deb http://us.archive.ubuntu.com/ubuntu/ disco main restricted universe multiverse
deb http://us.archive.ubuntu.com/ubuntu/ disco main restricted universe multiverse
# vi /etc/apt/preferences.d/00priority
Package: *
Pin: release a=bionic
Pin-Priority: 700
Package: *
Pin: release a=disco
Pin-Priority: 100
Pin: release a=bionic
Pin-Priority: 700
Package: *
Pin: release a=disco
Pin-Priority: 100
Обновление "389-console" в новом дистрибутиве отсутствует, а вот используемый "фреймворк" даже свежее требуемого:
# aptitude update
# aptitude -t disco show libidm-console-framework-java
# aptitude -t disco show libidm-console-framework-java
....
Version: 1.2.0-1
State: installed (1.1.14-1), upgrade available (1.2.0-1)
....
Version: 1.2.0-1
State: installed (1.1.14-1), upgrade available (1.2.0-1)
....
Устанавливаем точечно только нужные нам APT-пакеты:
# aptitude -t disco install libidm-console-framework-java
После обновления "фреймворка" вылезла ещё одна ошибка - в дистрибутиве отсутствует новая библиотека функций журналирования:
....
CommManager> New CommRecord (https://ldap0.example.net:9830/admin-serv/authenticate)
Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
....
CommManager> New CommRecord (https://ldap0.example.net:9830/admin-serv/authenticate)
Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
....
Ставим требуемый APT-пакет с java-библиотекой:
# aptitude -t disco install libslf4j-java
Несколько грубовато - но так уж написан дистрибутивный скрипт запуска "389 Console" - добавляем путь к новой библиотеке в набор читаемых java-интерпретатором:
# vi /usr/bin/389-console
....
#
# Launch the Console
#
java \
-cp /usr/share/java/slf4j-api.jar:/usr/share/java/slf4j-simple.jar:/usr/share/java/jss4.jar:/usr/share/java/ldapjdk.jar:$CLASSDEST/idm-console-base.jar:$CLASSDEST/idm-console-mcc.jar:$CLASSDEST/idm-console-mcc_en.jar:$CLASSDEST/idm-console-nmclf.jar:$CLASSDEST/idm-console-nmclf_en.jar:$CLASSDEST/389-console_en.jar \
-Djava.util.prefs.systemRoot="$HOME/.389-console" \
-Djava.util.prefs.userRoot="$HOME/.389-console" \
$LIBDIR \
com.netscape.management.client.console.Console "$@"
....
#
# Launch the Console
#
java \
-cp /usr/share/java/slf4j-api.jar:/usr/share/java/slf4j-simple.jar:/usr/share/java/jss4.jar:/usr/share/java/ldapjdk.jar:$CLASSDEST/idm-console-base.jar:$CLASSDEST/idm-console-mcc.jar:$CLASSDEST/idm-console-mcc_en.jar:$CLASSDEST/idm-console-nmclf.jar:$CLASSDEST/idm-console-nmclf_en.jar:$CLASSDEST/389-console_en.jar \
-Djava.util.prefs.systemRoot="$HOME/.389-console" \
-Djava.util.prefs.userRoot="$HOME/.389-console" \
$LIBDIR \
com.netscape.management.client.console.Console "$@"
....
И вот, только теперь в "Linux Ubuntu 18.04 LTS" появляется возможность управлять серверами "389-AS/DS" штатными средствами через защищённое SSL-шифрованием соединение:
$ /usr/bin/389-console
[main] INFO org.mozilla.jss.CryptoManager - CryptoManager: loading JSS library
[main] INFO org.mozilla.jss.CryptoManager - CryptoManager: loaded JSS library from /usr/lib/jss/libjss4.so
[main] INFO org.mozilla.jss.CryptoManager - CryptoManager: initializing NSS database at /home/user/.389-console/
[main] INFO org.mozilla.jss.CryptoManager - CryptoManager: loaded JSS library from /usr/lib/jss/libjss4.so
[main] INFO org.mozilla.jss.CryptoManager - CryptoManager: initializing NSS database at /home/user/.389-console/
Наверняка версии для "RHEL/CentOS" и "MS Win", доступные для загрузки на сайте разработчиков, лишены описанных здесь проблем - но "Linux Debian/Ubuntu" нет в перечне поддерживаемых, так что порой приходится вот такие мини-расследования устраивать.
