I've successfully installed GitLab for management of private repositories (it's quite awesome!).
The problem I am having is by default, Gitlab login is presented when anyone hits my subdomain. I would like to protect the entire area with a basic_auth layer before the user gets the GitLab login screen. Unfortunately, this breaks my ability to push/pull from GitLab when it's enabled.
my nginx config to enable basic_auth:
auth_basic "Restricted";
auth_basic_user_file htpasswd;
Any ideas on how I can enable basic_auth without breaking git / gitlab functionality?
Add this to /etc/gitlab/gitlab.rb:
nginx['custom_gitlab_server_config'] = "auth_basic 'Restricted';\n auth_basic_user_file htpasswd;\n"
And run gitlab-ctl reconfigure
Kind of a hack at the moment but give this is a shot.
Edit your nginx site configuration to add / modify the following locations
location ^~ /api/v3/internal/allowed {
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 X-Forwarded-Proto $scheme;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass http://gitlab;}
location / {
auth_basic "Gitlab Restricted Access";
auth_basic_user_file /home/git/gitlab/htpasswd.users;
# 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;
}
Leaving your #gitlab location block as is.
The trick is you let /api/v3/internal/allowd bypass the authentication. If you look at the logs when you do an git pull / push a request is made to the server whether or not to allow it. And on the standard nginx config with htpasswd that request would be blocked because the server has no idea about the authentication required.
Anyway not sure if there's a better alternative (couldn't find any) but this seems to work for me.
Your issue is that you want set a password restriction for public access to GitLab, but let Gitlab-Shell access the local GitLab instance without restriction.
You can have 2 nginx configurations depending on the IP interface. Change the line listen 0.0.0.0:80 default_server to listen 127.0.0.1:80 default_server.
https://github.com/gitlabhq/gitlabhq/blob/v7.7.2/lib/support/nginx/gitlab#L37-38
Related
I have set up a reverse proxy with the following code in nginx:
server {
listen 80;
server_name domain.com;
server_name www.domain.com;
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://ip-of-server:80;
}
}
Is it possible to let users only access my main server via domain.com/?some-secret-token and not let them access it if they are going to domain.com directly? In best case, the secret-token would also disappear from URL after they open it. I know it would be possible within my homepage script - but can I also configure my nginx in such a way without changing script files?
Don't think this is possible with pure nginx. You can, however, set up basic authentication on your url with something like this after you've properly configured a .htpasswd file:
location / {
auth_basic "Private";
auth_basic_user_file /etc/nginx/.htpasswd;
}
Full details of how to set this up are available here.
It is on an amazon server so I checked the following post:
Changing Apache document root on AWS EC2 does not work
and
How to edit httpd.conf file in AMAZON EC2
or in general: How do I change the root directory of an apache server?
Well the information provided did help me so far.
The only file I could find in the etc/apache2 folder is the following:
Edit: The content of the config file is:
"Alias /javascript /usr/share/javascript/
Options FollowSymLinks MultiViews
"
I asked two month ago on his site: http://www.louisaslett.com/RStudio_AMI/, but didnt get an answer.
My question: How can i change the document root on an RStudio AMI server, so that I can change the directory of the rstudio login page away from the root directory to - say - domain.com/login and have a landing page + other folders on the root (domain.com).
Thank you for your help!
Edit:
After the answer from Frédéric Henri and edit:
Here is the content of my rstudio.conf file.
location / {
proxy_pass http://localhost:8787;
proxy_redirect http://localhost:8787/ $scheme://$host/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 20d;
access_log /var/log/nginx/rstudio-access.log;
error_log /var/log/nginx/rstudio-error.log;
}
Assuming i have the index.html file in the directory /home/idx/index.html, how would i change the file then.
The following didnt work for me:
proxy_pass http://localhost/home/idx;
proxy_redirect http://localhost/home/idx/ $scheme://$host/;
Or:
proxy_pass /home/idx;
proxy_redirect /home/idx/ $scheme://$host/;
and where would i configure to redirect my rstudio login to.
Thank you!
You are right and looking at the right place if you were using apache2/httpd web server; but in the case of the RStudio AMI it uses nginx web server so all configuration are stored in /etc/nginx
You can review Configure nginx with multiple locations with different root folders on subdomain to see how you can work with the conf file
In your current configuration, it is defined mainly 3 locations:
http://<web_server_ip>/
The conf file used for this case is /etc/nginx/RStudioAMI/rstudio.conf It processes all request and forward to http://localhost:8787 where rstudio is running.
http://<web_server_ip>/julia
The conf file used for this case is /etc/nginx/RStudioAMI/julia.conf It processes all request and forward to http://localhost:8000 where julia is running.
http://<web_server_ip>/shiny
The conf file used for this case is /etc/nginx/RStudioAMI/shiny.conf It processes all request and forward to http://localhost:3838 where shiny is running.
For example you could have the main location (which is simply / pointing to a specific folder) and changed the rstudio.conf to handle http://<web_server_ip>/rstudio
EDIT
where would i configure to redirect my rstudio login to
If you want the rstudio login page to be accessible from http://<server>/rtudio (for example) you would need to change in the `/etc/nginx/RStudioAMI/rstudio.conf``
location /rstudio/ {
proxy_pass http://localhost:8787/;
proxy_redirect http://localhost:8787/ $scheme://$host/;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 20d;
access_log /var/log/nginx/rstudio-access.log;
error_log /var/log/nginx/rstudio-error.log;
}
If you want to point the main http://<server>/index.html pointing to /home/idx/index.html you need to change in /etc/nginx/sites-enabled/RStudioAMI.conf and have a main location defined pointing to your root element
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
server {
listen 80 default_server;
index index.html;
location = / {
root /var/www/html;
}
include /etc/nginx/RStudioAMI/*.conf;
}
Note: Anytime you make a change to a nginx conf file, you need to restart nginx.
with: /etc/init.d/nginx restart.
I am looking at the nginx configuration to set up a docker repository
###########################################################
## this configuration was generated by JFrog Artifactory ##
###########################################################
## add ssl entries when https has been set in config
ssl_certificate /etc/nginx/ssl/demo.pem;
ssl_certificate_key /etc/nginx/ssl/demo.key;
ssl_session_cache shared:SSL:1m;
ssl_prefer_server_ciphers on;
## server configuration
server {
listen 443 ssl;
listen 80 ;
server_name ~(?<repo>.+)\.art.local art.local;
if ($http_x_forwarded_proto = '') {
set $http_x_forwarded_proto $scheme;
}
## Application specific logs
## access_log /var/log/nginx/art.local-access.log timing;
## error_log /var/log/nginx/art.local-error.log;
rewrite ^/$ /artifactory/webapp/ redirect;
rewrite ^/artifactory/?(/webapp)?$ /artifactory/webapp/ redirect;
rewrite ^/(v1|v2)/(.*) /artifactory/api/docker/$repo/$1/$2;
chunked_transfer_encoding on;
client_max_body_size 0;
location /artifactory/ {
proxy_read_timeout 900;
proxy_pass_header Server;
proxy_cookie_path ~*^/.* /;
proxy_pass http://localhost:8081/artifactory/;
proxy_set_header X-Artifactory-Override-Base-Url $http_x_forwarded_proto://$host:$server_port/artifactory;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Why is the location directive set to /artifactory Vs / the root location
The location directive is /artifactory/ and not / because you are using a public context. That is to say, all access to Artifactory will be in the form of servername/artifactory/ and not servername/. This has the advantage that you can use the same URL for multiple applications, for example, something like this:
Artifactory -> servername/artifactory/
Jenkins -> servername/jenkins/
My Custom Service -> servername/myapp/
In other words, it allows you to reuse the same servername (and port) with different contexts for different applications. If your reverse proxy was listening at the root level, all the requests would be forwarded to Artifactory.
Now to answer your specific question, why does Artifactory do this? That is likely for clarity/consistency since the default tomcat shipped with Artifactory uses the artifactory keyword for its context. You are of course free to remove the public context from the NGINX configuration and everything will work as expected with the root context servername/, provided you make all the necessary changes (removing it from the rewrites, location, and X-Artifactory-Override-Base-Url).
Wow, this is old but ranked high on Jfrogs 'Community' Portal. Basically if you are trying to configure a reverse proxy in front of Artifactory you will have an uphill job. From Artifactory 7.x they split out ui functions and api functions across ports 8082 and 8081. Maybe good for some technical reason, but really bad for anyone trying to configure a reverse proxy in front of it. Our only currently working nginx configurations are in front of Artifactory 6.x implementations. In 7.x they made things even harder by pulling the reverse proxy config generator. The examples they have for both nginx and haproxy today on their website DO NOT WORK. The haproxy example is closest but uses old syntax that has been update in past years (regirp becomes http-request replace-path). Honestly, we are looking for alternatives to Artifactory due to lack of real support on the Internet apart from additional paid service level plans above the license cost.
I have setup a reverse proxy between Nginx and Artifactory, following instructions from here : https://www.jfrog.com/confluence/display/RTF/nginx
I've also enabled HTTP SSO in Artifactory so that a user authenticated by Artifactory is able to log in to Artifactory automatically. Instructions followed from here : https://www.jfrog.com/confluence/display/RTF/Single+Sign-on
Everything is working except that Artifactory is really slow. When I go to the website (eg. artifactory.myorg.com/webapp/#/home,) a progress wheel comes up and it keeps rolling and on every page.
If I turn off Nginx and access Artifactory using its embedded Tomcat engine then everything works fine.
Is there anything I can do to fix this ?
Update
The browsing is fine as soon as I turn off the following setting:
proxy_set_header REMOTE_USER $remote_user;
I am guessing that Artifactory is currently processing this user setting for every request and maybe I need to do something at Tomcat side or to Artifactory settings to resolve that.
Here's how my nginx/artifactory config looks (They were generated by Reverse Proxy setup page in Artifactory 4.4):
ssl_certificate /etc/ssl/certs/dummy.crt;
ssl_certificate_key /etc/ssl/keys/dummy.key;
ssl_session_cache shared:SSL:1m;
ssl_prefer_server_ciphers on;
server {
listen 443 ssl;
server_name dummy.net;
if ($http_x_forwarded_proto = '') {
set $http_x_forwarded_proto $scheme;
}
## Application specific logs
access_log /var/log/nginx/dummy-access.log;
error_log /var/log/nginx/dummy-error.log;
rewrite ^/$ /artifactory/webapp/ redirect;
rewrite ^/artifactory$ /artifactory/webapp/ redirect;
location /artifactory/ {
auth_pam "Secure Zone";
auth_pam_service_name "sevice";
proxy_read_timeout 900;
proxy_pass_header Server;
proxy_cookie_path ~*^/.* /;
proxy_pass http://127.0.0.1:8081/artifactory/;
proxy_set_header DUMMY_USER $remote_user;
proxy_set_header X-Artifactory-Override-Base-Url $http_x_forwarded_proto://$host:$server_port/artifactory;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Yes. Using Nginx as a reverse proxy should not add noticeable overhead, and could speed up the experience if you use it to serve the static assets.
Your testing so far as implicated Nginx, so posting your related Nginx configuration would be helpful.
But I'll go out a limb and make a guess without seeing it. You are likely using proxy_pass in Nginx to send requests on to Artifactory. If Artifactory is on the same host as Nginx, the proxy_pass address should be a port on 127.0.0.1. If you are instead including a domain name there, then your traffic might doing some like being routed from Nginx back to a load balancer, through CloudFlare, or some other inefficient route.
After trying to reproduce your scenario a few times would recommend to try one more thing to isolate the problem.
Try to set a fix username in the REMOTE_USER value, instead of a variable.
proxy_set_header REMOTE_USER username;
BTW, from the snippet it appears the header name is DUMMY_USER and in the example you specified REMOTE_USER. Make sure you the header name is the same as configured in Artifactory under the Admin > Security | HTTP-SSO .
If this issue still reproduces, please contact support#jfrog.com.
I have Gitlab 5.2 + Nginx installed on a local machine in my university. Clone over http works for machines that are within the internal network, but trying to clone from a machine on an external network results in an "fatal: Authentication failed" message, even though the exact same credentials are supplied. (I use the same credentials as the ones I use to log in to Gitlab via the web interface)
The Gitlab web interface is accessible from external networks. It is only the clone over http that fails (clone over ssh is not possible because port 22 is blocked)
Here are some lines from the relevant configuration files:
from config/gitlab.yml
host: mydomain
port: 80
https: false
Here are the relevant lines from the ngnix config file
server {
listen *:80 default_server; # In most cases *:80 is a good idea
server_name mydomain; # e.g., server_name source.example.com;
root /home/git/gitlab/public;
# individual nginx logs for this gitlab vhost
access_log /var/log/nginx/gitlab_access.log;
error_log /var/log/nginx/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 2000; # https://github.com/gitlabhq/gitlabhq/issues/694
proxy_connect_timeout 2000; # https://github.com/gitlabhq/gitlabhq/issues/694
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_pass http://gitlab;
}
}
Note: I have added this line to /etc/hosts: 127.0.0.1 mydomain but it doesn't really help. (based on https://github.com/gitlabhq/gitlabhq/issues/3483#issuecomment-15783597)
Any ideas on what the issue might be/how I might debug this?
I believe this is fixed in 5.3, so try updating. See:
https://github.com/gitlabhq/gitlabhq/blob/master/CHANGELOG#L41
https://github.com/gitlabhq/gitlabhq/blob/master/config/gitlab.yml.example#L151