[ I write this for I found the solution applied to my case at the 3rd link of the 2nd page of my Google search. I had never gone beyond the first page for years. ]
So there was this gitosis repository that lived on an Ubuntu server that had to move to a CentOS one.
Thankfully EPEL still carries gitosis and I did not built it from the source. I copied over the files and was done with it.
That is until I needed to change access to one of the repositories to add a user. Said user was denied any kind of access with:
ERROR:gitosis.serve.main:Repository read access denied
There are plenty of reasons for this occur (examples), but none seemed to fit in my case, so I brute forced the search results. And at the first comment that was posted on the third link at the second page Google came up with, the solution was found.
# cd ~gitosis/repositories/gitosis-admin.git/hooks/
# ls -l
-rwxr-xr-x 1 gitosis gitosis 452 Sep 11 2011 applypatch-msg.sample
-rwxr-xr-x 1 gitosis gitosis 896 Sep 11 2011 commit-msg.sample
-rwxr-xr-x 1 gitosis gitosis 160 Sep 11 2011 post-commit.sample
-rwxr-xr-x 1 gitosis gitosis 552 Sep 11 2011 post-receive.sample
lrwxrwxrwx 1 gitosis gitosis 61 Dec 21 09:53 post-update -> /usr/share/pyshared/gitosis/templates/admin/hooks/post-update
-rwxr-xr-x 1 gitosis gitosis 189 Sep 11 2011 post-update.sample
-rwxr-xr-x 1 gitosis gitosis 398 Sep 11 2011 pre-applypatch.sample
-rwxr-xr-x 1 gitosis gitosis 1578 Sep 11 2011 pre-commit.sample
-rwxr-xr-x 1 gitosis gitosis 4971 Sep 11 2011 pre-rebase.sample
-rwxr-xr-x 1 gitosis gitosis 1239 Sep 11 2011 prepare-commit-msg.sample
-rwxr-xr-x 1 gitosis gitosis 3611 Sep 11 2011 update.sample
Yeah, you’ve guessed it by now:
did not exist on CentOS but
did. Fixing the symbolic link fixed the problem.
/* Oh what fun it is to chase bugs into the night */
I think I wrote the following playbook a few months ago, when I was halfway through watching the 2 hour introduction (now replaced with this):
- name: automatic deploy new version
- name: stop monit
command: service monit stop
- name: checkout correct version
command: chdir=/workspace/project git checkout release-1.0
- name: grab latest sources for that release
command: chdir=/workspace/project git pull origin release-1.0
- name: run db:migrate
- name: restart apache
command: service httpd restart
- name: start monit
command: service monit start
What the above playbook does is simple:
– Stop monit to avoid any automatic restarts when you’re half way through updating stuff that it monitors.
– It makes sure that you grab the latest updates from the correct branch
– It runs a script on all servers that takes care of any bundle install and db:migrate stuff.
– It restarts apache. Yes, a touch tmp/restart.txt should do the trick but sometimes it does not.
– It restarts monit.
There is plenty of room for improvement here, for example using the git module instead of running an explicit command and even making use of roles as the project expands and becomes more demanding and of course get rid of the script in favor of a more ansible specific play.
So why post it now? Basically at the request of @nanobeep and as a means of self-pressure to improve the playbook. Maybe I should promise this to someone?
So there, nothing complex or elaborate. BTW, here is a similar way to do this with git and Capistrano that I bumped into.