Configuration File Lecture and Lab --- There's must be something missing

In both Configuration File Lecture and Lab, there is not any indication in how to create the file mongod.conf
Is it through the shell? or should we open our text editor and copy-paste the following?

storage:
dbPath: “/data/db”
systemLog:
path: “/data/log.mongod.log”
destination: “file”
replication:
replSetName: M103
net:
bindIp : “127.0.0.1,192.168.0.100”
ssl:
mode: “requireSSL”
PEMKeyFile: “/etc/ssl/ssl.pem”
CAFile: “/etc/ssl/SSLCA.pem”
security:
keyFile: “/data/keyfile”
processManagement:
fork : true

If that is the case, where should we save this file? and in which extension?
mongod.conf , mongod.yaml , or mongod.conf.yaml ?

Thank you

If you don’t fancy learning how to use whatever text editors are present in the VM (I didn’t), your best bet is to create the config file on your host machine using your favourite text editor. You can then save it in the shared folder within the m103 folder created during the environment setup. This folder is accessible from both the host machine and the VM.

Then, within your VM (if you’ve got the vagrant@m103:~$ command prompt then you’re in the VM) you can copy the file from the shared folder to your home folder like this:

cp /shared/lab1.2.conf lab1.2.conf

I’m not sure whether there’s any restriction on the filename extension, but .conf worked fine for me. And provided you start mongod from within the same home folder that you’ve copied the file to, you can start it like this:

mongod --config lab1.2.conf

Or if you save the config file somewhere else, or you’re your starting it from somewhere other than the home folder, then you’ll need to pass the path to the config file on the command line, rather than just its filename.

I did the same as you suggested:
My conf file name mongod.conf

vagrant@m103:~$ cp /shared/mongod.conf mongod.conf

vagrant@m103:~$ mongod --config mongod.conf

Unrecognized option: ssl.CAFile
try ‘mongod --help’ for more information

I also did directly:

vagrant@m103:~$ mongod --config /shared/mongod.conf

Unrecognized option: ssl.CAFile
try ‘mongod --help’ for more information

I always have the problem of:

Unrecognized option: ssl.CAFile

So I deleted everything in the file and I kept:

net:
bindIp: “192.168.103.100,localhost”
port: 27000
security:
authorization: enabled
storage:
dbPath: “/data/db”

Still not working:

vagrant@m103:~$ cp /shared/mongod.conf mongod.conf

vagrant@m103:~$ mongod --config mongod.conf

2019-06-22T12:10:31.482+0000 I CONTROL [initandlisten] MongoDB starting : pid=2578 port=27000 dbpath=/data/db 64-bit host=m103
2019-06-22T12:10:31.483+0000 I CONTROL [initandlisten] db version v3.6.12
2019-06-22T12:10:31.484+0000 I CONTROL [initandlisten] git version: c2b9acad0248ca06b14ef1640734b5d0595b55f1
2019-06-22T12:10:31.485+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.1f 6 Jan 2014
2019-06-22T12:10:31.486+0000 I CONTROL [initandlisten] allocator: tcmalloc
2019-06-22T12:10:31.487+0000 I CONTROL [initandlisten] modules: enterprise
2019-06-22T12:10:31.487+0000 I CONTROL [initandlisten] build environment:
2019-06-22T12:10:31.488+0000 I CONTROL [initandlisten] distmod: ubuntu1404
2019-06-22T12:10:31.489+0000 I CONTROL [initandlisten] distarch: x86_64
2019-06-22T12:10:31.489+0000 I CONTROL [initandlisten] target_arch: x86_64
2019-06-22T12:10:31.489+0000 I CONTROL [initandlisten] options: { config: “mongod.conf”, net: { bindIp: “192.168.103.100,localhost”, port: 27000 }, security: { authorization: “enabled” }, storage: { dbPath: “/data/db” } }
2019-06-22T12:10:31.493+0000 I STORAGE [initandlisten] exception in initAndListen: DBPathInUse: Unable to lock the lock file: /data/db/mongod.lock (Resource temporarily unavailable). Another mongod instance is already running on the /data/db directory, terminating
2019-06-22T12:10:31.493+0000 I CONTROL [initandlisten] now exiting
2019-06-22T12:10:31.493+0000 I CONTROL [initandlisten] shutting down with code:100

vagrant@m103:~$ validate_lab_configuration_file
You need to start mongod with a configuration file.

Looks like indentation problem for the error

Unrecognized option: ssl.CAFile
Make sure CAfile is two spaces to the right under ssl as below
ssl:
CAFile:

Your mongod is failing even after removing above because you already have a mongod instance running on same port
“DBPathInUse: Unable to lock the lock file: /data/db/mongod.lock (Resource temporarily unavailable). Another mongod instance is already running on the /data/db directory, terminating”
Please kill all mongods and start fresh

@Ridah_97796, I concur with what @Ramachandra_37567 says. Initially there was a problem with the content of your config file, but once you’d fixed that, you couldn’t start mongod because there was already a mongod instance running and using the same data folder as the one that the mongod that you’re trying to start is trying to use.

This is a really easy mistake to make, starting up mongod instances in the background, forgetting to stop them once you’ve finished with them, and then trying to start another mongod instance when you’ve already got one running with the same config file (and therefore the same data directory). I should know, I’ve done it enough times during this course :flushed:

The answer is buried in the lecture notes for the chapter 1 lab “Launching Mongod”

ps -ef | grep mongod

To people like me who aren’t familiar with the Linux command line, that command means next to nothing and is difficult to recall when it’s needed, but basically it lists any running processes which might be mongod. You might want to write it on a post-it note and stick it to your monitor :slight_smile:

If I run it on my vagrant m103 VM, it tells me this:

vagrant@m103:~$ ps -ef | grep mongod
vagrant   2379     1  1 06:11 ?        00:08:57 mongod -f node1.conf
vagrant   2582     1  1 06:33 ?        00:07:59 mongod -f node2.conf
vagrant   2623     1  1 06:34 ?        00:08:07 mongod -f node3.conf
vagrant   4200     1  1 09:38 ?        00:05:41 mongod -f mongod-repl-1.conf
vagrant   4291     1  1 09:43 ?        00:05:41 mongod -f mongod-repl-2.conf
vagrant   4321     1  1 09:43 ?        00:06:04 mongod -f mongod-repl-3.conf
vagrant   7556     1  1 15:50 ?        00:00:32 mongod -f node4.conf
vagrant   8438  2919  0 16:41 pts/0    00:00:00 grep --color=auto mongod

What this tells me is that I’ve been very bad at stopping my mongod instances once I’m done with them, because I’m still running the mongod instances that I started for both the lesson on setting up a replica set, and for the lab on the same subject. I want to keep the mongod instances I started during the lesson, but I think I’ve finished with the mongod instances that I started for the lab, so I can stop them thus:

vagrant@m103:~$ kill 4200
vagrant@m103:~$ kill 4291
vagrant@m103:~$ kill 4321
vagrant@m103:~$ ps -ef | grep mongod
vagrant   2379     1  1 06:11 ?        00:09:18 mongod -f node1.conf
vagrant   2582     1  1 06:33 ?        00:08:21 mongod -f node2.conf
vagrant   2623     1  1 06:34 ?        00:08:29 mongod -f node3.conf
vagrant   7556     1  1 15:50 ?        00:00:53 mongod -f node4.conf
vagrant   8706  2919  0 17:06 pts/0    00:00:00 grep --color=auto mongod

So now the mongod instances I started for the lectures are still running, but I’ve killed the instances that I started for the lab and forgot to stop, so I can now start other mongod instances using their data directories if I want to.

Disclaimer: you probably don’t want to go killing mongod instances like this in a production environment. This approach is appropriate in the contrived scenario where you’re running all the nodes in a replica set on a single developer box (which doesn’t actually provide the resilience which replica sets are intended for), where your data is probably less important than your ability to learn about how replica sets work.

I get the feeling that I’m not the only one who’s come here to learn about administering MongoDB dabases but has had to sidetrack to learn Linux commands. Any chance of some kind of crib sheet with information about the Linux commands used in this course, for the benefit of Windows junkies like me?

Not that I’m moaning of course, the quality of the training available here (for free!) continues to be excellent, other than considerations such as having an audience who aren’t necessarily already familiar with Linux. Keep up the good work :slight_smile:

Yes you right. I only had to restart my pc and start again.
Thanks for your help.

Thank you for the this tip, I noticed that every time I turn the PC off, I got the message that the VM is still running. Now I know how to switch them off. Thanks.

Hello,

I’ve gotten vagrant up and seems to be running nicely. Here’s the issue i’m having below.

  1. “MongoDB Internal Client”, version: “3.6.12” }, os: { type: “Linux”, name: “Ubuntu”, architecture: “x86_64”, version: “14.04” } }
    2019-06-23T14:34:42.416+0000 I NETWORK [conn5] end connection 127.0.0.1:42201 (0 connections now open)
    2019-06-23T14:45:04.856+0000 I NETWORK [listener] connection accepted from 127.0.0.1:42202 #6 (1 connection now open)
    2019-06-23T14:45:04.857+0000 I NETWORK [conn6] received client metadata from 127.0.0.1:42202 conn6: { application: { name: “MongoDB Shell” }, driver: { name: “MongoDB Internal Client”, version: “3.6.12” }, os: { type: “Linux”, name: “Ubuntu”, architecture: “x86_64”, version: “14.04” } }

when it comes to adding the user part I believe i did it right.
ongoDB Enterprise > db.createUser({
… user: “m103-admin”,
… pwd: “m103-pass”,
… roles: [
… {role: “root”, db: “admin”}
… ]
… })
2019-06-23T15:03:55.031+0000 E QUERY [thread1] Error: couldn’t add user: User “m103-admin@test” already exists :
_getErrorWithCode@src/mongo/shell/utils.js:25:13
DB.prototype.createUser@src/mongo/shell/db.js:1437:15
@(shell):1:1

THIS IS THE ERROR I GET WHEN I VALIDATE:

vagrant@m103:/var/log$ validate_lab_launch_mongod

Client experienced a timeout when connecting to the database - check that mongod is running on the correct port, and that your user was created with the correct settings.

vagrant@m103:/var/log$

please push me in the right direction. Thanks

You should add user in admin DB
Looks like it was added in test DB as per error-user already exists?
Please check db.getUsers()
db.getUser(“m103-admin”)

This is what i got with the db

MongoDB Enterprise > db.getUsers()
[
{
“_id” : “test.m103-admin”,
“user” : “m103-admin”,
“db” : “test”,
“roles” : [
{
“role” : “root”,
“db” : “admin”
}
]
}
]
MongoDB Enterprise >

when i run the validation script this is what i get:

vagrant@m103:/var/log$ validate_lab_launch_mongod

Client experienced a timeout when connecting to the database - check that mongod is running on the correct port, and that your user was created with the correct settings.

in /etc/mongod.conf i changed the port line and added 2700 and the listen local interface line and added 192.168.103.100 as requested. Am i missing something?

mongod.conf

for documentation of all options, see:

http://docs.mongodb.org/manual/reference/configuration-options/

Where and how to store data.

storage:
dbPath: /var/lib/mongodb
journal:
enabled: true

engine:

mmapv1:

wiredTiger:

where to write logging data.

systemLog:
destination: file
logAppend: true
path: /var/log/mongodb/mongod.log

network interfaces

net:
port: 27017, 27000
bindIp: 127.0.0.1

#Listen to local interface only. Comment out to listen on all interfaces.

bind_ip = 192.168.103.100, 127.0.0.1

how the process runs

processManagement:

timeZoneInfo: /usr/share/zoneinfo

#security:

#operationProfiling:

#replication:

#sharding:

Enterprise-Only Options:

#auditLog:

#snmp:

security:
authorization: enabled

You appear to have created your m103-admin user in the test database, rather than the admin database where users should be created by convention.

Although I don’t know exactly what the validation script is doing, I guess it’s probably trying to authenticate itself as the m103-admin user in the admin database, rather than the m103-admin user in the test database which you’ve created. If you haven’t created that user in the admin database then the validation script won’t be able to authenticate itself because it’s trying to authenticate as a user which doesn’t exist.

Try this:

use admin

and then run the same db.createUser(…) command you did before. This time you’ll be running it against the admin database, which is where people (and the validation script) normally expect the users to be.

Hope this helps.

1 Like

@Simon_39939 thanks so much for the help that makes more sense. This is now what i see and without a key.

}

]
MongoDB Enterprise > use admin
switched to db admin
MongoDB Enterprise > db.getUsers()
[
{
“_id” : “admin.m103-admin”,
“user” : “m103-admin”,
“db” : “admin”,
“roles” : [
{
“role” : “root”,
“db” : “admin”
}
]
}
]

When i go back to the vagrant box to test script now this is what i’m seeing:

Client experienced a timeout when connecting to the database - check that mongod is running on the correct port, and that your user was created with the correct settings.

@Simon_39939 is it something to do with: * authentication is enabled line? or is it because i don’t have the correct ports set up

019-06-23T17:20:39.956+0000 I NETWORK [initandlisten] waiting for connections on port 27017
2019-06-23T17:20:43.807+0000 I NETWORK [listener] connection accepted from 127.0.0.1:42246 #1 (1 connection now open)
2019-06-23T17:20:43.808+0000 I NETWORK [conn1] received client metadata from 127.0.0.1:42246 conn1: { application: { name: “MongoDB Shell” }, driver: { name: “MongoDB Internal Client”, version: “3.6.12” }, os: { type: “Linux”, name: “Ubuntu”, architecture: “x86_64”, version: “14.04” } }
2019-06-23T17:25:56.371+0000 I NETWORK [conn1] end connection 127.0.0.1:42246 (0 connections now open)

Hmm, your user looks correct now, and it’s in the right database (admin). Have you tried connecting to your cluster using the mongo shell with the credentials of the m103-admin user? Did it succeed?

Have you set the m103-admin user’s password to m103-pass? If the password is anything else then I think the validation script will fail, because that’s probably what it’s expecting the password to be.

Whether or not you can connect to the cluster using the mongo shell and the m103-admin user’s credentials, I think it would help if you could share the command line you’re using to attempt to connect the mongo shell to your cluster.

Just a thought… you said

Pretty much everything we do in this course (the bits I’ve done so far, anyway), is done within that vagrant VM. We create the replica sets there, we start the mongod instances there, we run the mongo shell there, and we run the validation scripts there.

The only thing I’ve been doing on the host machine (my PC where I’ve installed VirtualBox etc in order to get this VM running) is making notes about the course, posting in this forum, and creating a basic configuration file which I then copied to the VM.

Please tell me you haven’t created your cluster, databases, user etc on your host machine and then attempted to run the validation script on the VM (which won’t be able to see anything that you’ve created on the host machine)?

Hi James_68753

Make sure no space between the two IP’s in bind_ip parameter
Why two ports added?
Only one value should be there as asked in your lab requirement

Please try to follow your lab instructions.If you deviate validation will fail
As Simon_39939 mentioned validation looks for the correct user with mongod running on correct port/IP etc

Yes I’ve done everything you mentioned. I’ll share my path here.

  1. vagrant@m103:~$ mongo

  2. MongoDB Enterprise > db.getUsers()
    [
    {
    “_id” : “test.m103-admin”,
    “user” : “m103-admin”,
    “db” : “test”,
    “roles” : [
    {
    “role” : “root”,
    “db” : “admin”
    }
    ]
    }
    ]
    I set the password exactly how it says in the directions

mongo admin --host localhost:27000 --eval ’
db.createUser({
user: “m103-admin”,
pwd: “m103-pass”,
roles: [
{role: “root”, db: “admin”}
]
})

  1. Exit from mongo

  2. vagrant@m103:~$ hostname

m103

  1. vagrant@m103:~ validate_lab_launch_mongod Client experienced a timeout when connecting to the database - check that mongod is running on the correct port, and that your user was created with the correct settings. vagrant@m103:~

So i followed everything as the directions stated. Thanks

@Simon_39939 FINALLY FIGURED IT OUT AND GOT IT WORKING!! I JUST KILLED THE PROCESS AND ADDED --AUTH THANKS!