Вы не поверите, но снова подтвердилась теория о том, что компьютеры обладают душой. Стоило мне написать предидущий пост, как ubuntu совершила самоубийство. Я просто закрыл ноутбук и он больше не вышел из сна. И потом вообще отказался загружаться – даже груб не мог запуститься.
В общем, буквально пара дней и у меня появилась почти удовлетворяющая меня система. И более того, в случае чего я могу повторить ее буквально за несколько минут. Всякие мелочи типа скорости курсора и прочее пока приходится настраивать руками.
Внезапно (тм) я обнаружил, что пользователям, которые сидят за кинетиком, не достается ipv6. Хотя сам кинетик исправно получает ipv6 и отображает его в дашборде. Немного погуглив, я обнаружил, что одной подсетки /64 кинетику мало, ему надо еще отдать некий prefix description.
Итак, схема соединения простая router - keenetic - user.
Роутер совершенно честно получает 2001:db8:99:0:52ff:20ff:fe7d:5d71 и показывает этот же адрес у себя в дашборде. И вот тут у меня возник затык. Везде рецепты по получению этого самого PD приводили к каким-то шаманским пляскам с systemd-network и прочим вещам. Естественно, роутеру на это было совершенно монопенисуально. В итоге индеец зоркий глаз обнаружил, что ISC DHCPD умеет отдавать этот самый PD.
Я вырезал лишнее. Если кратко, то вся суть в последних трех строчках. DHCPD садится на интерфейс, содержащий адрес из подсети 2001:db8:99::/48 и говорит, что любой обратившийся может взять префикс /56 из диапазона 2001:db8:100:100-200
Перезапускаем и тут же получаем в логах следующее
Sep 04 14:36:19 router-wifi dhcpd[2060]: Rebind message from fe80::52ff:20ff:fe7d:5d71 port 546, transaction ID 0x4E15F400
Sep 04 14:36:19 router-wifi dhcpd[2060]: Reply PD: address 2001:db8:100:200::/56 to client with duid 00:03:00:01:50:ff:20:7d:5d:71 iaid = 1 valid for 150 seconds
Sep 04 14:36:19 router-wifi dhcpd[2060]: Sending Reply to fe80::52ff:20ff:fe7d:5d71 port 546
Идем в дашборд кинетика и видим появившуся строчку IPv6 prefix
И клиент тоже подтверждает, что он получил айпишник из этого префикса
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 68:3e:26:b0:b1:93 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.128/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp0s20f3
valid_lft 215sec preferred_lft 215sec
inet6 2001:db8:100:200:fd6c:e8a9:6e3:7d75/64 scope global temporary dynamic
valid_lft 134sec preferred_lft 84sec
inet6 2001:db8:100:200:ae30:1497:47c9:c0e7/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 134sec preferred_lft 84sec
inet6 fe80::8e0b:e946:d9e4:9dfd/64 scope link noprefixroute
valid_lft forever preferred_lft forever
И теперь самое сложное: дать роутеру понять, куда надо роутить трафик для 2001:db8:100: . Вот тут я нормальных решений не нашел. Кинетик не умеет в динамические протоколы роутинга, а городить некий парсер логов и потом править роуты мне стало откровенно лень. Как делают большие пацаны из телекомов я тоже не нашел. Поэтому я взял и захардкодил это в роуты
routes:
- to: "2001:db8:100::/48"
via: "2001:db8:99:0:52ff:20ff:fe7d:5d71"
on-link: true
Да, криво. Да, может сломаться, если кто-то еще в этой сети попросит PD. Но, повторюсь, других вариантов я не нашел.
Ну а дальше наслаждаемся нормальным ipv6 и прочими положенными плюшками
Недавно мне потребовалось соеденить две площадки с виртуалками. Обе у нас (ПОДЧЕРКИВАЮ!), обе у достаточно крупных провайдеров. В общем, надо сделать так, чтобы Н машин у одного провайдера видели М машин у другого. Трафик не большой, но достаточно критичный.
“ХА!” – сказал я и нарисовал классическую схему соединения.
Выделяем на каждой площадке машинку (или на одну из доступных вешаем внешний ip), обвешиваемся файрволами и закрываем трафик тем же IPSec. Инструкций много, вариантов много – в общем, прорвемся!
Быстренько собрал, накидал конфиги и получил веслом по морде. Протокол ESP где-то по пути заблокирован. Техподдержка обоих провайдеров клянется, что это не у них, но ipsec не верит и отказывается подниматься. Ладно, хотелось по-корпоративному, пойдем по-молодежному.
OpenVPN шустро поднялся, поначалу начал бодро гонять трафик, но через некоторое время начались проблемы. Он переподсоединялся, слал немного байт и снова уходил в нирвану. Смена протокола с UDP на TCP приносила лишь временное облегчение.
Кто виноват – мне, если честно говорить, абсолютно пофиг. Мне трафик нужно гонять. Поэтому расчехлил тяжелую хипстерскую артиллерию – shadowsocks + v2ray. Качаем с гита, просто распаковываем, плюем в конфиг сервера следующее (1.1.1.1 – это внешний адрес сервера, если что):
Запускаем и получаем на клиенте socks5 сервер на 1080 порту. А теперь – финт конем. В конфиг OpenVPN на клиенте добавляем одну единственную строчку:
socks-proxy 127.0.0.1 1080
Ну и перезапускаем все, чтобы прочитало конфиги. Вуаля! У нас получилась следующая схема:
OpenVPN ходит через ShadowSocks, который ходит через хрен знает как настроенный интернет.
Но через некоторое время проявилась та же самая боль: немного погодя клиент терял соединение с сервером. Причем перезапустишь – все снова начинает бегать. Ставил опции ping, менял MSS и MTU – пофиг: рандомно теряем коннект.
Ок, перевел openvpn и shadowsock на TCP. Всё магически исправилось. Коннект стабильный, не рвется, пакетики бегают туда-сюда.
Отключил "mode": "tcp_and_udp", позакрывал фаирволлами и начал тестить.
Итак, прямой tcp линк безо всяких штук
[ 1] 0.0000-10.2561 sec 112 MBytes 91.8 Mbits/sec
Да, клиент сидит на дешевом тарифном плане в 100 мегабит, поэтому практически упираемся в полку. Теперь через все эти навороты:
И это без какого-либо тюнинга! Да, tcp-over-tcp-over-tcp еще тот изврат, но ведь работает же! А после тюнинга (банальные буфера и прочее – в любом мануале по openvpn) я получил следующее:
Нам надо платить меньше. На одной стороне не нужен выделенный ip (а они нынче дорогие). Выпускают всех через SNAT и норм.
Настраивается не просто, а очень просто.
Снаружи на сервере порт OpenVPN можно спокойно закрыть фаирволлом. Соединение идет с локалхоста. Больше сесуретей богу сесурити!
Память не жрет. Можно смело брать самую дешевую виртуалку под “роутеры”. Вся вот эта машинерия + FRR с OSPF сьели 200 мегов.
Оно работает. Реально, за неделю уже не одиного разрыва.
Что в минусах:
Потеряли в скорости. Немного, но есть. Проблема в том, что на стороне клиента я банально уперся в единственный ЦПУ виртуалки. Когда тесты идут, на той стороне в топе такое:
С другой стороны, там трафик в 20-30 мегабит уже редкость, так что в любом случае все в порядке. Но запас карман не тянет.
Ну и нафига я все это делал: мне нужно было среплицировать один MySQL в другой. Предложенная схема их удовлетворила, значит задача выполнена.
Поначалу я планировал этот пост про InfluxDB. Дескать, вот так поставим, вот так настроим… Однако реальность больно тыкнула вилкой в глаз: поставил, запустил, зашел на influx:8086, установил пароль, завел организацию… и всё. Нет, реально всё. Больше там ничего не потребовалось делать.
А вот с телеграфом пришлось повозиться. Дело в том, что я возжелал с одной машины отправлять разные метрики в разные бакеты. Ну всякие там “загрузка процессора и памяти” в один, а “температура в доме” – в другой. Ну вот захотелось мне так.
Все просто. Для начала прямо в telegraf.conf добавим тег influxdb_database
# Global tags can be specified here in key="value" format.
[global_tags]
# dc = "us-east-1" # will tag all metrics with dc=us-east-1
# rack = "1a"
## Environment variables can be used as tags, and throughout the config file
# user = "$USER"
influxdb_database = "default"
Да, я очень неоригинален в этом плане. Теперь ко всему, что собирает telegraf по умолчанию добавляется тэг influxdb_database со значением default.
Теперь добавляем сборку данных с mqtt. Заполняем файл /etc/telegraf/telegraf.d/mqtt.conf
[[inputs.mqtt_consumer]]
servers = ["tcp://127.0.0.1:1883"]
## Topics that will be subscribed to.
topics = [
"/devices/+/controls/temperature",
"/devices/+/controls/battery",
"/devices/+/controls/humidity",
"/devices/+/controls/pressure",
"/devices/+/controls/co2",
"/devices/+/controls/MCU Temperature",
"/devices/+/controls/CPU Temperature",
"/devices/dark_room_power/controls/voltage",
"/devices/dark_room_power/controls/power",
"/devices/sleeping_room_power2/controls/voltage",
"/devices/sleeping_room_power2/controls/power",
]
data_format = "value"
data_type = "float"
[inputs.mqtt_consumer.tags]
influxdb_database = "mqtt"
Тут тоже все просто: указываем адрес сервера, указываем, на какие топики подписаться, их формат и последней строчкой меняем значение тега на mqtt. И теперь самая магия:
Наверняка для матерых инфлюксоводов это покажестя легкой шуткой, но я честно потратил пару часов на раскуривание функционала tagpass. Больше, правда, на выяснение, как и куда его правильно прописать. В общем, теперь все с influxdb_database = default попадает в бакет hlevnoe, а mqtt в mqtt.
Запустив все это и убедившись в отсутствии ошибок, можно вернуться в influx. Там есть простенький data explorer, позволяющий потыкаться и порисовать графики. Даже можно простейшие дашборды собрать!
Вот, к примеру, график потребления электричества у морозильника.
Или график температуры у меня за окном
В общем, это далеко не графана, но по-быстрому позырить что к чему – можно.
Умная мысля приходит обычно слишком поздно. Вот и тут, я много лет страдал при переходе с одного компа на другой. В каждой операционке своя терминалка, со своими дрючками и глючками. Я ходил, настраивал и пытался их подогнать одну к другой.. Хорошо еще, что хоть чуть-чуть шорткаты устаканились, а то вообще боль была…
В общем, я решил сменить терминалку. Немного подумал и составил офигенно длинный лист требований:
Терминалка должна работать под Linux, MacOS и Windows (WSL)
Она должна работать одинаково. То есть один и тот же параметр в конфиге должен приводить к одним и тем же изменениям в поведении.
Терминалка должна уметь в truecolor.
Терминалка должна уметь в шрифтовые лигатуры.
Всё остальное, типа рендеринга на GPU или особо правильной поддержке многих систем, мне было совершенно не нужно. Главное, чтобы я взял ноутбук на другой операционке и получил абсолютно тот же… сейчас это модно называть экспириенсом. Внезапно самым сложным для терминалок оказался последний пункт.
Я не понимаю, чего сложного в подобной конвертации символов -> >> <> != ? Но, например, авторы gnome terminal не осилили подобного и отмазались, что не для всех языков это может работать. Ну сделали бы не для всех…
И, внезапно, всем моим хотелкам удовлетворила только одна терминалка – kitty. Если быть до конца честным, то нет, были и другие, но они не такие гламурные. Ставить котёнка можно 100500 способами, но я предпочел через пакетный менеджер.
После установки я некоторое время испытывал реальную боль. Дело в том, что автор этой терминалки – индус и очень своеобразно подошел к составлению документации. Кусочек тут, кусочек там, а потом можно и вот сюда глянуть… В общем, вот мой конфиг
Последние строчки – это дань моей лени, чтобы новые окошки открывались как на макоси. Win+n и не надо пальцы ломать об Ctrl+Shift+n . Мелочь, а удобно. Ну и файлик theme.conf, честно спертый из интернета и имитирующий тему homebrew
И вот я уже почти неделю живу на двух операционках и с одним терминалом. Нормально …
Теперь операционко-специфичные штуки.
MacOS: надо в ENV переменные добавить KITTY_CONFIG_DIRECTORY=~/.config/kitty/ , иначе котенок хз где хранит конфиги. А так все в одинаковом месте. Чтобы сменить иконку, надо ее просто рядом с конфигом положить и обозвать kitty.app.png.
Linux: чтобы сменить иконку, надо сделать desktop файл, аналогичный нижеприведенному, и положить его в .local/share/applications/ . Главная боль – путь до иконки должен быть абсолютным.
Пора, пора описывать то, что было сделано. А то как обычно, забудется и всё, пиши “прощай”.
Итак, давным-давно, когда ещё существовала страна под названием “Украина”, я начал делать свою… Ну даже не знаю, на лабораторию это не тянет, на свой датацентр тоже. В общем, несколько серверов, выполняющих нужные для меня задачи. Часть арендованные, часть свои… И всё было совсем хорошо, пока не началась СВО. Тут же вылезла куча говна и давай блочить доступ. Следом к ним присоеденились убегуны и давай портить до чего руки дотянутся. Дескать, они все такие чувствительные, что не могут позволить такое и вааще, они только за самое хорошее! Но тут не про них, а про то, как сделать себе хорошо и нагло игнорировать подобное сейчас и в будущем.
Итак, условия для этой задачи и последующих простые: я должен иметь возможность поставить или обновить нужное мне в любой момент времени. Есть интернет, нету – все равно. И первым шагом я сделаю зеркало для пакетов дистрибутива ubuntu.
Погуглив, я нашел несколько инструкций, как сделать свое зеркало. Немного потыкался в монстров типа Nexus и прочих JFrog и решил, что лучшее враг хорошего. Итак, для начала нам нужна машинка с более-менее приличным диском. Далее все просто и прямолинейно: ставим необходимое и подготавливаем структуру каталогов
А вот теперь скрипт, который все друг у друга таскают. Я не исключение
# cat > debmirroramd64.sh
#!/bin/bash
## Setting variables with explanations.
#
# Don't touch the user's keyring, have our own instead
#
export GNUPGHOME=/mirror/debmirror/mirrorkeyring
# Arch= -a # Architecture. For Ubuntu can be i386, powerpc or amd64.
# sparc, only starts in dapper, it is only the later models of sparc.
# For multiple architecture, use ",". like "i386,amd64"
arch=amd64
# Minimum Ubuntu system requires main, restricted
# Section= -s # Section (One of the following - main/restricted/universe/multiverse).
# You can add extra file with $Section/debian-installer. ex: main/debian-installer,universe/debian-installer,multiverse/debian-installer,restricted/debian-installer
#
section=main,restricted,universe,multiverse
# Release= -d # Release of the system (, focal ), and the -updates and -security ( -backports can be added if desired)
# List of updated releases in: https://wiki.ubuntu.com/Releases
# List of sort codenames used: http://archive.ubuntu.com/ubuntu/dists/
release=noble,noble-security,noble-updates,noble-backports
# Server= -h # Server name, minus the protocol and the path at the end
# CHANGE "*" to equal the mirror you want to create your mirror from. au. in Australia ca. in Canada.
# This can be found in your own /etc/apt/sources.list file, assuming you have Ubuntu installed.
#
server=ru.archive.ubuntu.com
# Dir= -r # Path from the main server, so http://my.web.server/$dir, Server dependant
#
inPath=/ubuntu
# Proto= --method= # Protocol to use for transfer (http, ftp, hftp, rsync)
# Choose one - http is most usual the service, and the service must be available on the server you point at.
# For some "rsync" may be faster.
proto=rsync
# Outpath= # Directory to store the mirror in
# Make this a full path to where you want to mirror the material.
#
outPath=/mirror/debmirror/amd64
# By default bandwidth is not limited. Uncommend this variable and set it to the apropriate
# value in Kilobytes per second. Also don't forget to uncomment the --rsync-options line in the last section below.
bwlimit=1000
# The --nosource option only downloads debs and not deb-src's
# The --progress option shows files as they are downloaded
# --source \ in the place of --no-source \ if you want sources also.
# --nocleanup Do not clean up the local mirror after mirroring is complete. Use this option to keep older repository
# Start script
#
debmirror -a $arch \
--no-source \
-s $section \
-h $server \
-d $release \
-r $inPath \
--progress \
--method=$proto \
--rsync-options "-aIL --partial --bwlimit=$bwlimit" \
$outPath
Скрипт настроен на российский миррор и лимит в 1 мегабайт в секунду, чтобы не забивать канал, как минимум при первоначальной скачке. Ну и релиз поменял на noble, ибо нынче уже 2024 год и в ходу у меня 24.04. Далее просто запускаем этот скрипт и идем заниматься своими делами. Оно медленно и печально высосет кучу гигабайт. Реально КУЧУ гигабайт. На момент написания размер зеркала был в районе двухсот гигов.
Ну а дальше просто везде разбрасываем новый ubuntu.list, заменяя им ubuntu.sources
deb http://mirror/ubuntu noble main restricted universe multiverse
deb http://mirror/ubuntu noble-security main restricted universe multiverse
deb http://mirror/ubuntu noble-updates main restricted universe multiverse
И точно так же миррорим что-то другое. К примеру, возжелал я поставить InfluxDB. Можно пакетики тащить, а можно зеркало сделать.
И чуточку поправленный скрипт без комментариев. Изменил только откуда брать, куда ложить и то, что не надо использовать rsync. Адреса и прочее я нагло упер из инструкции с официальной страницы https://www.influxdata.com/downloads/, когда выбрал Ubuntu&Debian
С чего начинается любой умный дом? Ну в смысле если он действительно претендует на право называться умным? Правильно, с места хранения состояния всяких устройств и датчиков.
Исторически сложилось, что для централизации подобного используется протокол MQTT. Он легкий, простой и поддерживается всеми участвующими в деле устройствами.
Вообще у меня уже есть один mqtt сервер, встроенный в wirenboad. Но есть два больших но: 1) сам по себе wirenboard очень дохлый (хотя народ радостно на него даже Home Assistant в докере водружает) и 2) у меня будет очень много устройств, общающихся по MQTT.
Поэтому решение простое: поднимаем на виртуалке MQTT сервер и заставляем всех с ним работать. А кто не умеет или умеет не кошерно – забирать с тех данные самим. Для реально больших нагрузок или отказоустойчивости народ ставит EMQX, но у меня такого не будет, поэтому использую mosquitto.
apt install mosquitto mosquitto-clients
Все настройки оставляю по умолчанию, просто добавляю один мост wirenboard->mosquitto.
Принцип простой: тупо подписываемся на все топики с сервера wirenboard. Паролей и логинов нет, всяких TLS тоже не наблюдается. Проверить работоспособность полученного решения тоже проще простого:
mosquitto_sub -t \#
Если все хорошо, то вы должны увидеть бегущую колонку цифр. Wirenboard сам по себе генерирует кучу трафика, так что никаких пауз не будет. А если у вас, как и у меня, уже подключены датчики, то трафик становится довольно большим для глаз.
Дело было как-то вечером. Есть у меня дома контроллер wirenboard. Пока идет знакомство, наладка и отстройка, управляет светом около стола, да и меряет температуру по всему дому. Но не суть. наткнулся я на одну интересную багофичу: если пощелкать переключателями, а потом тут же обрубить питание, то эти самые переключатели после загрузки окажутся в рандомном состоянии.
Небольшое расследование со службой поддержки wirenboard показало, что дело в одном маленьком файлике. Вернее с тем, как linux с ним обращается. Верхнеуровневый софт честно в него пишет нужное, а вот линукс, желая сберечь ресурс emmc, начинает активно кешировать и сбрасывает файловый кеш тогда, когда в 99% уже поздно.
Казалось бы, фигня вопрос: засунь в крон sync и дело в шляпе. Ок, не в крон, это перебор, а после inotify и всё. Но сбрасывать всю FS ради одного файла… В общем, рецепт ниже.
# cat /etc/systemd/system/libwbmqtt-saver.service
[Unit]
Description=Drop file cache for libwbmqtt.db if it changed
[Service]
ExecStart=/bin/bash -c 'inotifywait -qq -e modify /var/lib/wb-mqtt-gpio/libwbmqtt.db && dd of=/var/lib/wb-mqtt-gpio/libwbmqtt.db oflag=nocache conv=notrunc,fdatasync count=0 status=none'
Restart=always
[Install]
WantedBy=multi-user.target
Всё написано на скорую руку, но тем не менее, прекрасно работает. Вся магия в том, что dd открывает фаил на запись, записывает 0 байт и закрывает, сбрасывая кеш. Такую оптимизацию подсмотрел где-то в инете, мое первоначальное решение было гораздо страшнее (и нет, не покажу).
… на вшивость. Или как проверить, что вам дают ровно столько интернета, сколько положено по тарифному плану.
В самом начале обязан раскрыть спойлер. Если обнаружится, что вам не докладывают интернета, то вы с этим ничего сделать не сможете. Ну разве что в воздух поорать чаечкой или попробовать счастья у другого провайдера. Техподдержка будет отвечать, что все в порядке и вообще так и должно быть. В общем, у вас просто нет никаких ручек для изменения ситуации.
Итак, для начала первый и единственный признак, что вам дают мало интернета: качается медленно. Но слово “медленно” очень субьективное, а нам нужна обьективность.
Итак, пойдем проверять по шагам:
Шаг первый: проверить вашу линию и устройства на ней. Ну сколько она может переварить в нынешних условиях. Откройте на том устройстве, на котором медленно, сайт speedtest.net. Почему именно его? Причина простая: все провайдеры в курсе этого сайта и специально оптимизируют свою инфраструктуру под него. Так что показанное значение скорости можно считать максимальным для данных условий.
Проверять лучше всего ранним утром и в выходные. Или хотя бы несколько раз в разное время. Причина простая: разные люди качают разное и вы вполне можете начать делить вышестоящий канал.
Когда не надо волноваться: показометр скорости интернета регулярно показывает 85% и больше от вашего тарифного плана. Иначе говоря, если у вас тарифный план в 300 мегабит, то увидеть вы должны 260 мегабит и больше. И да, на скорость исходящего трафика особого внимания можете не обращать.
Когда надо волноваться: во всех остальных случаях. Причин может быть множество: от дохлого роутера до забитого диапазона WiFi. К сожалению, лечение по фотографии тут невозможно, поэтому найдите и пригласите того, кто умеет в компьютеры.
Шаг второй: проверяем реальную скорость. Просто берем, гуляем по интернету и качаем большие файлы. Лично я по роду увлечений иду и качаю дистрибутивы линукса. Они в меру большие, часто лежат на отдельных серверах с хорошим каналом и поэтому вполне себе подходят под такое использование.
Что не надо делать: использовать большие и популярные сайты для скачивания. Причина простая: на них обычно ограничивается скорость скачивания для одного клиента.
Для визуализации очень полезно использовать монитор загруженности системы. В windows его можно позвать по комбинации клавиш Ctrl-Shift-Esc. В MacOS он в папке Утилиты, ну а линуксоиды сами знают, где его найти.
Опять же, когда не надо волноваться: файлики качаются быстро. Скорость, которую показывает браузер или монитор, очень похожа на то, что обещает провайдер. Редкие закачки, на которых скорость не растет – сорян, но это не показатель. Интернет на самом деле так устроен.
Когда надо волноваться: что бы вы не качали, откуда бы не пробовали – всегда скорость низкая.
Для примера визуализация, когда все идеально: и канал свободный и сервера не загружены и ваш компьютер не тормозит.
Для начала обратите внимание на уровень крутизны левой границы. Чем она вертикальнее, тем свободнее канал. Ну или если говорить другими словами, тем меньше расстояние до сервера, откуда вы качаете. Верхняя “полочка” своей ровностью говорит о том, что скорость что-то ограничивает. В данном случае – ограничение канала. Он просто физически быстрее не умеет передавать данные. Картинка ниже показывает, что сервер далеко (скорость растет гораздо медленней), но тоже упирается в какие-то внешние ограничения.
А теперь картинка, которую вы должны видеть в 99% случаев.
Скорость растет и потом начинает “колбаситься” возле верхней границы тарифа. Такое поведение абсолютно нормальное. В интернете постоянно летают туда-сюда тонны данных, маршруты перестраиваются, оборудование провайдера ограничивает вашу скорость согласно тарифному плану и так далее.
И теперь самое обидное, в общем-то ради чего и был написан этот пост. Случай, когда вам специально ограничивают скорость интернета. Провайдер, чужой сервер, инопланетянин – вам все равно, ибо вы никак это не контролируете.
На что тут необходимо обратить внимание?
Скорость загрузки далека от возможностей канала и тарифного плана. Но повторюсь, это не абсолютный признак – может, просто сервер далеко или перегружен.
Верхний левый угол всегда содержит пик вверх, а следом яму. Вот это уже 100% признак ограничения скорости. Суть в том, что все ограничители настраивают по одной схеме: всегда есть какой-то объем данных, отдаваемых на максимальной скорости. Это очень помогает улучшить “отзывчивость” интернета. Следом яма – это ограничитель скорости понимает, что клиент вылез за границы и необходимо его “вогнать” лимиты. Высота пика и ямы может быть разная (сравните картинки выше) – это зависит от настроек шейпера.
“Расколбас” скорости дальше гораздо меньше, чем при нормальном скачивании. И он никогда не перепрыгивает первый пик. При “злых” ограничителях расколбас вообще исчезает.
Что можно сделать? Ну в общем-то только абсолютно банальные вещи:
Все-таки проверьте свое оборудование и условия, в котором оно работает. Как бы вы не были уверены, но и на старуху бывает проруха. Покачайте файлики локально, погоняйте тесты.
Смените сервер, откуда качаете. Совсем не факт, что выбранный (по расстоянию, национальной принадлежности и прочему) самый быстрый.
Пожалуйтесь в техподдержку провайдера. Может, вы просто чего-то упустили? Например, на всех “безлимитных” тарифных планах сейчас есть приписка мелким шрифтом, что можно скачать столько-то, а дальше либо скорость режут, либо вообще в инет не пускают. Вполне вероятен ваш случай.
Пожалуйтесь в соцсетях, с обязательным упоминанием провайдера. Это задействует совершенно другой канал коммуникаций с техперсоналом. Да, идиотизм, но это иногда работает
После какого-то обновления мой ноутбук стал плохо соединяться с Wifi. Ну как плохо… Регулярно стал терять сеть, ругаться на то, что не может соедениться и так далее и тому подобное. Так как у меня идет ремонт и я регулярно перетряхиваю сеть, то я грешил на точки доступа, линукс-сервер, выступающий роутером и на прочее, что могло повлиять.
Однако через некотрое время индеец зоркий глаз стал замечать, что на WiFi жалуется только ноутбук на Fedora. Windows, MacOS и андроиды и iOS цеплялись хорошо и никаких призывов не выдавали. И это бы продолжалось еще долго, но вчера линукс сказал “все, я больше не хочу соединяться с сетью”. Совсем.
Симптомы простые: ноутбук видит WiFi, соединяется, но через 45 секунд происходит тайм-аут DHCP и он отсоединяется. Установка статического адреса не помогает. Он перестает отваливаться, но пакеты никуда не ходят.
Проверка с помощью tcpdump показала, что в общем-то на это есть резоны: в канале было тихо. Причем настолько тихо, что даже запущенный с ноутбука ping не было видно. Тут я наконец-то понял, что проблемы именно на моей стороне.
Первым делом я решил, что проблема в сетевой. Воткнул USB, она со второго или третьего раза зацепилась. Тут бы мне насторожиться, но я пропустил этот момент. Начал играться с настройками WIFi на роутере. Ну так отключать/включать MIMO и прочее. Не помогло.
Включил точку доступа на телефоне. Ноутбук мгновенно прицепился и сообщил, что все в порядке.
То есть у ноутбука проблемы именно с моей точкой доступа. Стал разбираться. Ни каналы, ни смены настройки меш-сети – ничего не помогало. В веб-панели роутера я видел, что ноутбук соединяется и потом через некоторое время отваливается.
Так я сделал вывод, что железная часть работает. Дело в софте. И тут мне повезло запустить еще раз tcpdump как раз во время той самой паузы до таймаута. И внезапно я увидел бегающие туда-сюда пакетики, характерные для любой сети. Точно софт!
Стал разбираться. Оказалось, что добрые идиоты, пишущие Network Manager, где-то налажали в последних апдейтах и теперь мак-адрес меняется так, что он вводит сетевую в кому (или что-то еще в потрохах, но разбираться было лень). Ок, значит проблема простая: надо найти, где это выключается и дело в шляпе!
А вот тут возникла проблема. Оно нигде не выключается. Все найденные рецепты про wifi.cloned-mac-address и ethernet.cloned-mac-address не дали ровном счетом ничего. Повторяю: николай, иван, хартон, ульяна, яна. Так как дело было вечером, я решил не мучаться и вернуться на шаг назад. Говоря другими словами, вырубить нафиг NetworkManager.
Первым делом отвязываем wpa_supplicant от NM, хардкодим интерфейс и выключаем сам NM
Продолжаю делать записи для себя. На этот раз потребовалось отфильтровать роуты, отдаваемые другим. OSPF для этого не подходит: стандарт такого попросту не предусматривает. Значит, переключаемся на BGP. Минимальный конфиг для FRR
На другой стороне есть адрес 6.7.8.9, котрый не должен попасть на этот роутер.
!
ip route 6.7.8.9/32 10.1.0.254
!
router bgp 65000
bgp router-id 10.0.0.3
no bgp ebgp-requires-policy
neighbor 10.0.0.2 remote-as 65000
!
address-family ipv4 unicast
redistribute connected
redistribute static
neighbor 10.0.0.2 next-hop-self
neighbor 10.0.0.2 prefix-list nobad-out out
exit-address-family
exit
!
ip prefix-list nobad-out seq 5 deny 6.7.8.9/32 le 32
ip prefix-list nobad-out seq 10 permit 10.1.0.0/24 le 32
!
Проверяем
router2# show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
B>* 10.1.0.0/24 [200/0] via 10.0.0.3, ens19, weight 1, 00:16:06
ВНИМАНИЕ: правка “на живую” permit-list не приведет к перечитыванию правил на другой стороне. Надо вручную в router bgp прицепить-отцепить их. Почему так – хз.
Вариант лечения: не важно где сказать clear ip bgp 10.0.0.3 (ессно, на передатчике адрес приемника и наоборот), это сбросит сессию bgp и заставит перечитать роуты.
В целях покупки домика загорелось мне устроить видеонаблюдение. И чтобы потом как в фильмах “вот преступник, увеличь кадр. еще! ага, попался!”. У меня преступников не ожидается, но хотелку осуществить очень охота.
И в процессе погружения в мир видеонаблюдения оказалось, что все в нем совсем не так просто. Вернее наоборот, просто, но совершенно перпендикулярно сознанию обычного ИТшника.
В начале было самое простое: система будет аналоговая или цифровая? В пользу первой говорит ровно два фактора: сейчас она очень (подчеркиваю очень) дешевая и она базируется на отработанных решениях. Все давно изучено, вылизано и понятно. Самое простое решение: купить валяющийся на складе готовый комплект, раскидать кабеля и успокоиться.
Но у аналогов есть и минус: от каждой камеры нужен прямой кабель до регистратора. 16 камер? 16 линков на коаксиале. В общем, не мой размерчик от слова совсем.
Значит, цифровая. Тем более, что ethernet с wifi у меня точно будет в каждом угле.
Открываю браузер, иду в магазин и немного охреневаю от изобилия камер со всякими аббревиатурами. А цены скачут на три порядка. Что делать, куда бежать?
Первое условие “никаких облаков” сразу отсеивает большую половину камер. Эти камеры потому и дешевы, что сливают китайцам и корейцам все, что можно слить. Новомодным системам надо же на чем-то обучаться? Да и безопасность таких камер хромает на обе ноги – достаточно погуглить и вы обнаружите кучу кредов на любой вкус: хоть напрямую, хоть через “облако”.
А вот следующее условие я не смог внятно сформулировать. Слишком уж много было разноплановой информации. Поэтому я поступил старым проверенным способом: тупо накидал в корзину несколько камер разных производителей и с разной ценой, чтобы лично пощупать и оценить.
Пока камеры ехали, я принялся изучать, чем же их обслуживать. Или, говоря другими словами, DVR, NVR или ip-видеорегистратор. Тут я тоже сразу задрал планку “работает под linux, управление через браузер”. Казалось бы, софта на рынке дофига и больше – бери и пробуй.
Ан, нет. 99% софта – это откровенные поделки, лишь бы было. Особенно этим отличаются отечественные производители. Ни инструкций по настройке, ни поддержки чего-то более-менее распространенного… ничего вообще. Я ставил, смотрел, плевался и удалял. “серверные” версии, которые требуют qtgui? да легко!
Где-то тут приехали и сами камеры, сразу же добавив много интересных аспектов. Например, некоторые камеры сами по себе видеорегистраторы. Можно вставить sd карту, обрисовать зоны для детектора движений и вуаля – все заработает.
Но в итоге самым важным оказалось совершенно другое. Формат, в котором передается видео. MJPEG, H264 и самый моднявый, H265 с плюсиками и буквами на конце. Внезапно для меня это стало могильным камнем для 99,99% видеорегистраторов. Дело в том, что чем моднее формат, тем меньше он требует диска для хранения. В проспектах буржуев я встречал, что H265 S+ требует до 70% меньше места, чем H264.
В итоге с банальной задачей “смотри в камеры, если обнаружишь движение, пиши на диск” справился только один видеорегистратор – AgentDVR. Все остальные, включая широко известный ZoneMinder – тупо крешились, жрали проц и память и так далее и тому подобное. Отдавать им такую важную задачу – глупость высшего уровня.
Выше – скриншот с тестовой инсталляции AgentDVR. Три камеры – 4МП, 2МП и 2МП. Пишется по детектору движения. Как видите, за 11 дней сожрало 120 гигов. И процессор совершенно не нагружен. Было бы прелестно, если бы была хоть какая-то интеграция со сторонними системами. Нет, она вроде заявлена, но за помесячную денежку. Не подходит – я готов заплатить за софт, но единоразово.
Увидев подобные цифры потребления, я воспрял духом. Никаких петабайт на глубину в неделю не нужно – хватит и обычных объемов! А их, как вы понимаете, есть у меня!
Следующий шаг – это полностью “аппаратные” решения. Специализированные, заточенные на работу с камерами и только с камерами. Ну и за кучу (или не очень) денежек.
И тут очередная засада. Как выбрать видеорегистратор? Ни одна собака не пишет, сколько камер он может понятнуть. Вместо этого вовсю рекламируют, сколько потоков с каким разрешением он может одновременно отображать. Но мне-то это не надо…
Когда ко мне приехала очередная пачка железок, то тайна оказалась не такой-то уж и тайной. У каждого приличного видеорегистратора есть параметр “максимальный входной поток”. Он измеряется в мегабитах. И чтобы подсчитать, сколько камер потянет регистратор, надо просто принять “1 мегапиксел камеры = 1 мегабит на регистраторе”. И не смотрите, что 4МП камера выдает по сети всего 600-800 килобайт в секунду – это не те потоки, не итшные. В итоге для трех камер на 4, 2 и 2 мегапикселя нужен регистратор, умеющий переваривать поток в 9+ мегабит. Почему не 8? Оставьте небольшой процент на всякие просадки, усушки и утруски.
С дисками вообще все просто: подойдет абсолютно любой. Но если деньги есть, то надо взять именно для систем видеонаблюдения. Во-первых, они все медленные, 5200, а значит холодные и тихие. А во-вторых, в них льется спецпрошивка, которая оптимизирована для постоянной записи в кучу потоков. Мелочь, но по словам бывалых, на нагруженных системах увеличивает срок службы с года до трех практически гарантированно.
Вот мой, купленный на пробу от tiandy. Два диска, 200МБ входного. Усб справа для ориентира в размерах.
Сами регистраторы тоже разные. Самые простые умеют просто писать поток с камеры на диск. Платы таких на али можно найти от 1500 рублей. У регистраторов покруче добавляется возможность писать на внешние диски, в случае каких-то событий отправлять письма, включать что-то внешнее и прочее подобное.
И тут меня настигла первая засада: у “дешевых” регистратов вся аналитика (распознование человек-машина, границы и так далее) ложится исключительно на камеры. Если камера не умеет (или железка не знает про возможности камеры) – то регистратор напишет “ой, и я тоже не могу”. Вот мой, к примеру, не может.
Вторая засада та же, что и с отечественными: документации нет. Вообще. Пара-тройка страничек с общими телодвижениями и все. Поначалу я думал, что это мне так повезло. Но нет, даже у хваленого HikVision та же фигня.
Значит что? Оставляем текущую мешанину работать, набираться опыта и приступаю к тестированию регистраторов под windows. Причем, раз аппетит пришел, с особым упором на аналитику, ибо задача простой записи по движению решена аж двумя способами.
Я как-то привык к заикающемуся и запинающемуся звуку внутри виртуалки. Ну сколько не пробовал разных рецептов, помогали … не очень. А тут внезапно выдался свободный часик и я решил немного погуглить. Оказывается, проблема известная, только не все знают про ее решение.
Скопировал файлик, заменил значения … и вуаля! Звук снова в наличии.
В предидущем посте я прошелся по библиотеке и расставил везде теги и обложки. Но теперь надо решить другую проблему: у меня есть mp3, m4a и flac файлы. Причем я точно знаю, что некоторые flac и m4a получены из mp3. Да, источники музыки были не всегда адекватными …
Поэтому шаг номер раз: приводим всю библиотеку в mp3 формат. То, что из m4a и flac перезапишутся mp3 – пофиг
Теперь можно грохнуть “оригиналы”. И совсем маленький шаг: необходимо избавиться от дубликатов. Так как источников было много, то и для некоторых популярных песен было аж до 5 вариантов. Пишу маленький скрипт, который удаляет все дубликаты меньшего размера (да, буду считать, что бОльший размер означает лучшее качество).
#!/bin/bash
IFS=$(echo -en "\n\b")
function traverse() {
# lets find copies in directory and i dont want use .m?? in search
for file in $(ls -1 ${1} |grep -e \(1\).mp3 -e \(2\).mp3 -e \(3\).mp3 -e \(4\).mp3 -e \(5\).mp3)
do
l="${1}/${file%????????}*" # cut (X).mp3 from file name
# delete all files except first and biggest
ls -1S ${l} | tail -n +2 | xargs -d '\n' rm -f
# Now rename file. Leave mv alone for errors "the file is same" - its working indicator for me :)
ffin="${l%?}.mp3"
mv $l $ffin
done
# now lets find another directory to deep in
for file in $(ls "$1")
do
if [[ -d ${1}/${file} ]]; then
traverse "${1}/${file}"
fi
done
}
function main() {
traverse "$1"
}
main "$1"
И натравливаем его на библиотеку. Я специально не стал обрамлять вокруг mv, что бы хоть что-то выводило во время работы, поэтому сообщения типа mv: '/mnt/swamp/Reloaded//松居慶子/Dream Walk/04 Fire in the Desert.mp3' and '/mnt/swamp/Reloaded//松居慶子/Dream Walk/04 Fire in the Desert.mp3' are the same file стали для меня индикатором, что скрипт работает.
В результате у меня теперь есть библиотека музыки, где все разложено по полочкам (иногда полупустым), протегано и с обложками. Но (ох уж это но) есть куча песен с битрейтом 96 и 128 кбит/с. Но как к этому подобраться автоматически – я пока не представляю.
Довольно долго я таскаю с собой архив музыки. Первые треки в нем датируются аж 1995 годом. Естественно, что за все это время внутри образовалась каша. Я много раз пытался подойти к этой свалке, что бы разгрести ее содержимое и разложить все по полочкам. Однако регулярно обламывался из-за банальной лени: все-таки раскидать почти 100 тысяч файлов нужно адское терпение.
Ситуацию усложняло то, что куча файлов имело очень говорящие названия типа 3.mp3. Естественно, каких-либо тегов тоже ожидать не приходилось. Ну вот просто как-то понравилась мне песенка, я ее и забросил в архив …
Наконец в очередной раз я подошел к этой свалке. Тыкался, тыкался, смотрел на всякие редакторы тегов и горестно вздыхал. Пока не решил погуглить, как можно для всего этого поиспользовать всякие шазамы и прочие новомодные (почти) штучки. И вуаля!
Оставлю эту ссылку отдельной строкой. Жрет mp3, ищет по аудиотпечатку что же это за трек и заполняет теги, добавляет обложку и раскладывает получившееся красиво. Я в совершеннейшем восторге. На тестовой выборке в 7 тыщ файлов не нашла соответствие только для 3. Но их никто не знает, ни яндекс, ни яблоки. Мелочь …
Внезапно пришла уведомлялка: дескать, дорогой товарищ, ваше время истекло, заплатите еще 10 баксов за следующий год.
Не то, что бы мне жалко денег, но заводить какой-то странный bitcoin кошелек на не менее странных биржах мне стремно. А оплата карточкой через paypal не доступна, ибо они поддерживают нацистов и типа санкции.
Сначала я подумал поднять свой сервер для него, благо есть аж два варианта. Но реально, как-то стало очень лень. Решил попробовать KeePassXC. Нашел репу https://github.com/davidnemec/bitwarden-to-keepass, сделал три шага по мануалу и вуаля – оно все заработало и заработало подозрительно легко. И даже клиент не такой вырвиглазный, каким я его помню …
Не так давно некоторые (я не буду показывать пальцем) провайдеры начали заниматься херней. А именно блокировать или подменять DNS ответы. И ладно бы блочили какой-нибудь абстрактный facebook.com, так они ломают к примеру резолвинг обратных записей, что например для почтовых серверов больно и печально. Если обратиться к техподдержку, то там начинают лепетать про защиту от угроз и предлагают пользоваться серверами провайдера, ведь они защищены и вообще лучше всех.
В общем, на данный момент это все лечится очень просто. Берем любой клиент DNS over HTTPS (DoH), ставим его и направляем весь днс трафик через него. Для ubuntu рецепт следующий:
В результате на 127.0.2.1:53 появляется DNS сервер, который кладет всевозможные причиндалы на провайдерские потуги. Ну а дальше во всех клиентах просто указываем этот сервер. Лично я просто добавил одну строчку на главном домашнем кеширующем bind
mail.ka12.co замените на свой домен. Принцип простой – сначала любым привычным способом получаете сертификат через LE, а потом запуская скрипт выше засовываете сертификат в zimbra
