Журнал Витуса

Использовать RaspBerry PI в качестве рабочего места мне понравилось. Тишина, легко сосредоточиться. Только вот беда - диски-то присоединены к большому компьютеру. В принципе у пишки хватает мощности на современный браузер, почтовый клиент, либреофис. Но как только надо работать с тем, что сохранено локально, надо идти по ssh на большой компьютер. А там pdf-ы, фоссиловский web ui и прочее что требует локального запуска программ.

А файрфокс через ssh X-forwarding работает что-то медленно. Потому что ethernet порты у роутера стомегабитные. Не искать же другой роутер. Впрочем может быть это еще и оверхед на шифровaние заметен.

Сначала я подумал о том, чтобы примонтировать его диски. Но как-то nfs настраивть лениво. Тем более, что NFS как-то хреново относится к server outages. Из самбы нынче выпилили smbmount, и монтировать на ходу стало довольно неудобно. А smb в принципе требует монтирования в каждой пользовательской сессии отдельно.

И тут я вспомнил что когда-то настраивал свой lightdm на работу с VNC как со вторым X-display.

Попробовал, получается.

Конечно, протокол spice был бы лучше vnc, Он позволяет редиректить звук (но у rasberry pi нет колонок) и USB-устройства (но у Raspberry pi ограничена мощность, вряд ли она что кроме флешки потянет). Кстати, не уверен, что все это умеет раздавать Xspice,

Решил тут попробовать перейти на одном из ноутбуков с конфигурации сети с помощью пакета ifupdown на использование systemd-networkd. А то мне как-то начинает казаться что ifupdown постепенно перестает развиваться и поддерживаться.

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

На серверах и сборочных контейнерах я уже как-то давно использую systemd-networkd там где дистрибутивный способ конфигурирования сети не срабатывает без вмешательства человека. В смысле. если сеть завелась сама, то пусть работает. А если надо разбираться в какой-нибудь очередной etcnet, то лучше ее оторвать и делать через systemd, он везде одинаковый.

Требования к конфигурации сети на ноутбуке у меня следующие:

1. Есть три интерфейса - wifi, ethernet и внутренний бридж для контейнеров и виртуальных машин.
2. По умолчанию работает wifi, но если в enhernet воткнули кабель, то он лучше.
3. Есть кэширующий DNS-сервер, он же резолвит имена виртуалок и контейнеров, поэтому единственным сервером в /etc/resolv.conf должен быть он.
4. Виртуалки маскарадятся.
5. Надо использовать DNS-сервера выданные по DHCP, потому как мало ли в какой сети ноутбук окажется. Т.е. инструмент конфигурировани сети должен уметь подсунуть dnsmasq-у правильный resolv-файл, и этот файл не должен называться /etc/resolv.conf.

Для этой цели потребовалась следующая конфигурация

1) enable-м сервис wpa_supplican@имя-интерфейса (вот пусть тому уроду, который придумал интерфейсы переименовывать, икнется). Конфиг к нему вполне подошел тот же самый, какой использовался для ifupdown. Пришлось только переименовать из просто wpa_supplicant.conf в wpa_wsupplicant-имя-интерфейса.conf.

Для тех, кто раньше wpa_supplicant-ом не пользовался - советую обратить внимание на опции сtrl_interface и update_config. Если у вас в ctrl_interface написана группа, в которую консольный пользователь входит, например netdev, то это позволит коннектиться всякими инструментами конфигурирования, например wpa_gui. Ну и update_config нужен для того чтобы сохранить то, что с их помощью конфигурировали. И то, и другое жизненно необходимо если вы периодически подключаетесь к ранее незнакомым сетям, например во всяких кафе.

2) то же самое проделываем с сервисами systemd-resolved и systemd-networkd (казалось бы зачем нам resolved? Он только мешает, пытаясь прибиндиться к 53 порту localhost, где у нас должен быть dnsmasq). Но нет, нам нужно чтобы systemd-networkd передал ему по d-bus адреса dns-серверов, а тот прописал их в /run/systemd/resolve/resolv.conf. А чтобы отучить его занимать порт, пропишем в /etc/systemd/resolved.conf DNSStubListener=no.

3) Прописываем /run/systemd/resolve/resolv.conf в как resolv-file в /etc/dnsmasq.conf

4) пишем файлы конфигурации интерфейсов. У Wi-Fi он совсем простой

[Match] Name=wlp* [Network] DHCP=yes А вот эзернету надо еще указать

[Link] RequiredForOnline=no

Что касается бриджа, там конфиг наиболее сложный. Потому что если раньше в /etc/network/interfaces были post-up команды с помощью которых можно было включить в ядре форвардинг, или там маскарад для этого интерфейса. то теперь у systemd-networkd отдельные ключевые слова на каждый такой случай. Ну это общее правило systemd. Ничего не делается обычными командами, для всего предусмотрены специальные опции в конфиге. а если не предусмотрены, то вам не повезло.

Впрочем зачем вообще держать форвардинг выключенным не понимаю, поэтому его можно включить глобально, добавив соотвествующее правило в /etc/sysctl.d. А для настройки маскарда воспользоваться nftables. Хотя вот тут, похоже сервис, предоставленный systemd-networkd будет не лишним.

Собрался, наконец, доделать последнюю задачу из области сетапа нового сервера - web-based xmpp-клиент. Теперь у меня есть не только webmail, но и web-jabber. (надо сказать что установить на предыдущий сервер element я собирался гораздо дольше).

После отбрасывания из списка того что есть на xmpp.org совершенно галимой проприетарщины, осталось три кандидата

jsxc, xmpp-web и converse.js.

Первый хорош тем, что присутствует в дистрибутиве в виде пакета libjs-jsxc. Поэтому начал я с него. Но к сожалению, документацию в пакет положить забыли, а по документации на сайте как-то тяжело разобраться с тем, что уже сделал мейнтейнер пакета, а что надо сделать пользователю. Ну и вообще он хочет устаревший интерфейс к xmpp-серверу. Работает только через bosh, а через websockets не умеет.

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

Вот converse.js удалось достаточно просто настроить. К тому же она, в отличие от xmpp-web не требует отдельного виртуального хоста и инструкция по установке не предполагает что файлы скриптов должны принадлежать пользователю www-data (c моей точки зрения файлы скриптов, которые может писать процесс веб-сервера это нехорошо).

Converse.js умеет много чего, в частности OMEMO. А вот аудио-видео звонков, увы, не умеет.

X-Post to LJ

Начал понемногу переносить содержимое wagner.pp.ru на новый сервер. Процесс идет медленно, поскольку за время существования сервера у меня там столько барахла скопилось, что прям разгребательство авгиенвых конюшен получается.

Тем более, что я сначала себе заказал виртуалку с Debian 13, а потом стал понемногу туда переносить конфиги и данные с бэкапа виртуалки, работавшей под debian 12, причепм многие из конфигов и скриптов там не редактировались со времен Debian 10, если не 9.

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

В спамассасине auto_whitelist заменили на auto_welcomelist.

Обнаружил, что у меня скрипт для менеджмента почтовых юзеров и паролей в базе sqlite до сих пор написан на втором питоне. Быстренько поправил и довел до 10 баллов в pylint. В принципе там 2to3 бы справился, но мне было проще руками поправить, чем разбираться с использвоанием 2to3 - скрипт там близок к тривиальному.

Вот вебовский вариант смены паролей надо будет переделать. Я все защищенные области в http пересадил на ту же sqlite-вскую базу, которую использует dovecot.

Матрицу решил выкинуть. Равно как и openid-провайдера. Черт те сколько лет никуда по openid не логинился. А матрица оказалась абсолютно бессмысленной в качестве канала посылки сообщений от роботов на смартфон - пока клиент не откроешь, он не видит что что-то приходило. Чтобы видел, нужно к мобильному клиенту какой-то сервис нотификации прикрутить - либо Google Play, либо ntfy, либо jabber. Так уж проще jabber и использовать без нахлобучек в виде матрицы. Благо веб-клиентов к нему теперь море - он через вебсокеты работать научился, и вебклиенты есть даже в дистрибутиве. И dovecot sasl prosody умеет из коробки. В отличие от матрицы с ее стремлением перелезть на oauth. Но, увы, старых конфигов prosody у меня в бэкапах не сохранилось. Отротировались уже. Придется тоже с нуля делать. Посмотрим, научились ли за последние 5 лет jabber-клиенты аудио-видео звонкам. В начале ковида оно работало как-то плохо.

Разобрался тут, как использовать опцию -w у ssh. Надо будет в рассказку дописать.

Токен %T в LocalCommand вполне работает. А на серверной стороне у команды которая передана в командной строке ssh есть переменная среды SSH_TUNNEL.

Получилось следующее:

1. На сервере требуется опция PermitTunnel yes и PermitRootLogin yes в глобальном sshd_config и у рута в .ssh/authorized_keys ключи клиентов. Надо их ограничить, чтобы ничего лишнего не делал, прописав там command и прочее
2. На клиенте в глобальном ssh_config PermitLocalCommand yes
3. На сервере в /usr/local/bin скриптик sshnetsetup
4. На клиенте в /usr/local/bin sshnetclient и sshvpn
5. На клиенте в /etc/ssh файлиk vpn.conf, содержащий следующией настройки

```

 # !/bin/sh
 # Config file for  ssh vpn   

 # DNS name of server to connect to (required)
 SERVER=example.com
 # IP of this computer in VPN (required)
 MY_IP=192.168.217.194
 # IP of server in VPN (required)
 SERVER_IP=192.168.217.193
 # network to route via server (optional)
 NET=192.168.217.128/25
 # Port for dynamic port forwarding (optional)
 SOCKS_PORT=1080

```

SERVER - это имя сервера куда ходить по ssh в открытом интернете. А MY_IP и SERVER_IP - "серые" адреса внутри vpn. SOCKS_PORT - это чтобы не держать отдельной ssh-сессии для ssh -D, NET - это если нам сеть нужна не для обхода блокировок. а как виртуальная частная сеть, объединяющая наши компьютеры, вошедшие в интернет через разных провайдеров. На каждом клиенте для рута генерируется ключевая пара ssh и открытый ключ помещается руту на сервер.

На этом настройка заканчивася. Дальше запускаем sshvpn, оно устанавливает соединение и voila.

Скрипт sshvpn имеет следующий вид:

  #!/bin/sh
  if [ "$(id -u)" -ne 0 ]; then
     sudo "$0"
     exit "$?"
  fi
  if ! [ -f /etc/ssh/vpn.conf ]; then
      echo "No /etc/ssh/vpn.conf found"
      exit 1
  fi
  . /etc/ssh/vpn.conf
  ssh -w "any:any" -o LocalCommand="sshnetclient %T"  ${SOCKS_PORT:+-D "localhost:$SOCKS_PORT" }"$SERVER" sshnetsetup "$MY_IP"

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

#!/bin/sh
. /etc/ssh/vpn.conf
DEVICE="$1"
ip addr add dev "$DEVICE" local "$MY_IP" peer "$SERVER_IP"
ip link set "$DEVICE" up
[ -n "$NET" ] && ip route add "$NET" via "$SERVER_IP"

Он прочитает тот же конфиг и сконфигурирует интерфейс, имя которого ему передано в командной строке через токен %T (см раздел TOKENS в man ssh_config)

На сервере выполняется вот такой скрипт:

#!/bin/sh
client=$1
if  [ -z "$client" ]; then
    client="${SSH_ORIGINAL_COMMAND##* }"
fi
ip addr add 192.168.217.193 peer $client dev $SSH_TUNNEL
ip link set $SSH_TUNNEL up
# now wait until other side would break connection
cat

Он конфигурирует интерфпейс указанный в переменной среды SSH_TUNNEL в переданный ему в командной строке из клиентского sshvpn IP-адрес, а потом запускает команду cat, т.е. ждет ввода на stdin до упора. Пока SIGINT не прилетит. Если в authorized_keys мы пропишем command=/usr/local/bin/sshnetsetup, то параметр $MY_IP sshd в скрипт не передаст. Зато засунет оригинальную команду в SSH_ORIGINAL_COMMAND, откуда этот адрес мы и выкусываем. Особые параноики могут там использовать какой-нибудь sed, чтобы убедиться что ORIGINAL_COMMAND это действительно sshnetsetup ip-address.

При таком сетапе, когда IP-адреса клиентам назначаются явным образом и прописываются на клиентах же в конфиг, нет необходимости что-то делать с динамическим DNS можно всех клиентов статически прописать.

Теперь бы еще разобраться как совместить это дело с SessionType=none (aka -N) и RemoteCommand.

Обнаружил в trixie еще две проблемы, кроме вчерашней со сканированием из GIMP 3.0

Надо будет баги зарепортить.

1) Не работает XKBOPTIONS=compose в /etc/default/keyboard. В смысле не долетает, видимо до X-сервера. В качестве workaroun можно определить Multi_key через xmodmap. Но вообще без compose грустно. Не через диграфы же в vim-е знаки препинания вставлять.

xmodmap -e 'keysym Control_R = Multi_key'

в .xsessionrc. Вместо Control_R можно поставить что-нибудь другое но у меня в /etc/default/keyboard было написано именно compose:rctrl

2) Почему-то сегфолтится spacefm при отмонтировании диска, который открыт в текущем окне. Раньше он так не делал а спокойно переходил в ${HOME}. C этим еще немножко поразбираться надо, потому что версии вроде в bookworm и trixie одинаковы, менялись только опции сборки.

Тут некоторое время назад обнаружились проблем с работой матричных клиентов. Причем всех. Ну как минимум nheko и fluffychat страдали.

Выяснилось что почему-то перестали работать клиентские соединения на 8448 порт. На 443 все работает и после перенастройки клиентов все стало летать.

При этом synapse продолжает слушать на этом порту и openssl s_client к нему вполне коннектится.

Вопрос в том, а должно ли работать в таком режиме s2s. Ау. nataraj, может потестируем?

Синапс вроде не обновлялся. Сейчас packages.debian.org его вообще ни в bookworm-backports, ни в trixie не показывает. Как выйдет trixie, придется, наверное из sid ставить.

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

Решил тут прикрутить к openwrt-шному web-интерфейсу сертификат, которому браузер бы доверял. Выяснилгось что выученный четверть века назад способ генерации сепртифкатов с помощью скрипта CA.pl для этого не годится.

Потому что там хостнейм пишется в CN. А мозилле теперь подавай обязательно dns name в subjectAltName.

Правда, команда openssl req в 3-й версии openssl зато научилоась ключику -addext. Поэтому сгенерировать правильную заявку на сертификат (после подписания которой тем же CA.pl палучается правильный сертификат) можно безо всяких скриптовых обвязок.

 openssl req -newkey -keyout mysite.key -out mysite.req -subj "/CN=mysite.domain/C=RU/L=Moscow" \
    -addext "subkectAltName=DNS:mysite.domain"

Надо еще покопаться. может еще и вокруг openssl ca скрпитовая обвязка тоже лишняя, и можно непосредственно ей пользоватья.

Еще выяснил что в /usr/local/share/ca-certificates на десктопе у меня лежит уже два года как заэкспайрившийся сертификат моего собственного CA. Последнее время я этот CA использовал исключительно для openvpn, потому что все, что торчит во внешний интернет испольузет сертификаты с Let's Encrypt, а локальные https-сайты в своей домашней сети я как-то не очень использую.

Тут при оченедном обсуждении мессенждеров vikarti_anantra задала вопрос: "А что сложно свой сервер поднять?".

Сложно. Для тех для кого адмнистрирование юникс-систем не является основной работой, поднять сервер и сконфигурировать на нем пяток нужных сервисов - занятие и правда не простое. Другой вопрос, что уже давно можно было бы, если бы существовал хоть какой консенсус на тему того, что на таком сервере должно быть, следать коробку "все в одном", настраивать которую было бы не сложнее, чем типичный Wi-Fi роутер. А с ними вроде народ в массе своей справляется. И чтобы можно было в течение нескольких минут накатить этот образ на виртуалку на любом VPS-хостинге.

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

1. Сервер электронной почты на пару десятков аккаунтов. При этом чтобы почту с него принимали во всяких gmail-ах (а это, увы, moving target), и чтобы была какая-никакая защита от спама. graylisting+spamassassin вполне хватает по моему опыту.
2. Веб-интерфейс к этой почте. А то вдруг придется доступаться из какого-нибдуь интернет кафе, где ничего кроме браузера не предусмотрено.
3. Сервер федерированного мессенжера (matrix или jabber).
4. К нему тоже web-интерфейс (element)
5. turn-сервер, как совершенно необходимая вещь для голосовых и видеозвонокв через matrix/jabber
6. CalDAV/CardDAV сервер
7. Возможность выложить файл для последующего скачивания. Я в общем обхожусь для этого webdav. Хотя возможно web-based файл-менеджер не помешал бы. В принципе этого уже достаточно для того чтобы сделать сколь угодно навороченный статический web-сайт, благо локальных генераторов сайтов, запускаемых на ноутбуке/рабочей станции существует море. Поэтому пока вам не нужно на сайте комментирование, ничего более другого и не нужно.
8. Фотогалерея. Она отдельно, потому что фотграфируют нынче в основном смартфонами и планшетами, следовательно фотографии должны попадать на сайт непосредственно с мобильного устройства, и минимально обрабатываться уже на сервере.
9. Средства администрирования. Должны позволять завести нового юзера всего предыдущего, заблокировать/удалить старого, сменить пароль. Возможно стоит жестко требовать наличия единого пароля для всего перечисленного, а возможно и нет. Возможно, тот же инструмент должен менеджить authorized_keys для доступа по ssh. Тут, правда, стоит подумать о соотношении системных пользователей и пользователей веб-сервисов (по-моему не должны совпадать). Там же должна быть кнопочка для установки апдейтов.
10. Автомат для обновления сертификатов Let's Encrypt
11. DNS-сервер. Дело в том, для значительной части вышеприведенных сервисов нам понадобятся специальные (SRV, TXT) записи в DNS. Да, и электронной почты это тоже касается. Без TXT-записи _dmarc никто почту принимать с вашего домена не будет. Опять же openpgp-ключи так публиковать можно. Но в общем стоит исходить из того, что именно этот сервер будет первичным DNS вашего домена. Тогда все этои нетривилаьные DNS-записи можно будет автоматизировать.

Можно еще поставить туда прокси/VPN, если юрисдикция хостера не совпадает с юрисдикцией домашней машины, но мы пока этот вопрос рассматривать не будем. На худой конец можно ssh -D использовать.

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

Для решения перечисленных задач нужно

1. dovecot (в дистрибутиве)
2. postfix (в дистрибутиве)
3. ciderwebmail (по-моему в Debian еще не попала версия, которую я год назад патчил на предмет русских имен папок )
4. matrix-synapse (надо брать из бэкпортов, там он заметно новее)
5. element-web (в дистрибутиве нет, но есть отдельный репозиторий с пакетами
6. coturn (в дистрибутиве)
7. radicale (в дистрибутиве)
8. Какой-нибудь web-сервер чтобы все вышеперчисленные интерфейсы проксировать. nginx сойдет, но apache лучше (оба в дистрибутиве)
9. acme-tiny (в дистрибутиве)
10. bind9 (в дистрибутиве.)

Остальное надо писать, но его довольно немного. В основном скрипты для администрирования. Учитывая что почти у всех сервисов которые нам нужны, свои заморочки насчет хранения паролей. Насчет галерей и CMS я просто не очень в курсе что нынче бывает, и как его задеплоить так, чтобы не бояться взлома при отсутствии квалифицированного администрирования.

Деплоймент этой штуки выглядит так:

1. Регистрируем домен.
2. Покупаем VPS-ку
3. Накатываем на VPS-ку образ системы (лично я всегда rsync-ом обходился, но возможны варианты вроде загрузочного ISO-образа)
4. Заходим в эту VPS-ку по HTTP. Указываем домен и IP-адрес выданный хостером. Жмем кнопку "обновить сертификаты"
5. Заходим туда по HTTPS, меняем пароли, загружаем ssh-ключи и проверяем соответветсвие списка включенных сервисов требуемому.
6. Правим в настройках DNS регистратора адрес первичного DNS, указывая вот на этот сервер, и настраиваем вторичный DNS.
7. Пинаем хостера чтобы разрешил слать и принимать почту с этой VPS-ки

Вместо п 2 и 3 можно поставить raspberry pi, и на нее накатить аналогичный образ. Правда перспективы запинывания домашнего провайдера, чтобы разрешил слать/получать почту мне кажутся несколько менее радужными. Зато порыться в вашем почтовом ящике без вашего ведома ни одна спецслужба не сможет - они будут вынуждены прийти к вам домой и предъявить ордер на обыск.

X-Post to LJ

Совершенно случайно обратил внимание на сообщения:

gpg: создан каталог '/home/v.wagner/.gnupg'
gpg: создан щит с ключами '/home/v.wagner/.gnupg/pubring.kbx'

Какая образная метафора "щит с ключами"! Так и представляешь себе вахтера на проходной какого-нибудь почтового ящика, у которого за спиной висит щит с ключами от всех лабораторий, и он их сотрудникам по утрам выдает по предъявлению пропуска (passphrase) а по вечерам следит, чтобы сдать не забыли.