#5011 Please help us add a post-receive hook to mirror sssd to github
Closed: Fixed None Opened 8 years ago by jhrozek.

= bug description =
For various reasons, we would like to mirror the SSSD repository to github. The fedorahosted repo would still be the main one, but it would send updates to the github repo. I understand the way to do this would be to set up a post-receive hook that would push to github

= bug analysis =
We already have a github organization. IIUC, there is no way to generate an access token on behalf of the organization, so I guess I would have to generate one as the organization admin with my personal account and ask you to include it..

= fix recommendation =
If you don't think this is a good thing to be done on the fedorahosted side, we can setup a cron job that would poll the fedorahosted repo and push to github..


Why not just move the repository to pagure and then use its mirroring capability to mirror out to both github and fedorahosted? At least I think it can do that.

Replying to [comment:1 tibbs]:

Why not just move the repository to pagure and then use its mirroring capability to mirror out to both github and fedorahosted? At least I think it can do that.

This is the first time I hear about pagure :-)

Are there any docs to read? Navigating to pagure.io just shows me a list of projects..

While you are welcome to migrate to pagure if you like (there is some doc at https://docs.pagure.org/pagure/ but it's mostly on how to get pagure running atm), I think Tibbs confused the work done by two GSoC students from CentOS who worked on a service to sync tickets and PR from github to Pagure.

Pagure itself does not have the ability to automatically mirror to github. It would be pretty cool to do, but that means giving pagure the ability to commit on the project on github, so from a security point of view, might be a little tricky maybe even risky.

tbh, I keep in sync pagure on pagure.io, my own server and github, but I do it manually, when I push, I make sure to push to the three locations.

Thanks for chiming in.

So the reason I asked for a hook was that while I could set up a cronjob on a machine I own, I realize there must be a write access to github -- and I would giving the token with the write access to a machine I know is in good hands of Fedora admins :-)

If you know such a hook, adding the feature to pagure should be doable quite easily, even to a git on fedorahosted but there keeping the token secret will be a little more tricky as you would have to send it to us, we would have to place it in the private repo and have a way to enable it for this repo.

Tbh, I do not know if we ever have done something like this before (/me will asks)

I was thinking (and maybe it's naive, correct me if I'm wrong):
* we would add a github remote to fedorahosted's sssd repo
* authentication would happen through [https://developer.github.com/guides/managing-deploy-keys/#deploy-keys github deploy keys]
* the post-receive hook would call a script that does git push --mirror github

Hi,

First of, please note that git remote's are local to your own clone, so we'll have to create the remote on fhosted, but that's no problem.

For exchange of keys: we could generate the ssh key, and give you the public component to add. That would make that part a lot easier.

The problem now becomes that the git push runs as the git user on our server (since that's what everyone pushes as).
This means that we can surely make this work, but we'd have to make the push key readable by the git user.
While this is a limited user that only has access to gitolite push/pull, it's up to you to decide whether you'd feel comfortable with that, as it means that if people find a security hole in gitolite, they could access the ssh key (As it's not protected from the git user by the linux ACLs).

So in short, I think we could do this, just let us know if you want us to.

Replying to [comment:7 puiterwijk]:

Hi,

First of, please note that git remote's are local to your own clone, so we'll have to create the remote on fhosted, but that's no problem.

That's actually what I think would be nice. We have other machines that run SSSD CI and of course devel machines, but I'm pretty sure none of those is as stable as fedorahosted..

I would prefer to have the hook on the same server as the 'official' git repo.

For exchange of keys: we could generate the ssh key, and give you the public component to add. That would make that part a lot easier.

OK, I see

The problem now becomes that the git push runs as the git user on our server (since that's what everyone pushes as).
This means that we can surely make this work, but we'd have to make the push key readable by the git user.
While this is a limited user that only has access to gitolite push/pull, it's up to you to decide whether you'd feel comfortable with that, as it means that if people find a security hole in gitolite, they could access the ssh key (As it's not protected from the git user by the linux ACLs).

So in short, I think we could do this, just let us know if you want us to.

Thank you for the nice analysis, I will discuss this with the rest of the sssd team and let you know.

On the sssd upstream list, we agreed that the key accessible by the git user is OK for us.

If you can help us generate the keypair and send the pubkey and then help us set up the hook, that would be mostly appreciated!

Patrick kindly helped us set up the keypair which shows as usable in github.

Now, if we could have the hook added, we'd be all set. Thanks for your help so far!

This has now been setup.

In the end I didn't need to open up the key for everyone, since I had mistaken fhosted with the Pagure setup: in fhosted the push is done as the actual user.
As such, the keys are only readable by the members of the gitsssd group, and whenever someone is removed from that group, you might want to consider contacting us to update the SSH key used.

The post-receive hook is now in place, and will run on every push with a git push github --mirror --force.

Please let us know if we can help you with anything else in the future!

Login to comment on this ticket.

Metadata