@scottalanmiller said in Deploying NodeBB 1.14 on CentOS 8 with MongoDB 4.2: By default, NodeBB uses the REDIS NoSQL database, By default, in 1.15.x it uses Mongo I'm pretty sure it did in the last version I installed also. But that was months ago and I do not recall clearly.

@JaredBusch said in Deploying NodeBB 1.13 on CentOS 8 with MongoDB 4.2: You can only remove this line if you are going to host the reverse proxy on the same instance. No reverse proxy needed if you are going to just look at it locally without going over the network.

@bnrstnr said in Deploying NodeBB 1.11.1 on CentOS 7 with MongoDB 4: What specific reasons for the CentOS recommendation here? Revisiting a little... Basically the three main Linux releases supported by MongoDB are CentOS, Ubuntu, and Debian. CentOS and Ubuntu here are mostly six of one. But CentOS 8 Stream I like a little more than the Ubuntu LTS options. We use Ubuntu a little more often than CentOS today, but in this case I feel that CentOS is slightly better for us. But really, all three options are perfectly fine. We just have to pick one.

@StorageNinja said in MongoDB Major Change to Licensing: @scottalanmiller said in MongoDB Major Change to Licensing: if you are a SaaS vendor looking at building software that uses MongoDB somewhere, you'd better get a lawyer looking over this license and how it applies to you. This is becoming a bigger issue as the biggest SaaS vendors hide behind this clause more and more with incredibly proprietary forks. They offer very little to no actual core development or contribution and it goes against the previous method of GPL code getting funding. It annoys me, as the legal headaches of contributing internal only use code back will block some companies from using OSS, but I see it both ways. The startups who are doing a lot of the core housekeeping of NOSQL platforms are learning they can't find a business model. This is getting messier and messier. Partially because there are just too any vendors involved. What's amazing, though, is that a move like this took a customer who was very into MongoDB and using it in projects and was literally working with MongoDB's own hosted product and now looking to avoid it like the plague. So at least in this one case, they are likely losing hosted product from this. And gaining nothing. I imagine a lot of customers going through this same process.

@mattbagan said in Install NodeBB 1.10.2 on Fedora 28 with Mongo: @JaredBusch worked like a charm. Thank you! Thanks, great to hear.

@jaredbusch said in MongoDB Storage Engine Error Detected MMapV1 and wiredTiger: @scottalanmiller okay, they totally fucked this up. Yeah, this is some weird stuff.

@black3dynamite said in MongoDB 3.6 Update Issues: @scottalanmiller said in MongoDB 3.6 Update Issues: @black3dynamite said in MongoDB 3.6 Update Issues: Is this an issue when using the packages from Fedora and Ubuntu repo or from MongoDB repo or both? Fedora and Ubuntu repos will cause this issue. If you just do your normal 27 -> 28, or 16.04 -> 18.04, or 17.10 -> 18.04 updates, it gets you. No warnings (within the system.) This will be a big problem for people who get MongoDB installed as part of an app in the background and don't know that they are running it! Wiki.js That, too, would be affected. Yes. But only in the 1.x series. Once they go to 2.0, they are dumping MongoDB.

@ccwtech said in Unifi 5.7 on Ubuntu 18.04: Scott, why did you go with Ubuntu vs. Fedora? (Asking for a friend) Because it's the official OS of the product. Absolutely no reason to use Fedora here. Unifi only supports Ubuntu and Debian, and Jared and I have opposite views here. Ubuntu is the business product of the Debian family, Debian is the hobby project that is used as the basis for it. Debian is great, I love the project and they do great work, but it doesn't have primary vendor support, you are at the mercy of a hobby project. Ubuntu uses that basis and turns it into a production ready release with vendor and market support options. Ubuntu isn't Fedora, but it's still extremely good.

@scottalanmiller said in Remove Duplicate Entries from MongDB Collection: You can add an index as well, to avoid having duplicates occur in the future: db.myCollection.createIndex({"my_field_to_be_unique":1},{unique:true}) Good idea.

For more detail, showing the UIDs of each of the duplicates in question, try this little extension: db.myCollection.aggregate([ {$group: { _id: "$field_to_search", "dups": { "$push": "$_id" }, count: { $sum: 1}}}, {$match: { count: { $gt: 1 }}}])

Gotta love that MongoDB

@brrabill said in SELinux issue with MongoDB on Fedora 27: @jaredbusch said in SELinux issue with MongoDB on Fedora 27: @black3dynamite said in SELinux issue with MongoDB on Fedora 27: Have not see that issue but I'm also using mongodb that is available from Fedora instead. /var/lib/mongo/ doesn't exist for me. But /var/lib/mongodb does exist. I also do have local.ns too. /sigh FFS @jaredbusch pay attention to what you are doing. don't use old versions. Long day when you have to sigh and FFS at yourself. Something like that, yes.

@scottalanmiller Well you know, let's break it

@JaredBusch not necessarily abnormal but surely a mix of 3 independent repos.

@Romo said in Extortionists competing to get paid for the same databases!: Explanation of the vulnerability Understanding the hack The hack itself is alarmingly simple. In versions >= 2.6.0, MongoDB includes a default configuration file that binds MongoDB to 127.0.0.1 by default. As a result, the database will only listen to local connections. Before version 2.6.0, that wasn’t true. By default, MongoDB was left open to remote connections. Authentication is also not required by default, which means that out of the box installs of MongoDB before version 2.6.0 happily accept unauthenticated remote connections. Users could still restrict access to local connections if they took the time to configure the install but that meant manually adding a line to their mongodb.conf file. Since that wasn’t the default configuration, many existing installs never included this critical step. Making matters worse is that it’s easy to identify potential MongoDB attack candidates. MongoDB’s default port is 27017. Using a search engine such as ZoomEye, you can query for MongoDB installs, see what port they’re available over, and find around 100,000 vulnerable candidates. The vulnerability itself is hardly new. The issue was first raised back in 2012 and released somewhere around 2015. Also, in early 2015, John Matherly made some noise when he reported finding around 30,000 insecure installs of MongoDB. In other words, this is something that everyone could have known about for a while. That's not a vulnerability, that is STILL a half configured system AND no firewall on the server. And MongoDB 2.6 is relatively old, we are on 3.3 these days. This is a database cluster component, not a complete database piece on its own. Whatever "security" professional is writing this piece clearly isn't aware of what they are writing about. What they write is half true, 27017 is listening on 0.0.0.0, but it does so for a reason and is only vulnerable in places where someone did not finish setting up their database AND their server. It's not a vulnerability in the product.

For those looking through the logs, this is the key entry to notice: error: Error creating index Index with name: _key_1_value_-1 already exists with different options

@scottalanmiller said in Installing MongoDB 3.2 on CentOS 7: Just tested and deployed to CentOS 7.2 on Linode. This failed me, so I went to the mongo docs and the baseurl contains the variable $releasever. using that results in redhat//mongodb in the file, which is why I assume you hard coded that bit. Escaping the $ fixes it. cat > /etc/yum.repos.d/mongodb-org-3.2.repo <<EOF [mongodb-org-3.2] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/redhat/\$releasever/mongodb-org/3.2/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc EOF

gte and lte values create the "bounds" of the query. Adjust accordingly to change the date range. Value is "epoch time."

Fix was pretty easy: export LC_ALL=C

Aww.. I thought someone reached out to them and said "hey we are talking about you over at ML, why not stick your head in?"

Sucks that we will not have a chance to get MongoDB 3 ahead of Friday's event. Would have been awesome to put it through its paces.

I never even had a chance to know that it was broken.

@dyasny said in MongoDB vs. Redis: @jmoore said in MongoDB vs. Redis: ... I don't see how just using some flashy marketing terms would actually get good talent. my point exactly! Not really what companies using recruiters like that want. It's mostly a myth that people want to hire great talent. Most places want to hire cool sounding, middling talent.