Установка NanoVNA-Saver в Debian 13

Понадобилось снять характеристику с самодельного аттенюатора и для этого хотел использовать приложение NanoVNA-Saver которое есть в репозитарии Debian 13. После установки оказалось что оно не запускается из-за неверно указанных зависимостей для пакета (подробности в #1123607).

Чтобы приложение запустилось нужно дополнительно установить несколько библиотек

$ sudo apt-get install -y python3-pyside6 python3-pyside6.qtcore python3-pyside6.qtgui python3-pyside6.qtwidgets

После этого приложение запускается и работает

Отключение кеширования метаданных для сетевых дисков в Windows

На рабочем ноутбуке у меня стоит Windows как корпоративный стандарт, но основная работа происходит в Linux который установлен в VirtualBox. Такой подход у меня появился давно, когда ещё в Windows первый WSL был нестабилен и несколько попыток перейти на него провалились. К слову и WSL2 которым уже можно вполне пользоваться меня не устраивает из-за меньшей производительности.

Все рабочие файлы лежат в виртуальной машине и к Windows подключены в виде сетевого диска Samba (настройки я описывал тут). После обновления на Windows 11 я заметил что изменения, которые сделаны со стороны виртуальной машины долгое время не видны в Windows. Приходилось создавать новый файл и затем удалять его, но всё не доходили руки поправить эту проблему.

Сегодня терпение лопнуло и был сделан беглый поиск решения который вылился в несколько строчек для редактора реестра 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
"DirectoryCacheLifetime"=dword:00000000

После внесения в реестр нужно перезапустить службу workstation 

net stop workstation
net start workstation

Или перезагрузить весь компьютер для надёжности.

Подробности можно почитать по ссылкам:

• Windows 11 file reading corruptions
• SMB2 Client Redirector Caches Explained 

Добавить метку времени к событиям в Kubernetes

 Если по какой-то причине нет доступа в панель мониторинга Kubernetes кластера, но нужно знать в какое время происходит определённое событие, то есть простой способ сделать это

$ kubectl -n default get events -w | ts
Dec 24 09:39:13 LAST SEEN   TYPE     REASON              OBJECT                        MESSAGE
Dec 24 09:39:13 15s         Normal   Scheduled           pod/debug-658b996798-52g2g    Successfully assigned default/debug-658b996798-52g2g to aks-workerf1f9-29801352-vmss000003
Dec 24 09:39:13 14s         Normal   Pulling             pod/debug-658b996798-52g2g    Pulling image "nicolaka/netshoot"
Dec 24 09:39:13 14s         Normal   Pulled              pod/debug-658b996798-52g2g    Successfully pulled image "nicolaka/netshoot" in 237ms (237ms including waiting). Image size: 207893848 bytes.
Dec 24 09:39:13 14s         Normal   Created             pod/debug-658b996798-52g2g    Created container: netshoot
Dec 24 09:39:13 14s         Normal   Started             pod/debug-658b996798-52g2g    Started container netshoot
Dec 24 09:39:13 15s         Normal   SuccessfulCreate    replicaset/debug-658b996798   Created pod: debug-658b996798-52g2g
Dec 24 09:39:13 15s         Normal   ScalingReplicaSet   deployment/debug              Scaled up replica set debug-658b996798 from 0 to 1

Dec 24 09:39:26 0s          Normal   ScalingReplicaSet   deployment/debug              Scaled down replica set debug-658b996798 from 1 to 0
Dec 24 09:39:26 0s          Normal   Killing             pod/debug-658b996798-52g2g    Stopping container netshoot
Dec 24 09:39:26 0s          Normal   SuccessfulDelete    replicaset/debug-658b996798   Deleted pod: debug-658b996798-52g2g

Я раньше не знал про утилиту "ts" из пакета moreutils и узнал о ней из вопроса на stackoverlow. Забавно что больше откликов набрал другой вариант ответа на вопрос.

Глюки паяльной станции Silverflo 982-I

В прошлом году приобрёл себе паяльную станцию Silverflo 982-I (она же Yihua 982-I) на жалах C245. За год использования несколько раз видел как она глючила при длительной пайке в режиме ожидания, если установленная температура выше 300 °C (температура начинала расти выше установленной когда паяльник находился в подставке). Решалось это выключением/включением обратно и работа продолжалась.

Вчера это поведение повторилось и дополнительно появилась ошибка "S-E" (скорее всего сокращение от Sensor-Error, но я не уверен).

Поискал распиновку для жала C245 и для начала измерил сопротивление нагревателя чтобы проверить что проблема не в жале

Когда не хватает розеток

Надоело постоянно переключать вилки в удлинителе на рабочем столе когда нужно поработать с генератором сигналов, развязывающим трансформатором или паяльником. Изначально на столе был удлинитель на 6 розеток (что-то бюджетное от Defender), но за пару месяцев активного использования у него прикипела кнопка включения и он перестал выключаться.

Покупать аналогичный удлинитель на замену смысла не было, т.к. качество будет не лучше. Решил собрать себе блок на 12 розеток и добавить к нему фильтр помех, предохранитель и выключатель с запасом.

В хозяйственном магазине взял три накладные розетки для помещений

Внутрянка у них так себе, но лучше того что я видел в потрохах удлинителя от Defender.

Не видел раньше такие подпружиненные контакты и не знаю насколько они надёжные, но вилка входит плотно

NetworkManager перестал принимать одинаковый IP для проводной и беспроводной сетей

Подключил проводную сеть к ноутбуку для обновления OpenWrt в домашней Wifi сети и заметил что NetworkManager долго "крутит" иконку настройки нового подключения в трее. Полез в логи посмотреть что там происходит и нашёл такое

Dec 13 11:29:34 XXXXXXXXXX NetworkManager[978]: <warn>  [1765614574.8401] device (enp0s31f6): IP address 192.168.XX.XX cannot be configured because it is already in use in the network by host XX:XX:XX:XX:XX:XX
Dec 13 11:30:04 XXXXXXXXXX NetworkManager[978]: <warn>  [1765614604.9456] device (enp0s31f6): IP address 192.168.XX.XX cannot be configured because it is already in use in the network by host XX:XX:XX:XX:XX:XX

Т.е. он отказывается назначить IP адрес, который ему выдал DHCP сервер, т.к. этот адрес уже используется на беспроводном интерфейсе.

Тут нужно сделать пояснение что такое назначение адресов сделано намеренно и одинаковый IP выдаётся на проводной и беспроводной интерфейсы (не все DHCP сервера позволяют делать такое). В настройках маршрутизации у интерфейсов разный приоритет и при наличии подключения через проводную сеть будет использоваться она, а при отключении пакеты идут через беспроводной интерфейс без разрыва соединений.

Distribution не работает через workload identity в Azure

 Довольно долго провозился с настройкой distribution в Azure через workload identity в AKS который не хотел работать.

Сама настройка простая:

• аннотация на сервис аккаунт в кластере (azure.workload.identity/client-id)
• метка на под (azure.workload.identity/use: "true")
• настроить конфигурацию в distribution

  storage:
    azure:
      accountname: accountname
      container: containername
      credentials:
        type: default_credentials
  

Но в лог валится ошибка "403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature."