crower

systemd, ntpd и другие

2017-09-18T01:07:55Z

В продолжении разговора.

Ваять systemd-style конфиги для ntpd пока не охота. Полез в /etc/rc3.d и офигел.
Раньше какие только порядковые номера там не видел, а теперь всё как-то скомкано. Да, ntp был в первой партии, но там был и bind, а bind-у больше ничего не было нужно кроме работающего интерфейса.
А сейчас бинду нужен, как минимум, dnscrypt-proxy. Или, на худой конец, tor-resolver. #нуивот.
Но раньше и тор, и transmission-daemon были двадцатыми, а сейчас какая-то скотина сделал тор четвёртым, а трансмишин вообще первым. И это не смотря на то, что в настройках трансмишина чётко написано запускать после тора, бинда и привокси.
В общем, для начала отодвинул ntp по порядку подальше.
С остальным ещё предстоит разбираться.

comments

И снова systemd

2017-08-05T04:45:38Z

Рано радовался.
Как там система умудрилась пару раз подняться без даунгредового статуса не знаю, но после этого два раза подряд загружается с проблемами. Как всегда, с networking.service. И transmission-daemon не запускает.
Это хорошо, что я стат-робота научил мне сразу писать xmpp, так что практически сразу после перезагрузки получаю сообщение "не могу подключиться".
При этом нигде никаких следов не нашёл, почему такая замечательная systemd не захотела transmission загружать. Вроде зависимостей не много: privoxy, tor и dsncrypt-proxy. Все работают. Тут на днях, кстати, последние два как-то молча отваливались. Хорошо я как раз рядом был и быстро заметил — что-то не так, ну и знаю куда надо смотреть для начала. Даже подумал было что провайдер устроил атаку на "средства обхода". Но, слава Ктулху, нет — перезагрузил одно, другое и всё поехало дальше.
Сейчас тоже поглядел — networking как обычно со статусом failed. В логах eth1 поднимался нехорошо ("я уже поднялся, нехрен меня дёргать") и в ifstate его нет. Тупо зачем-то вписал, как и в прошлый раз. Другие-же вписаны - eth0 и lo. Но эту хрень не обманешь. При этом всё работает. Для профилактики systemctl start networking снова сделал. Обычно поднимается уже без failed, хотя кое-каких демонов система и дёргает зачем-то. В этот раз тоже пониженный статус ушёл, но какие-то странности стали наблюдаться. Трансмишин странно себя повёл - говорил что трафик есть, но не могут же цифры стоять как вкопаные. Рестартанул.
Пнул tor. Вроде активность появилась.
Глянул интерфейсы — а teredo-то и нету. Он тут, конечно, погоды не делает, но если поставили, то должон работать. Даю start - не работает. Ещё раз - хрен. Тогда сначала кладу: stop, start - поднялся мгновенно. Не иначе лежал, но pid остался и система считала что он работает. А раз работает, то нефиг трогать. Такой болезнью, кстати, страдает ntpd. Просишь ntpq время - а в ответ "Connection refused". В systemctl он зелёный, status=0/SUCCESS, active, но при этом exited. А он, оказывается не осчастливлен systemd. Надо посмотреть как его настроить чтобы автоматом перезапускался. Это, наверно, потому что они какой-то свой синхронизатор времени придумали.
Посмотрел логи - слишком быстро ntp поднимается и не может отресолвить нужные опорные сервера.

Борьба продолжается. :)

comments

Бодание с systemd

2017-07-25T02:36:30Z

systemd, как некая хрень, данная нам в наказание, чтобы жизнь мёдом не казалась.

Началось всё, конечно, гораздо раньше, но конкретно эта история началась с желания добиться от privoxy адекватной работы. Нет, конечно, он работает правильно. Но основная его задача — вставлять в запросы от transmission к аннонсерам строчки x-forwarded-for. Дабы аннонсеры знали его рабочий адрес, не принимая за таковой адрес выходной ноды. То есть конструкция довольно простая: transmission, iptables, privoxy, tor, аннонсеры. Чуток её усложняет dnscrypt-proxy, предназначенный для противодействия MITM-атакам. Сначала, правда, пытался заюзать tor-resolve, но безопасный ресолвинг сходу получить не вышло, потому и переключился на dnscrypt. Сейчас-то понимаю, что проблема могла быть в том, что tor был тогда не в достаточной степени адаптирован под изменившиеся обстоятельства и, imho, выходная нода попадала под MITM-атаку. Потом всё-равно пришлось делать "тонкую настройку" тору, но на dnscrypt так и остался. IMHO, он всё-таки лучше, чем tor-resolve.
Итого, клиент ресолвит адрес через dnscrypt, шлёт анонсы на трекеры, но их перехватывает iptables и отправляет к privoxy. Тот дописывает x-forwarded-for и заталкивает в тор. В результате анонсеры узнают реальный адрес и отдают его пирам.
Но transmission находится за роутером, который имеет динамический адрес и не знает свой адрес.
Да и никто его не знает. Как-то штудировал протоколы, по которым transmission запрашивает проброс порта и что-о не нашёл штатного способа об этом узнать. Хрень какая-то.
А как-же его узнать?
Варинта вижу два.
1). Идти на роутер и выпарсивать адрес из его страничек. Но это долго и нудно.
2). Можно кого-нибудь спросить. Например на api.apify.org или у wtfismyip.com. Которые дают чистый адрес без необходимости выискивать его на странице. Подсмотрел у друзей по несчастью и клонировал демона, который периодически узнаёт рабочий адрес и подсказывает его privoxy.
И всё было прекрасно, до тех пор пока на пол-дня transmission не потерял связь с трекерами.
С чего бы это?
А с того, что privoxy упал
А почему он упал?
А потому что демон внешнего адреса (назовём его Еидом) был тупой (дарёному демону в зубы не смотрят) и когда вместо адреса получил какую-то хрень, то попортил "зону комфорта" для privoxy, который упал на пол, стал стучать ножками и отказался дальше работать. Еиду-то что — его к жизни всякий раз возвращает кронос, а привокси на такое не был расчитан.
Ну, понятное дело, что скил демона был прокачан, дабы тот впредь сообщал привокси только внятный валидный адрес. Но грусть в душу запала, ибо надеяться на чужие ресурсы, которые могут отвалиться, отсплититься или ещё какая напасть возникнет, негоже. Придётся писать собственного демона, который внешний адрес будет узнавать у роутера.
И казалось бы, всё заработало, но тут-то и выходит весь из себя systemd.
Надо сказать, что я на него давно уже зуб имею. Странный какой-то, запутанный, дурной. Чтобы ковырять, надо кучу терминалов открыть, потому что разные конфиги в куче разных мест, весьма далёких друг от друга. А ещё он сразу невзлюбил miredo. И второй интерфейс на компе тоже. А из-за него якобы networking не поднимается. То есть, по факту он всё-таки поднят. Но поскольку при его поднятии второй интерфейс обругал, что он и так уже запущен, то systemd его пометила как failed.
Так вот, задумался я, что Еид должен быть запущен перед privoxy, дабы прописать правильный адрес до того, как тот начнёт рассылать недостоверную информацию. Но тогда и transmission должен быть запущен только после privoxy. А privoxy должен быть запущен после tor. Ну, и так далее.
Сначала, конечно, накосячил :)
Во-первых, conntrack нельзя, оказывается, настраивать до того, как загружен модуль ;)
И transmission вообще не запустился. Может потому что загнал ему в after networking.target, а networking у меня, как помните, failed.
Зато потом, внимательно поразмыслив кто после кого должен запускаться и удалив некоторые избыточные (и, видимо, запутывающие) зависимости, довёл до нужного вида. В результате чего, даже networking стал подниматься без fail.
Сегодня была как раз вторая (внеплановая) перезагрузка и в этот раз тоже всё поднялось как нужно.

comments