Community

Great job and congrats to the team and contributors!

It's probably the download time for the package-dependencies that takes a while. They all end up in the node_modules folder when ready.

Guess you could have copy ready and just copy it to your NodeBB folder before running setup.

But why is this a problem? What is the use case for shortening this step that usually only is done once?

Shouldn't this request be directed to Taptalk Inc? They seem to charge both the app user and the forum maintainer for "pro" features.

As this is an open source project, they're free to provide a NodeBB taptalk plugin and earn more money

Probably a spam user...

It will only actually only renew when it is time. So no need to worry!

@etakmit

Yep, just point it to the public folder of your install.

@etakmit
Goto https://certbot.eff.org/ and choose your webserver/platform for a step-by-step guide.

It takes a couple of minutes to be up and running:

> sudo apt-get install letsencrypt 
> letsencrypt certonly --webroot -w /home/blaha/NodeBB/public -d **yourdomain.com**

The certs will be available in the following folder (this is the nginx config)

 ssl_certificate         /etc/letsencrypt/live/**yourdomain.com**/fullchain.pem;
 ssl_certificate_key     /etc/letsencrypt/live/**yourdomain.com**/privkey.pem;

Then add letsenctypt renew (and service ngninx reload) in a crontab running every day.

@RoiEXLab
Just point the letsencrypt script to the public folder of your NodeBB install.

Recommendation

Do NOT use cloudflare (at least not the free plan) on NodeBB when you have a moderate traffic to your forum. Cloudflare seems to silently throttle the traffic resulting in very strange NodeBB behaviour (for some clients) where the simply cut websockets.

The throttled client will see a lot of popups "Looks like your connection to XXX Forum was lost, please wait while we try to reconnect."

In the ngnix error log you will also see lots of:
2017/01/25 09:56:15 [error] 13909#13909: *799654 upstream timed out (110: Connection timed out) while reading response header from upstream, client: xxxxxxxxxxxx.123, server: forum.mysensors.org, request: "GET /socket.io/?EIO=3&transport=polling&t=xxxxx&sid=xxxxxxxxx HTTP/1.1", upstream: "http://127.0.0.1:4568/socket.io/?EIO=3&transport=polling&t=xxxx&sid=xxxxxxx", host: "forum.mysensors.org", referrer: "https://forum.mysensors.org/topic/702/openhab-mqtt-example/2"

It has been kind of hellish to find the root cause.

Done...

https://github.com/NodeBB/NodeBB/issues/5393

After spending a few days debugging a problem on our forum/nginx, I've finally found a solution to a massive amount of http 400 errors we've seen when loading the nodebb forum. These problems normally only manifest itself on high load.. In our case >500 connected clients.

In the browser console you will see responses like this (for the failed connections):
{"code":1,"message":"Session ID unknown"}

Background

• When receiving a 4xx error, nginx proxy by default will take the errant upstream out of rotation for 10 seconds
• When upstream-A is unavailable, ip_hash will route all of A's requests instead to upstream-B
• Unfortunately, when upstream-B gets the new requests, it spits out 4xx errors (correctly) because the SID is not found in this.clients
• That makes them get taken out of rotation as well, and their requests get routed to upstream-C
• and so on...

The Solution

Set the max_fails on the upstream to something higher than default (1).

Example:

upstream io_nodes {
   ip_hash;
   server 127.0.0.1:4567 max_fails=50;
   server 127.0.0.1:4568 max_fails=50;
   server 127.0.0.1:4569 max_fails=50;
}

I suggest someone to update the NodeBB documentation, including this in the nginx examples.

You've been asked not to bump. Please don't continue doing it!

You know, it might be so simple that people don't know how to help you without putting a lot of effort into investigating this issue.
If you hire/pay the nodebb staff for a few hour they might be able to help you.

Haha, that might be one of the most annoying avatars I've seen.

Ok, I had similar problems when running on a droplet with little memory (1 Gb). Resulting in a none responsive NodeBB after a few days.

After moving to a bigger plan (8Gb mem) it's been running for months w/o any problems.

The log was old

Which log? The redis one?

You should probably check the redis log as it seems down.

Hehe, it used to be possible to display multi-badges, this calls for getting that functionality back :).

@exodo

I ended up configuring ssl on our domain (Cloudflare Full SSL setup).
I had to adopt config.json to enable ssl for websockets. But as you can see I didn't change the socket.io transports defaults.

{
    "port": ["4567", "4568", "4569"],
    "ssl": {
         "cert": "/etc/nginx/ssl/mysensors_certificate.pem",
         "key": "/etc/nginx/ssl/mysensors_key.pem"
    },
    "url": "https://forum.mysensors.org",
    "secret": "****************",
    "database": "redis",
    "redis": {
        "host": "127.0.0.1",
        "port": "6380",
        "password": "**********",
        "database": "1"
    }
}

This is our nginx config.

upstream io_nodes {
    ip_hash;
    server 127.0.0.1:4567;
    server 127.0.0.1:4568;
    server 127.0.0.1:4569;
}

server {
    server_name forum.mysensors.org;
    listen     443 ssl spdy;

    ssl        on;
    ssl_certificate         /etc/nginx/ssl/mysensors_certificate.pem;
    ssl_certificate_key     /etc/nginx/ssl/mysensors_key.pem;

    # enables all versions of TLS, but not SSLv2 or 3 which are weak and now deprecated.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    # disables all weak ciphers
    ssl_ciphers 'AES128+EECDH:AES128+EDH';

    ssl_prefer_server_ciphers on;

    # prevents 502 bad gateway error
    large_client_header_buffers 8 32k;

    client_max_body_size 2M;

    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_set_header X-NginX-Proxy true;
    proxy_redirect off;
    proxy_buffering off;

    # Socket.IO Support
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";

    gzip on;
    gzip_min_length 1000;
    gzip_proxied off;
    gzip_types text/plain application/xml application/x-javascript text/css application/json;

    location @nodebb {
        proxy_pass https://io_nodes;
    }

    location ~ ^/(images|language|sounds|templates|uploads|vendor|src\/modules|nodebb\.min\.js|stylesheet\.css|admin\.css) {
        root /home/msforum/NodeBB/public/;
        try_files $uri $uri/ @nodebb;
    }


    location / {
        error_page 502 =200 @maintenance;
        # prevents 502 bad gateway error
        proxy_buffers 8 32k;
        proxy_buffer_size 64k;
        proxy_pass https://io_nodes;
    }
    location @maintenance {
        root /opt/nginx/maintanance/;
        try_files $uri /index.html =503;
    }
}

Quite a few browsers still seem to use polling. I really don't know why.
We got quite a peak in cloudflare.. But a slowly decreasing bandwidth usage:

This is great news!

We're now running on CF CDN.

We have around 2-300 concurrent connection. No problem so far. Much snappier! And nice to offload the SSL to them

They should probably be two different things. Category description should be a short text like today, while the introduction could potentially be longer (and preferable support markup).

Got an even better idea... We could actually use the "Widget" feature. Would only require a new widget property where you can specify which category it should be shown on... that way you could place texts both in header/footer/sidebar for a specific category. Flexible!

I have a feature request for a optional category header [markdown] text displayed here:

Many of your categories requires some introduction and or additional information. Sticky threads just isn't good enough [people don't read them].

Like in the bug report category here on the forum, it would be nice to add a link to github issue tracker and give a short explanation on how to add a bug report.