Gitlab runner error checking for jobs forbidden

Summary I have successfully registered runners and jobs are being built and everything is fine and dandy. But, then......
Skip to content



Open


Issue created Aug 02, 2018 by Dennis Thisner@herobix

Upon Cancelling a Running Job, server running gitlab-runner gets «ERROR: Checking for jobs… forbidden»

Summary

I have successfully registered runners and jobs are being built and everything is fine and dandy.

But, then… if a build gets cancelled, it stop accepting jobs.

When trying to debug I am finding following:
gitlab-runner —debug verify

sudo gitlab-runner --debug verify
Runtime platform                                    arch=386 os=linux revision=5396d320 version=11.0.0
Checking runtime mode                               GOOS=linux uid=0
Running in system-mode.

Trying to load /etc/gitlab-runner/certs/gitlab.company.com.crt ...
Dialing: tcp gitlab.cumul8.com:443 ...
ERROR: Verifying runner... is removed               runner=907ca4f2
FATAL: Failed to verify runners

gitlab-runner —debug run

sudo gitlab-runner --debug run
Runtime platform                                    arch=386 os=linux revision=5396d320 version=11.0.0
Starting multi-runner from /etc/gitlab-runner/config.toml ...  builds=0
Checking runtime mode                               GOOS=linux uid=0
Running in system-mode.

Configuration loaded                                builds=0
metricsserveraddress: ""
listenaddress: ""
concurrent: 4
checkinterval: 0
loglevel: null
user: ""
runners:
- name: cirunner03a-ozone
  limit: 1
  outputlimit: 20000
  requestconcurrency: 0
  runnercredentials:
    url: https://gitlab.company.com/
    token: 907ca4f265a53497887506fd24ad08
    tlscafile: ""
    tlscertfile: ""
    tlskeyfile: ""
  runnersettings:
    executor: shell
    buildsdir: /home/gitlab-runner/builds/runner_a/builds_dir
    cachedir: /home/gitlab-runner/builds/runner_a/cache_dir
    cloneurl: ""
    environment: []
    preclonescript: ""
    prebuildscript: ""
    postbuildscript: ""
    shell: ""
    ssh: null
    docker: null
    parallels: null
    virtualbox: null
    cache:
      type: ""
      serveraddress: ""
      accesskey: ""
      secretkey: ""
      bucketname: ""
      bucketlocation: ""
      insecure: false
      path: ""
      shared: false
    machine: null
    kubernetes: null
sentrydsn: null
modtime: 2018-05-09T14:54:51.489977488-07:00
loaded: true
  builds=0
Waiting for stop signal                             builds=0
WARNING: 'metrics_server' configuration entry is deprecated and will be removed in one of future releases; please use 'listen_address' instead
Metrics server disabled
Feeding runners to channel                          builds=0
Starting worker                                     builds=0 worker=0
Starting worker                                     builds=0 worker=1
Starting worker                                     builds=0 worker=2
Starting worker                                     builds=0 worker=3
Trying to load /etc/gitlab-runner/certs/gitlab.company.com.crt ...
Dialing: tcp gitlab.cumul8.com:443 ...
ERROR: Checking for jobs... forbidden               runner=907ca4f2
Feeding runners to channel                          builds=0
ERROR: Checking for jobs... forbidden               runner=907ca4f2
Feeding runners to channel                          builds=0
ERROR: Checking for jobs... forbidden               runner=907ca4f2
ERROR: Runner https://gitlab.cumul8.com/907ca4f265a53497887506fd24ad08 is not healthy and will be disabled!
Feeding runners to channel                          builds=0
Feeding runners to channel                          builds=0

gitlab-runner —version

sudo gitlab-runner --version
Version:      11.0.0
Git revision: 5396d320
Git branch:   11-0-stable
GO version:   go1.8.7
Built:        2018-06-22T11:03:37+00:00
OS/Arch:      linux/386

I have tried stopping, starting and restarting the Gitlab-runner
Also restarting the VM/Server
Dosen’t work.

Sometimes updating the version works.

Steps to reproduce

  1. Start a job
  2. Cancel the job
  3. Wait for it to start next job
  4. Nothing happens…
  5. Wait for about 1h and it starts accepting jobs

Running:

gitlab-runner verify --delete
gitlab-runner run

Seems to make is start again

What is the current bug behavior?

Cancelling a job stops the runner from picking up new jobs

What is the expected correct behavior?

When cancelling a job, it should just pick up next available job

Relevant logs and/or screenshots

(Paste any relevant logs — please use code blocks («`) to format console output,
logs, and code as it’s very hard to read otherwise.)

Output of checks

This is happening on our private gitlab

Results of GitLab environment info

GitLab 10.8.0 (gitlab-ce@55e4a0b334139a5b5949c91c8325b330e425989b)
GitLab Shell 7.1.2
GitLab Workhorse v4.2.0
GitLab API

Possible fixes

(If you can, link to the line of code that might be responsible for the problem)

Skip to content



Open


Issue created Nov 29, 2019 by Clive Crous@clive.crous

gitlab-runner run-single always fails with ‘forbidden’ with docker executor

Summary

When using the same arguments but given to gitlab-runner register and then running with gitlab-runner run the runner runs fine, however attempting the exact same configuration for gitlab-runner run-single fails with «ERROR: Checking for jobs… forbidden»

Steps to reproduce

Simply execute a gitlab-runner with run-single, here’s my exact command-line used (with sensitive info removed)

gitlab-runner run-single —url «${GITLAB_URI}» —token «${GITLAB_TOKEN}» —description «My Runner» —executor docker —docker-image ‘docker:latest’ —docker-volumes ‘/var/run/docker.sock:/var/run/docker.sock’ —limit 1 —request-concurrency 1

Actual behavior

Runtime platform arch=amd64 os=linux pid=22 revision=577f813d version=12.5.0
Starting runner for XXXXX with token ZZZZZ …
ERROR: Checking for jobs… forbidden runner=ZZZZZ
Runner is not healthy!

Expected behavior

It should not fail, this is the output from executing via register then run, with the same arguments:

Runtime platform arch=amd64 os=linux pid=48 revision=577f813d version=12.5.0
Running in system-mode.

Registering runner… succeeded runner=ZZZZZ
Runner registered successfully. Feel free to start it, but if it’s running already the config should be automatically reloaded!
Runtime platform arch=amd64 os=linux pid=56 revision=577f813d version=12.5.0
Starting multi-runner from /etc/gitlab-runner/config.toml … builds=0
Running in system-mode.

Configuration loaded builds=0
Locking configuration file builds=0 file=/etc/gitlab-runner/config.toml pid=56

Environment description

Self-Managed / Starter

Empty config.toml, runner executed in clean container.

config.toml contents

Used GitLab Runner version

Version:      12.5.0
Git revision: 577f813d
Git branch:   12-5-stable
GO version:   go1.10.8
Built:        2019-11-20T09:14:54+0000
OS/Arch:      linux/amd64

I hosts my repository with gitlab.com and I install runner in the DigitalOcean. It ran fine until today 16March2019 14:24 Thailand time.

# gitlab-runner status
Runtime platform                                    arch=amd64 os=linux pid=16937 revision=4745a6f3 version=11.8.0
gitlab-runner: Service is running!
# gitlab-runner unregister --all-runners
Runtime platform                                    arch=amd64 os=linux pid=16299 revision=4745a6f3 version=11.8.0
Running in system-mode.

WARNING: Unregistering all runners
ERROR: Unregistering runner from GitLab forbidden   runner=2bcd7af4
ERROR: Failed to unregister runner HerrRunner
# gitlab-runner list
Runtime platform                                    arch=amd64 os=linux pid=16346 revision=4745a6f3 version=11.8.0
Listing configured runners                          ConfigFile=/etc/gitlab-runner/config.toml
HerrRunner                                          Executor=shell Token=2bcd7af455f866ede7991992a68780 URL=https://gitlab.com/
# gitlab-runner --debug run
Runtime platform                                    arch=amd64 os=linux pid=16395 revision=4745a6f3 version=11.8.0
Starting multi-runner from /etc/gitlab-runner/config.toml ...  builds=0
Checking runtime mode                               GOOS=linux uid=0
Running in system-mode.

Configuration loaded                                builds=0
listenaddress: ""
sessionserver:
  listenaddress: ""
  advertiseaddress: ""
  sessiontimeout: 1800
metricsserveraddress: ""
concurrent: 1
checkinterval: 0
loglevel: null
logformat: null
user: ""
runners:
- name: HerrRunner
  limit: 0
  outputlimit: 0
  requestconcurrency: 0
  runnercredentials:
    url: https://gitlab.com/
    token: 2bcd7af455f866ede7991992a68780
    tlscafile: ""
    tlscertfile: ""
    tlskeyfile: ""
  runnersettings:
    executor: shell
    buildsdir: ""
    cachedir: ""
    cloneurl: ""
    environment: []
    preclonescript: ""
    prebuildscript: ""
    postbuildscript: ""
    shell: ""
    ssh: null
    docker: null
    parallels: null
    virtualbox: null
    cache:
      type: ""
      path: ""
      shared: false
      s3: null
      gcs: null
      s3cachepath: ""
      cacheshared: false
      serveraddress: ""
      accesskey: ""
      secretkey: ""
      bucketname: ""
      bucketlocation: ""
      insecure: false
    machine: null
    kubernetes: null
sentrydsn: null
modtime: 2018-08-12T18:07:07.963445119Z
loaded: true
  builds=0
Waiting for stop signal                             builds=0
Listen address not defined, metrics server disabled  builds=0
Listen address not defined, session server disabled  builds=0
Starting worker                                     builds=0 worker=0
Feeding runners to channel                          builds=0
Dialing: tcp gitlab.com:443 ...
ERROR: Checking for jobs... forbidden               runner=2bcd7af4
Feeding runners to channel                          builds=0
ERROR: Checking for jobs... forbidden               runner=2bcd7af4
Feeding runners to channel                          builds=0
ERROR: Checking for jobs... forbidden               runner=2bcd7af4
ERROR: Runner https://gitlab.com/2bcd7af455f866ede7991992a68780 is not healthy and will be disabled!
Feeding runners to channel                          builds=0
Feeding runners to channel                          builds=0
Feeding runners to channel                          builds=0
^CWARNING: Requested service stop: interrupt          builds=0
All workers stopped. Can exit now                   builds=0

Ultimate Goal

Get my runner up and run again

Question:

  1. What does not healthy means?

  2. I can’t unregister my runner. How to fix this?

asked Mar 16, 2019 at 7:30

joe's user avatar

joejoe

7,88612 gold badges56 silver badges105 bronze badges

0

No idea. But seems like gitlab.com remove my runner token. Therefore I have to remove my runner, register, and run it again.

answered Mar 16, 2019 at 13:03

joe's user avatar

joejoe

7,88612 gold badges56 silver badges105 bronze badges

I was integrating my runner for the first time, and anyone familiar with gitlab will know this was never going to be a walk in the park. I spent many hours chasing down this error message only to find I was completely looking in the wrong direction.

ERROR: Checking for jobs... forbidden               runner=s3xBVnW8
ERROR: Checking for jobs... forbidden               runner=s3xBVnW8
ERROR: Checking for jobs... forbidden               runner=s3xBVnW8
ERROR: Runner https://gitlab.com/s3xBVnW8JZPTaocALN3i is not healthy and will be disabled!

I now believe my runner was telling me that the «runner» at gitlab.com is not healthy and has been rejected (by my runner). When I left it running and put a pipeline job in, it processed fine, there was no issue at my end, I had spent hours looking for nothing!

answered Jan 7, 2021 at 8:38

hi2meuk's user avatar

hi2meukhi2meuk

89010 silver badges7 bronze badges

2

I faced with the same issue. Register you runner as described in the installation instructions. Go to admin/runners and click Show runner installation instructions button. The most important is Register runner session where you have to run register command that resolves the issue described. For instance, linux:

sudo gitlab-runner register --url YOUR_GITLAB_SERVER_URL --registration-token TOKEN

# YOUR_GITLAB_SERVER_URL like http://localhost:8100/ or https://mygitlabserver.com/

Follow instructions and you are good to go.

Once your runner is setup and running you can add modifications to the config file, stop and start it again after config changes.

You may find duplicate [[runners]] sections, that happens if you tried to configure it yourself and then with register command. That’s fine, leave only one latest.

answered Feb 23, 2021 at 17:53

Madman's user avatar

MadmanMadman

3,1342 gold badges31 silver badges44 bronze badges

0

When I ran into this (running in user mode because of lack of sudo access), removing and reregistering the runner didn’t seem to help. The extra step that was required was removing the config.toml file (located at ~/.gitlab-runner/config.toml for me). After deleting that file, I was able to register and run a new runner (using the exact same commands as before) and everything seems to work fine.

Note:

When you register a runner, it should say something like Configuration (with the authentication token) was saved in "<some/path/config.toml>". That’s the file that needed deleting.

answered Dec 7, 2022 at 15:05

John's user avatar

JohnJohn

1,6498 silver badges11 bronze badges

I also had this problem, which was solved by changing the service as a sub-problem
From:
ExecStart=/usr/bin/gitlab-runner «run» «—working-directory» «/var/lib/gitlab-runner» «—config» «/etc/gitlab-runner/config.toml» «—service» «gitlab-runner» «—user» «gitlab-runner»
ExecStart=/usr/bin/gitlab-runner «run»

To:
ExecStart=/usr/bin/gitlab-runner «run»

answered Jan 9 at 13:07

Abed farvardin's user avatar

1

Runners are isolated machines (preferably not installed on the same machine as Gitlab) that pick up and execute CI/CD jobs for your Gitlab server.
A Runner can be specific to a certain project or serve any project in GitLab CI. A Runner that serves all projects is called a shared Runner.
You don’t have to have any runners at all if you are just using Gitlab for version control, but you will need at least one if you wish to implement CI/CD.
You can deploy as many runners as you want and it is a good idea to scale horizontally across multiple servers.

Related Posts

  • GitLab Documentation Index

Steps

Install Docker

Deploy a gitlab-runner container with docker.

docker run -d 
  --name gitlab-runner 
  --restart always 
  -v $HOME/gitlab-runner-volume/config:/etc/gitlab-runner 
  -v /var/run/docker.sock:/var/run/docker.sock 
  gitlab/gitlab-runner:latest

This will result in any state being held in a directory at $HOME/gitlab-runner-volume. Feel free to change this path if you want it somewhere else, but I like it to be «in my face» so I don’t forget it’s there..

Update

To update your runner, pull the latest image, remove the existing container and re-deploy.

docker pull gitlab/gitlab-runner:latest
docker stop gitlab-runner && docker rm gitlab-runner

docker run -d 
  --name gitlab-runner 
  --restart always 
  -v $HOME/gitlab-runner-volume/config:/etc/gitlab-runner 
  -v /var/run/docker.sock:/var/run/docker.sock 
  gitlab/gitlab-runner:latest

Register The Runner

Go to the runners section of Gitlab and grab the url (4) and registration token (5)

Enter the container

After having grabbed the URL and token, you need to enter the container.

You now need to run a command inside the container to register the runner.
You can either explicitly specify your configuration options through arguments or run the command without the arguments and answer them in a series of interactive questions.
I recommend going with explicit if you are unsure.

Explicit Registration

Run the command below after having substituted the variables or having set them.
This uses the docker socket binding method so that the docker daemon is shared and your containers run directly on the host.
You can use other methods if you like.

REGISTRATION_TOKEN=""
URL=""

gitlab-runner register -n 
  --url $URL 
  --registration-token $REGISTRATION_TOKEN 
  --executor docker 
  --description "My Docker Runner" 
  --docker-image "docker:latest" 
  --docker-volumes /var/run/docker.sock:/var/run/docker.sock

Interactive Registration

Run the following command (inside the container):

sudo gitlab-runner register

You will be asked a series of questions. When asked for the url and token, enter the url and token that you grabbed earler from Gitlab.

When asked which type of executor, I went with docker and I suggest you do the same unless you specifically know that you want to use a different executor such as Kubernetes.
You can read up more on runner executors.
Whilst shell is the easiest, it results in an environment that gets polluted from past runs, unlike using docker whereby you start with a clean slate each time.
I was unsure as to whether I wanted the docker executor or the docker-ssh executor, but it looks like the docker-ssh executor is being discontinued which made the choice easy.

Runner Registered

After having run the explicit command or using the interactive prompts, you will be shown the following error message:

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

If you navigate back to the runners section of Gitlab, you will see your newly registered runner.

Debugging

If you need to debug what it going wrong, use the command:

docker logs gitlab-runner

If you see this message:

ERROR: Failed to load config stat /etc/gitlab-runner/config.toml: no such file or directory  builds=0

That means that you probably haven’t yet run the sudo gitlab-runner register command within your container yet. Please go back up to the register section.

At one point, I thought I needed to manually create the config.toml file using online examples, in order to register the runner.
This will only end up in pain as you need to pass the token to the gitlab-runner register and if you try using that token within the config file you will end up with messages like this in the logs:

ERROR: Checking for jobs... forbidden               runner=9f09eda9
ERROR: Checking for jobs... forbidden               runner=9f09eda9
ERROR: Checking for jobs... forbidden               runner=9f09eda9
ERROR: Runner https://gitlab.com/... is not healthy and will be disabled!

Running Out Of Space

If you don’t put something in place, your runners will probably eventually run out of space. Thus, I have it run a system prune every day.

sudo crontab -e
@daily /usr/bin/docker system prune -f

Even after that, my runner still ran out of space, so I added the following:

@daily /usr/bin/docker image prune --all --force

References

  • Gitlab Docs — Run GitLab Runner in a container
  • Gitlab runner blocked by IP
  • Gitlab Documentation — Building Docker images with GitLab CI/CD

Last updated: 27th October 2022
First published: 16th August 2018

Now that the CI minutes are being gimped I need to have another go at setting up and running my own runners, which I failed at miserably in the past (I need docker-in-docker to work).

My docker-compose for the registrator and the runner:

version: "3.5"

services:
  runner:
    container_name: gl-runner
    image: gitlab/gitlab-runner:latest
    restart: unless-stopped
    volumes:
      - ./gitlab-runner.toml:/etc/gitlab-runner/config.toml
      - ./config:/etc/gitlab-runner
      - /var/run/docker.sock:/var/run/docker.sock
    depends_on:
      - registrator

  registrator:
    container_name: gl-registrator
    image: gitlab/gitlab-runner:latest
    volumes:
      - ./config:/etc/gitlab-runner
    command: |
      register
      --non-interactive
      --executor "docker"
      --docker-image alpine:latest
      --url "https://gitlab.com/"
      --registration-token "<redacted>"
      --description "docker-runner"
      --tag-list "docker"
      --run-untagged="true"
      --locked="false"
      --access-level="not_protected"

The resulting config.toml:

[[runners]]
  name = "docker"
  url = "https://gitlab.com/"
  token = "<redacted>"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "alpine"
    privileged = true
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
  [runners.cache]

The registrator run just fine and the runner is registered to my group at gitlab.com, but when the runner starts right after the registrator it fails with this output:

❯ docker-compose up
Creating network "gitlab-runner_default" with the default driver
Creating gl-registrator ... done
Creating gl-runner      ... done
Attaching to gl-registrator, gl-runner
gl-registrator | Runtime platform                                    arch=amd64 os=linux pid=6 revision=738bbe5a version=13.3.1
gl-registrator | Running in system-mode.
gl-registrator |
gl-runner      | Runtime platform                                    arch=amd64 os=linux pid=6 revision=738bbe5a version=13.3.1
gl-runner      | Starting multi-runner from /etc/gitlab-runner/config.toml...  builds=0
gl-runner      | Running in system-mode.
gl-runner      |
gl-runner      | Configuration loaded                                builds=0
gl-runner      | listen_address not defined, metrics & debug endpoints disabled  builds=0
gl-runner      | [session_server].listen_address not defined, session endpoints disabled  builds=0
gl-registrator | Registering runner... succeeded                     runner=<redacted>
gl-registrator | Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
gl-runner      | ERROR: Checking for jobs... forbidden               runner=<redacted>
gl-registrator exited with code 0
gl-runner      | ERROR: Checking for jobs... forbidden               runner=<redacted>
gl-runner      | ERROR: Checking for jobs... forbidden               runner=<redacted>
gl-runner      | ERROR: Runner https://gitlab.com/<redacted> is not healthy and will be disabled!

What am I doing wrong here?

  • Remove From My Forums
  • Вопрос

  • Hello team!

      We are working with docker on the W2K19 core and we are facing the following error:

    Event[3]:
      Log Name: Application
      Source: gitlab-runner
      Date: 2020-07-01T20:33:41.282
      Event ID: 3
      Task: N/A
      Level: Error
      Opcode: Info
      Keyword: Classic
      User: N/A
      User Name: N/A
      Computer: srvwi049.tce.ms
      Description: 
    [31;1mERROR: Runner http://git.tce.ms.gov.br/fZDyuf8FprnnD91iMWBT is not healthy and will be disabled![0;m 
    
    
    Event[4]:
      Log Name: Application
      Source: gitlab-runner
      Date: 2020-07-01T20:33:41.282
      Event ID: 3
      Task: N/A
      Level: Error
      Opcode: Info
      Keyword: Classic
      User: N/A
      User Name: N/A
      Computer: srvwi049.tce.ms
      Description: 
    [31;1mERROR: Checking for jobs... forbidden             [0;m  [31;1mrunner[0;m=fZDyuf8F

      Has anyone ever experienced this?

    Thanks.


    Doria

    • Изменено

      2 июля 2020 г. 1:49

Ответы

  • Hi,

    For Gitlab related issue, it is recommended to post in Gitlab forums for more help:

    https://about.gitlab.com/get-help/

    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge
    or learn from your interaction with us.  Thank you for your understanding.


    Please remember to mark the replies as answers if they help.
    «Windows 10 Installation, Setup, and Deployment» forum will be migrating to a new home on
    Microsoft Q&A (Preview)!
    We invite you to post new questions in the «Windows 10 Installation, Setup, and Deployment» forum’s new home on
    Microsoft Q&A (Preview)!
    For more information, please refer to the
    sticky post.

    • Помечено в качестве ответа
      dydoria
      2 июля 2020 г. 15:47

Пытаюсь запустить сборку через gitlab-runner docker:

$ gitlab-runner exec docker build:deb
ERRO[0000] Docker executor: prebuilt image helpers will be loaded from /var/lib/gitlab-runner. 
Running with gitlab-runner 11.2.0 (11.2.0)
Using Docker executor with image debian:buster ...
ERROR: Preparation failed: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: "gitlab-runner-cache": executable file not found in $PATH": unknown (executor_docker.go:412:0s)
Will be retried in 3s ...
Using Docker executor with image debian:buster ...
ERROR: Preparation failed: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: "gitlab-runner-cache": executable file not found in $PATH": unknown (executor_docker.go:412:0s)
Will be retried in 3s ...
Using Docker executor with image debian:buster ...
ERROR: Preparation failed: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: "gitlab-runner-cache": executable file not found in $PATH": unknown (executor_docker.go:412:0s)
Will be retried in 3s ...
ERROR: Job failed (system failure): Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: "gitlab-runner-cache": executable file not found in $PATH": unknown (executor_docker.go:412:0s)
FATAL: Error response from daemon: OCI runtime create failed: container_linux.go:345: starting container process caused "exec: "gitlab-runner-cache": executable file not found in $PATH": unknown (executor_docker.go:412:0s)

Содержимое .gitlab-ci.yml:

stages:
  - build

build:deb:
  stage: build
  image: debian:buster
  tags:
  - deb
  before_script:
  - mkdir build && cd build
  - apt install cmake
  script:
  - cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DRA_STATIC_LINK=ON ..
  - cmake --build . -- -j 8
  artifacts:
    paths:
    - build/run

Как исправить ошибку?

Troubleshooting SSL (FREE SELF)

This page contains a list of common SSL-related errors and scenarios that you
may encounter while working with GitLab. It should serve as an addition to the
main SSL documentation:

  • Omnibus SSL Configuration.
  • Self-signed certificates or custom Certification Authorities for GitLab Runner.
  • Manually configuring HTTPS.

Using an internal CA certificate with GitLab

After configuring a GitLab instance with an internal CA certificate, you might
not be able to access it by using various CLI tools. You may experience the
following issues:

  • curl fails:

    curl "https://gitlab.domain.tld"
    curl: (60) SSL certificate problem: unable to get local issuer certificate
    More details here: https://curl.haxx.se/docs/sslcerts.html
  • Testing by using the rails console
    also fails:

    uri = URI.parse("https://gitlab.domain.tld")
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    http.verify_mode = 1
    response = http.request(Net::HTTP::Get.new(uri.request_uri))
    ...
    Traceback (most recent call last):
          1: from (irb):5
    OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate))
  • The error SSL certificate problem: unable to get local issuer certificate
    is displayed when setting up a mirror
    from this GitLab instance.

  • openssl works when specifying the path to the certificate:

    /opt/gitlab/embedded/bin/openssl s_client -CAfile /root/my-cert.crt -connect gitlab.domain.tld:443

If you have the previously described issues, add your certificate to
/etc/gitlab/trusted-certs, and then run sudo gitlab-ctl reconfigure.

X.509 key values mismatch error

After configuring your instance with a certificate bundle, NGINX may display
the following error message:

SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

This error message means that the server certificate and key you have provided
don’t match. You can confirm this by running the following command and then
comparing the output:

openssl rsa -noout -modulus -in path/to/your/.key | openssl md5
openssl x509 -noout -modulus -in path/to/your/.crt | openssl md5

The following is an example of an md5 output between a matching key and
certificate. Note the matching md5 hashes:

$ openssl rsa -noout -modulus -in private.key | openssl md5
4f49b61b25225abeb7542b29ae20e98c
$ openssl x509 -noout -modulus -in public.crt | openssl md5
4f49b61b25225abeb7542b29ae20e98c

This is an opposing output with a non-matching key and certificate which shows
different md5 hashes:

$ openssl rsa -noout -modulus -in private.key | openssl md5
d418865077299af27707b1d1fa83cd99
$ openssl x509 -noout -modulus -in public.crt | openssl md5
4f49b61b25225abeb7542b29ae20e98c

If the two outputs differ like the previous example, there’s a mismatch between
the certificate and key. Contact the provider of the SSL certificate for
further support.

Using GitLab Runner with a GitLab instance configured with internal CA certificate or self-signed certificate

Besides getting the errors mentioned in
Using an internal CA certificate with GitLab,
your CI pipelines may get stuck in Pending status. In the runner logs you may
see the following error message:

Dec  6 02:43:17 runner-host01 gitlab-runner[15131]: #033[0;33mWARNING: Checking for jobs... failed
#033[0;m  #033[0;33mrunner#033[0;m=Bfkz1fyb #033[0;33mstatus#033[0;m=couldn't execute POST against
https://gitlab.domain.tld/api/v4/jobs/request: Post https://gitlab.domain.tld/api/v4/jobs/request:
x509: certificate signed by unknown authority

Follow the details in Self-signed certificates or custom Certification Authorities for GitLab Runner.

Mirroring a remote GitLab repository that uses a self-signed SSL certificate

When configuring a local GitLab instance to mirror a repository
from a remote GitLab instance that uses a self-signed certificate, you may see
the SSL certificate problem: self signed certificate error message in the
user interface.

The cause of the issue can be confirmed by checking if:

  • curl fails:

    $ curl "https://gitlab.domain.tld"
    curl: (60) SSL certificate problem: self signed certificate
    More details here: https://curl.haxx.se/docs/sslcerts.html
  • Testing by using the Rails console also fails:

    uri = URI.parse("https://gitlab.domain.tld")
    http = Net::HTTP.new(uri.host, uri.port)
    http.use_ssl = true
    http.verify_mode = 1
    response = http.request(Net::HTTP::Get.new(uri.request_uri))
    ...
    Traceback (most recent call last):
          1: from (irb):5
    OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate))

To fix this problem:

  • Add the self-signed certificate from the remote GitLab instance to the
    /etc/gitlab/trusted-certs directory on the local GitLab instance, and then
    run sudo gitlab-ctl reconfigure as per the instructions for
    installing custom public certificates.
  • If your local GitLab instance was installed using the Helm Charts, you can
    add your self-signed certificate to your GitLab instance.

You may also get another error message when trying to mirror a repository from
a remote GitLab instance that uses a self-signed certificate:

2:Fetching remote upstream failed: fatal: unable to access &amp;#39;https://gitlab.domain.tld/root/test-repo/&amp;#39;:
SSL: unable to obtain common name from peer certificate

In this case, the problem can be related to the certificate itself:

  1. Validate that your self-signed certificate isn’t missing a common name. If it
    is, regenerate a valid certificate
  2. Add the certificate to /etc/gitlab/trusted-certs.
  3. Run sudo gitlab-ctl reconfigure.

Unable to perform Git operations due to an internal or self-signed certificate

If your GitLab instance is using a self-signed certificate, or if the
certificate is signed by an internal certificate authority (CA), you might
experience the following errors when attempting to perform Git operations:

$ git clone https://gitlab.domain.tld/group/project.git
Cloning into 'project'...
fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': SSL certificate problem: self signed certificate
$ git clone https://gitlab.domain.tld/group/project.git
Cloning into 'project'...
fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none

To fix this problem:

  • If possible, use SSH remotes for all Git operations. This is considered more
    secure and convenient to use.
  • If you must use HTTPS remotes, you can try the following:
    • Copy the self-signed certificate or the internal root CA certificate to a
      local directory (for example, ~/.ssl) and configure Git to trust your
      certificate:

      git config --global http.sslCAInfo ~/.ssl/gitlab.domain.tld.crt
    • Disable SSL verification in your Git client. This is intended as a
      temporary measure, as it could be considered a security risk.

      git config --global http.sslVerify false

SSL_connect wrong version number

A misconfiguration may result in:

  • gitlab-rails/exceptions_json.log entries containing:

    "exception.class":"Excon::Error::Socket","exception.message":"SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)",
    "exception.class":"Excon::Error::Socket","exception.message":"SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)",
  • gitlab-workhorse/current containing:

    http: server gave HTTP response to HTTPS client
    http: server gave HTTP response to HTTPS client
  • gitlab-rails/sidekiq.log or sidekiq/current containing:

    message: SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)
    message: SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)

Some of these errors come from the Excon Ruby gem, and could be generated in
circumstances where GitLab is configured to initiate an HTTPS session to a
remote server that is serving only HTTP.

One scenario is that you’re using object storage, which
isn’t served under HTTPS. GitLab is misconfigured and attempts a TLS handshake,
but the object storage responds with plain HTTP.

schannel: SEC_E_UNTRUSTED_ROOT

If you’re on Windows and get the following error:

Fatal: unable to access 'https://gitlab.domain.tld/group/project.git': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted."

You must specify that Git should use OpenSSL:

git config --system http.sslbackend openssl

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Gitlab error tracking
  • Gitlab error src refspec master does not match any
  • Get adcomputer сервер вернул следующую ошибку недопустимый контекст перечисления
  • Get 500 ошибка
  • Get 500 internal server error ajax

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии