action #42920

Gitlab user gets blocked: Try out gitlab deployment tokens for openQA

Added by nicksinger over 1 year ago. Updated about 1 year ago.

Status:ResolvedStart date:25/10/2018
Priority:NormalDue date:
Assignee:nicksinger% Done:

0%

Category:-
Target version:-
Duration:

Description

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.


Related issues

Related to openQA Tests - action #38747: [tools] Needles from the OSD web editor do not get pushed... Resolved 23/07/2018
Related to openQA Infrastructure - action #35290: [tools] again needles could not be pushed from osd to git... Resolved 20/04/2018
Related to openQA Project - action #12128: pushing needles from osd to gitlab fails but needle is pr... Resolved 25/05/2016

History

#1 Updated by nicksinger over 1 year ago

  • Status changed from New to Workable

#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.

Current situation:

  • 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:

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.

-> works

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

#3 Updated by okurz about 1 year ago

awesome, a proper solution at last :) Can you saltify this as well?

#4 Updated by okurz about 1 year ago

  • Related to action #38747: [tools] Needles from the OSD web editor do not get pushed to gitlab any longer added

#5 Updated by okurz about 1 year ago

  • Related to action #35290: [tools] again needles could not be pushed from osd to gitlab.suse.de due to "account has been blocked" and apparently no monitoring alert about this was observed added

#6 Updated by okurz about 1 year ago

  • Related to action #12128: pushing needles from osd to gitlab fails but needle is present in repo added

#7 Updated by nicksinger about 1 year ago

  • Status changed from In Progress to Resolved

Currently the openqa-pusher account seems blocked in gitlab again but can pull/push its changes:

From root@linux.site  Tue Apr  2 09:45:02 2019
Return-Path: <root@linux.site>
X-Original-To: root
Delivered-To: root@linux.site
Received: by linux.site (Postfix, from userid 0)
        id 030459F44; Tue,  2 Apr 2019 09:45:01 +0200 (CEST)
From: "(Cron Daemon)" <root@linux.site>
To: root@linux.site
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 :)

Also available in: Atom PDF