Рад помочь :) пиши если будут вопросы :)

Оно уже в ядре

спасибо! Если что, обращусь :)

у меня тут убунта 20.04, там видимо его нет, но пакет такой есть в репах.

в ubuntu 20.04 уже есть, но он всё равно модуль поставил

wireguard.ko:
Running module version sanity check.

Good news! Module version 1.0.20200611 for wireguard.ko
exactly matches what is already found in kernel 5.4.0-47-generic.
DKMS will not replace this module.
You may override by specifying --force.

depmod...

DKMS: install completed.

Ну у меня вообще 5.9rc4 ))

@not_logan ну кажется в общих чертах оно завелось.
единственное, Table=wire вот это клиент считает некорректным параметром конфигурации.

И я не прописывал второй интерфейс:

AllowedIPs = 192.168.254.2/32, 192.168.1.1/24

работает вот с такой записью:
AllowedIPs = 10.0.0.2/32

для генерации конфигов я взял скрипт вот отсюда:
https://raw.githubusercontent.com/drew2a/wireguard/master/wg-genconf.sh

но он как-то криво задает правила iptables, заменил на твои.

Норм

Далекие прекрасные времена, когда на башорге шутили про айти, а не про детей...

Когда люди пользовались фрей

Говорю же - хорошее было время...

Почему в software engineering так сложно с оценками сроков? Потому что зачастую практически невозможно на глазок оценить глубины кроличьей норы, если речь идет о чем-то сложнее перекраски кнопки на лендинге.

Вот небольшой пример. Есть сервис на питоне, в котором некоторые запросы начали тормозить. Хочется найти эти запросы, для этого - добавить в логи какой-то request_id.

Но в мире асинхронного питона нельзя просто хранить какой-то id на уровне треде, т.к. тред может переключаться между запросами в процессе await, нужно использовать ContextVars. Чтобы прикрутить ContextVars, нужен Python 3.7+, нужно обновиться. В процессе обновления выясняется, что некоторая старая версия библиотеки официально не поддерживает новый питон, нужно собрать ее руками. Методом проб и ошибок находим коммит, с которого собиралась старая версия для старого питона, собираем для нового питона - результаты не сходятся, тесты падают!

Для начала нужно собрать минимальный воспроизводимый пример (в моем случае получился Dockerfile на 50 строк и примерно столько же Python-кода). Разбираем билд и видим, что библиотеке нужен с десяток shared зависимостей, для которых не всегда указаны версии. Можно найти какие-то древние логи на CI-сервере, который собирал библиотеку для старого питона, и из них достать какие-то куски информации. Их не хватает, и версии приходится перебирать бинарным поиском. Версии подобраны, они конфликтуют друг с другом, и склеить их вместе можно только странным перебором apt install ... && apt remove ... && apt install.

На все эти развлечения ушло уже три дня, и я не могу сказать, что приблизился к заветным request_id. А ведь сторонний наблюдатель с навыками эффективного менеджера вполне мог бы возмутиться: "че там делать вообще? завел переменную и клади в лог, делов-то".

а в торнадо без contextvars все работало)

в их собственных корутинах

даже на втором питоне)

вот и пишите сами на это вашем торнадо)

*пишет на торнадо и не ноет в телеграме*

А ведь можно было просто поставить contextvars отдельным модулем

Bruh, не люблю торнадо 🌚