@dogs Curious, had you seen this https://docs.nodebb.org/configuring/proxies/apache/
Something there not working for you? Inquiring minds are curious.
@dogs Curious, had you seen this https://docs.nodebb.org/configuring/proxies/apache/
Something there not working for you? Inquiring minds are curious.
All of which eventually leads to....
Contribute to NodeBB/nodebb-plugin-feed development by creating an account on GitHub.
GitHub (github.com)
Nice.
You go Mr. Miller!
So long away, and then, poof! A deluge of cuttin' to the chase wisdom. Salute!
How's Nicaragua, eh? A little bird told me you were groovin' on it.
Have mercy!
@kurulumu-net said in Widget pages missing after NodeBB migration:
But I had to re-install with root user.
Ill advised. Have you tried recursively chown'ing all the nodebb files?
chown -R nodebb:nodebb /opt/nodebb
@dunlix It would be beneficial to confirm APT-Sources, e.g.;
APT-Sources: http://repo.mongodb.org/apt/debian buster/mongodb-org/4.4/main amd64 Packages
Description: MongoDB shell client
Note the repo.mongodb.org bit above. Preferential to use mongo built pkgs if available. And they should be for Ubuntu. But maybe not set as default? So just confirm this bit for me whilst at it, eh?
@yariplus Good to know! Thx for this.
I presume Ghost is already sanitizing the html comment input so safe to pass thru to nodebb?
@phenomlab Meh... more like Much ado about nothing.....
Unless you were being purposefully clueless....
@someoneyoulike I run daily mongodumps. Then I daily rsync those dumps and nodebb's uploads dir to another box for safe keeping. If you want/need to restore to some other boxen rsync the db and uploads accordingly, mongorestore the dump and geronimo! You should be good to go. Well, yeah, okay, do not forget to also backup your config.json, your mongod.conf, nginx, conf, etc. and restore to the new box as well.
Edit: I guess I should add the not so obvious: Yes, I have used this process to move nodebb vm's about. More than once, even. Works fer' me. On my machines. Caveat emptor.
@dunlix said in Mongodb not working:
I looked around and realized that it wasn’t loading the confit file or something,
Hmmm..... I wonder... Reaching here but perchance might your mongod.conf file have become corrupted in some manner? You said all you did was a system upgrade and that should not have touched mongod.conf on a running system. But one never knows....
Also, along related note, mongod.conf is ASCII text only. No UTF-8. So if your text editor somehow slipped a little utf-8 in there during some edit, but you did not reboot until the update, and then/now mongod can no longer read/load mongod.conf? Maybe, just maybe?
But mainly in the main, need to confirm mongod is indeed listening on localhost port 27017.
@phenomlab I see.... I have a couple things I think may warrant further exploration but am busy w/else at present and not gone beyond perfunctory examination. Sigh...
But it is on my list!!
Once one envisions past the crowd funded, etc. marketroid hoopla.... the reality of ghost seems to leave the end luser somewhat wanting. Yes, I get that ghost has "eaten WP's lunch". But ghost failed to trip my trigger. I am curious as to whether others hereabouts have explored alternative bee loggin' engines? If so, what/which? Please report. Thx bunches.
@phenomlab yeah, mon! I realize ye' be old n' gray but ten decades is one hundred years. Hence I imagine even the old farts among us have a ways to go yet fer' that one, eh?
Rock on!
Another quick thought: What is ACP->Advanced->Cache telling you about your hit ratios, eh?
Have fun!
@normando said in How to reduce the load?:
Anyway, seems crawler bots.
Do you have the logs? Is it primarily googlebot? It will come in like a thundering herd of thunderin' hoovers. Does not respect conventions, e.g. robots.txt, but rather requires you to sign up for their webmaster tools. Anyways, back to the relevance, if not, then googlebot will basically scale to suck up as much as it can as fast as it possibly can. Hence, if you are running NodeBB on a VM in some reasonably well connected data center, network bandwidth is unlikely to be the bottleneck, leaving the vm itself.
The googlebot comes in fast, but also leaves fast. Several times a day, at +/- regular intervals depending on site activity and its mystery algos. So if you are seeing more off the wall bots, at random times 'twixt visits, then maybe these bots warrant further investigation. Otherwise, not much you can do about goog bot. But maybe give it more resources and it can leave sooner.
Have fun!
Somehow missed this. But now found it. Cool.
"Here's to a decade in the industry, and here's to 10 more."
Naw, I think I'd rather retire before all that long...
Cool retrospective. And yeah, life IS a trip!
@normando Hmm.. curious... how many worker processes and connections?
nginx -T| grep -i worker_connect
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
worker_connections 1024;
[root@forums nginx]# nginx -T| grep -i worker_process
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
worker_processes auto;
I am not all that familiar with nginx's proxy tunables. And some of above differs from my set up. Be that as it may, why not spin up a couple more nodebb nodes, i.e. 20002 and 20003? You've only got two. Just to see what happens whilst yer' testing anyways, eh?
Beyond tweakin' and tunin' nginx et.al. you are effectively experiencing a low level denial of service. So you much take steps to mitigate at the problem source. Maybe some adaptive firewall rulesets? Maybe a WAF? Maybe Fail2Ban?
Have fun! o/
@dunlix Well, I do not use Ubuntu for long while now so cannot comment there. Mongodb Debian pkgs default to /var/lib/mongodb. The contents of wh/should look something akin to this:
root@mallard:~# ll /var/lib/mongodb/
total 421696
drwxr-xr-x 4 mongodb mongodb 4096 Nov 16 00:26 .
drwxr-xr-x 32 root root 4096 Apr 12 2021 ..
-rw------- 1 mongodb mongodb 47 Apr 11 2021 WiredTiger
-rw------- 1 mongodb mongodb 21 Apr 11 2021 WiredTiger.lock
-rw------- 1 mongodb mongodb 1455 Nov 16 00:26 WiredTiger.turtle
-rw------- 1 mongodb mongodb 241664 Nov 16 00:26 WiredTiger.wt
-rw------- 1 mongodb mongodb 36864 Nov 16 00:26 WiredTigerHS.wt
-rw------- 1 mongodb mongodb 36864 Nov 3 01:53 _mdb_catalog.wt
-rw------- 1 mongodb mongodb 36864 Nov 3 01:53 collection-0--6779710148686833028.wt
-rw------- 1 mongodb mongodb 4096 Nov 3 01:52 collection-0--8716107555814307976.wt
-rw------- 1 mongodb mongodb 114978816 Nov 3 01:51 collection-0-7297207552526326231.wt
-rw------- 1 mongodb mongodb 223993856 Nov 16 00:26 collection-10--6779710148686833028.wt
-rw------- 1 mongodb mongodb 36864 Nov 3 01:52 collection-11--6779710148686833028.wt
-rw------- 1 mongodb mongodb 32768 Nov 3 01:52 collection-13--6779710148686833028.wt
-rw------- 1 mongodb mongodb 32768 Nov 3 01:52 collection-15--6779710148686833028.wt
-rw------- 1 mongodb mongodb 12288 Nov 3 01:52 collection-17--6779710148686833028.wt
The db location is configured in /etc/mongod.conf:
root@mallard:~# grep -i db /etc/mongod.conf
# http://docs.mongodb.org/manual/reference/configuration-options/
dbPath: /var/lib/mongodb
I would expect Ubuntu to be same. Use systemctl to stop and start mongodb service. Check the mongo server via systemctl status.
root@mallard:~# systemctl status mongod
● mongod.service - MongoDB Database Server
Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2021-11-03 01:51:58 UTC; 1 weeks 5 days ago
Docs: https://docs.mongodb.org/manual
Main PID: 573 (mongod)
Memory: 208.2M
CGroup: /system.slice/mongod.service
└─573 /usr/bin/mongod --config /etc/mongod.conf
If running and all reports back dandy confirm it is listening on port 27017:
root@mallard:~# netstat -na | grep 27017
tcp 0 0 192.168.128.121:27017 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN
tcp 0 0 192.168.128.121:38624 192.168.128.121:27017 ESTABLISHED
tcp 0 0 192.168.128.121:37938 192.168.128.122:27017 ESTABLISHED
tcp 0 0 192.168.128.121:27017 192.168.128.122:56238 ESTABLISHED
tcp 0 0 192.168.128.121:33606 192.168.128.123:27017 ESTABLISHED
But I got a feelin' that yours is not and only listening via unix socket. So please check mongo's "Net" settings in /etc/mongod.conf:
# network interfaces
net:
port: 27017
bindIp: 127.0.0.1
NodeBB should now be able to talk to MongoDB. Start it from CLI with logging.
@pitaj said in message history in group chat:
Yes, there's no technical barrier to allowing this. It comes down to a choice. We choose for chats to act like WhatsApp, SMS, IRC, etc because the chats are meant more for real-time communication. The forum exists for persistent communication.
I concur with @PitaJ on this one. While technically feasible, socially unacceptable. Private chat should be private. If that private chat subsequently becomes a group chat I have the option to opt out and cease participating. But to replay any and all prior messages would be a violation of trust. Twixt both the end user to end user and site operators who facilitated such.
My $0.02. Caveat Emptor.
@mark-coniglio I like Stop Forum Spam. Free is not always good, but in this case it is. Nothing will be a magic bullet. Layered onions, etc. Google is evil so I naturally prefer hCaptcha.
@tallship Some of the "temporal" may be mitigated via use of a bouncer, e.g. ZNC. Bouncers remain connected on per account/network and channel basis w/configurable scroll back buffers, e.g. 70 - 300 lines.
ZNC is likely the best known ROSS bouncer. Cruises right along on even most minimally provisioned vm offered by this, that, or the other cloud provider of the day....
Feel free to reach out for additional help.
Have a groovy day, eh?