Комментарии 11
Почему решить? Ошибки исправляют, решают задачи.
Как уст румяных без улыбки,
Без грамматической ошибки
Я русской речи не люблю..., писал Пушкин)
Коллега, а к статье (кроме заголовка) у вас есть какие-то комментарии? Да, в Apache NiFi, я действительно сильней, чем в русском.
И это не ошибки программного продукта Apache NiFi чтобы их исправлять. При его настройке, настройке конфигурации, NiFi показывает, что что-то настроено неправильно. Приходилось потратить много времени при дебаге самого сервиса, чтобы решить проблему и понять что не так.
В данной статье описано большинство случаев проблем при настройке Apache NiFi, решения которых в интернете не найти, либо данные решения не совсем корректно изложены. Надеюсь, обратите внимание на содержание.
По тексту вообще мне всё нравится. Поясню почему придрался к слову "Решить", если не прав - минусы никто не отменял)))
Сейчас наблюдаю тотальную безграмотность. Если заглянуть на тостер - везде "как решить ошибку" и в последнее время это очень режет глаз (про ться/тся вообще молчу), но решают проблемы или вопросы, ошибки исправляют. В вашем случае возможно более корректно было сформулировать "Как найти ошибку...", но это только моё мнение, ничем не хотел кого либо обидеть/унизить или оскорбить.
Пару недель назад аналогичные шишки собирали, и с 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 или только на определенную?
Сертификаты для каждой ноды собственные или на кластер одни и те же? Если это будет в следующей статье, то подождем
Apache NiFi: как починить ошибки, которые не гуглятся