Оболочка Impala зависает при вызове для пользователей LDAP

Я установил кластер с impala и sentry (CDH 5.2) на CentOS 6.5 с помощью командной строки, а также настроил openLDAP (без TLS). Оба работают без каких-либо проблем независимо друг от друга.

Чтобы настроить кластер Hadoop для openLDAP, я создал необходимые группы LDAP для всех служб Hadoop, а также сделал необходимые записи в файле конфигурации core-site.xml и impala со списком LDAP uri и т. д., как указано в документации.

Когда я вызываю impala-shell для пользователей LDAP, используя «impala-shell -l -u test1», где test1 — действительный пользователь openLDAP, он запрашивает пароль, который я предоставляю. Проблема в том, что как только это сделано - он просто зависает. От impala-shell нет абсолютно никакого ответа, и ни журналы impala, ни журналы LDAP не фиксируют никакой активности. Я также пытался перехватить tcpdump на порту 389 (где работает ldap), но, похоже, там нет связи с Impala, так как обмен пакетами вообще не происходит. Напротив, он отлично работает при вызове без директивы «-l» для обычных пользователей CentOS. Ниже приведен файл конфигурации impala:

**IMPALA_CATALOG_SERVICE_HOST=master.server.com
IMPALA_STATE_STORE_HOST=master.server.com
IMPALA_STATE_STORE_PORT=24000
IMPALA_BACKEND_PORT=22000
IMPALA_LOG_DIR=/var/log/impala
IMPALA_CATALOG_ARGS="  -log_dir=${IMPALA_LOG_DIR} -        sentry_config=/etc/hive/conf/sentry-site.xml  "**
IMPALA_STATE_STORE_ARGS=" -log_dir=${IMPALA_LOG_DIR} -state_store_port=${IMPALA_STATE_STORE_PORT}"
IMPALA_SERVER_ARGS="
    -server_name = master.server.com \
    -sentry_config=/etc/hive/conf/sentry-site.xml \
    -authorization_policy_provider_class = org.apache.sentry.provider.file.LocalGroupResourceAuthorizationProvider \
    -authorization_policy_file = /user/hive/warehouse/impala-policy.ini \
    -ldap_uri=ldap://slave.server.com:389 \
    --enable_ldap_auth=true \
    -log_dir=${IMPALA_LOG_DIR} \
    -catalog_service_host=${IMPALA_CATALOG_SERVICE_HOST} \
    -state_store_port=${IMPALA_STATE_STORE_PORT} \
    -use_statestore \
    -state_store_host=${IMPALA_STATE_STORE_HOST} \
    -be_port=${IMPALA_BACKEND_PORT}"
ENABLE_CORE_DUMPS=false
# LIBHDFS_OPTS=-Djava.library.path=/usr/lib/impala/lib
# MYSQL_CONNECTOR_JAR=/usr/share/java/mysql-connector-java.jar
# IMPALA_BIN=/usr/lib/impala/sbin
# IMPALA_HOME=/usr/lib/impala
# HIVE_HOME=/usr/lib/hive
# HBASE_HOME=/usr/lib/hbase
# IMPALA_CONF_DIR=/etc/impala/conf
# HADOOP_CONF_DIR=/etc/impala/conf
# HIVE_CONF_DIR=/etc/impala/conf
# HBASE_CONF_DIR=/etc/impala/conf

Пожалуйста, помогите мне решить эту проблему, если вы испытали это. Заранее спасибо.


person user5092078    schedule 08.07.2015    source источник


Ответы (1)


Я нашел первопричину. Причина заключалась в том, что демон impala не собирал данные ldap из конфигурационного файла impala (обычно в /etc/default/impala). Я не знаю, что решило это, но просто переустановка Impala заставила его подобрать детали по мере необходимости. После того, как это было сделано, следующей задачей была настройка групп openLDAP в соответствии с ожиданиями Impala, то есть DN должен содержать uid, а не cn и rest, используя параметр ldap_listDN, при условии полного DN, который регистрируется в журналах LDAP. Это был действительно глупый вопрос, который заставил меня подробно изучить openLDAP.

person user5092078    schedule 09.07.2015