tinkerbell/playground

Tink_worker on sandbox deployment fails with CERT issue

Closed this issue ยท 3 comments

As soon as the tink_worker is started it fails with an error x509 : certificate signed by unknown authority at linuxkit

Expected Behaviour

The tink_worker should work as the certificate is signed by Tinkerbell CA

Current Behaviour

The linuxkit boot screen is stuck waiting for the deployment. Upon checking the logs of the container we see that it fails to start with Unknown certificate issue.

Possible Solution

Need to sign the certificate properly

Steps to Reproduce (for bugs)

  1. Run the docker container sandbox
  2. Complete the template, hardware and workflow
  3. Wait for the physical machine to acquire PXE boot and start of linuxkit
  4. Linuxkit is stuck waiting for the container (tink_worker) to start. Upon evaluating the container logs we see the x509: certificate signed by Unknown authority.

Context

We are using tinkerbell in production to provision multiple linux physical machines and this issue has stopped us from moving forward.

Your Environment

  • Operating System and version (e.g. Linux, Windows, MacOS):

Ubuntu 18.04

  • How are you running Tinkerbell? Using Vagrant & VirtualBox, Vagrant & Libvirt, on Packet using Terraform, or give details:

Using docker-compose from sandbox ( https://github.com/tinkerbell/sandbox/tree/main/deploy/compose)

  • Link to your project or a code example to reproduce issue:

image

@gianarb , Did you get a chance to have a look at this issue? because I am also facing some cert related issues in tink-worker from last couple of days while setting it up on local machine using vagrant and virtualbox on Ubuntu 20.04.
I have not created a new ticket/issue because I think it is somewhat similar to this one.

Hey @umashankar1988, sorry for the delayed response. I've experienced this before and was able to resolve it by deleting the ca.pem file (this is in the deploy/compose/state/webroot/workflow/ dir) and then docker-compose down and docker-compose up -d. Mind trying that?

Hi @jacobweinstock I tried using the steps suggested above but the issue still remains the same. Below is a screenshot of docker container logs from the worker

MicrosoftTeams-image