I have hit a wall trying to fix a problem with my openProject installation. I installed it following the instructions in this guide. Then, I added an A record for my public IP and subdomain using world4you. I also created SSL certificates with Let's Encrypt:
mkdir /var/www/certbot/openproject.invert.at
certbot certonly --webroot -w /var/www/certbot/openproject.invert.at -d openproject.invert.at
Then I created and modified a file named /etc/nginx/sites-enabled/openproject.eeg_invert.de as follows:
server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
# ssl_certificate /etc/letsencrypt/live/openproject.eeg_invert.de/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/openproject.eeg_invert.de/privkey.pem;
access_log /var/log/nginx/access_openproject.eeg_invert.de.log;
error_log /var/log/nginx/error_openproject.eeg_invert.de.log;
server_name openproject.eeg_invert.de;
if ($http_user_agent ~* ".*SemrushBot.*") {return 403;}
location '/.well-known/acme-challenge' {
root /var/www/certbot/openproject.eeg_invert.de;
}
location / {
if ($scheme = http) {
return 301 https://$server_name$request_uri;
}
proxy_set_header X-Script-Name /;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Remote-User $remote_user;
proxy_set_header Host $http_host;
# proxy_redirect http:// https://;
proxy_pass http://localhost:8080;
}
}
I reloaded nginx and everything worked just fine. However, I updated this application using cd /docker/openproject/compose && docker-compose pull && docker-compose up -d and reloaded nginx but now I am getting this message on chrome:
This page isn’t working openproject.eeg_invert.de redirected you too many times.
Try clearing your cookies.
ERR_TOO_MANY_REDIRECTS
I backed up all relevant docker volumes and the entire project folder (where the compose file is located) before updating. I am in no way an expert in IT so what I did so far is to run docker-compose down after updating. Then I restored the project folder and ran docker-compose up -d.
The problem is that now I am still getting the same error. I looked at the nginx error log files, but nothing comes up. I tried disabling some of the options at random from the nginx files to see if that changes something but it is always the same.
I have hit a wall now and I would very much appreciate your help! Thanks in advance for any suggestions or ideas you may have.
Did you try clearing cookies in your browser? There are many reasons why this issue can occur:
Issues with the browser's cache/cookies. The browser may be caching faulty data that leads to the redirection error.
The browser extensions. Sometimes a browser extension can cause a redirection error.
The website's URL. A misconfiguration in URL settings can cause the redirection error.
WordPress cache. The website cache could be causing a redirect loop.
SSL certificate. A misconfigured security protocol (SSL certificate) can cause a redirect loop.
Third-party services and plugins. A faulty WordPress plugin could be causing the redirection loop.
The site's .htaccess file. A user-level configuration file WordPress uses to rewrite URLs to the index.php file. The website URL is defined as a value in the database.
Related
In the past I tried setting up Jfrog Artifactory OSS and was able to get it through my reverse proxy exposed outside my home network, and I was able to push to it VIA my computer local CLI and through Drone CI but it took an abnormal amount of time (roughly 5 min) to push to my own registry when pushing to DockerHub or Gitlab took a matter of seconds.
My container is really small (think MBs) and I never have any issues with pushing it to any other remote registry. I always thought it might have been the registry and the fact it was running on an old machine until now.
I recently discovered my git solution Gitea has a registry built in, so I did the same, I got everything set up and mapped and once again it took an abnormal amount of time (roughly 5 min) to push to my own registry (this time backed by Gitea).
This leads me to think my issues is Nginx Proxy Manager related. I found some documenation online but it was really general and vague, I have the current proxy config below and it still has the issue. Could anyone point me in the right direction? I also included a few other posts related to this issue.
server {
set $forward_scheme http;
set $server "192.168.X.XX";
set $port 3000;
listen 8080;
#listen [::]:8080;
listen 4443 ssl http2;
#listen [::]:4443;
server_name my.domain.com;
# Let's Encrypt SSL
include conf.d/include/letsencrypt-acme-challenge.conf;
include conf.d/include/ssl-ciphers.conf;
ssl_certificate /etc/letsencrypt/live/npm-47/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/npm-47/privkey.pem;
# Force SSL
include conf.d/include/force-ssl.conf;
access_log /data/logs/proxy-host-10_access.log proxy;
error_log /data/logs/proxy-host-10_error.log warn;
#Additional fields I added ontop of the default Nginx Proxy Manager config
proxy_buffering off; proxy_ignore_headers "X-Accel-Buffering";
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
location / {
# Proxy!
include conf.d/include/proxy.conf;
}
# Custom
include /data/nginx/custom/server_proxy[.]conf;
}
I also checked the live logs for Gitea and I see the requests coming real time and processed really fast, but there is always a significant delay before it receives the next request which makes me think the Nginx Proxy Manager is not correctly forwarding the requests or there is some setting that I missed. Any help would be greatly appreciated!
Some of the settings I got to try were from the below sources
Another registry
Another stack overflow suggestion
I'm receiving the error Authentication required after I login in the Wildfly 13 Management Console.
If I type a user or password wrong, it asks again, but if I type correctly it shows the page with the error message (so I assume the user and password are correct, but something else after that gives the error).
I'm using docker to run a nginx container and a wildfly container.
The nginx listens externally on port 9991 and proxy pass the request to the wildfly container, but it shows the error described before.
It just happens with the Wildfly Console, every other request proxied, even request proxied to a websocket or to Wildfly on port 8080, are done successfully.
The Wildfly container listens externally on port 9990 and I can access the console successfully in this port. If on docker I map the port "9992:9990" I still can access the console successfully through port 9992.
So, it seems that this is not related to docker, but to the Wildfly Console itself. Probably some kind of authentication that is not happening successfully when using a reverse proxy in the middle.
I have a demo docker project on https://github.com/lucasbasquerotto/pod/tree/0.0.6, and you can download the tag 0.0.6 that has everything setup to work with Wildfly 13 and nginx, and to simulate this error.
git clone -b 0.0.6 --single-branch --depth 1 https://github.com/lucasbasquerotto/pod.git
cd pod
docker-compose up -d
Then, if you access the container directly in http://localhost:9990 with user monitor and password Monitor#70365 everything works.
But if you access http://localhost:9991 with the same credentials, through the nginx reverse proxy, you receive the error.
My nginx.conf file:
upstream docker-wildfly {
server wildfly:9990;
}
location / {
proxy_pass http://docker-wildfly;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
I've also tried with:
proxy_set_header X-Forwarded-Proto $scheme;
And also with the Authorization header (just the 2nd line and also with both):
proxy_set_header Authorization $http_authorization;
proxy_pass_header Authorization;
And also defining the host header with the port (instead of just $host):
proxy_set_header Host $server_addr:$server_port;
I've tried the above configurations isolated and combined together. All to no avail.
Any sugestions?
Has anyone successfully accessed the Wildfly Console through a reverse proxy?
Update (2018-09-22)
It seems Wildfly uses a digest authentication (instead of basic).
I see the header in the console like the following:
Authorization: Digest username="monitor", realm="ManagementRealm", nonce="AAAAAQAAAStPzpEGR3LxjJcd+HqIX2eJ+W8JuzRHejXPcGH++43AGWSVYTA=", uri="/console/index.html", algorithm=MD5, response="8d5b2b26adce452555d13598e77c0f63", opaque="00000000000000000000000000000000", qop=auth, nc=00000005, cnonce="fe0e31dd57f83948"
I don't see much documentation about using nginx to proxy pass requests with digest headers (but I think it should be transparent).
One question I saw here in SO is https://serverfault.com/questions/750213/http-digest-authentication-on-proxied-server, but there is no answer so far.
I saw that there is the nginx non-official module https://www.nginx.com/resources/wiki/modules/auth_digest/, but in the github repository (https://github.com/atomx/nginx-http-auth-digest) it says:
The ngx_http_auth_digest module supplements Nginx's built-in Basic
Authentication module by providing support for RFC 2617 Digest
Authentication. The module is currently functional but has only been
tested and reviewed by its author. And given that this is security
code, one set of eyes is almost certainly insufficient to guarantee
that it's 100% correct. Until a few bug reports come in and some of
the ‘unknown unknowns’ in the code are flushed out, consider this
module an ‘alpha’ and treat it with the appropriate amount of
skepticism.
Also it doesn't seem to me allright to hardcode the user and pass in a file to be used by nginx (the authentication should be transparent to the reverse proxy in this case).
In any case, I tried it and it correctly asks me to authenticate, even if the final destination does not have a digest authentication, like when trying to connect to the wildfly site (not console), it asks when trying to connect to nginx (before proxying the request), then it forwards successfully to the destination, except in the case of wildfly console, it keeps asking me to authenticate forever.
So I think this is not the solution. The problem seems to be in what the nginx is passing to the Wildfly Console.
I had the same problem with the HAL management console v3.3 and 3.2
I could not get ngnix HTTPS working due to authentication errors, even though the page prompted http basic auth user and pass
This was tested in standalone mode on the same server
My setup was :
outside (https) -> nginx -> http://halServer:9990/
This resulted in working https but with HAL authentication errors (seen in the browsers console) the webpage was blank.
At first access the webpage would ask http basic auth credentials normally, but then almost all https requests would return an authentication error
I managed to make it work correctly by first enabling the HAL console https with a self signed certificate and then configuring nginx to proxy pass to the HAL HTTPS listener
Working setup is :
outside (https) -> nginx (https) -> https://halServer:9993/
Here is the ngnix configuration
server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
server_name halconsole.mywebsite.com;
# SSL
ssl_certificate /keys/hal_fullchain.pem;
ssl_certificate_key /keys/hal_privkey.pem;
ssl_trusted_certificate /keys/hal_chain.pem;
# security
include nginxconfig.io/security.conf;
# logging
access_log /var/log/nginx/halconsole.mywebsite.com.access.log;
error_log /var/log/nginx/halconsole.mywebsite.com.error.log warn;
# reverse proxy
location / {
# or use static ip, or nginx upstream
proxy_pass https://halServer:9993;
include nginxconfig.io/proxy.conf;
}
# additional config
include nginxconfig.io/general.conf;
include nginxconfig.io/letsencrypt.conf;
}
# subdomains redirect
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name *.halconsole.mywebsite.com;
# SSL
ssl_certificate /keys/hal_fullchain.pem;
ssl_certificate_key /keys/hal_privkey.pem;
ssl_trusted_certificate /keys/hal_chain.pem;
return 301 https://halconsole.mywebsite.com$request_uri;
}
proxy.conf
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;
# Proxy headers
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Forwarded $proxy_add_forwarded;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-By $server_addr;
# Proxy timeouts
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
The easiest way to enable https console is by using the console itself
generate a java JKS keystore using either the command line keytool or a GUI program
I like GUIs, so I used Key Store Explorer https://github.com/kaikramer/keystore-explorer
copy keystore file on the halServer server where it has read access (no need to keep it secret) i placed mine inside wildfly data dir in a "keystore" directory.
# your file paths might differ, don't copy paste
cp /home/someUser/sftp_uploads/managementKS /opt/wildfly/standalone/data/keystore/managementKS
set permissions
# your file paths might differ, don't copy paste
chown --recursive -H wildfly:wildfly /opt/wildfly/standalone/data/keystore
(use vpn) login to cleartext console http://halServer:9990/
add keystore : navigate :
configuration -> subsystems -> security (elytron) -> other settings (click view button)
stores -> keystore -> add
...
Name = managementKS
Type = JKS
Path = keystore/managementKS
Relative to = jboss.server.data.dir
Credential Reference Clear Text = keystore-password click Add
result in standalone.xml
<key-store name="managementKS">
<credential-reference clear-text="keystore-password"/>
<implementation type="JKS"/>
<file path="keystore/managementKS" relative-to="jboss.server.data.dir"/>
</key-store>
add key manager : navigate :
ssl -> key manager -> add
...
Name = managementKM
Credential Reference Clear Text = keystore-password
Key Store = managementKS
result in standalone.xml
<key-manager name="managementKM" key-store="managementKS">
<credential-reference clear-text="keystore-password"/>
</key-manager>
add ssl context : navigate :
ssl -> server ssl context -> add
...
Name = managementSSC
Key Manager = managementKM
...
Edit added : Protocols = TLSv1.2
save
result in standalone.xml
<server-ssl-contexts>
<server-ssl-context name="managementSSC" protocols="TLSv1.2" key-manager="managementKM"/>
</server-ssl-contexts>
go back
runtime -> server (click view button)
http management interface (edit)
set secure socket binding = management-https
set ssl context = managementSSC
save
restart wildfly
systemctl restart wildfly
Hey.
After a few hours of research I couldn't find any easy how-to solutions for my problem.
I have written earlier a RoR app that's deployed on my server and running just fine. Now I'm trying to deploy also a Nodejs app to run alongside my RoR app. The two apps don't have anything to do with each other - they are to be used separately.
I only have one domain to use and I'm trying to use Nginx.
The RoR app is running on Unicorn + Nginx already.
My first question is what is the correct way to deploy two separate apps alongside on the same server?
Should they listen to different ports? Other to port :80 and other to :81 for example?
Or should I alternatively use sub folders? Going for exampleDomain/app1 and exampleDomain/app2?
I also read about an option of creating sub domains, but does this work when running my apps in production?
My RoR app is deployed following these instructions:
https://www.digitalocean.com/community/tutorials/how-to-deploy-a-rails-app-with-unicorn-and-nginx-on-ubuntu-14-04
(as a note I'm using Digital Ocean's virtual server)
Currently my Nginx file looks the following:
upstream app {
# Path to Unicorn SOCK file, as defined previously
server unix:/home/deploy/appname/shared/sockets/unicorn.sock fail_timeout=0;
}
server {
listen 80;
server_name localhost;
root /home/deploy/appname/public;
try_files $uri/index.html $uri #app;
location #app {
proxy_pass http://app;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
}
error_page 500 502 503 504 /500.html;
client_max_body_size 4G;
keepalive_timeout 10;
}
It's a direct copy from the above RoR tutorial. For some reason if I switch the file name it stops working? Even that I couldn't find the file name being defined anywhere.
The file is under /etc/nginx/sites-available/ and named "default".
I tried to follow this tutorial for deploying the Nodejs app:
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-node-js-application-for-production-on-ubuntu-14-04
I get my app running with pm2. And I tried writing the following code in another file in /etc/nginx/sites-available/ and also including the code in the existing default file alongside with the code for RoR but neither of them worked.
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://APP_PRIVATE_IP_ADDRESS:8080;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_cache_bypass $http_upgrade;
}
}
Nginx logs are not showing anything useful either. I ran
sudo tail -f /var/log/nginx/error.log
a couple of times but the logs were empty.
I would be really thankful if someone could give me some guidance which way to go from here.
First question "How to put two apps on same server?".
All those approaches you mentioned will work, but probably the cleanest way for you and potential users would be to use a subdomain. To do this,
1) Decide on your subdomain (ie. nodejs.example.com and ror.example.com) and point both of those to your server.
2) In your 2 ngnix files for each name set the server name to the respective subdomain:
server {
listen 80;
server_name ror.example.com;
# Rest of conf below (pointing to ROR project)
}
And:
server {
listen 80;
server_name nodejs.example.com
# Rest of conf below (pointing to nodejs project)
}
Second Question: "Where do I place these files?"
To see where these files are actually used by nginx, I'd first look at the main nginx.conf file usually in the location: '/etc/nginx/nginx.conf'. There should be 2 lines near the end that tell you where nginx is looking for conf files:
http {
# A bunch of default nginx settings
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
If this is what is in your nginx.conf file, then nginx never will look in the sites-available folder. Where nginx is actually looking is in the two folders: /etc/nginx/conf.d/ and /etc/nginx/sites-enabled What I would suggest is do 3 things:
1) cd into /etc/nginx/sites-enabled folder. Remove the 'default' file.
2) create 2 files, nodejs and ror, and put the resptive nginx configurations into both of those files within the folder: /etc/nginx/sites-enabled.
3) Run:
sudo service nginx reload
sudo service nginx restart
If reload fails, run the following to help debug the configuration:
sudo nginx -t
This will show the file and line number of the issue.
Hope this helps. Comment if you have trouble with any of this.
I'm developing a web site with web.py and nginx which, up until now I have been working on locally with the built in development server. Its now its time to move the site over to a live server. I'd like to deploy the site so the root is something like examples.com/test but all my url handling stuff is broken. I had thought I could create a url_prefix variable and pepper it around the web.py code but that sure seems dirty. It seems like the best thing to do would be to have nginx strip the prefix from the url so the web.py application never sees it but I'm not sure its even possible.
Does anybody know how to handle this situation?
Run the web.py app on a local port using a web server such as gunicorn, then configure nginx to host static files and reverse proxy the gunicorn server. Here are some configuration snippets, assuming that:
your project is in /var/www/example-webpy
your static files are in example-webpy/static
your nginx configuration is in /etc/nginx.
Expose the WSGI object in your application
It looks like web.py doesn't do this by default, so you'll want something like the following in your app.py (or whichever file bootstraps your app):
# For serving using any wsgi server
wsgi_app = web.application(urls, globals()).wsgifunc()
More information in this SO question.
Run your application server
Install gunicorn and start your application by running something like this (where example is the name of your Python module):
gunicorn example:wsgi_app -b localhost:3001
(You'll probably want to automate this using something like Supervisor so that the application server is restarted if your server bounces.)
Configure nginx
Put the following in /etc/nginx/reverse-proxy.conf (see this SO answer)
# Serve / from local http server.
# Just add the following to individual vhost configs:
# proxy_pass http://localhost:3001/;
proxy_pass_header Server;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Scheme $scheme;
proxy_connect_timeout 10;
proxy_read_timeout 10;
Then configure your domain in /etc/nginx/sites-enabled/example.com.conf:
server {
server_name example.com
location /test/ {
include /etc/nginx/reverse-proxy.conf;
rewrite /test/(.*) /$1 break;
proxy_pass http://localhost:3001/;
}
location / {
root /var/www/example-webpy/static/;
}
}
Note the rewrite, which should ensure that your web.py app never sees the /test/ URL prefix. See the nginx documentation on proxy_pass and HttpRewriteModule.
This will result in requests for example.com/js/main.js to map to example-weby/static/js/main.js, so it assumes that your web.py templates didn't add a /static/ prefix. It also results in everything in the static directory becoming visible to the web, so make sure that's what you intend!
I'm following along with a Railscast http://railscasts.com/episodes/293-nginx-unicorn?view=asciicast about setting up Nginx and Unicorn on Vagrant, with one important difference. Ryan's making his application with Rails 3 (that has the default /public/index.html that Rails 4 only generates dynamically). After getting Nginx installed and running, we were able to see the default page on port 8080. We then created a basic config file for Nginx to put in the config directory of the rails application
/config/nginx.conf
server {
listen 80 default;
# server_name example.com;
root /vagrant/public;
}
and then removed the default page in sites enabled and symlinked to the configuration file
vagrant#lucid32:/etc/nginx/sites-enabled$ sudo rm default
vagrant#lucid32:/etc/nginx/sites-enabled$ sudo ln -s /vagrant/config/nginx.conf todo
After this, Ryan restarted nginx and was able to see the Rails index page at localhost:8080. However, when I visit localhost:8080, I'm getting a 403 Forbidden error.
403 Forbidden
nginx/1.1.19
Update
since Rails 4 doesn't have the public/index.html file anymore, I think the 403 error might be caused by that, as I learned from this blog post
http://www.nginxtips.com/403-forbidden-nginx/. It says to set autoindex to on (the default is off) in the config, but I'm not sure how to set it to get the Rails homepage to show.
When I did this
server {
listen 80 default;
root /vagrant/public;
location / {
autoindex on;
}
}
it got rid of the 403 permissions error (yay!), however, it's not showing the default Rails home page. Rather it's showing the directory structure so I'm wondering what the proper way to set it is.
If I try to set it to location/public, I get the 403 error again. Any ideas?
location /public {
autoindex on;
}
Update
Since I'm using Vagrant (virtual box), the app is in /vagrant, however setting the location to location/vagrant also results in a 403 error
location /vagrant {
autoindex on;
}
You'll need to pass the request from Nginx to Unicorn. You can do this like so:
server {
listen *:80;
root /vagrant/public;
location / {
# Serve static files if they exist, if not pass the request to rails
try_files $uri $uri/index.html $uri.html #rails;
}
location #rails {
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://127.0.0.1:8080;
}
}
You may have to change the proxy_pass url. By default, unicorn will listen on 127.0.0.1:8080 but, if you have changed that, then you will need to specify that port.