Installed NodeBB can't access installation, Nginx setup & SSL

Question

I created a new Ubuntu droplet with the Node.js one click install.

Followed this guide to have nodebb installed on the server https://nodebb.readthedocs.io/en/latest/installing/os/ubuntu.html

I created an A record to point the server to my subdomain community.intelisight.com and added same on cloudflare.

But when I try to access the installation (which was successful and the service shows as running) with this http://community.intelisight.com:4567 I get nothing.
When I say http://community.intelisight.com same thing, I’m simply unable to access the live site.

My questions are

a) What am I doing wrong? What do I need to do to see the nodebb installation?
b) Is there a guide showing how to use nginx as the proxy server so I don’t have to put in the port to access the website?
c) How can I setup a free Let’s Encrypt SSL on this installation?

Thank you

Answer 1

jtittle1 March 3, 2017

@ososoba

When it comes to NodeJS apps and NGINX, the only way to access your URL with attaching the port to the end would be to use NGINX as a Proxy, in which case you would proxy requests on 80/443 to the port of your choice (i.e. your NodeJS app).

For example, this server block will take requests on port 80 and redirect them to port 443, and proxy requests on 443 to port 4567 (i.e your app). This would all be in a single file (i.e. yourdomain.conf).

NGINX as a Proxy

#
# HTTP - Redirect Requests on Port 80 to 443
#
server {
    listen 80;
    listen [::]:80;
    server_name yourdomain.com www.yourdomain.com;

    return 301 https://$host$request_uri;
}

#
# HTTPS
#
server {
    listen 443;
    listen [::]:443;

    server_name yourdomain.com www.yourdomain.com

    #
    # SSL Configuration Goes Here
    #

    location / {
        proxy_pass http://localhost:4567;
        proxy_connect_timeout 59s;
        proxy_send_timeout 600;
        proxy_read_timeout 600;
        proxy_buffer_size 64k;
        proxy_buffers 16 32k;
        proxy_busy_buffers_size 128k;
        proxy_temp_file_write_size 64k;
        proxy_pass_header Set-Cookie;
        proxy_redirect off;
        proxy_set_header Accept-Encoding '';
        proxy_ignore_headers Cache-Control Expires;
        proxy_set_header Referer $http_referer;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_hide_header X-Powered-By;
        proxy_set_header Cookie $http_cookie;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_no_cache $http_pragma $http_authorization;
        proxy_cache_bypass $http_pragma $http_authorization;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;
    }
}

You’d need to change yourdomain.com to your actual domain, of course, though the above will set you up so that you’re not forced to use the port in the URL.

You’ll need to reload NGINX once you’re done making changes using:

systemctl reload nginx

or

service nginx reload

LetsEncrypt

https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-16-04

How To Secure Nginx with Let's Encrypt on Ubuntu 16.04

by Mitchell Anicas

In this tutorial, we will show you how to use Let's Encrypt to obtain a free SSL certificate and use it with Nginx on Ubuntu 16.04. We will also show you how to automatically renew your SSL certificate. If you're running a different web server, simply follow your web server's documentation to learn how to use the certificate with your setup.

Reply Report

Answer 2

jtittle1 March 3, 2017

@ososoba

As a side note, if NodeBB isn’t running on the port itself, try running:

sudo service nodebb status

If it’s showing a failure, you’ll want to check your permissions. You’ll need to run:

sudo adduser --system --group nodebb

and

sudo chown -R nodebb:nodebb /opt/nodebb

It’s easy to overlook those two commands, but without them, NodeBB won’t run if you are using the service file they provide in the guide.

That being said, if it’s still not running after setting proper permissions, it’s most likely due to the URL provided during setup. If you set it to the default localhost, then you need to use NGINX to proxy the request. Otherwise you’d need to set a valid public IP or domain.

Reply Report

Answer 3

ososoba March 3, 2017

Thanks a lot @jtittle you’ve really been awesome

I’m having a separate issue now, not sure if you’d be able to identify the problem.

SSL & Nginx have been installed and configured, but I get a broken page and all links lead to a 404 error page

This is the URL https://community.intelisight.org/

Reply Report

Answer 4

jtittle1 March 3, 2017

@ososoba

If you would, please post your exact configuration for your server block in a code block as a reply and I’ll be more than happy to take a look at it for you :-).

Reply Report

Answer 5

ososoba March 3, 2017

So I might have found something, but I’m not sure if this is the problem

I checked the root www directory and could only find one file, I don’t think the nodebb files reside there

ls -R
.:
index.nginx-debian.html

But I’m a little worried that the nodebb install folder can’t be moved because some file associations might be lost. Same would happen if I move the root dir I guess

Reply Report

jtittle1 March 4, 2017

@ososoba

The root directory shouldn’t matter since we should be using NGINX as a proxy (as per my configuration example above), which passes requests over to http://localhost:4567, which would be NodeBB.

I’d need to see your fully configured server block to see if there’s something that’s causing the URL’s not to work properly.
Reply Report

Answer 6

jtittle1 March 4, 2017

@ososoba

The root directory shouldn’t matter since we should be using NGINX as a proxy (as per my configuration example above), which passes requests over to http://localhost:4567, which would be NodeBB.

I’d need to see your fully configured server block to see if there’s something that’s causing the URL’s not to work properly.
Reply Report

Answer 7

ososoba March 4, 2017

Sorry, I know this might be an absolute no brainer, but I’m having issues copying the whole .conf file, I can’t get past the text on screen.

Any pointers will be appreciated

Reply Report

Answer 8

ososoba March 4, 2017

Figured it out with cyberduck :D

Here’s the file

##
# You should look at the following URL's in order to grasp a solid understanding
# of Nginx configuration files in order to fully unleash the power of Nginx.
# http://wiki.nginx.org/Pitfalls
# http://wiki.nginx.org/QuickStart
# http://wiki.nginx.org/Configuration
#
# Generally, you will want to move this file somewhere, and start with a clean
# file but keep this around for reference. Or just disable in sites-enabled.
#
# Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples.
##

# Default server configuration
#
server {
    listen 80 default_server;
    listen [::]:80 default_server;
        server_name community.intelisight.org;
        return 301 https://$server_name$request_uri;
}

server {

    # SSL configuration
    #
     listen 443 ssl http2 default_server;
     listen [::]:443 ssl http2 default_server;
         include snippets/ssl-community.intelisight.org.conf;
         include snippets/ssl-params.conf;
         server_name community.intelisight.org

    #
    # Note: You should disable gzip for SSL traffic.
    # See: https://bugs.debian.org/773332
    #
    # Read up on ssl_ciphers to ensure a secure configuration.
    # See: https://bugs.debian.org/765782
    #
    # Self signed certs generated by the ssl-cert package
    # Don't use them in a production server!
    #
    # include snippets/snakeoil.conf;

    root /var/www/html;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location / {
        # First attempt to serve request as file, then
        # as directory, then fall back to displaying a 404.
        try_files $uri $uri/ =404;
                proxy_pass http://localhost:4567;
        proxy_connect_timeout 59s;
        proxy_send_timeout 600;
        proxy_read_timeout 600;
        proxy_buffer_size 64k;
        proxy_buffers 16 32k;
        proxy_busy_buffers_size 128k;
        proxy_temp_file_write_size 64k;
        proxy_pass_header Set-Cookie;
        proxy_redirect off;
        proxy_set_header Accept-Encoding '';
        proxy_ignore_headers Cache-Control Expires;
        proxy_set_header Referer $http_referer;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_hide_header X-Powered-By;
        proxy_set_header Cookie $http_cookie;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_no_cache $http_pragma $http_authorization;
        proxy_cache_bypass $http_pragma $http_authorization;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;
    }

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #   include snippets/fastcgi-php.conf;
    #
    #   # With php7.0-cgi alone:
    #   fastcgi_pass 127.0.0.1:9000;
    #   # With php7.0-fpm:
    #   fastcgi_pass unix:/run/php/php7.0-fpm.sock;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #   deny all;
    #}

        location ~ /.well-known {
                allow all;
        }
}



# Virtual Host configuration for example.com
#
# You can move that to a different file under sites-available/ and symlink that
# to sites-enabled/ to enable it.
#
#server {
#   listen 80;
#   listen [::]:80;
#
#   server_name example.com;
#
#   root /var/www/example.com;
#   index index.html;
#
#   location / {
#       try_files $uri $uri/ =404;
#   }
#}

Reply Report

Answer 9

jtittle1 March 4, 2017

@ososoba

Ah, now that makes sense :-). The issue is due to this line:

try_files $uri $uri/ =404;

With the above line, you’re telling NGINX to look in the directory defined by root, which invalidates the proxy configuration we’re doing.

So what I would recommend doing is simply making a backup of that file locally, and then deleting it from your server. You can then create a new one using the one I’ve provided below (which is cleaned up a bit).

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name community.intelisight.org;

    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;
    server_name community.intelisight.org

    include snippets/ssl-community.intelisight.org.conf;
    include snippets/ssl-params.conf;

    location / {
        proxy_pass http://localhost:4567;
        proxy_connect_timeout 59s;
        proxy_send_timeout 600;
        proxy_read_timeout 600;
        proxy_buffer_size 64k;
        proxy_buffers 16 32k;
        proxy_busy_buffers_size 128k;
        proxy_temp_file_write_size 64k;
        proxy_pass_header Set-Cookie;
        proxy_redirect off;
        proxy_set_header Accept-Encoding '';
        proxy_ignore_headers Cache-Control Expires;
        proxy_set_header Referer $http_referer;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_hide_header X-Powered-By;
        proxy_set_header Cookie $http_cookie;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Server $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_no_cache $http_pragma $http_authorization;
        proxy_cache_bypass $http_pragma $http_authorization;
        proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504 http_404;
    }

    location ~ /.well-known {
        allow all;
    }
}

Reply Report

jtittle1 March 4, 2017
@ososoba

To further explain this line:

try_files $uri $uri/ =404;

What the above does is takes:

https://yourdomain.com/category/this-is-a-post/

..and and tests whether or not category/this-is-a-post/ exists – if not, it returns a 404.

Since category and this-is-a-post are not real directories or files, you’ll always receive a 404. By removing this line and simply letting proxy_pass handle passing the request on to NodeBB, NodeBB handles the rewrites for you, as it should in this case.

When it comes to proxying, you want NGINX to simply pass the request on and let the app do what it needs to do with the request. The rest of the configuration in the location block handles making sure NodeJS/NodeBB has all the information it needs to validate the request when it’s passed over.
Reply Report

Answer 10

jtittle1 March 4, 2017
@ososoba

To further explain this line:

try_files $uri $uri/ =404;

What the above does is takes:

https://yourdomain.com/category/this-is-a-post/

..and and tests whether or not category/this-is-a-post/ exists – if not, it returns a 404.

Since category and this-is-a-post are not real directories or files, you’ll always receive a 404. By removing this line and simply letting proxy_pass handle passing the request on to NodeBB, NodeBB handles the rewrites for you, as it should in this case.

When it comes to proxying, you want NGINX to simply pass the request on and let the app do what it needs to do with the request. The rest of the configuration in the location block handles making sure NodeJS/NodeBB has all the information it needs to validate the request when it’s passed over.
Reply Report

Answer 11

ososoba March 4, 2017

Thanks a lot @jtittle you’ve been really helpful.

I tried the config you sent over, was getting an error on Cloudflare, something like “SSL Handshake Error” so I retried the old config without that “try” line, and it worked.

Reply Report

Answer 12

jtittle1 March 4, 2017

@ososoba

The issue with CloudFlare is common. If you login and navigate to their SSL Settings page, you should see a drop-down with a few options. It’s either Full or Full (Strict) – that’s the setting you need to use.

I’ve ran in to that issue with quite a few sites as of late and that seems to be the only fix for those who use CloudFlare.

Reply Report

Related

Question

Installed NodeBB can't access installation, Nginx setup & SSL

Related

Leave a comment

Looking for something else?

Sign up for our newsletter

Related

Question

Installed NodeBB can't access installation, Nginx setup & SSL

Related

Leave a comment

Related

question

502 bad gateway after root password reset

question

cpu from 13% to 100% in one minute

question

Problem installing wordpress on subdomain (nginx / ubuntu)

question

GUI for MongoDB needed to mange Meteor app

Looking for something else?