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

Кажется, авторы RFC 5545 рассчитывали на использование их пользователями GTD.

Иначе зачем бы объекту VTODO статус DELEGATED?

Если у нас набор задач общий для всех членов команды, логичнее иметь поле ASSIGNEE как, скажем, в jira.

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

Авторы todoman похоже, тоже что-тоимели в виду GTD, предусмотрев команду копирование задачи из списка в список. Хотя правильнее было бы не копировать, а перемещать. GTD заточена под бумажные описания задач, которые скопировать сложно, а переместить из лотка в лоток - легко.

И в андроином tasks.org поддержка множественных списков тоже есть. Хотя эта программа больше расчитана на работу с категориями задач. Но категории - это по смыслу тэги. Вещь неструктурировананая, способствующая разведению бардака. Правда в tasks.org есть поддержка подзадач, причем произвольной глубины вложенности. а в todoman нет. Я было подумывал ее туда дописать, но что-то с ходу не получилось. Больно уж там много функиональности унесено в модуль icalendar, который в другом репозитории и в другом пакете. Править их параллельно - неудобно.

Лучше сразу своё делать. Потому что все кто работает с RFC 5545 умеют аккуратно сохранть неподдерживаемые поля. Так что с одним и тем же календарем (список задач как ни странно - часть календаря) можно работать разными программами, причем как локально, так и по сети с помощью CalDAV. Благо есть на свете vdirsyncer

Случилась тут у меня в VK дискуссия с nataraj по поводу того, могут ли среди современных студентов попасться "опытные пользователи Linux". И что вообще такое "опытный пользователь Linux" из которого должна получиться хорошая заготовка для будущего разработчика прикладных программ.

На мой взгляд, пользователь, это тот кто решает на компьютере какие-то свои задачи, желательно не имеющие отношения к IT (а то будет "это вроде как машина скорой помощи идет, сама режет, сама давит, сама помощь подает"). Причем пользователем Linux в этом контексте является не тот, кто использует Linux-систему в качестве платформы для запуска браузера, используемого для доступа к чужим сайтам, на которых задачи и решаются, а тот, кто использует для решения задач именно средства, специфичные для POSIX-совместимых систем. Шелл, coreutils, в меньшей степени скриптовые языки вроде Perl и Python - те более системно-независимы.

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

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

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

X-Post to LJ

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

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

Но может быть стоит посмотреть на что-то более современное?

Пока рассматриваю два варианта urwid и textual.

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

Второй - более развесистый, есть например готовый tree widget. Но за красоту платить придется, и платить в первую очередь местом на экране. Ну что такое текстовая кнопка в три строки размером? Даже в Turbo Vision две было.

X-Post to LJ

В связи с кончиной десктопа остался без рабочей инсталляции XEphem.

А как же мне без этой программы распланировать рейс корабля пришельцев по Солнечной системе?

Пришлось опять собирать из исходников. Ну заодно, наверное версия обновится.

Вообще конечно кто-то уже собирал deb-пакеты для убунту. Но скачать debian.tar.xz c opensuse build system почему-то не получается. Во всяком случае без регистрации.

А какая там убунту, какая в ней версия motif и libc - не написано.

Так что потратил примерно час времени и сделал свои пакетировочные файлы.

И залил на github

X-Post to LJ

Решил тут попробовать перейти на одном из ноутбуков с конфигурации сети с помощью пакета 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

Вот задумался над тем что применить на новой vds-ке для управления файрволлом.

Раньше у меня был iptables-persistent, но сколько можно, iptables уже лет пять как deprecated.

В Debian умолчательным способом считается юнит nftables, который просто загружает вручную напсанный конфиг. Есть еще nftables-persistent, который работает так же как iptables-persistent т.е. сохраняет конфигурацию, а потом ее загружает, но средствами nftables.

Есть ufw, который использует bsd-шный синтаксис, а есть firewalld, который имеет крайне развесистую схему конфигурации. Насколько я понял firewalld, это попытка сделать из linux андроид, т.е. передать контроль над ситуацией от пользователя/сисадмина авторам приложений. Впрочем как я почитал ченджлоги systemd 258, идея сделать из линукса андроид потихоньку овладевает массами.

Мне, естественно, концепция firewalld не понравилась. Тем более что в имеющемся наборе конфигов как-то путаница между приложениями и протоколами. Например для imap, imaps, и managesieve - разные конфиги. Хотя сервис один и тот же.

Вот теперь думаю, nftables или nftables-persistent. Первый заставит выучить новый синтаксис (вообще-то давно пора), со вторым можно по-моему договориться, используя синатксис iptables (через iptables-nft).

X-Post to LJ

Выйдя на работу после четырех с половиной месяцев перервыа, обнаружил что в мире Open Source произошло много чего, чего я не заметил. Нет, что 10-й редхат перестал быть бетой, я заметил. Но вот выход 15 GCC - пропустил. В больнице валялся. И как называется актуальная не-LTS убунта забыл. Хотя контейнер с именем plucky я сетапил еще в ноябре. Впрочем ждем опять же ноября и убунты на букву r - она LTS будет.

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

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 выйдет.

Тут призадумался о том, как бы избежать хранения одних и тех же паролей одних и тех же юзеров в пяти разных местах с тремя разными способами хэширования. Это не столько к гипотетическому проекту 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