Log file Viewer
#mongodb logs for Wednesday the 21st of August, 2019
[04:02:38] <cgi> when one builds a mongodb HA - how does one do ssl using certbot. Is it that the whole replica set has the same certificate (say for db.domainname.com) - or does it have an individual domain name for each machine?
[04:06:52] <cgi> if i dont plan to access this 3 machine replica from outside my private network - can i used self signed certificates? Or perhaps a simple username/password?
[11:42:28] <Markow> I have MongoDB 4.2.0 and tried running the server with the command "mongod", but getting the following error:
[11:42:51] <Markow> STORAGE [initandlisten] exception in initAndListen: MustDowngrade: Collection does not have UUID in KVCatalog. Collection: admin.system.version, terminating
[11:49:14] <GothAlice> Most package managers when installing network services create a user for that service. By running as root, it may create files (e.g. data files, log files) that the “real” user for that service will not have access to modify, delete, etc., breaking the service when *not* run as root.
[11:49:54] <Markow> I'm not using the Systemd service file. I'm invoking mongod directly using the bin
[11:50:05] <GothAlice> (Plus, if anyone manages to utilize a RCE—remote code execution flaw—they then absolutely and completely own your server, as you’ve given them unrestricted root access to the machine. ;)
[11:51:48] <GothAlice> https://gist.github.com/amcgregor/c33da0d76350f7018875 ← here’s a shell script I used back in the day to test out a 3x3 sharded replica set on a single machine, to test out sharding keys, run entirely as an ordinary user.
[11:54:19] <GothAlice> It’s just not a good idea for reliability, durability, HA, … (full disclosure: I’m a very happy Atlas user; rolling major version upgrades across a cluster without downtime is BEAUTIFUL.)
[14:55:35] <cgi> when one builds a mongodb HA - how does one do ssl using certbot. Is it that the whole replica set has the same certificate (say for db.domainname.com) - or does it have an individual domain name for each machine?
[15:01:00] <GothAlice> cgi: Replicas talk to each-other with their own keys. Only the application-connecting nodes (i.e. the query router in a shard set, or the replicas) need SSL, AFIK. They do not need to be the same literal SSL cert between them unless you implement certificate pinning application-side.
[15:01:22] <GothAlice> cgi: For many details: https://docs.mongodb.com/manual/administration/security-checklist/ + https://docs.mongodb.com/manual/security/ + https://www.mongodb.com/blog/post/how-to-avoid-a-malicious-attack-that-ransoms-your-data
[16:37:04] <cgi> GothAlice, so these keys have to be generated by certbot with a domain naming of the 3 machines as db1, db2, db3 - for example?
[16:55:50] <GothAlice> cgi: Is there a reason you seem so intent on sharing a private key (secret) between multiple machines? This is an overcomplication that will only frustrate, and shipping secrets around is a good way to lose control of (leak) those secrets.
[16:56:59] <GothAlice> (No, it doesn’t need to be done that way. I’d issue a distinct certificate for each machine. Always. Regardless of service being secured, because you do not want a) a single point of failure for reliability, and b) a single point of failure for information security.)
[17:35:19] <Markow> GothAlice: I hope a note has been taken here on the channel that providing a path via --dbpath prevents errors and the server from not starting up
[17:39:52] <GothAlice> 2019-08-21T13:39:41.444-0400 I STORAGE [initandlisten] exception in initAndListen: NonExistentPath: Data directory /data/db not found., terminating
[17:40:01] <GothAlice> You would have seen something like that, which is very explicitly telling you what the problem is.
[17:40:51] <GothAlice> (This wasn’t a fault in the software. This may have been a fault with your eyes, combined with a failure to read the manual.)
[17:41:38] <Markow> "Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'."
[17:43:08] <GothAlice> So, still an obviously advertised dbpath. If that could be written to, there are larger issues.
[17:44:49] <Markow> So, creating a path in my home directory (/home/ejm/mongodb) and specifying that path in --dbpath indeed fixed it and makes the server run w/o any issues
[17:48:47] <Markow> Anyway, thanks everyone for your input here, much appreciated, and have a good day / evening.
[17:53:02] <cgi> GothAlice, so it seems the right way to solve this is - I have 3 machines. Each have their own independent DNS + certbot - db1.mydomain.com, db2.mydomain.com, db3.mydomain.com - then use these certificates for ssl/mongodb?
[17:56:03] <GothAlice> c1rs3sN.db.example.com where N is however many servers are needed to ensure the dataset can fit in RAM on each shard member. (No swapping.)
[17:56:51] <GothAlice> C is the cluster number (might have one for North America, one for Europe, another in-office), RS is the replica set, S is the shard member.