@baris Ugh, duh! And coincidentally all the other users I checked were in the same boat. Thanks for the clue bat.

I was going to post this in "Feature Requests" but then I noted during my search for "reader view" that I did indeed have the reader view icon now available. So I thought maybe a new feature w/the latest and greatest newest version but as I browsed about community I noted that sometimes it was available while others not. Some threads provide the option, others not. I thought maybe NodeBB devs were being slick and correlated it w/thread length/post count or some such but there does not seem to be the case. The only place it consistently seems to be available is search page results. I use Firefox. Admittedly my browser config is non standard but I'd mentioned this to a Safari user a few days back and reader view is absent from their browser as well. Presuming I am not having a brain dead moment Reader View would be a dandy feature to have available where appropriate. If I am having a brain dead moment, clue bats appreciated.

Who Is This Document For? Well... like most things.... it depends.... If one or more of following shoes fits: Just want to get NodeBB up and running with minimum of hassle please I refer you to the tl;dr commentary from my NodeBB Email Options article. Intermediate to advanced Linux user. You can likely get this on your own. May be of some value to those unfamiliar with network and server side aspects of SMTP? Seasoned email administrator? Right. Please do not be too harsh as I'm endeavoring to bridge a gap here... SME commentary welcome. If, on the other hand: You're attracted to the "Ops" side of DevOps. Like to know how things work. Medium/advanced "beginner" to the Unix/Linux command line and eager to learn. Have the time to invest in that learning (i.e. big boss man or some other urgency not twisting your arm to get this done yesterday) and not afraid to RTFM. Then....... For Those About to Rock... I confess to deploying a Null Client set up for my forums. I thought I'd expand upon this a bit for interested parties not already possessing subject matter expertise but comfortable with the command line and willing to roll up their sleeves. Follows is meant to be a thumbnail sketch to get the DIY inclined pointed in the proper directions rather than exhaustive step by step copy pasta. Firstly, let's take a look at some reasons why/when this use case may be a fit: Isolation and separation of duties. Some favor an all on one approach. I favor dedicated vm's for dedicated tasks. I'd rather not have my app servers initiating connections with the Big Bad Internet. Incoming http(s), smtp, etc. requests from non local VM's is proxied. Access to prexisting email infrastructure. Security and stability concerns. All software has bugs. Postfix has weathered extensive scrutiny and audit. As such, I expect it is less vulnerable to things like malformed responses. Flexibility moving forward. For e.g. you want a daemon to manage NodeBB's outgoing mail queue - and perhaps that daemon also comes in handy for other duties like emailing various reports or alerts to administrators. Presumptions: You have a Postfix Null Client configured as outlined in the Postfix Standard Configuration Readme. You have NodeBB configured to utilize such as depicted in my screenshot in my prior article linked above. I've mentioned this can get complex in a hurry. Let's see if we give it a little K.I.S.S. Incoming!! Let's get our biggest hurdle out of the way. Null clients do not receive incoming mail. Setting up SMTP relays, IMAP server, virus/malware scanner, etc. ups the ante considerably. We've already got enough on our plates, at least for now, embarking upon this Null Client journey so lets save ourselves some grief and off load those duties to a reputable third party service such as Proton Mail. Outgoing As always, there's more than one way to do it: Null client delivers email directly to one of the servers listed in recipient domains MX records. Null client forwards email to a dedicated SMTP relay host, e.g. the folks handling your incoming mail (you may need to coordinate with them to configure some knobs, e.g. which hosts they will relay email from). Advantages to using a relay host include: 1) Undeliverable mail does not get stuck on your NodeBB server, and 2) Our null client is now initiating outgong SMTP connections with only the relayhost(s) rather than the big bad Internet at large. Postfix needs to know about your relay host to get this working. Add the following line to your null client's main.cf relayhost = your-relay-host.domain.tld You may also choose to specify relayhost via alternate parameters, such as IP address. I recommend sticking with hostnames as IP addresses may change from time to time. DNS Record Cogs & Widgets DNS presents yet another challenge and can have a high price for mistakes. So you're best off offloading this to a third party. Good news is your email provider likely bundles this with their service. Your domain registrar surely does. Consider leveraging that. Submit a request to have forward and SPF records added for your NodeBB instance's hostname. Note: I've used traditional Bind zone file syntax in the examples below. Using this syntax in help desk requests helps avoid confusion. Your provider may well offer a web based UI. You want records that look similar to the following (mind the trailing periods on fully qualified host names): Forward Record null-host-name.your-domain.tld. IN A XXX.YYY.WWW.ZZZ SPF Record The purpose of an SPF record is to provide a list of servers authorized to send email from your domain and must therefore necessarily include your third party provder's servers as well as your null client(s). your-domain.tld. IN TXT "v=spf1 ip4:primary-ip, ip4:secondary-ip, ip4:null-host-ip -all" MX Records Your mailbox provider likely handles configuration of MX records seamlessly but for the sake of completeness.... RFC's dictate primary and secondary mail exchangers. Get these from your mailbox host. @ IN MX 50 primary-mx.domain.tld. @ IN MX 80 secondary-mx.domain.tld. Reverse Record Your cloud provider is authoritative for reverse records for IP space assigned to them. Set up a PTR record for your NodeBB host using your providers management ui or submit a request ticket for them to create such for you. XXX.YYY.WWW.ZZZ.in-addr.arpa. IN PTR null-host-name.your-domain.tld. I manage my own DNS servers. DKIM is a royal pita for even seasoned adminstrators and imho an accident waiting to happen. Hence, unless you have a passion for learning about this stuff, I recommend letting your email/IMAP provider handle DNS for you, as it is lots easier to have them add an A or CNAME record as necessary for web servers and such than for you to configure and maintain DKIM. Else avoid DKIM entirely. Postmaster Other systems expect the existence of a valid postmaster address for communication of issues such as bounced mail, etc. Create "[email protected]", either as a dedicated mailbox or a forward to an existing mailbox, e.g. [email protected] if you prefer not having to check multiple mailboxes. Test this. Don't sweep postmaster mail under the rug lest it come back to haunt you at the most inopportune of times. Blacklists We need to ensure our newly minted Null Client is not blacklisted. MX Toolbox offers a meta blacklist check. Barracuda Networks will most likely do so before you've sent even a single email and requires jumping thru their hoops to become delisted. And jump ye' shall because their stuff is in wide spread use, particularly corporate side. It behooves you to check these blacklists from time to time, particularly with a newly minted server. Bippity Boppity Boo! Put it together and what have we got? Robust SMTP daemon relaying outgoing NodeBB email. Robust and reasonably secure IMAP mailboxes sans administration headaches. No worries about third party email plugin breakage between version upgrades. While this method adds complexity it's not too difficult to get set up once you understand some underlying concepts, moving pieces involved and what you're targeting. It also serves as a stepping stone to building out your own email infrastructure should you decide this stuff is all just too much fun. Enjoy! o/

@julian You're welcome and thank you for the kind words.

I talk backups all the time. I've been a senior advisor for multiple of the big backup players over the years and now my company builds its own backup systems for our own products. So we think about backups all the time.

The case for asciidoc from the asciidoctor folks, quoted liberally from AsciiDoc vs Markdown for purposes of discussion and analysis (i.e. Fair Use): "The defacto lightweight markup language is Markdown. (At least, that’s what you call it at first). The main advantage of Markdown lies in its primitive syntax: its manual and cheatsheet are one and the same. But this advantage is also its greatest weakness. As soon as authors need something slightly more complex than basic prose (e.g., tables, cross references, footnotes, embedded YouTube videos, etc.), they find themselves resorting to embedded HTML or seeking out more feature-rich implementations. Markdown has become a maze of different implementations, termed “flavors”, which make a universal definition evasive. The IETF has declared “there is no such thing as "invalid" Markdown.” See This Is Markdown! Or: Markup and Its Discontents. Here’s how the story inevitably goes. You start out with Markdown. Then it’s Markdown + X. Then Markdown + X + Y. And down the rabbit hole you go. What’s worse, X and Y often require you to sprinkle in HTML, unnecessarily coupling content with presentation and wrecking portability. Your instinct to choose Markdown is good. There are just better options. AsciiDoc presents a more sound alternative. The AsciiDoc syntax is more concise than (or at least as concise as) Markdown. At the same time, AsciiDoc offers power and flexibility without requiring the use of HTML or “flavors” for essential syntax such as tables, description lists, admonitions (tips, notes, warnings, etc.) and table of contents. It’s important to understand that AsciiDoc was initially designed as a plain-text alternative to the DocBook XML schema. AsciiDoc isn’t stuck in a game of whack-a-mole trying to satisfy publishing needs like Markdown. Rather, the AsciiDoc syntax was explicitly designed with the needs of publishing in mind, both print and web. If the need arises, you can make full use of the huge choice of tools available for a DocBook workflow using Asciidoctor’s DocBook converter. That’s why mapping to an enterprise documentation format like DocBook remains a key use case for AsciiDoc. And yet, AsciiDoc is simple enough to stand in as a better flavor of Markdown. But what truly makes AsciiDoc the right investment is that its syntax was designed to be extended as a core feature. This extensibility not only means that AsciiDoc has a lot more to offer, with room to grow, it also fulfills the objective of ensuring your content is maximally reusable."

@julian said in Nodejs Version Managers: In my experience there are few reasons to use a version manager, except for development reasons (i.e. testing on older versions of Node, etc.) In production, I am increasingly in favour of compartmentalization via containers (or currently, simply separate servers). They can each maintain their own version of Node via the OS package manager, and that's that. Yep. I concur one hundred percent with the separate vm's for production approach. I don't think I'd utilize containers directly unless I owned the bare metal and needed to leverage that investment for additional duties. And then I'd use a better hypervisor and launch a Linux vm from there. I sometimes muck about with different nodejs based stuff that wants different versions, requirements, and such and thought it might be nice to forgo spinning up vm's for the quick exploratatories.... None of them seem to want to play nicely with FreeBSD these days though so the question seems rather moot for my use case. Thanks for your thoughts.

@julian Yeah, I was thinking more of the Nginx Plux vs. Nginx Open Source duality. Too often such results in major split personality disorders wh/end up essentially forcing extortion to even get access to any reasonable docs or support. Nginx woes are still unclear. My concern is that if the bad actors succeed in their claims, then the license itself may be declared null and void. I can imagine this then leading to a scenario where "might makes right" and any forks then become their next targets. Crazy stuff happens in the US Federal Courts these days, particularly a certain district court in Texas, which has a well earned reputation for being very pro corporation in its rulings. Some towns thrive on industry, others eco tourism, etc. That TX town's niche is rich corporate lawyers dumping buckets of cash into the local economy. Anyways, I am still curious as to community reports regarding Apache deployments, as I have not used it in many years now. NodeBB rocks and is one of the best pieces of FOSS this ol' dinosaur had the pleasure of using. Keep up the great work.

Not an nginx guru so please bear with me here. For simplicity sake let's assume site lives at forums.example.com rather than a example.com/forums subfolder. Unless specified otherwise, nginx root dir is /usr/share/nginx/html Nodebb nginx configuration docs utilize this when describing setting up a custom error page. Nginx is being used exclusively as reverse proxy and not serving any additional sites. I think I read somewhere that under such configuration an explicit default server docroot should not be specified? But even in such cases I think the hard coded default /usr/share/nginx/html still serves up 50x.html error page. In absence of a custom error page, nodebb uses nodebb/public/503.html? Nginx has been configured for scaling. Nginx Pitfalls and Common Mistakes documentation suggest putting doc root inside a location block is bad practice even though it will work. Soo... now my question... taking all of above into consideration.. what is proper/correct best practice configuration for a "scaled" nginx nodebb deployment? I know what "could" work. I am curious what "should" be recommended best practice. (Yeah, I know I already posted this in a different thread but it was a mistake at the time not to have started a new thread because this is pretty specific w.r.t. best practices configuration rather than "why isn't my stuff isn't working" question. Apologies for that.)

Maybe not a lot of interest in this due to complexity of deploying/configuring ModSecurity, combined w/absence of nodebb stack specific rulesets. Security is difficult so not much can be done about the deploy/config aspects but ModSecurity devs are starting to focus some efforts on the latter. For those interested, and willing to roll up their sleeves, development of node.js targeted attack ruleset is slated for next release of OWASP CRS, scheduled for Sept. 2019. More info here: https://github.com/SpiderLabs/owasp-modsecurity-crs/pull/1487#issuecomment-519071541 P.S.; Obviously ModSecurity can be deployed on Apache setups as well but my sense is that Nginx is the overwhelming favorite w/the nodebb community and I didn't want to start a new thread.

@julian Thanks. Figured some such, wh/is why I did not want to open bug report prior to checking in P.S.; Prior to github and markdown becoming defacto I always preferred asciidoc for such duties. Still do. Much richer options for when you need/want them but still dead simple to use when you don't. Also, actually standardized, as contrasted w/the markdown flavor fest. But hey, github made markdown the golden boy for modern devs that never used else. Don't blame 'em cuz devs wanna code not invest time learning different markup 'time savers'. So whaddya gonna do, eh?

@julian said in Search options for 2019 NodeBB: Dbsearch is the recommendation This is what we are using now. We used to use Solr but it had issues and we came back.

@루루 I use this one mongodb70-7.0.4 , no issue all perfect