Logitech Options+ за прокси

Обычная версия Logitech Options+ отказывается корректно работать за корпоративным прокси: установка проходит успешно, однако проверка обновлений, а также загрузка информации о девайсах не работает, в итоге ни один девайс добавить не получаестя. Решение - использовать оффлайн-установщик, он не требует подключения к интернету для загрузки информации о девайсах: https://prosupport.logi.com/hc/en-us/articles/10991109278871-Logitech-Options-Offline-Installer. 

gitleaks ломает мердж в Idea

Проблема

Пытаюсь смерджить две ветки в IntelliJ Idea, после разрешения конфликтов появляется уведомление:

В итоге мердж можно только откатить. Причина ясна - gitleaks нашел какую-то уязвимость в коде, который мерджится. Но что если это false-positive и мы хотим все же смерджиться?

Решение

Идем в .git/hooks/pre-commit, там комментим вызов gitleaks:

#"C:\Program Files\Git\gitleaks.exe" protect -v --staged

После мерджа строчку можно раскомментить обратно. 

Linux Mint: ноутбук засыпает при отключении внешнего монитора при закрытой крышке

Проблема

Ноутбук с Linux Mint работает с закрытой крышкой и внешним монитором. Стоит отключить внешний монитор (точнее, я просто переключаю монитор на другой ноутбук через KVM Switch), ноутбук уходит в сон, хотя в настройках питания стоит "ничего не делать" по закрытию крышки (собственно, по закрытию крышки он и не засыпает).

Решение

В файле /etc/systemd/logind.conf строчки:

#HandleLidSwitch=suspend
#HandleLidSwitchExternalPower=suspend

заменяем на 

HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore

И делаем:

sudo service systemd-logind restart

Spring Boot with Gradle in IntelliJ Idea: profiler cannot connect to the application

When I'm trying to profile my Spring Boot application, built with Gradle and run with :bootRun, in IntelliJ Idea, I face the following error:

"Cannot connect to target JVM. Exception creating connection to: 192.168.x.x; ..."

The reason is obviously in the fact, that IntelliJ tries to use my IP from the network card instead of localhost. 

To change that, in my build.gradle I configured the bootRun task in the following way:

bootRun {

    jvmArgs('-Djava.rmi.server.hostname=localhost')

}

Linux Mint и TP-link Archer T4U v3

Годы идут, а установка драйверов для некоторого железа в Linux все также периодически требует нетривиальных действий. Актуальный на июнь 2024 года Linux Mint "из коробки" не видит внешний WiFi-адаптер TP-link Archer T4U v3. Официальных драйверов под актуальные ядра Linux производитель не предоставляет, приходится делать следующее:

sudo apt install git dkms
git clone https://github.com/cilynx/rtl88x2bu.git
sudo dkms add ./rtl88x2bu
sudo dkms install rtl88x2bu/5.8.7.1 

После - перезагрузка. 

Установка дополнений в OpenLens вручную

Иногда невозможно воспользоваться автоматической установкой дополнений в OpenLens, например, если из OpenLens нет доступа в интернет. Тогда можно сделать следующее (в примере я устанавливаю дополнение @alebcay/openlens-node-pod-menu):

npm pack @alebcay/openlens-node-pod-menu

В папке появится tgz-архив, и вот его уже можно установить через выбор файла вручную в меню Extensions в OpenLens.

initialDelaySeconds в Kubernetes Probes

В Kubernetes для probes (например, readinessProbe) есть параметр initialDelaySeconds, предназначенный для того, чтобы дать контейнеру некоторое время на инициализацию, прежде чем Kubernetes начнет выполнять ту или иную probe.

Можно подумать, что этот параметр буквально задает "отсрочку" для начала выполнения той или иной probe. Т.е., к примеру, в такой конфигурации:

          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: http
              scheme: HTTP
            initialDelaySeconds: 20
            timeoutSeconds: 5
            periodSeconds: 15
            successThreshold: 1
            failureThreshold: 5

можно ожидать, что первый раз probe будет выполнен через 20 сек после запуска контейнера, потому что в initialDelaySeconds указано 20. 

Однако, это не так. Отсчет периодов для выполнения probe начинается в момент запуска контейнера вне зависимости от того, установлен ли initialDelaySeconds или нет. Т.е. probe будет запланирован на запуск в 0сек, 15сек, 30сек, 45сек и т.д. начиная от момента запуска контейнера. То, что initialDelaySeconds равен 20, приведет лишь к тому, что те попытки выполнить probe, которые попадут в эти первые 20сек, будут пропущены:

Таким образом, первый раз readiness probe сработает не через 20 сек после запуска контейнера, а через 30 сек.