kellvin

Вот есть у меня сейчас несколько опенсурсных проектов, которыми может быть стоит заняться, пока не устроился на фулл-тайм работу

1. переписать gost-engine на новый, появившийся в openssl 3.x интерфейс провайдеров.
2. Если уж взялся, за провайдеров то покопаться в pkcs11 провайдере - вдруг там можно малой кровью допилить до поддержки гостовских алгоритмов. Правда плату за это надо требовать с Aktiv, потому что играться я буду с ruToken. А они вряд ли так сильно заинтересованы в этом.
3. Посмотреть что у нас в Postgres с провайдерским интерфейсом openssl и может чего на коммитфест залить на предмет и алгоритмов, и токенов на клиенте. В 18 версию уже не успею, так хоть в 19.
4. По-моему в собственно утилите openssl явно не хватает ключиков для работы с ключами и, особенно, сертификатами на токенах. Но не уверен что пропихнуть соответствующий патчик будет легко даже с помощью beldmit.
5. Написать упрощенный CA для маленьких интранетов. Который будет ориентирован на генерацию ключа вместе с сертификатом, потому что и для внутрикорпоративных сайтов, и для openvpn это основной юз-кейс, когда администратор CA и администратор сайта/VPN - одно лицо. А то что CA.pl, что easy-rsa требуют два движения для получения сертифката - сначала создать ключ и заявку, а потом на заявку выписать сертификат. А здесь основное должен быть даже не код, а лежащий максимально близко к коду, чуть ли не в виде встроенного хелпа учебник по правильному обращению с сертифкатами и ключами. (надо irenedragon попытаться привлечь).
6. Вспомнить про ctypescrypto и переписать ее под 3-е версии и python, и openssl (возможно пригодится для юнит-тестов на провайдеры. А возможно, для юнит-тестов на провайдеры надо портануть ctypescrypto на Platypus )
7. Написать аналог calcurse но с бэкэндом пригодным для синрхронизации vdirsyncer. Под этот проект я даже когда-то репозиторий завел.
8. Была у меня еще идея про линуксовый management interface для openvpn Правда из-за отсутствия у меня теперь необходимости ходить в конторскую openvpn оно как-то менее актуально стало.
9. vws тоже надо бы переписать с нуля под третий питон и девятый qemu. Но может стоит подождать пока 12-й qemu выйдет.

Вообще, конечно идеальная схема снабжения деревенского дома интернетом должна выглядеть так:

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

Беда в том, что такие модемы (а они в продаже есть) стоят довольно дорого. Правда, если модем торчит над крышей. то можно над ним прикрутитть имеющуюся внешнюю антенну. Она по-моему правда всего децибелл на 12. Еще при этом почти во все такие модемы встраивают свой wi-fi модуль, который в данном сетапе, вероятно лишний. Если что и может покрыть, то садовые скамейки на участке. Потому как от дома его экранирует шиферная крыша. Шифер очень хорошо глушит что wi-fi, что сотовый сигнал, неоднократно в этом убеждался. Поэтому сейчас у меня антенна висит на первом этаже, ниже шифера. Хотя подними я ее хотя бы на уровень второго эатажа, прием станет лучше. Но надо не просто на уровень второго этажа, а чтобы шифер между антенной и базовой станцией не попал.

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

Недостаток этого решения заключается в том что LTE-модемы с POE и эзернетом стоят заметнро дороже тревел-роутеров и даже устройств вроде Tlink TL MR150 или OLAX MC-60 (которому и UPS не нужен, правда POE-инжектором в отличие от 9-вольтового UPS он работать не умеет).

X-Post to LJ

Решил тут прикрутить к 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-сайты в своей домашней сети я как-то не очень использую.

Вот думаю, купить 50 метров витой пары и провести по деревенскому дому ethernet. А то там получается что несколько удобных рабочих мест отделены от точки доступа wifi русской печкой. А через два метра кирпича радиоволны проходят плохо. А в роутере все равно 4 порта есть.

В московских квартирах где ethernet по всей квартире был сделан еще давно сейчас и Ирина, и Артур, и я пользуемся преимущественно проводным соединением а не wi-fi. Правда, в Москве есть еще такой фактор, что 2.4ГГц диапазон забит нафиг соседями, а в 5ГГц сидят 2-3 станции, но уж сидят так сидят.

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

X-Post to LJ

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

Заодно почистили мне там АТX-ную кнопку и продемонстрировали штатный шатдаун машины по ее нажатию.

Собрался тут перепрошить все свои роутеры, которые на openwrt на более новую версию. А то прям невозможно что ssh при коннекте ругается на древние алгоритмы ключа хоста. У нового-то 21.10, там dropbear ed25519 поддерживает.

• Asus RT-AC51U (ранее 19.07) прошился sysupgrade без вопросов и сохранил все настройки.
• TP-Link Archer C5 v4 ранее прошитый какой-то неофициальной сборкой 19.07 сказал что прошивка не от той модели, но после чеканья галочки Force upgrade, прошился. Правда, настройки потерял, пришлось заново настраивать. Зато, похоже, еще активно не тестировал, заработал 5ГГц диапазон WiFi, который там ранее не работал.
• TP-Link MR3020 v3 закирпичился. Впрочем и для того, чтобы первый раз его прошить тоже какой-то неофициальной прошивкой, пришлось идти на поклон к nasse и припаивать проводки к JTag.

Еще у меня есть TP-Link MR150 (он же MR6400) в котором до сих пор не openwrt, а родная, жутко неудобная прошивка. Но он в деревне, и чтобы его там перешивать, нужно иметь альтернативный роутер с 4G модемом под рукой. По крайней мере я убедился что openwrt с его встроенным 4G модемом работать умеет. Правда непонятно как с SMS-ками. А SMS-ки нужны - в личный кабинет Мегафона логиниться.

Вот теперь думаю чо с MR3020 делать. Он у меня живет для применния на даче в Бужаниново и во всяких поездках. При этом встроенного 4G модема там нет, втыкается USB-шный.

Вариант 1. Настроить на работу с USB 4G модемом модемом Archer, благо с должности основного роутера в московской квартрие я его разжаловал, вернув туда Asus AC51U, у которого wi-fi получше. зато эзернет 100Мбит. Все равно у меня все клиенты, которым нужна большая скорость по ethernet воткнуты не прямо в роутер, а в стоящий на столе 8-портовый свитч. Опять же настроенный таким образом Archer можно использовать в качестве резеревного в деревне и перешить наконец там MR150 получив нормальный dnsmasq и перестать трахаться с avahi.

недостатки Archer в качестве таскаемого с собой в поездках роутера: 1. 12-вольтовое питание. От повербанка или USB-порта ноутбука не запитаешь (а MR3020 - можно) 2. Здоровый, зараза.

Вариант 2. Плюнуть на openwrt в поездке и использовать какой-нибудь travel router с аккумулятором. У меня их два, один Huawei и 3G, другой 4G с возможностью подключения внешней антенны, не помню чей. Он лежит в ящике стола в деревне. Недостаток - нету эзернета, у MR3020 хотя бы один есть.

Вариант 3. Купить что-нибудь поновее. Вопрос в том - что, чтобы оно было совместимо с openwrt, питалось от USB имело встроенный 4G модем и хотя бы один ethernet?

Вариант 4. Раскирпичить таки MR3020. Попробую по tftp. Но если не получится...

X-Post to LJ

Тут Толченов в комментариях к одному из предыдущих постов предложил держать на VPS у провайдера только внешний роутер локальной сети, соединенный с ней с помощью VPN. А архивы электронной почты и прочий ценный конетент держать дома, под письменным столом.

Это решение имеет очевидные преимущества - нет проблемы с домовыми провайдерами, у которых достижимый извне IP по нынешним временам стоит дороже той VPS, да еще и реверсной зоны к нему нет.

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

Исходя из этих соображений я бы по крайней мере SMTP-listener на внешнем сайте реализовывал не как проброс портов внутрь VPN, а как полноценный MTA с релеингом. Соответственно, если у нас домовая сеть лежит, то приходящая извне почта складывается в очередь на этом внешнем сайте, и ждет когда сеть поднимется. С другой стороны если письмо изнутри не отправилось сразу, оно тоже сложится там в очередь и ретрай будет делать внешний сервер, независимо от доступности внутренней сети.

Публичный web-контент тоже стоит туда сложить. Он все равно публичный и несанкционированного доступа к нему быть не может (ибо любое чтение публичного контента - доступ санкционированный). Но исходя из концепции "ничего ценного и невоспроизводимого" это должно быть зеркало внутреннего сайта, регулярно (вплоть до раз в час) синхронизируемого через тот же самый VPN. Тогда даже попытка что-то там несанкционированно изменить доживет только до следующего сеанса синхронизации.

А вот синапс матрицы надо держать внутри. Проксируя с внешнего сайта средствами http сервера. И imap внутри. Вот его можно пробрасывать средствами роутинга. Хотя можно и stunnel-ом. А вебмейл можно на внешнем хосте чтобы ходил к внутреннему imap. Ну нету канала из дома во внешний мир, значит к лежащему дома архиву почты нет доступа из внешнего мира. Если мы считаем физический контроль над этим архивом важнее его доступности из любой точки мира, значит придется с этим мириться. Хотя, конечно возможен автоматический фаллбэк на LTE-модем в случае падения домашнего канала. VPN передподключится и сразу коннект восстановися. Правда почему-то сотовые операторы не любят когда их сим-карты используют в качестве аварийного фоллбэка. А для автоматического фоллбэка явно понадобится отдельная карта.

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

У меня сейчас так веб-интерфейс transmission устроен. В смысле transmisson-то крутится на домашнем десктопе, а с сервера на VPS-ке проксируется ее веб-интерфейс. Поэтому если домашний компьютер включен, я могу с работы или из деревни поставить что-нибудь на закачку.Все равно я обычно качаю через торренты что-то редкое, что будет качаться недели или месяцы, так что доехать до дома и забрать файл скорее всего сумею, качать через узкий канал не потребуется.

X-Post to LJ

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

Сейчас у меня там есть dovecot и postfix. Postfix за аутентификацией ходит к dovecot. Соответственно, протоколы imap, sieve и smtp используют единую базу пользователей. web-мейл, естественно, тоже так как аутентифицируется об imap.

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

У matrix-synapse есть систеама аутентификационные плагины. А на pypi модуль dovecot который умеет аунтинфицироваться об dovecot'овский sasl. Правда, не обновлялся лет 15. Но в дистрибутиве есть пакет python3-radicale-dovecot-sasl, откуда можно выдрать несколько более свежий код аутентификации через dovecot sasl. Всего 6-летней давности.

Для apache тоже есть mod_authn_dovecot. Тоже не шибко активно развиваемый.

Так что по идее можно пересадить всех на использование dovecot-овского sasl. Я правда, несколько не уверен что это является наилучшим решением. Учитывая, что эти клиенты к довекотовскому sasl какие-то слишком не развивающиеся. В наше время это как-то подозрительно.

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

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

Upd Подумал, что может быть наиболее правильным решением будет всех (кроме postfix, который с dovecot уже умеет договариваться) аутентифицировать непосредвтсвенно по sqlite-базе с которой работает dovecot, Для apache это точно решается штатными средствами. Если только используемое dovecot-ом шифрование совместимо с apr. А dovecot использует стандартный crypt(3), А для синапса так и так провайдер аутентификации писать.

X-Post to LJ

В процессе обсуждения точки присутствия в интернете (admin-less сервера), всплыла тема мониторинга.

Как показывает мой собственный опыт, известные средства мониторинга, вроде zabbix или open telemetry, могут быть крайне мощным инструментом в руках опытного админа, но абсолютно бесполезны при отсутствии такового.

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

А для этого человек должен хотя бы некоторое представление иметь о том, что делают подвластные ему сервера. Про проблему разделения ответственности между DBA и админом сервера я слушал разные байки десять лет, работая в фирме, которая помимо всего прочего занималась поддержкой баз данных. Сам, как пользователь сборочно-тестового кластера тоже неоднократно сталкивался с тем, что админы не понимают специфику задач и пытаются оптимизировать то, что отнимает от силы единицы процентов ресурсов, в ущерб тому, что требует 90%.

В наше время (началось это в эпоху Big Data, и продолжилось нейросетями) принято полагаться на алгоритмы обучения без учителя. Мол, если мы напихаем в некую "мясорубку данных" достаточно много данных, дальше она сама сообразит, какие закономерности можно по этим данным вывести.

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

Впрочем, подозреваю что достаточно умная система анализаа почтовой статистики поймет, что подготовка конференции это легитимная активность. Видя, что количество входящей почты возросло пропроционально исходящей, и эта входящая не от MAILER-DAEMON.

С мониторингом свободного места на диске примерно то же самое. Достаточно умная система должна отследить как именно расходуется место, и не беспокоить пользователя алертами, если занято 90-95% дисков, но рост в таких пределах, что на ближайшие пару месяцев хватит. И наоборот, начать пугаться, даже если свободна четверть диска, но раз-два в сутки бывают такие задачи, которые временно отжирают почти все свободное место.

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

X-Post to LJ