Topics created by gotwf

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. lifeforms created this issue in SpiderLabs/owasp-modsecurity-crs closed some node.js unserialization + javascript RCE snippets #1487

@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.

@gotwf Thanks. Sorry I was AWOL yesterday. I was in that Canton, TX tornado! Okay, not "in" it, but was in Canton when it happened.