Not yet, but I will.

I installed UbuntuServer on Virtualbox of MacOSX and logged in via SSH (and tmux)
redis-server can be installed via apt-get, and node.js is also straightforward in some way (obviously bunch of info available on the net).

Currently, I studies email functionality of nodeBB.
I probably use Amazon SES, but it seems that there is no nodebb-plugin for that yet.
So, that is the major problem for now, and wonder how other guys manage that.
Perhaps, I end up with developing the plug-in by my own.

@julian said:

we're using 40mb

For this scale and period, the memory size seems very reasonable. Thanks for this great project @julian

@psychobunny Thanks!

https://docs.nodebb.org/en/latest/widgets/create.html

I found ./nodebb setup resets Wiegets configuration from ACP GUI.

How do we preserve the Widgets configuration including backup/migration scenario??
Possibly config files?

One more thing.
I found email template(registration/password-change/digests) is controlled by nodebb-theme-* node_modules.
Do we need to create own ````nodebb-theme-*``` for email template?

@julian Just works as intended.
The approach here totally works.
As you kindly suggested, it's my mistake not to have set subdomain by DNS.
I somehow misunderstood Ngynx takes care of subdomainsDNS IP routing, my bad.
Thanks a lot.

@julian said:

Make sure the subdomain is routed properly via your DNS server (so that sub.mydomain.net goes to the same ip as mydomain.net),

Oh my... I totally miss it!

You have true insights always. Appreciated Julian.

@julian No, the browser says - Oops! Google Chrome could not find sub.mydomain.net

Currently, I'm trying to figure out how to observe nginex behavior with log.

So far, simply,
mydomain.net shows the frontpage of nginex.
mydomain.net/4567 shows the nodeBB properly.

Thanks

@psychobunny @julian

Thanks for this thread, and I think this kind of information can be placed in docs or wiki.

I use nginx now, and the default page of mydomain.net works, and mydomain.net:4567 works for nodeBB.

Now, I try to implement sub.mydomain.net proxy to 127.0.0.0:4567 (nodeBB), so I tried:

/etc/nginx/sites-available/subdomain

server {
      listen   myipaddress:80;
     server_name sub.mydomain.net;
     error_log ./log error;

     location / {
        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_pass      http://127.0.0.1:4567/;
        proxy_redirect off;

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

But seems not working.

I properly set the symbolic link in /etc/nginx/sites-enabled/

ln -s /etc/nginx/sites-available/subdomain

So here is no problem, I think.

Please advice ,
Thanks.

PS. reading

https://media.readthedocs.org/pdf/nodebb/latest/nodebb.pdf
I've changed

server {
      listen   myipaddress:80;
//........

and
sudo /etc/init.d/nginx restart

The result is same...
sub.mydomain.net does not lead to mydomain.net:4567...

Ubuntu 14.04
nginx version: nginx/1.6.0

Thanks @julian , I understand that.
/etc/redis/redis.conf is configured as│dir /var/lib/redis
Actually, I sort of knew this, but if so, it does not make any sense dump.rdb appears under the home/username/ directory...

I'm new to nodeBB and Redis.
Having said that, I am so confused by Redis behavior along with nodeBB.

Reading the docs-Upgrading NodeBB

Upgrading - NodeBB Documentation

Backing up Redis
As with all upgrades, the first step is to back up your data! Nobody likes database corruption/misplacement.
All of the textual data stored in NodeBB is found in a .rdb file. On typical installs of Redis, the main database is found at /var/lib/redis/dump.rdb.

However, during heavy tweak/installation of nodeBB, sometimes, dump.rdb appears under my user's home root /home/ken/dump.rdb.
I try to figure out which dump.rdb is actually connected to nodeBB and updated, and observed the time-stamp with redis-cli save/bgsave.
The dump.rdb under the home is updated, and /var/lib/redis/dump.rdb is not updated.
Sometimes, redis-cli save reflect redis-server log, sometimes does not.

Does someone have same kind of trouble? If I miss something, please let me know.

Thanks.

@julian said:

No problem, gh#1592
So we'd add another level of users... those who are "confirmed".. or "verified"... the terminology itself is flexible.

Thanks for your prompt reaction.

As you mentioned at GitHub-issues, some counter system against spamming is must-have, and actually the most common SNS or BB employes the email verification to register.

I cloned the master edge and trying now, but Category Permissions is confusing I would suggest.

I observe that
checked = allow
unchecked = disallow

but, obviously, it does not work like this so far. In other words, the checking status does not reflect the permission status.
As a default nothing is checked, but in fact guest is restricted in some way.
When I start checking the Administrator, with logging out, the category disappear since guest has lost permission to view the contents even if their checking status is untouched.

I know this is under heavy development, but just let you know, the current checking status does not reflect the permission at all.

I wish I can help to code this section, but I'm new here, and wonder I can do right way.

Thanks.

@julian

Thanks for the detailed reply.
I will try v0.5.0 or the pre-released master.

I observe the most common BB systems around employ the level of users as below:

1. administrator (and modifiers with some limited administration privileges )
2. registered users (the registration is not complete until the user verifies their emails)
3. guests (just can view contents)

The concept of registered user(2) or registration with email verification is widely shared among SNS such as Twitter/Facebook/Google+.

The problem of the current nodeBB system as the default I think is the forum is way too open without any email verification, and irregular/uncommon.

Say, I have malicious intention, I can gain extra privileges with offering fake or random email addresses that actually does not exist.

So, I suggest "verified users" as you say should be registered users, and "unverified users" should simply remain as guests.
I see no points having registered-verified-guests users, and this idea would definitely confuse both administrators/developers (us) and users.

What do you think?

Regards.