GitLab CI не выполняет after_script при таймауте

На днях столкнулся с очень старой проблемой (открыта 6 лет назад) в GitLab CI когда after_script не выполняется если джоба отвалилась по таймауту. В моём случае в after_script реализован сбор логов эфемерного окружения для end-to-end теста. Ирония в том что при успешном прохождении теста эти логи, как правило, никто не смотрит. А вот если тест упал, то начинают разбираться, а логов нету...

Первой мыслью было внедрить контроль времени в сам сценарий тестирования, но это не всегда бывает удобно или возможно. Например при нехватке ресурсов в кластере значительно возрастает время ожидания установки чартов и считать время придется придётся после каждой команды которая потенциально может стать "долгой".

Второй мыслью был timeout из coreutils:

$ timeout --kill-after=350s 300s ./test.sh

В принципе эта утилита не должна оставлять "осиротевших" процессов, но если запуск происходит вне контейнера, то дополнительно можно добавить systemd-run:

$ timeout --kill-after=350s 300s systemd-run --user --pty --same-dir --wait --collect ./test.sh

На следующей неделе попробую внедрить в один из проектов и посмотреть.

Выборка данных из CSV файла

Нужно обработать отчёт сканеров уязвимостей, который CI сохраняет в CSV и HTML. Внутри CSV файла есть следующие колонки

• Scanner
• Component
• Package
• Type
• Vulnerability ID
• Severity
• Installed Version
• Fixed Version

Нужно в CI показать краткий отчет со списком найденных уязвимостей, важностью и в каких компонентах есть данная уязвимость.

Скачать объект из GCS бакета без gsutil

Чтобы скачать объект из Google Cloud Storage (GCS) бакета необязательно устанавливать google-cloud-sdk или даже gsutil. При условии что токен можно получить у metadata server, то достаточно curl и jq

Пример ниже скачивает gs://GCS_BUCKET_NAME/tests/data.zip

AUTH_TOKEN=$(curl -fsSH 'Metadata-Flavor:Google' http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token | jq -r .access_token)

curl -X GET -H "Authorization:Bearer ${AUTH_TOKEN}" -Lo /tmp/data.zip https://storage.googleapis.com/GCS_BUCKET_NAME/tests/data.zip

Проверка подключения по IPv6 в Nagios

Несколько лет использовал www.google.com в Nagios чтобы проверять "связность" своих серверов с внешним миром по IPv6. На позапрошлой неделе сервера попали в "бан" и проверка перестала работать.

Поскольку www.google.com все же не предназначен для таких проверок, то переделал проверку на использование msftconnecttest.com. Для IPv6 вместо www.msftconnecttest.com нужно использовать ipv6.msftconnecttest.com.

Этот сервис использует Windows чтобы проверить подключение к Internet. Если при скачивании http://ipv6.msftconnecttest.com/connecttest.txt вы получаете строку "Microsoft Connect Test", то все IPv6 работает без ограничений.

$ /usr/lib/nagios/plugins/check_http -6 -H ipv6.msftconnecttest.com -u /connecttest.txt -s 'Microsoft Connect Test'
HTTP OK: HTTP/1.1 200 OK - 537 bytes in 0.012 second response time |time=0.012383s;;;0.000000;10.000000 size=537B;;;0

The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05

Периодически сталкиваюсь с устареванием GPG ключа которым подписывается APT репозитарий google-cloud-sdk. Ошибка выглядит так:

Err:9 https://packages.cloud.google.com/apt cloud-sdk InRelease
  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
Fetched 6,361 B in 1s (4,349 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
27 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.cloud.google.com/apt cloud-sdk InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
W: Failed to fetch https://packages.cloud.google.com/apt/dists/cloud-sdk/InRelease  The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B53DC80D13EDEF05
W: Some index files failed to download. They have been ignored, or old ones used instead.

Судя по выводу GPG старый ключ (7F92E05B31093BEF5A3C2D38FEEA9169307EA071) истёк еще в начале марта

$ gpg /usr/share/keyrings/cloud.google.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa2048 2021-03-01 [SC] [expired: 2023-03-02]
      7F92E05B31093BEF5A3C2D38FEEA9169307EA071
uid           Rapture Automatic Signing Key (cloud-rapture-signing-key-2021-03-01-08_01_09.pub)
sub   rsa2048 2021-03-01 [E] [expired: never     ]
pub   rsa2048 2020-12-04 [SC] [expired: 2022-12-04]
      59FE0256827269DC81578F928B57C5C2836F4BEB
uid           gLinux Rapture Automatic Signing Key (//depot/google3/production/borg/cloud-rapture/keys/cloud-rapture-pubkeys/cloud-rapture-signing-key-2020-12-03-16_08_05.pub) <glinux-team@google.com>
sub   rsa2048 2020-12-04 [E] [expired: never     ]

Назначение префикса URI для веб сервисов

Эта история из разряда "как не нужно делать". Изначально не планировал ее писать, но потратил некоторое количество времеми и хочется предостеречь других от хождения по граблям.

Имеется набор веб сервисов в которых не реализована настройка префикса URI, т.е. все ссылки строятся относительно "корня" (например: hostname:port/login, hostname:port/public/script.js, и т.д.).

И есть желание проверить сможет ли Nginx прозрачно проксировать запросы добавляя префикс каждому сервису чтобы не пришлось менять внутренности самих сервисов.

Сразу скажу что существует более надежное и простое решение - дать каждому сервису собственный поддомен, но это бывает сложно с точки зрения процессов: одобрение доменных имён, новые записи в DNS, SSL сертификаты и т.д.

Решение проблемы "sysctl: permission denied" при обновлении GitLab

У меня GitLab живёт в непривилегированном контейнере LXC и при очередной установке обновления появились ошибки связанные с отсутсвием прав менять настройки sysctl. Это ожидаемое поведение, т.к. на сервере много других контейнеров и я не хочу чтобы каждый из них мог крутить настройки ядра.

Ошибки выглядят пример так

  * gitlab_sysctl[kernel.sem] action create
    * directory[create /etc/sysctl.d for kernel.sem] action create (up to date)
    * file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] action create[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] backed up to /opt/gitlab/embedded/cookbooks/cache/backup/opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf.chef-20230331221328.890308
[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] updated file contents /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf

      - update content in file /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf from 09a346 to 3b0a60
      --- /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf    2017-06-21 13:47:53.000000000 +0300
      +++ /opt/gitlab/embedded/etc/.chef-90-omnibus-gitlab-kernel20230331-271264-19acez0.sem.conf       2023-03-31 22:13:28.886738600 +0300
      @@ -1 +1 @@
      -kernel.sem = 250 32000 32 262
      +kernel.sem = 250 32000 32 275
    * link[/etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf] action create (up to date)
    * execute[load sysctl conf kernel.sem] action nothing (skipped due to action :nothing)
[2023-03-31T22:13:28+03:00] INFO: file[create /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.sem.conf kernel.sem] sending run action to execute[load sysctl conf kernel.sem] (delayed)
    * execute[load sysctl conf kernel.sem] action run
      [execute] sysctl: permission denied on key "kernel.sem"

Чтобы избежать попыток "крутить" настройки ядра достаточно добавить параметр package['modify_kernel_parameters'] = false в /etc/gitlab/gitlab.rb и выполнить обновление конфигурации

$ cat <<_EOF_ | sudo tee -a /etc/gitlab/gitlab.rb
gitlab_kas['enable'] = false
_EOF_

$ sudo gitlab-ctl reconfigure

$ sudo gitlab-ctl restart

Перезапускать сервис не обязательно, но в моем случае часть сервисов оказались остановленными. Решение подсмотрел тут.