Gitlab user gets blocked: Try out gitlab deployment tokens for openQA
From time to time the openQA user gets blocked in gitlab.
This happend last time on 2018-10-25. We suspect that it could be caused if the backend authentication infrastructure (aka LDAP) is not available while a login-attempt is made.
It can be resolved by a manual login into the webui (creds at https://gitlab.suse.de/openqa/scripts/blob/master/password).
Gitlab supports deployment tokens (read as well as write is possible): https://docs.gitlab.com/ee/user/project/deploy_tokens/
Maybe they work a little bit different and could solve our problem -> Needs to be tried out
An alternative solution to at least notice such issues is of course monitoring again.
#2 Updated by nicksinger about 1 year ago
- Status changed from Workable to In Progress
- Assignee set to nicksinger
Alright since the user got disabled once again it is time to do this now.
- There is a separate gitlab user for openQA called "openqa-pusher".
- This account has an ssh-key attached (2048 SHA256:WLfyo/WGDxFVrYmzfud65MN3pwUyLbApaHehzkUlJck wwwrun@autoinst (RSA))
- This key can't be used as deployment key
What I did now:
- Create a new ssh-key (/var/lib/openqa/.ssh/id_rsa.gitlab) (4096 SHA256:walE7SywGmiOeD2NAn0Jg5YNc7Hqwks0slyvYDLcnJI email@example.com (RSA))
- Added this key as "Deployment Key" (with write access) to https://gitlab.suse.de/openqa/os-autoinst-needles-sles/settings/repository
- Added a ssh-config entry for gitlab:
Host gitlab.suse.de HostName gitlab.suse.de User gitlab IdentityFile ~/.ssh/id_rsa.gitlab IdentitiesOnly yes
To test this I simply tried to ssh into that host:
geekotest@openqa:~/.ssh> ssh gitlab.suse.de PTY allocation request failed on channel 0 Welcome to GitLab, @nicksinger! Connection to gitlab.suse.de closed.
Other repos where the key needs to be added:
find /var/lib/openqa/share/tests -maxdepth 1 -mindepth 1 -type d
/var/lib/openqa/share/tests/vmdp /var/lib/openqa/share/tests/sle-12.pre_oado#920 /var/lib/openqa/share/tests/sle /var/lib/openqa/share/tests/dont_use.sle-11-sp3
#7 Updated by nicksinger about 1 year ago
- Status changed from In Progress to Resolved
openqa-pusher account seems blocked in gitlab again but can pull/push its changes:
From firstname.lastname@example.org Tue Apr 2 09:45:02 2019 Return-Path: <email@example.com> X-Original-To: root Delivered-To: firstname.lastname@example.org Received: by linux.site (Postfix, from userid 0) id 030459F44; Tue, 2 Apr 2019 09:45:01 +0200 (CEST) From: "(Cron Daemon)" <email@example.com> To: firstname.lastname@example.org Subject: Cron <root@openqa> cd /opt/openqa-scripts && git fetch --all && git reset --hard origin/master Content-Type: text/plain; charset=UTF-8 Auto-Submitted: auto-generated Precedence: bulk X-Cron-Env: <XDG_SESSION_ID=23662> X-Cron-Env: <XDG_RUNTIME_DIR=/run/user/0> X-Cron-Env: <LC_CTYPE=en_US.UTF-8> X-Cron-Env: <SHELL=/bin/sh> X-Cron-Env: <HOME=/root> X-Cron-Env: <PATH=/usr/bin:/bin> X-Cron-Env: <LOGNAME=root> X-Cron-Env: <USER=root> Message-Id: <20190402074502.030459F44@linux.site> Date: Tue, 2 Apr 2019 09:45:01 +0200 (CEST) Fetching origin HEAD is now at 4e44fdf Merge branch 'smart_next_number' into 'master'
So for now I assume that this actually worked exactly how I imagined it :)