Pull to refresh

Comments 11

Почему решить? Ошибки исправляют, решают задачи.

Как уст румяных без улыбки,

Без грамматической ошибки

Я русской речи не люблю..., писал Пушкин)

Коллега, а к статье (кроме заголовка) у вас есть какие-то комментарии? Да, в Apache NiFi, я действительно сильней, чем в русском.

И это не ошибки программного продукта Apache NiFi чтобы их исправлять. При его настройке, настройке конфигурации, NiFi показывает, что что-то настроено неправильно. Приходилось потратить много времени при дебаге самого сервиса, чтобы решить проблему и понять что не так.

В данной статье описано большинство случаев проблем при настройке Apache NiFi, решения которых в интернете не найти, либо данные решения не совсем корректно изложены. Надеюсь, обратите внимание на содержание.

По тексту вообще мне всё нравится. Поясню почему придрался к слову "Решить", если не прав - минусы никто не отменял)))

Сейчас наблюдаю тотальную безграмотность. Если заглянуть на тостер - везде "как решить ошибку" и в последнее время это очень режет глаз (про ться/тся вообще молчу), но решают проблемы или вопросы, ошибки исправляют. В вашем случае возможно более корректно было сформулировать "Как найти ошибку...", но это только моё мнение, ничем не хотел кого либо обидеть/унизить или оскорбить.

Cпасибо за подробное объяснение, буду следить и решать только задачи))

Пару недель назад аналогичные шишки собирали, и с LDAP, и с Registry. Где ж вы раньше с вашей статьёй были... :)

С HTTPS еще огребли историю с куками, у нас везде по умолчанию стоит `proxy_cookie_flags ~ httponly secure samesite=lax;` на Nginx, а NiFi такие параметры не подошли, в итоге вместо внятной ошибки NiFi просто 403 отдавал с довольно невнятной руганью

Да, жаль самому, что долго "выкладывался". Но, поверьте, там еще есть, что "поковырять" и я еще пару статей готовлю: "Автоматическая доставка и управление сертификатами, драйверами, процессорами NiFi", "NiFi Cluster Coordinator в рамках Nifi as a Service для проектов". Можем обмениваться опытом, раз вы тоже по этим граблям прошлись)

Отличная статья, коллега.

Небольшое замечание (м.б. вы специально так сделали).

В настройках провайдера указано

  <property name="Manager DN">cn=nifiadmin,ou=nifi-habr,ou=nifi,ou=test,ou=example,dc=com,dc=mycompany</property>
  <property name="Manager Password">pass</property>

Насколько я понимаю, Manager DN - учетная запись, под которой NIFI идет в LDAP, запрашивает данные о пользователях. У вас эта же учётка является админом, выполняющим начальную настройку.
У себя сделал так - создал учётку для NIFI, админы запретили все все что можно, кроме авторизации и запроса даных из каталога LDAP. А initial admin указал себя)

Добрый день, коллега. Спасибо за твой комментарий.

Да, на самом деле у нас в Manager DN стоит другой пользователь, этот указан чисто в статье.

В нашей компании первоначальный админ необходим для того создать локального пользователя в NiFi, которому привязываются права для редактирования всех сущностей.

Далее используется NiFi cluster coordinator который уже управляет всеми группами процессоров, пользователями, группами, политиками это позволяет использовать 1 кластер NiFi для множества проектов (Но тут есть ограничения для больших проектов). После этого первоначальный админ уже не нужен. Подробнее я расскажу об этом в своей следующей статье.

Есть еще вопрос про web.proxy - что применяете? Как настроили балансировку? Пускаете на все ноды в UI или только на определенную?
Сертификаты для каждой ноды собственные или на кластер одни и те же? Если это будет в следующей статье, то подождем

Балансировка уровня L4, пускаем на все ноды. Сертификаты для каждой ноды собственные в зависимости от хоста.

Sign up to leave a comment.