1.3 bind_ip host FQDN

can FQDN be alone or must it be paired also with an IP ? my examples from prior classes all paired a host name with an ip …but not sure…searched the manual but didn’t find this topic…

Not aware of using bind_ip for any of security labs
Somewhere it is mentioned you can use this for remote hosts but we are doing everything on the same box

hmmm I’m clearly confused then… the homework for lab 1.3: "When you set up your replica set make sure that you use the fully qualified domain name (FQDN) when initiating the replica set. Failing to do so will prevent the validation script "…
have been looking thru my notes on the video and don’t see this in the current class and then in past class I see host as part of the bind… when I searched the manual I didn’t find anything directly on this topic…

maybe am overthinking this and it just gets paired with the port…will try that…

What they meant is while using rs.initiate() or rs.add use hostname as below
FQDN will be database.m310.mongodb.university

1 Like

got it thanks…

rs.add for 31131 with FQDN worked fine I think…
but next for 31132 throws error…

rs.status shows
name : database 31130 which has become SECONDARY

name : database.m310.mongodb.university:31131 is ‘STARTUP’

I don’t understand this - though I do realize I have never applied the FQDN to 31130…not sure how that is done since it doesn’t require the rs.add task…

I backed out of the situation posted just before and killed the PIDs…

I brought all 3 members up again, and believing my rs.initiate() was correct
created user and authenticated ok (return:1)
rs.add would not add the members into the same replica set…

thinking I had made a typo perhaps forgetting to use admin db…I killed all 3 PIDs to start fresh once more…

I relaunched just member1 this time…
…and when connecting as an authorized x509 it immediately displays that it is SECONDARY

so I run the following:
MongoDB Enterprise myReplSet:SECONDARY> db.runCommand( { isMaster: 1 } )
{
“hosts” : [
“database:31130”,
“database.m310.mongodb.university:31131”
],
“setName” : “myReplSet”,

have re-verified that 31 and 32 are not connectable…so confused that the old (1st attempt) replica set is still in place…

kind of stuck…

Are your 3 mongods up and running?
31132 is missing in the above output
What does rs.status() show?
ps -ef|grep mongo
Please check mongod.log for each instance