В GitLab есть встроенная проверка на доступность новой версии, которая ещё и рассказывает о критичности такого обновления. Но эта проверка адекватно работает только для поддерживаемых версий.
Пример: есть инсталляция GitLab CE 16.7.7 и недавняя рассылка GitLab Security Release: 16.10.1, 16.9.3, 16.8.5. Там упоминаются CVE-2023-6371 (High) и CVE-2024-2818 (Medium) которым подвержены все версии до 16.8.5.
При этом в дашборде показывает только "Update available", а не "Update ASAP"
На днях столкнулся с очень старой проблемой (открыта 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
На следующей неделе попробую внедрить в один из проектов и посмотреть.
У меня 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
Перезапускать сервис не обязательно, но в моем случае часть сервисов оказались остановленными. Решение подсмотрел тут.
Настраиваю workload identity federation между on-prem GitLab и GCP согласно документации. Сделал настройки в GCP, взял готовый пример пайплайна, но джоба падает с ошибкой
$ gcloud auth print-access-token
ERROR: (gcloud.auth.print-access-token) ("Error code invalid_grant: Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected '{']", '{"error":"invalid_grant","error_description":"Parsing error for OIDC discovery document: [Line 0, column 0: Unexpected end of stream : expected \'{\']"}')
Смотрю что выдаёт https://GITLAB/.well-known/openid-configuration и вижу 302 редирект на /users/sign_in - это неожиданное поведение. На этот запрос должно возвращать JSON вида
$ curl -s https://gitlab.com/.well-known/openid-configuration
{"issuer":"https://gitlab.com","authorization_endpoint":"https://gitlab.com/oauth/authorize","token_endpoint":"https://gitlab.com/oauth/token","revocation_endpoint":"https://gitlab.com/oauth/revoke","introspection_endpoint":"https://gitlab.com/oauth/introspect","userinfo_endpoint":"https://gitlab.com/oauth/userinfo","jwks_uri":"https://gitlab.com/oauth/discovery/keys","scopes_supported":["api","read_api","read_user","read_repository","write_repository","read_registry","write_registry","sudo","openid","profile","email"],"response_types_supported":["code"],"response_modes_supported":["query","fragment"],"grant_types_supported":["authorization_code","password","client_credentials","refresh_token"],"token_endpoint_auth_methods_supported":["client_secret_basic","client_secret_post"],"subject_types_supported":["public"],"id_token_signing_alg_values_supported":["RS256"],"claim_types_supported":["normal"],"claims_supported":["iss","sub","aud","exp","iat","sub_legacy","name","nickname","email","email_verified","website","profile","picture","groups","groups_direct","https://gitlab.org/claims/groups/owner","https://gitlab.org/claims/groups/maintainer","https://gitlab.org/claims/groups/developer"]}
Нужно разобраться откуда у меня берется этот редирект.
Could not authenticate you from Ldapmain because "Ssl connect returned=1 errno=0 state=error: certificate verify failed".ca_file в секции настроек LDAP