Flux: Flux is unable to clone gitlab repository

Created on 14 Sep 2018  路  9Comments  路  Source: fluxcd/flux

Summary

I am trying to install Flux in my GKE cluster and pointing it to my private gitlab repo however when I look at the Flux logs I keep seeing this

ts=2018-09-14T13:45:29.971777093Z caller=loop.go:87 component=sync-loop err="git repo not ready: git clone --mirror: fatal: Could not read from remote repository."

What I have done

  1. Created a gitlab repository under [email protected]:myproject/myfolder/gitops-repo.git and commited some manifest files inside
  2. Created the following helm configuration
git:
  url: "ssh://[email protected]:myproject/myfolder/gitops-repo.git"
  1. Install Flux with helm using the previous configuration
    helm install --name flux -f values.yml --namespace kube-system weaveworks/flux

  2. Grab the key from Flux
    k -n kube-system logs deployment/flux | grep identity.pub | cut -d '"' -f2

  3. Go to the gitlab repository and add the public key gotten from step 3 with write access

Further details

I have jumped inside the Flux container and manually ran git clone --mirror [email protected]:myproject/myfolder/gitops-repo.git and it works.

I then removed access from the token in the git repository and tried manually cloning it again and confirmed that it failed with a permission denied.

Am I missing something obvious? I can see that Flux is printing a lot of docker registry urls in the logs for things I have deployed in my cluster in different namespaces but I cannot find any problems with the setup itself

FAQ question

Most helpful comment

Just for other googlers which find this issue:

I've got the same error message. After some try and error I detected, that in my case the entry in the .know_hosts file was missing.

A simple ssh-keyscan -H gitrepo.example.de helped to get the entries for the .know_hosts file.
After that you have to set this entries into the helm values: --set ssh.known_hosts="..." (Be careful with multiline strings).

Hope this help someone in the future with the same issue.

All 9 comments

I think the URL is wrong, should be --set git.url=ssh://[email protected]/myproject/myfolder/gitops-repo.git

git: url: "ssh://[email protected]:myproject/myfolder/gitops-repo.git"

this should be either

ssh://[email protected]/myproject/myfolder/gitops-repo.git

or

[email protected]:myproject/myfolder/gitops-repo.git

NB slash for ssh://..., colon for git@....

@squaremo will helm-op work with [email protected]:myproject/myfolder/gitops-repo.git I had the impression it only works with ssh://[email protected]/myproject/myfolder/gitops-repo.git

will helm-op work with [email protected]:myproject/myfolder/gitops-repo.git

Yes; I replaced the git implementation.

I had the same impression too. I tried replacing the : with a / and that did the job.

Thank you

Just for other googlers which find this issue:

I've got the same error message. After some try and error I detected, that in my case the entry in the .know_hosts file was missing.

A simple ssh-keyscan -H gitrepo.example.de helped to get the entries for the .know_hosts file.
After that you have to set this entries into the helm values: --set ssh.known_hosts="..." (Be careful with multiline strings).

Hope this help someone in the future with the same issue.

To add to @florianrusch when using helm operator with an azure devops repo, the operator container does not have azure devops added to /etc/ssh/ssh_known_hosts. This is probably a bug, because the the main flux container does include azure in the known hosts file.

I found this link helpful for debugging: https://github.com/weaveworks/flux/blob/master/site/standalone-setup.md#using-a-private-git-host

This is probably a bug, because the the main flux container does include azure in the known hosts file.

There hasn't been an official release yet with the changes made to the Dockerfile.helm-operator. The correct /etc/ssh/ssh_known_hosts is however included in the nightly builds (master-<commit>) and will be included in the next Helm operator release.

Thanks @hiddeco. I was able to pass --set helmOperator.tag=master-0aec0e29 into my helm upgrade/install and get things working.

Was this page helpful?
0 / 5 - 0 ratings