But the ~/.gitolite.rc is not a script, why do you want to run it?

I was sleepy :) and I try to connect Pagure and gitolite.

there is not direct connection between both, basically the only connection that exists is that pagure write gitolite's ACL file (describing who can access which repo). Once this file is written, pagure compiles it and that's it, the rest is regular gitolite configuration :)

Currently I have trouble with public keys.,,
When I update my public key, gitolit does not update own configuration and system not accept my requests to git cloning.

So is pagure running under the gitolite user? (That's a setting the wsgi file)

Do you see the key being written in ~/.gitolite/keydir?

Pagure and gitolite running under git user.

Yes, all works OK, but ~/.ssh/autrorized_keys does not updated

That's something that gitolite generates itself when compiling, is the configuration for the gitolite version, home, bindir correct in pagure?

Which version of gitolite do you have?

gitolite located at /home/git/bin/

pagure.cfg contain next parameters:

GITOLITE_HOME = "/home/git"

GITOLITE_VERSION = 3

GITOLITE_KEYDIR = "/home/git/.gitolite/keydir"

GL_RC = "/home/git"

GL_BINDIR = "/home/git/bin/"

Hm, do you see anything in gitolite's logs?

What if you run the command yourself, does it update the authorized_keys file?

Yehh, I ran gitolite setup and authorized_keys was update =(

but it's not setup that's called by pagure, it's :

HOME=... gitolite compile && HOME=.. gitolite trigger POST_COMPILE

where I need to make changes for automatically execute this operation?

This should be done automatically, there is an option to trigger it manually in the admin panel (you'll have to update the DB to add yourself to the group you're listing as the admin group in the configuration)

Can you share link to documentation about "admin panel" and "add yourself to the admin group"?

There isn't anything in the doc about this for the moment I believe.

Pagure's configuration file provides a key to list admin groups: https://pagure.io/pagure/blob/master/f/files/pagure.cfg.sample#_19-20
If you're using openid or FAS to authenticate, the group would be given by the OpenID provider or FAS.
If you're using the local authentication system (which I guess is what you're using), then you will have to create a group in the DB and add yourself to it (cf the pagure_group and pagure_user_group tables). This will add in the top bar, near the button to login an Admin link that offers you a few options.

Thank you.
But, this was not automatically too...
Do you planing to using background worker for automatically updating?

Which prt wasn't automated? The group addition? The gitolite compile? Because this last one should be done by pagure, it's in the code: https://pagure.io/pagure/blob/master/f/pagure/lib/git.py#_124-154 and I am quite curious why this isn't being executed :/

Ok so is this ticket solved or is there still a problem?

I'm going to close this ticket, if you still have some questions/problems feel free to re-open it or if you're on IRC feel free to drop by #fedora-apps on freenode and we can try debugging them live :)

Thanks for you reports, it's highly appreciated!

Yes, this issue was solved. Thank You.

@pingou I just noticed this issue is still occurring on pagure 5.1.4. Adding a new user or deleting a user from a project does not update the /srv/git/.ssh/authorized_keys file. I can update the file by manually running gl-setup-authkeys -batch /srv/git/.gitolite/keydir/keys_0 as the git user but I don't want to do this every time a user is added or removed from a project.

Is there a service that needs to be running or enabled to update the authorized keys file automatically?

Do you have the pagure_gitolite_worker service running? That's what handles this...

@ngompa The service is running and does not show any errors or activity at all.

● pagure_gitolite_worker.service - Pagure worker for backend git interaction
   Loaded: loaded (/usr/lib/systemd/system/pagure_gitolite_worker.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2019-02-19 17:08:58 EST; 3min 27s ago
     Docs: https://pagure.io/pagure
 Main PID: 30239 (celery)
   CGroup: /system.slice/pagure_gitolite_worker.service
           ├─30239 /usr/bin/python2 /usr/bin/celery worker -A pagure.lib.tasks --loglevel=info -c 1 -Q gitolite_queue
           └─30247 /usr/bin/python2 /usr/bin/celery worker -A pagure.lib.tasks --loglevel=info -c 1 -Q gitolite_queue
Feb 19 17:08:59 pagure.example.com celery[30239]: . pagure.lib.tasks.update_git
Feb 19 17:08:59 pagure.example.com celery[30239]: . pagure.lib.tasks.update_pull_request
Feb 19 17:08:59 pagure.example.com celery[30239]: . pagure.lib.tasks_services.load_json_commits_to_db
Feb 19 17:08:59 pagure.example.com celery[30239]: . pagure.lib.tasks_services.log_commit_send_notifications
Feb 19 17:08:59 pagure.example.com celery[30239]: . pagure.lib.tasks_services.trigger_ci_build
Feb 19 17:08:59 pagure.example.com celery[30239]: . pagure.lib.tasks_services.webhook_notification
Feb 19 17:08:59 pagure.example.com celery[30239]: 2019-02-19 17:08:59,739 [INFO] celery.worker.consumer.connection: Connected to redis://127.0.0.1:6379//
Feb 19 17:08:59 pagure.example.com celery[30239]: 2019-02-19 17:08:59,752 [INFO] celery.worker.consumer.mingle: mingle: searching for neighbors
Feb 19 17:09:00 pagure.example.com celery[30239]: 2019-02-19 17:09:00,775 [INFO] celery.worker.consumer.mingle: mingle: all alone
Feb 19 17:09:00 pagure.example.com celery[30239]: 2019-02-19 17:09:00,788 [INFO] celery.apps.worker: celery@pagure.example.com ready.

One thing to note is that we are using gitolite2, should I update the server to use gitolite3?

@wattersmt I don't know if anyone has actually been using gitolite2 much, so I suggest migrating to gitolite3. This is available in EPEL7 alongside pagure itself.

@ngompa I'll have to look into upgrading to gitolite3 later. I'm more interested in why the pagure_gitolite_worker server isn't doing its job in the first place.

Did you set GITOLITE_CELERY_QUEUE in the configuration file? Otherwise the gitolite tasks are processed by the regular workers not by the gitolite_worker.

The command ran is: GL_RC=... GL_BINDIR=... gl-compile-conf