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 сек. 

Ubuntu 20.04 + Podman: error "potentially insufficient UIDs or GIDs available in user namespace" when trying to run a container

Проблема

При попытке запустить контейнер с помощью Podman появляется ошибка:

Error: writing blob: adding layer with blob "sha256:...": Error processing tar file(exit status 1): potentially insufficient UIDs or GIDs available in user namespace (requested 110779:100 for /usr/local/lib/node_modules/@stoplight/spectral/node_modules/optionator/CHANGELOG.md): Check /etc/subuid and /etc/subgid: lchown /usr/local/lib/node_modules/@stoplight/spectral/node_modules/optionator/CHANGELOG.md: invalid argument

Причина

На эту тему есть отличная статья https://www.redhat.com/sysadmin/rootless-podman, в двух словах - причина в том, что UID 110779, используемый в docker-образе, не может быть смапплен в хост-ОС из-за того, что он больше, чем 65536.

Решение

Правим на хост-ОС файл /etc/subuid, заменяя для пользователя, из-под которого запускается podman, ограничение 65536 на другое, большее чем UID, фигурирующий в ошибке, например:

aspirinspb:100000:165536