LINUX.ORG.RU
ФорумTalks

Systemd убивает Postgresql, ест детей и взрывает IPC

 , , ,


1

3

tl;dr - на Ubuntu 16.04 если вы не подшаманите logind.conf, ssh в пользователя 'postgres' убьет базу данных.

https://lists.freedesktop.org/archives/systemd-devel/2014-April/018373.html

Каменты жгут, я переведу только оппост для Ъ:

В Systemd 212 новые дефолты удаляют IPC (включая память SYSV), когда пользователь «полностью» вылогинивается. Яко опция RemoveIPC=yes

Т.е. сервис postgresql service - не логин, если вы ssh'итесь в постгрес (например чтобы rsync'нуть wal файлы) и потом вылогиниваетесь, Systemd удоляет всю постгресовскую SYSV память, шта тут же приводит к чудным ошибкам типа:

FATAL:  semop(id=92307463) failed: Invalid argument
CONTEXT:  xlog redo insert: rel 1663/16414/112697213; tid 1319269/129
LOG:  background writer process (PID 24589) exited with exit code 1
LOG:  terminating any other active server processes
LOG:  all server processes terminated; reinitializing
LOG:  semctl(119406593, 0, IPC_RMID, ...) failed: Invalid argument

Приходит на ум простейший фикс на postgresql.service:

PAMname=systemd-login

Но сие не выйдет по двум причинам: 1) оно не подхватывается logind (в логах не появляется ничего типа «Started User Manager for UID 88», как это происходит при заходе по ssh) 2) как только pg_ctl останавливается, сессия закрывается. (pg_ctl запускает postgres в фоне)

★★★★☆

Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от crypt

Он странный для тех, кто не работал с postgres. О чем собственно тебе все и пишут, но ты, ес-но, ведешь себя, как Д'Артаньян.:)

никогда не требовалось логиниться по ssh, как postgres. Если нужно было, логинился под своим пользователем, потом переключался на postgres.

PS безотносительно systemd

arcanis ★★★★
()
Ответ на: комментарий от kirk_johnson

а никто и не предлагает давать рута

каждой роли и каждому сервису по юзеру, опасные инстансы я вообще сую в jail-ы

P.S. Алсо ты можешь ограничить круг запускаемых программ через тот же sshd_config.

нынче кстати такие новоиспеченные админы поперли, которые в глаза не видел этот sshd_config :D

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

каждой роли и каждому сервису по юзеру, опасные инстансы я вообще сую в jail-ы

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

нынче кстати такие новоиспеченные админы поперли, которые в глаза не видел этот sshd_config

Ну мы не берем в расчет совсем уж клинических идиотов.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

Тебе один хрен нужен будет доступ с правами postgres, шоп сделать с ним что-то полезное.

администратор и так может выполнить login с помощью одноименной команды

для всяких бекапов и т.д. можно навешать хуков

Опять таки, нормальная безопасность строится на предположении, что внешняя активность опасна по дефолту, и доверенные креденшлы скомпрометированы. Тогда и начинаешь думать иначе...

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

для всяких бекапов и т.д. можно навешать хуков

А што эти хуки будут делать? Если они что-то собрали, это что-то должен кто-то забрать. Либо этот сервер должен што-то куда-то записать. И в том, и в другом случае мы получаем необходимость сделать креды для доступа. Сделать креды для доступа к центральному архиву с моей точки зрения куда более опасно.

Опять таки, нормальная безопасность строится на предположении, что внешняя активность опасна по дефолту, и доверенные креденшлы скомпрометированы. Тогда и начинаешь думать иначе...

Тогда придется вырубить SSH вообще :)

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

если в роли login shell-а твоя кастомная прога, которая позволяет делать залогиненому юзеру только то, что положено, то всё ок :)

reprimand ★★★★★
()
Ответ на: комментарий от reprimand

Ну так и я о том же. Просто без отдельной роли. И средствами ssh.

kirk_johnson ★☆
()
Ответ на: комментарий от intelfx

Я не собираюсь отвечать на «спердобейся».

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

в моей голове мир может и идеальный, а вот мир перед моими глазами вполне реален, и когда пропихнутая толпой школяров софтина ломает, простите, tmux и постгрес (пусть даже для второго метод и правда экзотичен имхо), на которых завязаны процессы десятков тысяч компаний - нахрен такую софтину.

Или ты считаешь что tmux/postgres нинужно, и вообще все могут сидеть на монго и открывать три десятка окошек putty из дисяточки, да и вообще иксы-кеды на сервак ставить?

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от upcFrost

Да там сама идея костыльная. С какого перепугу одно приложение лезет чистить память за другим приложением?! Ну сделали ли бы опцию в крайнем случае, если не могут пофиксить гном, или чего им там память засирало. А впиливание такого дефолта говорит, что из Лёни архитектор как из дерьма пуля.

ya-betmen ★★★★★
()
Ответ на: комментарий от crypt

Я плохо разбираюсь в админстве. Но разве это нормально - торчать наружу доступом к БД через ssh? Это ж почти то же самое, что давать доступ к root по ssh.

Куда логичнее выглядит авторизация вида «обычный юзер по ssh - root - postgre», разве нет?

ekzotech ★★★★
()
Ответ на: комментарий от intelfx

Если часто повторять слова ублюдочный, долбанутый и прочие, то это, к сожалению, не добавит весомости утверждениям. Только появится мысль, что дядя высказывающий эти утверждения дурак :(

qnikst ★★★★★
()
Ответ на: комментарий от ekzotech

Куда логичнее выглядит авторизация вида «обычный юзер по ssh - root - postgre», разве нет?

так обычно и делается, просто бывают отдельные случаи, когда вариант с ssh на бд-юзера проще либо вообще единственный вменяемо работающий

upcFrost ★★★★★
()

Пользователи говнод должны страдать, так-то

stels ★★★
()
Ответ на: комментарий от alpha

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

qnikst ★★★★★
()
Ответ на: комментарий от arcanis

Логинился через SSH в postgres, чтобы добавить роли и создать новую БД на проекте. Правда это дев. сервер. Где твой бог теперь?

spoilt ★★★
()
Ответ на: комментарий от ekzotech

Но разве это нормально - торчать наружу доступом к БД через ssh?

ИРЛ я ни разу такого не встречал. И да, это ненормально.

redgremlin ★★★★★
()
Ответ на: комментарий от redgremlin

По крайней мере пока так работает barman (PostgreSQL backup) И так Яндекс бекапит свои тачки. Proof №1: https://events.yandex.ru/lib/talks/3202/ Proof №2: http://pgday.ru/files/papers/80/pgday2016_backups.pdf

uspen ★★★★★
()
Последнее исправление: uspen (всего исправлений: 2)
Ответ на: комментарий от ekzotech

в сложных сетапах, когда у тебя пачка этих серверов бд, это все находится в отдельной сети и ничего никуда не торчит. а те, кто отписались сверху, скорее всего использовали postgres просто по необходимости с каким-нибудь одиночным web сервисом. сетап был простой, но всеравно то, с чем они не столкнулись, кажется им «странным».

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от quest

Линюкс свободен. переходить на системы без системд. благо, системщики его терпеть не могут и с удовольствием будут поддерживать разработку дров без внедрения всякого анального потцеринга.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Shadow

вот с этого и начинается моральное разложение. сначала игнорируют баги, потом система превращается в нечто типа маздая, где баги и синий экран - это вообще обычное явление.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Alpha мне пару лет тут лекцию писала, что в серьёзном бизнесе потребность «зайти и выйти», а не сделать, чтоб работало.

Shadow ★★★★★
()
Ответ на: комментарий от leave

Не абсолютный, но аргумент. Выше уже приводили картинку про «reenable spacebar heating».

intelfx ★★★★★
()
Ответ на: комментарий от stevejobs

да и подчищение памяти у пользователя - имхо, это круто, непонятно только, почему эта фича включается и отключается только сразу для всего компьютера, а не для отдельного сервиса

Потому что нельзя так сделать при всём желании. Нигде не сохраняется информация о том, какой объект SysV IPC кому приналежит. Например, подчистку процессов сделали per-service с самого начала, потому что для этого в ядре есть подходящий инструмент (цгруппы).

Единственное, что можно заюзать — это IPC namespaces. Но это тоже «не то», потому что нельзя придумать вменяемый дефолт.

непонятно какую дурь жрали в RHEL, когда вместо того чтобы самостоятельно пофиксить баг, они зачем-то в документации предложили сделать это пользователю

Так они и пофиксили, сабжевая RemoveIPC= теперь работает только для не-системных пользователей.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от crypt

а мне показалось, это ты назвал всех истеричными хейтерами:)

Обмен любезностями, ничего более.

Он странный для тех, кто не работал с postgres. О чем собственно тебе все и пишут, но ты, ес-но, ведешь себя, как Д'Артаньян.:)

Возможно. А возможно и нет. Если этот юзкейс встречается только при работе с одной программой — то он уже странный.

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

А кто говорит про «весь»? NB: стабильные и нестабильные релизы существуют не просто так. И авторы systemd, кажется, уже раз десять в разных местах говорили, что релизы systemd по умолчанию нестабильны, и дефолты подходят не всем, и конфиги/чейнджлоги читать нужно, и если у тебя кровавый продакшен — то тем более не стоит делать git clone && make && make install.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от crypt

Что мне было бы интересно понять, так это из-за чего произошел спор вокруг tmux.

Из-за того, что tmux демонизируется по-юниксовому, а из сессионной цгруппы не выходит. Раньше это работало, а потом в systemd решили прибивать сессионную цгруппу при завершении сессии.

Строго говоря, то, что делал tmux, было неправильно всегда. Предположим, у меня через PAM запускаются ssh/gpg-агенты и выполняется монтирование /home. Если я разлогинюсь, то это всё радостно исчезнет и не посмотрит, что там ещё где-то tmux запущен. Поэтому tmux'у стоило бы запускаться в отдельной PAM-сессии (т. е. использовать правильный механизм). В этом случае никакого спора бы не было, т. к. systemd встраивается в PAM.

Если уж делать большие многофункциональные программы, которые делают только ограниченный набор юзкейсов, то почему не включить еще один полезный юзкейс.

Это ты о чём?

intelfx ★★★★★
()
Ответ на: комментарий от quest

Эти черти и демонизацию хотят переделать чтобы работало в systemd и уже лезут с этим в работающий код.

Поподробнее?

intelfx ★★★★★
()
Ответ на: комментарий от quest

Неправильно помнишь — мы хотим либо правильную демонизацию, либо её отсутствие.

intelfx ★★★★★
()
Ответ на: комментарий от upcFrost

Или ты считаешь что tmux/postgres нинужно, и вообще все могут сидеть на монго и открывать три десятка окошек putty из дисяточки, да и вообще иксы-кеды на сервак ставить?

Нет, не считаю. С чего ты взял?

intelfx ★★★★★
()
Ответ на: комментарий от qnikst

Давай сделаем эквивалентную замену.

ублюдочный == не позволяющий достоверно определить создателя ресурса с точностью до процесса, использующий своё ни с чем не связанное пространство имён

долбанутый == странный, сомнительный и нераспространённый

Так легче?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

не-системных пользователей

кто это такие и где об этом можно подробнее почитать? аналогично, кто такие системные пользователи?

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

кто это такие и где об этом можно подробнее почитать?

Такие, от имени которых не выполняются какие-либо демоны. Иными словами, UID >= UID_MIN в /etc/login.defs.

аналогично, кто такие системные пользователи?

Отрицание того, что написано выше.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Если этот юзкейс встречается только при работе с одной программой — то он уже странный

Постгрес и tmux - чуть более весомые вещи чтоб называть их «одна программа». Это все равно что сказать «систумд збс только с ним sata харды не работают, купите себе ssd»

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

Ты перевираешь. В случае с постгресом не работает 1) конкретный метод администрирования этого постгреса, 2) с которым не все согласны даже не рассматривая systemd, 3) при определённом значении определённого параметра. В случае с tmux — метод, применяемый tmux, был сломан изначально.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

В случае с постгресом не работает 1) конкретный метод администрирования этого постгреса, 2) с которым не все согласны даже не рассматривая systemd, 3) при определённом значении определённого параметра.

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

В случае с tmux — метод, применяемый tmux, был сломан изначально.

который при этом уже 10 лет работает. А у тридцатилетнего screen тоже «кривые методы»? понимаешь, если ломается один из основных инструментов - это полный ппц, жестко нарушающий уже много лет как устоявшийся рабочий процесс. люди работают и получают зп, а бизнес получает прибыль. «алгоритмическая корректность» при поломке бизнес-процесса никому нахрен не нужна. так что аналогия с нерабочими хардами как раз к месту.

upcFrost ★★★★★
()
Ответ на: комментарий от upcFrost

понимаешь, если ломается один из основных инструментов - это полный ппц, жестко нарушающий уже много лет как устоявшийся рабочий процесс. люди работают и получают зп, а бизнес получает прибыль. «алгоритмическая корректность» при поломке бизнес-процесса никому нахрен не нужна.

Я ещё раз повторяю: стабильные (поддерживаемые) дистрибутивы ОС существуют не просто так. Они существуют для того, чтобы не приходилось выбирать между развитием софта и «устоявшимся рабочим процессом».

С твоей точки зрения ни одна программа, которая уже используется в Большом Бизнесе™, не должна получать ни одного нового коммита, кроме исправлений безопасности. Но это заведомо не так.

Поэтому любые слова про много крупных контор и прочий кровавый продакшен здесь немного не к месту.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

стабильные (поддерживаемые) дистрибутивы ОС существуют не просто так. Они существуют для того, чтобы не приходилось выбирать между развитием софта и «устоявшимся рабочим процессом».

ок, и какие были предложения во всех обсуждениях? впилить пачку костылей в tmux, постгрес и прочих, лишь бы они уживались с систумд. это не «развитие софта», это обмазывание и без того кривой пирамиды соплями, которое вполне закономерно вызывает неприязнь у любого адекватного человека. в результате следующий стабильный дистрибутив получит пачку костылей и запретов, что все равно не принесет радости при обновлении

upcFrost ★★★★★
()
Последнее исправление: upcFrost (всего исправлений: 1)
Ответ на: комментарий от upcFrost

ок, и какие были предложения во всех обсуждениях?

tmux

Systemd убивает Postgresql, ест детей и взрывает IPC (комментарий)

постгрес

Fixed in upstream, RemoveIPC= игнорирует UID < UID_MIN. Учитывая природу sysvipc, ничего лучше сделать нельзя. Если только засунуть каждый сервис в свой личный sysvipc namespace, но это наверняка что-нибудь у кого-нибудь сломает.

это не «развитие софта», это обмазывание и без того кривой пирамиды соплями

Это именно «развитие софта» и приведение в порядок имеющегося на данный момент бардака с временем жизни различных объектов. Или требование того, что процесс, который заведомо переживёт родительскую PAM-сессию, должен запускать свою собственную PAM-сессию — это по-твоему «пачка костылей»?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 5)
Ответ на: комментарий от intelfx

Да, я помню, что Грег и компания отказались предоставить планы дальнейшего развития. У меня такое ощущение, что они сделают сторонний модуль и засунут его в RHEL.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

А толку так делать, если никто не согласится переписывать клиентские библиотеки под какую-то неведомую out-of-tree херню?

intelfx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.