Давняя проблема была – с момента покупки нового ноута, наверное, когда установил туда Debian 9, где уже подтянулся и Pulseaudio со всякими там systemd – так вот, помимо традиционного “пш-ш-ш” вместо звука, которое как-то само по себе появилось, а потом так же само пропало, была еще проблема с микшированием звука от разных приложений.
Munin, NTP и IPv6
Такая себе заметка на тему…
Давно, в принципе, на хостах на сервере раскидан munin-node, строятся графики и все такое. Разве что местами не строились графики для сдвига ntp относительно мирового времени. Но график некритичный, так что не обращал внимания. Сейчас решил копнуть и найти разницу между хостами.
Разница в /etc/hosts – в тех случаях, где график был, не было записи ::1 localhost и обращение на локальный ntpq шло исключительно через ipv4. А вот запрос по ipv6 вешался и данные не отдавались. Может, конечно, удаление localhost для ipv6 не вполне корректный фикс, но – работает.
Снова немного iptables’а, на сей раз со вкусом IPv6
Еще один косяк словил при непродуманной работе с iptables’ом. В interfaces у меня описан 6to4-адрес – думаю в будущем использовать ipv6 на хостах, но пока повесил его только на внешний интерфейс сервера.
Глянув снаружи на адрес, увидел, что службы NFS-сервера теперь прекрасно видятся с внешнего мира. Решил это запретить через ip6tables -P INPUT DROP. Сделал, проверил – все ок, лег спать.
Наутро заметил, что в munin с dom0 один из графиков оборвался – график сдвига времени в ntp относительно мирового.
Что произошло: все осталось работать, так как работает через ipv4 и там правила корректно прописаны. Плагин ntp_kernel_pll_off дергает ntpq, который пытается обратиться к местному ntpd прежде всего по ipv6-адресу, видя, что тот слушает и ipv6-сеть. В итоге обламывается, так как политика для INPUT подразумевает отброс вообще любого входящего трафика, в том числе и для localhost’а, если не задано другое.
В общем, надо быстрее осваивать IPv6 и уже корректно оформлять все правила с учетом двух стеков 🙂
Пофиксил глючащий DHCP на сервере
(На самом деле нет) (с)
Собственно, сам по себе DHCP не глючил, путаница возникла из-за особенностей правил iptables. Я получал IP-адрес устройством один раз, а потом DHCP-сервер (поставил udhcpd) переставал откликаться на запросы. Грешил на udhcpd, думал ставить полноценную версию; временно использовал Tp-link 6020 как DHCP-сервер и так далее. Проблема оказалась немного в другом месте 🙂
Потребление в серверной
Заметка по потреблению нового железа:
- Примерно 32W уходит сейчас на полностью погашенной UPS’ке на заряд аккумуляторов. Почему так много – не знаю; на батареях 27.2V – т.е., заряд на 100%
- При включении UPS потребление 34.2W – т.е., собственное потребление UPS примерно 2.2W
- При подключении блока питания от сервера, который не подключен к серверу, потребление возрастает до 35.3W – т.е., блок сам по себе потребляет около 1W. Не сильно хороший КПД холостого хода, но уж как есть.
- Свич Tp-link TL-SG1016PE с подключенными к нему Xiaomi Mi Wifi 3G и GPON-модемом – 52.3 по ваттметру – т.е., 17W на все. При этом устройства, подключенные к PoE, судя по админке, потребляют в сумме 6.4W – 2.3W на модем и 4.1W на Xiaomi – т.е., собственное потребление свича около 10.5W. Примерно сходится с тем, что мерял на холостом ходу – там было 9.5W без подключенных кабелей и ближе к 10 при подключении какого-то устройства.
- Вместе с сервером на базе Gigabyte j4005n d2p, 8 ГБ DDR4 и 2 HDD на 1 ТБ – Hitachi HTS721010A9E630 – после загрузки ваттметр показывает 65-66W, изредка просаживаясь до 64.5. Итого потребление сервера порядка 13W.
Следовательно, критичной нагрузки у нас только на 10.5 (свич) + 13 (сервер) + 2.3 (модем) = 25.8W + 4.1 (wifi-точка) = 30W
Восстановление Biostar H61B
Пришлось тут по случаю помогать товарищу восстанавливать материнскую плату Biostar H61B. Возникла проблема с BIOS’ом из-за использования pci-e-хаба – уж не знаю, что там накосячили в BIOS’е разработчики в Biostar’е, но при попытке воткнуть 7-ю видеокарту через хаб в материнку BIOS окирпичивался и материнка переставала запускаться; сброс не помогал. Проблема популярная и, хоть сам не сталкивался, уже читал про это в Интернете ранее.
Впечатления о Tp-link TL-SG1016PE
Как уже упоминал ранее, купил себе новый управляемый свич на 16 портов – Tp-link TL-SG1016PE. Старого TL-SG2008 уже по портам хватало впритык с учетом увеличившегося парка машин (да и то еще не все подключено), а когда добавлю камеры наблюдения, то и вовсе портов не будет хватать.
Открыл для себя “оптимизаторы нагрузки”
Сабж. В “Эпицентре” при покупке всякого-разного для щитка в отделе электротоваров заметил интересный девайс – нечто, похожее на разветвитель на 2 розетки.
Ценника не было, но на упаковке прочитал краткое описание. Устройство оказалось “умным”: могло коммутировать одну из нагрузок в то время, когда другая нагрузка не работала. Как пример – бойлер и стиральная машина, подключенные в одну розетку. Штатно работает бойлер, но если включилась стиралка – бойлер отключается на время ее работы. В целом, достаточно полезный девайс при жестком ограничении по мощности (спасибо “Облэнерго”), недостаточно толстой проводке или по каким-то внешним причинам (например, сильные просадки сети без отключения автомата при большой потребляемой мощности – что, в принципе, родственно варианту с тонкой проводкой, но в глобальном масштабе).
Еще немного о щитке для серверной
Из нового для себя – обзавелся коммутатором фаз. В доме 3 фазы, но сеть бывает нестабильна; возможно отключение одной из фаз из-за реле напряжения в главном щитке в силу кратковременных просадок. Ну или по любой другой причине. Данный девайс по мере сил решает проблему.
Перешел на NFLOG в iptables
Решил добить проблему спама iptables’ом отброшенными пакетами системных логов. Логи сами по себе полезны (правда, стоит провести реорганизацию), но разрастаются до совсем уж неприличных размеров.