Синкштучка

[vitus_wagner]

По совету sergio остановился для синхронизации тех данных, которые не умеют синхронизироваться сами (баз keepass, всякой персональной информации, хранящейся в зашифрованных текстовых файлах) на syncthing.

Штука это довольно забавная. Управляется через встроенный вебинтерфейс, который автоматически взлетает на localhost:8384. В дебиановский пакет входят юнит-файлы для systemd, а скриптов для альтернативных инит-систем нет. Пришлось для ноутбука, где системд нет, самому писать.

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

По умолчанию заниматеся поисками peer-ов само, идентифицируя и авторизуя их по фингерпринтам сертификатов. Но можно настроить явно указанный IP для пира. Поэтому схему "звезда" с центральным сервером на VDS у хостинг-провайдера реализовать можно. Только настраивать сервер у провайдера приходится посредством проброса порта по ssh, поскольку в links веб-интерфейс syncthing не живет.

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

Comments

[avnik]

А еще не научились делать базовые sysvinit скрипты из юнитов? (в смысле готового генератора нет? там же достаточно тривиально должно быть)

[vitus_wagner]

Там сложный случай юнита. Который на @ кончается.
И который в systemd нужно руками enable-ть для всех нужных значений после @

[avnik]

Ну либо генерить по скрипту на каждую подстановку, либо играться с $0 седом в рантайме ;)

PS Подстановки -- это то что сделано относительно хорошо в systemd

[vitus_wagner]

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

Ну и я так же сделал. У меня запускается по экземпляру syncthing на каждого юзера (вернее, на каждую подддиректорию в /home, честно читать /etc/passwd меня заломало ), у которого есть
директория ~/.config/syncthing.

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

Вообще, в Debian скрипты из /etc/init.d недаром считались конфигурационными файлами, предназначенными для ручной правки. Не надо их автоматически генерировать, их надо руками писать. Подумавши головой.

[avnik]

> Вообще, в Debian скрипты из /etc/init.d недаром считались конфигурационными файлами, предназначенными для
> ручной правки. Не надо их автоматически генерировать, их надо руками писать. Подумавши головой.

Ну учитывая, что они с пакетами приезжают... Поэтому _эта часть_ логики systemd, что мы сначала читаем системный конфиг, потом админский который override'ит параметры из системного мне кажется разумным.

Единственное, чего мне там не хватает -- это возможности залогинить сервисного юзера (с systemd --user, pam сессией, итд) dbus'овым вызовом (потому что очень не хочется возиться с PAM и поддерживать своего рутового демона для запуска сессий). Ну либо я чего-то незнаю.

[vitus_wagner]

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

А systemd тут пошел по порочному пути, по которому уже прогулялась веб-разработка с CSS.
Когда хрен определишь из какого именно файлов в цепочке взялась конкретная настройка.

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

[avnik]

> Когда хрен определишь из какого именно файлов в цепочке взялась конкретная настройка.

Если мне не изменяет память, там есть утилита которая позволяет это посмотреть (я видел в последних release notes каких-то).

> И в dpkg есть довольно удобный механизм интеграции изменений, сделанных мейнтейнером с изменениями,
> сделанными сисадмином.

Ну он _относительно_ удобный.
А вообще тут есть два подхода -- либо есть админ, который помнит все тонкости 5-100 хостов, имеет время и желание мержить конфиги (и которого может переехать автобус).

А бывает когда дефолтные настройки не устраивают, но желания/времени все это помнить нет -- и тогда у нас идет devops, когда мы описали чего мы хотим, и пускаем систему под бульдозер (просто ли выкатив свой my.tar.gz в /etc, применил в ansible. nixos или любой другой девопс интсрумент). Тут подход systemd больше вписывается, потому что тебе надо описать разницу между стандартным и тем что ты хочешь. А не тупо приносить с собой свой набор инитскриптов -- потому что тут тоже может критическая масса нарасти)

[kostix]

`systemd-analyze cat-config`, полагаю (вот тут упомянуто: http://www.opennet.ru/opennews/art.shtml?num=48823).

[kostix]

Там есть `machinectl`, который умеет системных юзеров с полной поддержкой PAM и `systemd --user`.

Можно начать, например, с

$ machinectl shell --uid some_sys_user

[kostix]

Упс, там подразумевается # конечно же.

[vitus_wagner]

Почему-то в Debian machinectl кладут в пакет systemd-container вместе с systemd-nspawn. Как-то это вызывает подозрение, что не для хост-системы этот инструмент.

[avnik]

nspawn то как раз для хост системы --- запускать контейнеры

[avnik]

скорее systemd-run тогда (если верить мануалам).
Но мне все равно непонятно -- будет ли там (внутри) нормальный PAM (включая pam_mount), systemd --user/dbus --session итд).

(собственно задача -- выкинуть xrdp-sessman по причине его запредельной кривости, и пинать сессию dbus вызовом к systemd/logind/whatever)

[kostix]

Я не стану подписываться под этими словами, но:

- Интеграция с `systemd --user` точно есть (см. ниже), но нужно поставить `libpam-systemd`.
- Интеграция с `dbus` должна быть, если поставлен `dbus-user-session`.

Первое я проверял потому что у меня таким макаром настроено копирование "в облако" бэкапов с "бэкапного сервера".

Грубо говоря, скрипт с бэкапящейся машины юзает `borg`
чтобы забэкапить себя на бэкапный сервер, после чего
логинится туда по SSH ещё раз, дёргает `systemctl --user start sync-to-cloud@whatever_instance` и отваливается.
Для этого аккаунта настроен "лингеринг" (https://wiki.debian.org/systemd#orphaned_processes), и сессия остаётся жить после отлогина.

По поводу маунтов, я не знаю.
Быстрый гуглёж нашёл такое: https://kempniu.wordpress.com/2016/01/07/making-pam_mount-play-nicer-with-systemd-user-sessions/

Кстати, удобно юзать `loginctl user-status имяюзера` чтобы быстро посмотреть все деревья процессов, которые для него были созданы при участии systemd и всей этой механики.

[avnik]

> логинится туда по SSH

А вот мне это не нужно как раз, мне надо на локальной машине запустить сессию через dbus. (видимо через тот вызов, к оторый использует systemd-run).
Сами разработчики systemd ничего внятного сказать не могут, либо предлагают таки писать свой демон работающий с pam (чего мне совсем не хочется).

> По поводу маунтов, я не знаю
У pam_mount ecть

<!-- if activated, requires ofl from hxtools to be present -->
<logout wait="10" hup="yes" term="yes" kill="yes" />


И оно замечательно работает. (правда не luks, а оверлеи)
В принцпе вместо ofl можно наверное и скрипт с использованием fuser использовать, но я все время забываю как.
Поэтому пошел по пути наименьшего сопротивления, и выдрал утилитку из пакета.
Сессию гашу вызовом logind.TerminateUser(username)

PS То есть нужна именно та часть функционала (ну скажем) sshd, которая ответственна за создание юзерской сессии. А там PAM, а это боль и страдания. В идеале нужен logind.LoginUser(user, path_to_session_leader_script)

[vitus_wagner]

Нормальный pam не бывает. pam is defective by design.
Нельзя в юниксовой модели разграничения полномочий между процессами делать authentification modules подгружаемыми shared-объектами.

[avnik]

А как кстати должно быть нормально?

Я тут абсолютно согласен, что пам дефективный (особенно меня радует затыкание коллбека pam_print/pam_input (для получения логина/пароля _помимо_ того, что из могут передать туда как параметры (коллбеки я тут по смыслу обозвал, правильного их названия я не помню и слава б-гу))

[vitus_wagner]

Ну несколько более прямо сделан SASL, если говорить только об аутентификации.
Но PAM замахивается на куда больше, на настройку очень большого количества параметров сессии.

Тут, учитывая колоссальное разнообразие ныне существующих разновидностей аутентифицированных сессий, все гораздо сложнее. И если некоторые модули pam действительно имеют отношение к аунтентификации, например тот же pam_mount или pam_gnomekeyring, то какой-нибудь pam_env попал в pam только потому что никакого общего иницилизационного шелл-скрипта для консольной, графической и кроновской сессий не придумали раньше, чем появился pam.

[filin]

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

[vitus_wagner]

Да, пожалуй, тоже так сделаю. Потому что если оно ТАКУЮ батарейку, на 6а/ч так выжирает, то если вдруг я соберусь тонкую крышку поставить...

Камень в огород

[sergio.livejournal.com]

В синхровещи меня смущают два пунткта:

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

https://github.com/syncthing/website/issues/55


2. авторы предлагают гадить в /etc/apt/trusted.gpg, хотя в дебиане ясно сказано там не гадить а делать файл в trusted.gpg.d

https://github.com/syncthing/website/issues/56

https://manpages.debian.org/stretch/apt/apt-key.8.en.html


но ничего лучше syncthing под андроед нету

Re: Камень в огород

[vitus_wagner]

У меня даже и мысли не возникло брать не из дистрибутива. Ну и андроидную версию я качал с f-droid, куда оно аплоадится в исходниках и собирается местным buildd. Поэтому я этого эффекта не заметил.

Re: Камень в огород

[sergio.livejournal.com]

Поначалу его не было в дистрибутиве.

Я тоже с f-droid брал, не понял, какого эффекта?

Re: Камень в огород

[vitus_wagner]

Эффекта - в смысле кривых инструкций по подключению репозиториев на сайте.