S0ER

Ответил всем по Naris. Отобрал 37 человек из 109. Если не получили от меня ответ, то проверьте спам, и если ничего нет, то напишите еще раз, так как ответил всем и тем кого взял, и тем кого не взял, но мог кого-то пропустить.

Тех кому интересна современная архитектура, посмотрите на книгу "Practical Process Automation" Bernd Ruecker, это довольно свежее издание, поэтому отражает современный подход к оркестрации и хореографии в современных распределенных архитектурах. В книге показана связь кода и архитектуры, есть примеры на BPMN и процессный взгляд на решение. #книга

Запустил субботний стрим, залетайте! https://youtu.be/NzxhUsIN0x8

В мой проект Naris пришло уже почти 100 заявок, взять столько человек я не могу физически. Отберу 30-50 человек, всем отпишу в любом случае. До 1 февраля еще можно прислать заявки. Обрабатывать текущие буду на этих выходных. Спасибо за проявленный интерес! Отвечу в любом случае всем.

Теперь про ошибку RHEL 7 о которой так таинственно намекнул мой таинственный визави. Вот здесь можно почитать подробнее - https://bugzilla.redhat.com/show_bug.cgi?id=1122118 Но если коротко: - есть такая штука SCAP (Security Content Automation Protocol) в ней рекомендуется, как вы догадались не использовать шелов на служебных пользователей и ребята хотели выполнить эти рекомендации - оказалось, что на RedHat действительно нельзя инициализировать базу без шела - после инициализации проблема с запуском и работы в nologin режиме нет, надо просто: Fix, add '-s /bin/bash' to runuser command lines in the > /etc/init.d/postgresql script. Чувак, правда, перепутал init.d с systemd, но мы же не будем поправлять такого блестящего оратора, который еще ничего не начинал.

В то время как разработчики дистров признают наличие шела на служебных учетках багом, находятся люди, которые искренне уверены, что это фича.

Было много споров по поводу того, что вешать на служебных пользователей шел - это плохая практика. Эта проблема переодически обсуждается и сегодня очень мало приложений, которые используют такой вариант работы. Процесс не быстрый, вот например Bug report в Debian от 2004 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274229 исправлен он был только в 2010, потому что исправлять такие баги очень сложно, на них уже завязано куча всего, и просто так выпилить не получается.

Меня спрашивают чего я комменты не открываю? Вот из-за таких хамов и не открываю. Со своей стороны я потратил время, проверил все безумные утверждения этого товарища, показал конкретно с командами и конфигами что он ошибается, а в ответ хамство. Причем за весь разговор ни имен переменных, ни названия дистров, ни другой конкретики. И таких очень много. Для меня это впустую потраченное время.

Для справки, в postgresql параметры окружения лежат в юните с конфигурацией. Их легко найти в /usr/lib/systemd/system/postgresql.service (в разных ОС могут быть косметические отличия в пути). По дефолту там указывается только один параметр:

Environment=PGROOT=/var/lib/postgres

В env пользователя в режиме nologin не будет только пути к ~/.local/bin, остальное будет точно таким же как с /bin/bash Проверял на Ubuntu и Manjaro.

Отличный видос от Максима Горшенина про конфу в Норильске. Мне очень зашло, рекомендую посмотреть. https://rutube.ru/video/1fb42c8cc877a94a58e677d2f6a17191/

С позиции информационной безопасности, в корпоративной архитектуре, как правило, применяются следующие ограничения (или их вариации): - запрет суперпользователя; - разделение на администраторов и администраторов информационной безопасности (АИБ) - запрет на вход под служебными пользователями (если нельзя технически, то разделяют пароль между админом и АИБом, так что войти можно только вместе) - принцип наименьших привилегий (как правило, это значит, что все работает должно работать без вмешательства или использования учетной записи суперадминистратора) В некоторых организациях делают интересный ход, АИБ ничего не настраивает, а только контролирует и выносит "предписания", а администратор отвечает за реализацию требований. Администраторы очень не любят такое разграничение, но на практике, если объединить функции контроля и выполнения, то качество резко падает. Администраторы начинают ослаблять безопасность системы, мотивируя это тем, что "реализовать требование невозможно", в системе постоянно нарушается принцип наименьших привилегий, для администраторских задач используется суперпользователь и т.д. Архитекторам решений, тоже прилетает от АИБов, когда я согласовывал проекты с управлениями безопасности и потом взаимодействовал с АИБами при опытной эксплуатации, то постоянно сталкивался с требованиями, которые мне казались нереализуемыми. Первое что хочется сделать в такой ситуации, это доказать, что ничего сделать нельзя, но когда начинаешь искать аргументы, то оказывается, что многие вещи можно реализовать, просто решение лежит не на поверхности. Сейчас мне часто помогает этот опыт, я как-то привык думать о решении, а не о том почему это невозможно, в итоге это позволяет гораздо эффективнее строить свою работу. Не устаю утверждать, что в условиях жестких ограничений специалист получается более гармоничным и глубоким.

Я уже много раз доказывал свою профпригодность в разных ситуациях, но почему-то каждый раз одни и те же тупые набросы, типа как в комментарии. Еще раз для тех кто в танке, проблемы возникают после того как на postgres вешают пароль такой же как имя. С этого момента вас начинают пускать по ssh без проблем, по ssh пускают, потому что вы поставили пароль, но не убрали логин, делаете nologin и пускать перестает, чтобы попасть в своего горячолюбимого postgres нужно делать su —shell /bin/bash postgres или настраивать sudo Правильно в данном случае не ставить пароль и нормально настроить файрвол, если хотите пароль (ну вот захотелось аж не могу), то ставите nologin (или настраиваете sshd) Про systemd надо конкретнее, может чего не знаю, но postgresql стартанет и будет работать, может какие-то "глубокие" ошибки есть

Я таки не понял, это было оскорбление? Если да, то сильно толсто для меня.

"Интересно то, что программисты уверены, что именно с ними ничего подобного не случится, что они уж точно все настроят и будет все на высшем уровне" (С) S0ER

И главное помните "Если надо объяснять, то не надо объяснять". Зинаида Гиппиус (С)

Но надо признать, что грамотные админы действительно не переносят дефолтные порты, так как у них обычно куча железа на сопровождении и потом голову сломаешь что и куда перенесено. Им проще и эффективнее настроить файрвол и парольную защиту. Но, повторюсь, сколько угодно профессиональный программист не является таким же профессиональным админом. Поэтому лучше сделайте простые secure by obscure, это очевидно лучше, чем сидеть и без нормального файрвола и без хоть какого-то запутывания.

Надо завести себе правило не читать комменты и в других каналах. Вот такие штуки просто нарушают мое душевное равновесие. Отвечу коротко: - не сканируют ботнеты никакие порты кроме дефолтных, это же не вручную один хост промониторить; - не вешается в ssh на postgress никакой shell, можете погуглить про nologin - пароль рекомендуют менять - это правда, это не отменяет того факта, что их не меняют. И да, у автора данного комментария, все под контролем, он отлично разбирается в администрировании ))))) Ему можно не париться )))

Во-первых, сложность только повышается, а не понижается. Потому что облачная инфраструктура и вообще service as a code - это тот еще "пирожок". Во-вторых, в облаках проблем не меньше, на вскидку, проблемы нарушения изоляции. В-третьих, предлагать решение для уже решенной проблемы может любой, нужно предложить не просто альтернативу, а уменьшить риски, чтобы они были сопоставимы.

Менее чем за сутки пришло 40 заявок в Naris. Я буду их смотреть ближе к выходным, поэтому не волнуйтесь я все вижу. Ответ будет до конца недели.