Did you by any chance figure out something about why you got permission denied? I'm pretty sure it in fact is a SELinux issue.
In my case it definitely is an issue with SELinux. I followed the official gitlab instructions here: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache#selinux-modifications But had to make the following changes: $ setsebool -P httpd_can_network_connect on $ setsebool -P httpd_can_network_relay on $ setsebool -P httpd_can_network_relay on $ setsebool -P httpd_read_user_content on $ semanage -i - <<EOF $ fcontext -a -t user_home_dir_t '/var/opt/gitlab(/.*)?' $ fcontext -a -t ssh_home_t '/var/opt/gitlab/.ssh(/.*)?' $ fcontext -a -t httpd_sys_content_t '/opt/gitlab/embedded/service/gitlab-rails/public(/.*)?' $ fcontext -a -t httpd_sys_content_t '/var/opt/gitlab/git-data/repositories(/.*)?' $ EOF all as sudo. Next step was to create the policy package with the help of this guide: http://axilleas.me/en/blog/2013/selinux-policy-for-nginx-and-gitlab-unix-socket-in-fedora-19/ Furthermore I had to add the following audit policy. The problem with the "grep nginx /var/log/audit/audit.log" is, that it doesn't return anything as long as no access to the socket happens. As I have an unattended installation with an ansible playbook, I therefor had to automate the creation of the policy package by doing the following: $ echo "module nginx 1.0; require { type httpd_t; type var_t; type user_home_t; type user_home_dir_t; class sock_file write; } #============= httpd_t ============== #!!!! This avc is allowed in the current policy allow httpd_t user_home_dir_t:sock_file write; #!!!! This avc is allowed in the current policy allow httpd_t user_home_t:sock_file write; #!!!! This avc is allowed in the current policy allow httpd_t var_t:sock_file write;" >> /tmp/gitlab_nginx.te $ checkmodule -M -m -o /tmp/gitlab_nginx.mod /tmp/gitlab_nginx.te $ semodule_package -o /tmp/gitlab_nginx.pp -m /tmp/gitlab_nginx.mod $ semodule -i /tmp/gitlab_nginx.pp And then I ran: $ /usr/sbin/restorecon -R /var/opt/gitlab/ $ /usr/sbin/restorecon -R /opt/gitlab/ Not sure if the last statement is necessary I hope that helps. Adrian On Monday, February 16, 2015 at 12:48:19 AM UTC+1, Casper Færgemand wrote: > > It's apparently not SELinux complaining, it's the file permission for the > socket. > As root: > > # head /var/opt/gitlab/gitlab-rails/tmp/sockets/gitlab.socket > head: cannot open `/var/opt/gitlab/gitlab-rails/tmp/sockets/gitlab.socket' > for reading: No such device or address > > # sudo -u nginx head /var/opt/gitlab/gitlab-rails/tmp/sockets/gitlab.socket > head: cannot open `/var/opt/gitlab/gitlab-rails/tmp/sockets/gitlab.socket' > for reading: Permission denied > > I tried adding nginx to the git group, tried setting the gitlab-www group > which nginx is in as group owner of the file and the directory it's in, but > it doesn't seem to matter. But at least it's not SELinux. > > > > Den lørdag den 14. februar 2015 kl. 13.06.05 UTC+1 skrev Casper Færgemand: >> >> I'm afraid "grep nginx /var/log/audit/audit.log" returns nothing. In fact >> "grep failure /var/log/audit/audit.log" also returns nothing. Any clue? >> >> Den lørdag den 14. februar 2015 kl. 11.55.06 UTC+1 skrev Achilleas Pipis: >>> >>> On 14/02/2015 04:19 πμ, Casper Færgemand wrote: >>> > I have Omnibus Gitlab running with the default Nginx disabled on a >>> > Centos 6.5 x64 machine. My other Nginx logs the following error: >>> > >>> > 2015/02/14 02:01:36 [crit] 3669#0: *155 connect() to >>> > unix:/var/opt/gitlab/gitlab-rails/tmp/sockets/gitlab.socket failed >>> (13: >>> > Permission denied) while connecting to upstream, client: 10.215.76.40, >>> > server: gitlab.domain.net, request: "GET / HTTP/1.1", upstream: >>> > >>> "http://unix:/var/opt/gitlab/gitlab-rails/tmp/sockets/gitlab.socket:/";, >>> > host: "gitlab.domain.net" >>> > >>> > "ls -la /var/opt/gitlab/gitlab-rails/tmp/sockets/" gives me: >>> > >>> > "total 8 >>> > drwx------. 2 git root 4096 Dec 5 15:51 . >>> > drwx------. 4 git root 4096 Dec 5 12:14 .. >>> > srwxrwxrwx. 1 git git 0 Dec 5 15:51 gitlab.socket" >>> > >>> > "groups nginx" returns "nginx : nginx gitlab-www". >>> > >>> > /etc/gitlab/gitlab.rb contains >>> > >>> > "external_url 'https://gitlab.domain.net' >>> > redis['port'] = 1234 >>> > postgresql['port'] = 5432 >>> > nginx['enable'] = false >>> > web_server['external_users'] = ['gitlab-www']" >>> > >>> > On loading gitlab in a browser, I get a "502, Gitlab is not >>> responding." >>> > as well as a error in the log as listed above. >>> > >>> > The guide >>> > >>> https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md#using-a-non-bundled-web-server >>> >>> > refers to another guide here >>> > >>> https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/nginx.md#using-a-non-bundled-web-server >>> >>> > which seems outdated. Any help as to what I should change to make >>> > SELinux accept Nginx reading the Gitlab socket? I do not what to turn >>> > off the firewall. >>> >>> I had the same trouble almost 2 years ago and I had written a small >>> guide on making a SELinux policy for nginx [0]. >>> >>> Bottom line is: >>> >>> yum install -y policycoreutils-{python,devel} >>> grep nginx /var/log/audit/audit.log | audit2allow -M gitlab_nginx >>> semodule -i gitlab_nginx.pp >>> usermod -a -G git nginx >>> >>> >>> [0] >>> >>> http://axilleas.me/en/blog/2013/selinux-policy-for-nginx-and-gitlab-unix-socket-in-fedora-19/ >>> >>> >>> >>> -- >>> GPG : 0x3A7DDABC985EDC6E >>> Blog: http://axilleas.me >>> >> -- You received this message because you are subscribed to the Google Groups "GitLab" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/gitlabhq/ae23fa6d-0921-4b85-aa9e-91a153737188%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
