One other thing: I need to change self_signed_cert: false in /opt/gitlab/embedded/service/gitlab-shell/config.yml to self_signed_cert: true
I've tried to do it as with gitlab_rails settings: to /etc/gitlab/gitlab.rb I've added gitlab_shell[http_settings_self_signed_cert] = true then I executed gitlab-ctl reconfigure but it didn't change that setting any help? On Saturday, 19 April 2014 01:00:33 UTC+11, Александр Костырев wrote: > > silly me) > know it's working! > > thank you for you support! > > On Saturday, 19 April 2014 00:32:25 UTC+11, Jacob Vosmaer wrote: >> >> Try: >> >> external_url 'https://gitlab.local' >> >> >> >> Best regards, >> >> Jacob Vosmaer >> GitLab.com >> >> >> 2014-04-18 14:51 GMT+02:00 Александр Костырев <[email protected]>: >> >>> I thought that this problem arised because the rpm for centos had been >>> built with a rather old git repo >>> so I've rebuilt gitlab with instructions from here >>> >>> https://gitlab.com/gitlab-org/omnibus-gitlab/tree/03767a32d55690a54dfb3c640dbbf028202065ec >>> >>> but it didn't resolve that problem - I still can't get no https >>> with >>> external_url "http://gitlab.local"; >>> nginx['redirect_http_to_https'] = true >>> nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.crt" >>> nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.key" >>> >>> Any advice what should I modify? >>> >>> On Friday, 18 April 2014 20:48:42 UTC+11, Sytse Sijbrandij wrote: >>> >>>> CentOS is supported, https will be supported in the 6.8 packages >>>> >>>> On Fri, Apr 18, 2014 at 10:17 AM, Александр Костырев >>>> <[email protected]> wrote: >>>> > But isn't CentOS suppored? >>>> > I do not want to manually configure gitlab since they provided >>>> official >>>> > omnibus packages? >>>> > >>>> > Did anybody find out any workaround? >>>> > >>>> > >>>> > On Tuesday, 25 March 2014 17:29:51 UTC+11, Reinhard Fischer wrote: >>>> >> >>>> >> Hi, >>>> >> >>>> >> we had the same problems, finding no solution. The least ugly >>>> workaround >>>> >> we found in our hurry was: >>>> >> >>>> >> gitlab-ctl reconfigure uses >>>> >> /opt/gitlab/embedded/cookbooks/gitlab/templates/ >>>> default/nginx-gitlab-http.conf.erb >>>> >> as an input to create its config files, so we simply changed that >>>> one, to >>>> >> e.g.: >>>> >> >>>> >> # GITLAB >>>> >> # Maintainer: @randx >>>> >> >>>> >> # CHUNKED TRANSFER >>>> >> # It is a known issue that Git-over-HTTP requires chunked transfer >>>> >> encoding [0] which is not >>>> >> # supported by Nginx < 1.3.9 [1]. As a result, pushing a large >>>> object with >>>> >> Git (i.e. a single large file) >>>> >> # can lead to a 411 error. In theory you can get around this by >>>> tweaking >>>> >> this configuration file and either >>>> >> # - installing an old version of Nginx with the chunkin module [2] >>>> >> compiled in, or >>>> >> # - using a newer version of Nginx. >>>> >> # >>>> >> # At the time of writing we do not know if either of these >>>> theoretical >>>> >> solutions works. As a workaround >>>> >> # users can use Git over SSH to push large files. >>>> >> # >>>> >> # [0] >>>> >> https://git.kernel.org/cgit/git/git.git/tree/ >>>> Documentation/technical/http-protocol.txt#n99 >>>> >> # [1] https://github.com/agentzh/chunkin-nginx-module#status >>>> >> # [2] https://github.com/agentzh/chunkin-nginx-module >>>> >> >>>> >> upstream gitlab { >>>> >> server unix:<%= @socket %>; >>>> >> } >>>> >> >>>> >> server { >>>> >> listen *:80; >>>> >> server_name <%= @fqdn %>; # e.g., server_name >>>> source.example.com; >>>> >> server_tokens off; >>>> >> root /nowhere; # this doesn't have to be a valid path since we >>>> are >>>> >> redirecting, you don't have to change it. >>>> >> rewrite ^ https://$server_name$request_uri permanent; >>>> >> } >>>> >> >>>> >> #server { >>>> >> # listen *:80 default_server; # e.g., listen 192.168.1.1:80; >>>> In >>>> >> most cases *:80 is a good idea >>>> >> # server_name <%= @fqdn %>; # e.g., server_name >>>> source.example.com; >>>> >> # server_tokens off; # don't show the version number, a >>>> security best >>>> >> practice >>>> >> # root /opt/gitlab/embedded/service/gitlab-rails/public; >>>> >> # >>>> >> # # Increase this if you want to upload large attachments >>>> >> # # Or if you want to accept large git objects over http >>>> >> # client_max_body_size 5m; >>>> >> # >>>> >> # # individual nginx logs for this gitlab vhost >>>> >> # access_log <%= @log_directory %>/gitlab_access.log; >>>> >> # error_log <%= @log_directory %>/gitlab_error.log; >>>> >> # >>>> >> # location / { >>>> >> # # serve static files from defined root folder;. >>>> >> # # @gitlab is a named location for the upstream fallback, see >>>> below >>>> >> # try_files $uri $uri/index.html $uri.html @gitlab; >>>> >> # } >>>> >> # >>>> >> # # if a file, which is not found in the root folder is requested, >>>> >> # # then the proxy pass the request to the upsteam (gitlab unicorn) >>>> >> # location @gitlab { >>>> >> # proxy_read_timeout 300; # Some requests take more than 30 >>>> seconds. >>>> >> # proxy_connect_timeout 300; # Some requests take more than 30 >>>> seconds. >>>> >> # proxy_redirect off; >>>> >> # >>>> >> # proxy_set_header X-Forwarded-Proto $scheme; >>>> >> # proxy_set_header Host $http_host; >>>> >> # proxy_set_header X-Real-IP $remote_addr; >>>> >> # proxy_set_header X-Forwarded-For >>>> $proxy_add_x_forwarded_for; >>>> >> # >>>> >> # proxy_pass http://gitlab; >>>> >> # } >>>> >> # >>>> >> # error_page 502 /502.html; >>>> >> #} >>>> >> >>>> >> server { >>>> >> listen 443 ssl; >>>> >> server_name <%= @fqdn %>; # e.g., server_name >>>> source.example.com; >>>> >> server_tokens off; >>>> >> root /opt/gitlab/embedded/service/gitlab-rails/public; >>>> >> >>>> >> ssl on; >>>> >> ssl_certificate /etc/gitlab/ssl/gitlab.crt; >>>> >> ssl_certificate_key /etc/gitlab/ssl//gitlab.key; >>>> >> ssl_protocols SSLv3 TLSv1 TLSv1.2; >>>> >> ssl_ciphers AES:HIGH:!ADH:!MD5; >>>> >> ssl_prefer_server_ciphers on; >>>> >> >>>> >> # individual nginx logs for this gitlab vhost >>>> >> access_log <%= @log_directory %>/gitlab_access.log; >>>> >> error_log <%= @log_directory %>/gitlab_error.log; >>>> >> >>>> >> location / { >>>> >> # serve static files from defined root folder;. >>>> >> # @gitlab is a named location for the upstream fallback, see >>>> below >>>> >> try_files $uri $uri/index.html $uri.html @gitlab; >>>> >> } >>>> >> >>>> >> # if a file, which is not found in the root folder is requested, >>>> >> # then the proxy pass the request to the upsteam (gitlab >>>> unicorn) >>>> >> location @gitlab { >>>> >> proxy_read_timeout 300; # >>>> >> https://github.com/gitlabhq/gitlabhq/issues/694 >>>> >> proxy_connect_timeout 300; # >>>> >> https://github.com/gitlabhq/gitlabhq/issues/694 >>>> >> proxy_redirect off; >>>> >> >>>> >> proxy_set_header Host $http_host; >>>> >> proxy_set_header X-Real-IP $remote_addr; >>>> >> proxy_set_header X-Forwarded-Ssl on; >>>> >> proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; >>>> >> proxy_set_header X-Forwarded-Proto $scheme; >>>> >> >>>> >> proxy_pass http://gitlab; >>>> >> } >>>> >> } >>>> >> >>>> >> then run gitlab-ctl reconfigure. >>>> >> >>>> >> It looks like this hack is working.... Last week I ran across a >>>> patch >>>> >> which is supposed to solve this issue, but I can't find it now. >>>> >> >>>> >> I hope that helps, >>>> >> Reinhard >>>> >> >>>> >> On Tuesday, 18 March 2014 11:38:12 UTC+1, [email protected] wrote: >>>> >>> >>>> >>> Hello >>>> >>> >>>> >>> We installed gitlab-6.6.5_omnibus-1.el6.x86_64.rpm on a CentOS. >>>> Basic >>>> >>> config is fine, once we start to change config like >>>> >>> cat /etc/gitlab/gitlab.rb >>>> >>> external_url "https://gitlab.org"; >>>> >>> nginx['redirect'] = "true" >>>> >>> nginx['ssl_certificate'] = "/etc/gitlab/ssl/gitlab.crt" >>>> >>> nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/gitlab.key" >>>> >>> >>>> >>> >>>> >>> and run gitlab-ctl reconfigure >>>> >>> >>>> >>> it still works on port 80 - but NOT https not redirecting >>>> >>> >>>> >>> although it >>>> >>> gitlab-ctl show-config >>>> >>> Starting Chef Client, version 11.6.0 >>>> >>> Compiling Cookbooks... >>>> >>> { >>>> >>> "gitlab": { >>>> >>> "bootstrap": { >>>> >>> }, >>>> >>> "user": { >>>> >>> "git_user_email": "[email protected]" >>>> >>> }, >>>> >>> "redis": { >>>> >>> }, >>>> >>> "gitlab-rails": { >>>> >>> "secret_token": >>>> >>> "8fbc36531d06c2ef7b58d1f18e7b165f9dd9ffcbddeefb420b0301f469f4 >>>> 52ab65450deaf0bbf5742c3466f51bef87eeb2e14db591861e1338451087bfa77760", >>>> >>> "gitlab_host": "gitlab.org", >>>> >>> "gitlab_email_from": "[email protected]", >>>> >>> "gitlab_https": true, >>>> >>> "gitlab_port": 443 >>>> >>> }, >>>> >>> "gitlab-shell": { >>>> >>> }, >>>> >>> "unicorn": { >>>> >>> }, >>>> >>> "sidekiq": { >>>> >>> }, >>>> >>> "nginx": { >>>> >>> "redirect": "true", >>>> >>> "ssl_certificate": "/etc/gitlab/ssl/gitlab.crt", >>>> >>> "ssl_certificate_key": "/etc/gitlab/ssl/gitlab.key" >>>> >>> }, >>>> >>> "postgresql": { >>>> >>> "sql_password": >>>> >>> "9962d63d88378461274801d8b91a272236d152c86ee0a56d8f48e4353c85 >>>> 962189840d51fecb91107eac61c7ac91918f0045t678f" >>>> >>> } >>>> >>> } >>>> >>> } >>>> >>> Converging 0 resources >>>> >>> Chef Client finished, 0 resources updated >>>> >>> >>>> >>> >>>> >>> >>>> >>> and all these changes can be found in the config files in the >>>> location >>>> >>> e.g. /var/opt/gitlab/nginx/etc >>>> >>> >>>> >>> >>>> >>> Is there anything special to be considered? >>>> >>> >>>> >>> anyone knows about? >>>> >>> kind regards >>>> >>> >>>> > -- >>>> > 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]. >>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>> >> -- 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]. For more options, visit https://groups.google.com/d/optout.
