Через несколько итераций цикла “заблокировал – снова заработало” стало понятно что этот бой не в мою пользу. Следующей идеей был свойский DNS-сервер (и отключение DoH) – сервер должен для некоторых ресурсов возвращать адрес заглушки. Выглядело просто, тем более в прошлом уже приходилось работать с bind и powerdns. В процессе поиска современных альтернатив ВНЕЗАПНО обнаружил, что интернет уже давным давно придумал кучу сервисов, построенных на той идее – прописываешь у себя сервисный сервер (вместо провайдерских) и получаешь контроль над всеми  DNS-запросами + статистику и различные плюшки. Стоимость услуги не оставляет шансов на творчество, лень сдалась готовому решению.

Около полугода пользования сервисом принесли не только контроль над “проблемным” участком сети, но и кучу новых по тем фронтам, где проблем раньше не наблюдалось – сервис блокирует всякое непотребное (по его мнению), даже то, что явно не просили. Это можно было бы решать настройкой “стандартного” DNS на устройстве, которое не требуется контролировать. Но далеко не каждое устройство позволяет себя настраивать (да и чего уж там – не у всех устройств есть экран для того чтобы хотя бы узнать текущие настройки).

Когда старинный роутер был заменён на чуть более современный я вспомнил о проблеме с DNS и решил зайти слегка с другой стороны – не “мучить” все устройства тотальным контролем, а выдавать кастомный dns только “провинившимся” клиентам. И оказалось, что dnsmasq, который используется в прошивке нового роутера это позволяет: к mac-адресам привязываются теги, к тегам – кастомный опции DHCP, в моём случае dns-server.

dhcp-host=00:00:00:00:00:00,DeVice01,172.16.128.73,infinite,set:managed
dhcp-option=tag:managed,option:dns-server,9.9.9.9

В результате все довольны (ну кроме тех, которые недовольны), всё работает либо так как всем надо, либо не работает так как надо мне.

Т.к. обновлять уже нечего, релиз свежее некуда, то нужно как-то “дотянуть” до фикса своими силами. Т.е. нужно автоматически “рестартовать” драйвер карты после выхода из гибернации. “Решение” странное, но другого не гуглиться. И вроде бы понятное, но дело ВНЕЗАПНО осложняется тем, что прямо во время обновления были удалены pm-utils с помощью которых ранее уже доводилось реагировать на события по питанию. Все, что удалось нагуглить так или иначе ведёт либо в мануал к systemd, либо к pm-utils, но в дистрибутиве ни того, ни другого нет.

Были попытки запуска скрипта с acpid, crontab (@restart) и ещё несколько тупиковых идей, но поиск неожиданно привёл на страницу changelog-а дистрибутива, в которым тёмным по светлому было написано: ConsoleKit2 is gone, replaced by elogind (which also takes over for
cgmanager and pm-utils).

Правильным ответом оказался elogind. Однако и тут ждал небольшой сюрприз – мануал велит использовать /lib/elogind/system-sleep для своих скриптов, однако её не существует. Если же создать, то скрипты в ней не выполняются. Помогло изучение сборочного скрипта для пакета elogind – оказалось, что не /lib, а /lib64… (Патрик, ну как так-то ?).

Итого:

#!/bin/bash
# put this at /lib64/elogind/system-sleep/reload_r8169
if [ "$1/$2" = "post/hibernate" ]
then
        rmmod r8169;
        modprobe r8169;
fi

Костыли надёжно приварены к велосипеду, можно выживать дальше. “Такой день” (ц)

[19099:19099:0818/132537.104960:ERROR:browser_dm_token_storage_linux.cc(100)] Error: /etc/machine-id contains 0 characters (32 were expected)

Делаю:

cat /etc/machine-id
cat: /etc/machine-id: No such file or directory

Удивляюсь, иду гуглить.

Нахожу описание machine-id, внизу мелким шрифтом указано:

The simple configuration file format of /etc/machine-id originates in the /var/lib/dbus/machine-id file introduced by D-Bus. In fact, this latter file might be a symlink to /etc/machine-id.

Ясно всё.

# ln -s /var/lib/dbus/machine-id /etc/machine-id

if (version_compare($low_ip, $ip) + version_compare($ip, $high_ip) === -2) {
    echo "in range";
}

Это как стереокартинки – увидеть в 127.128.129.130 “PHP-standardized” version number strings дано не каждому…

Не спешите отправлять несчастного клиента в “обратитесь к вашему администратору”, попробуйте поискать проблему “в себе”:

• при наличии ipv6 адреса на вашем сервере – убедитесь в том, что адрес корректно указан в конфигурации используемого веб-сервера (в противном случае клиент может попадать в “умолчальный” server/VirtualHost); проверьте правильно ли указан адрес в DNS (запись типа AAAA) – в противном случае клиент попадает на чужой сервер или не попадает никуда.
• если адреса ipv6 на вашем сервере нет – убедитесь в том, что в DNS нет записи с типом AAAA

P.S.  
Здесь могла бы быть реклама сервисов вроде host-tracker.com, которые при удачном стечении обстоятельств могут “проявить” проблему. Но её не будет.

Обнаружил “странный” код, который судя по офф. документации работать так как ожидал автор не должен:

$filtered = filter_var($raw, FILTER_VALIDATE_INT,  array('flags' => FILTER_NULL_ON_FAILURE));

В документации флаг FILTER_NULL_ON_FAILURE указан только для фильтра FILTER_VALIDATE_BOOLEAN. Странно конечно, но это не единственная странность в php вообще и в filter в частности. Документированная странность… Однако код работает именно так, как ожидал автор – возвращает null если $raw не прошёл валидацию. И не только для INT – STRING, FLOAT… IP. В общем все проверенные фильтры возвращают нулл_он_файлуре.

Ну ок, значит автор не совсем… Но возможно что-то поправили в свежих версиях php и забыли обновить документацию? Может расчитывать на такое поведение не стоит? Оказывается это работает минимум с версии 5.2.1.

Не доверяй и проверяй…

Лавров кратко прокоментировал ситуацию, но цитировать его – преступно…

Особенно ВНЕЗАПНЫМ это “открытие” делает то, что настройка описана прямо в changelog mod_dav_svn, но кто ж его читает, правда?

В httpd.conf необходимо добавить:

SVNAllowBulkUpdates Prefer

Это решает проблему с “новыми” клиентами и не ломает работу “старых”.

Конечно “на ходу” загружать/выгружать xdebug не получится, но можно заранее запустить два процесса – один “production”, второй – с загруженным xdebug. Остаётся вопрос – как между ними переключаться ?

Первая мысль – сделать виртуальный хост со специальным именем  (https://debug.site.dev) или на отдельном порту (https://site.dev:9999/) . Однако это “не работает” в реальной эксплуатации – просто неудобно переходить на другой сайт и долго и нудно воссоздавать клиентское “окружение” в котором возникла проблема, требующая вмешательства с отладчиком. Хочется столкнувшись с ситуацией из которой без отладчика не выпутаться просто нажать на кнопку и “нутро” следующего http-запроса уже наблюдать в IDE (как и происходит обычно, когда xdebug постоянно загружен).

В общем  отдельная кнопка не нужна – существующие “xdebug helper-ы” к браузерам работают просто – при включении отладочного режима они устанавливают на текущем домене cookie с именем XDEBUG_SESSION. Эта же cookie поможет отделить “отладочные” запросы от “рабочих”.

Итак решение – запускаем два php-fpm на разных портах, один из них с загруженным xdebug, nginx в зависимости от наличия “отладочной” cookie проксирует запросы к разным upstream c php-fpm:

#nginx.conf

upstream php72 {
    server 127.0.0.1:9000;
}

upstream php72-xdebug {
    server 127.0.0.1:9001;
}


server {
    server_name site.dev;
    set $phpfpm "php72"; # по умолчанию запросы к "боевому" php
    if ($http_cookie ~* "XDEBUG_SESSION=.+") { # есть отладочная cookie?
        set $phpfpm "php72-xdebug"; 
    }

    if ($args ~* "XDEBUG_SESSION_START=.+") { # есть отладочный параметр в QUERY_STRING?
        set $phpfpm "php72-xdebug"; 
    }
    ...


    location ~ ^(.+\.php)(.*)$ {
        ...
        include fastcgi_params;
        fastcgi_pass $phpfpm;
    }

}

Для начала нужно создать туннель и организовать прокси-сервер:

ssh user@server -D1080 -f -N
Здесь:
* -D1080 – создаёт socks-прокси по адресу 127.0.0.1:1080
* -f -N – открывает соединение с ssh-сервером, но не открывает shell, отправляет процесс в фоновый режим

Затем создать конфигурационный файл для настройки proxy в браузере:


// ~/proxy.pac
function FindProxyForURL(url, host) {
// в chrome alert можно увидеть перейдя по ссылке chrome://net-internals/#events
// alert("url: " + url + ", host: " + host); // полезно для отладки в процессе настройки
if ( shExpMatch(host, "*.private") // все домены в "зоне" private
|| dnsDomainIs(host, "private-resource.local") // конкретный сайт private-resource.local
|| isInNet(dnsResolve(host), "172.16.0.0", "255.240.0.0") // любой ip в указанной сети (доступный вам резолвер должен знать про закрытую сеть)
) {
return "SOCKS 127.0.0.1:1080";
}
return "DIRECT";
}

Внутри синтаксически правильное подмножество javascript-а, на котором написана единственная функция FindProxyForURL, её задача – вернуть строку подключения к прокси (в данном случае – SOCKS) или “DIRECT”, если необходимо подключаться напрямую.

Затем в настройках браузера (в системных настройках) указываем путь к созданному файлу в качестве Proxy auto configuration url.

Теперь перечисленные в PAC-файле ресурсы доступны через локальный браузер.

Подробнее:
* Proxy auto configuration
* Функции доступные в PAC-файле
* autossh, если доступ к ресурсам нужен постоянно.