Please clarify the privileges needed for (remote) MongoDB access? about scot

[toddbruner]

Your remove instance may be requiring the mongo client to authenticate to the mongod server. You will have to get a DB username and password for scot from your DBA. Then plug that username and password into the config file and you should be good to go.

[ghub2015]

Todd, I already shared the credentials with the DBA (and re-verified with them) -- it was set to what I provided them (user, password, etc).

Any thoughts or suggestions?

[toddbruner]

At this point, I would start normal troubleshooting. Can the mongo-cli
connect to the remote mongo instance with the username and password. Is
SSL working (sometimes certs can be self-signed or invalid and this causes
connection problems.) Is there a firewall, proxy, or filter in between?

There isn't any special privileges necessary. SCOT acts just like a command
line client. If the command line can reach, but SCOT can't, it is probably
something to do with SSL (if enabled). Also ensure that you have the mongo
client libraries installed on the scot server.

Let me know if you continue to have problems...

---

[email protected]

On Mon, Feb 22, 2016 at 1:42 PM, ghub2015 [email protected] wrote:

Todd, I already shared the credentials with the DBA (and re-verified with
them) -- it was set to what I provided them (user, password, etc).

Any thoughts or suggestions?

—
Reply to this email directly or view it on GitHub
#32 (comment).

[ghub2015]

Thanks again Todd.

One thing we have noticed is:

• my App Server (Ubuntu 14.04 Server) is running MongoDB 2.6.11
• the DB Server (RedHat 6.7) is running MongoDB 3.2.1

Could this cause issues? If yes, should we upgrade the App Server or downgrade the DB server?

Thank you

[toddbruner]

that will definitely cause problems. client and server need to be at same
level. I recommend that you use something in the Mongo3 series. I know
that 3.0.8 works for sure. 3.2.1 should work, but I haven't tested. if
you use 3.2 let me know how it works. Thanks!

---

[email protected]

On Mon, Feb 22, 2016 at 4:34 PM, ghub2015 [email protected] wrote:

Thanks again Todd.

One thing we have noticed is:

• my App Server (Ubuntu 14.04 Server) is running MongoDB 2.6.11
• the DB Server (RedHat 6.7) is running MongoDB 3.2.1

Could this cause issues? If yes, should we upgrade the App Server or
downgrade the DB server?

Thank you

—
Reply to this email directly or view it on GitHub
#32 (comment).

[ghub2015]

Thanks Todd.

We are testing both approaches (downgrade DB server, and upgrade App server) to see the results.

FYI MongoDB 2.6.11 version is what is installed by default on Ubuntu Server 14.04 when you run the SCOT installer.

[toddbruner]

I'd recommend using the 3 series. That will be what we require in the next
release. Mongo has some good docs on how to upgrade to the 3 series.
pretty painless. I'll look into why 2.6 is the default.

---

[email protected]

On Tue, Feb 23, 2016 at 11:25 AM, ghub2015 [email protected] wrote:

Thanks Todd.

We are testing both approaches (downgrade DB server, and upgrade App
server) to see the results.

FYI MongoDB 2.6.11 version is what is installed by default on Ubuntu
Server 14.04 when you run the SCOT installer.

—
Reply to this email directly or view it on GitHub
#32 (comment).

[ghub2015]

Understood; I would rather have it working using 3 series as well. The DBA's downgraded the DB server to 2.6.11 first (and that worked; though we temporarily disable auth for it to work).

I will be testing with 3.2.1 on client & server as well.

[ghub2015]

BTW, here are instructions for installing MongoDB 3.2 on Ubuntu (only LTS releases are supported -- currently 12.04 or 14.04). Just posting in case it helps anyone else following this thread:

https://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/

The SCOT Ubuntu installer (/opt/sandia/webapps/scot3/ubuntu_installer.sh) currently installs MongoDB 2.6.11 using the "Mongo 10Gen" repo.

Thanks

[ghub2015]

Todd, since setting up MongoDB 3 on both Client & Server, still receiving the error below.

Note: It works fine without authentication enabled.

2016/02/25 09:52:52 [30289]        Mongo.pm:   95 ---- Mongo client connection build ---
2016/02/25 09:52:52 [30289]        Mongo.pm:   96 ---- host:    mongodb://<remote-db-hostname>:27021
2016/02/25 09:52:52 [30289]        Mongo.pm:   97 ---- port:    27017
2016/02/25 09:52:52 [30289]        Mongo.pm:   98 ---- name:    scotng-prod
2016/02/25 09:52:52 [30289]        Mongo.pm:   99 ---- user:    admin
2016/02/25 09:52:53 [30289]        Mongo.pm:  776 mongodb://<remote-db-hostname>:27021 Reading documents matching $VAR1 = {'match_ref' => {},'collection' => 'users'};
2016/02/25 09:52:53 [30289] DefaultHelpers.pm:   90 MongoDB::DatabaseError: not authorized on scotng-prod to execute command { count: "users", query: {} }

Here are the user named "admin" privileges from the most recent test:

{
    "_id" : "scotng-prod.admin",
    "user" : "admin",
    "db" : "scotng-prod",
    "roles" : [
        {
            "role" : "root",
            "db" : "admin"
        },
        {
            "role" : "readWrite",
            "db" : "scotng-prod"
        },
        {
            "role" : "dbAdmin",
            "db" : "scotng-prod"
        },
        {
            "role" : "userAdmin",
            "db" : "scotng-prod"
        }
    ]
}

Edit: Here is the database config from /opt/sandia/webapps/scot3/scot.conf

                   'database' => {
                                    'write_safety' => 1,
                                    'port' => 27017,
                                    'db_name' => 'scotng-prod',
                                    'host' => 'mongodb://<remote-db-hostname>:27021',
                                    'user' => 'admin',
                                    'pass' => 'password'
                                  }

Can you please advise?

Thank you

[toddbruner]

https://docs.mongodb.org/manual/reference/built-in-roles/

has a list of the possible roles and how they map to the various
activities. Since I mainly run SCOT with a local DB and do not use Mongo's
auth system, I have not previously considered how these intersect with the
activities on SCOT.

Thanks for bringing this to my attention and will begin to an audit to
document or automate the population of roles necessary for this to work.

Todd

---

[email protected]

On Thu, Feb 25, 2016 at 11:11 AM, ghub2015 [email protected] wrote:

Todd, since setting up MongoDB 3 on both Client & Server, still receiving
the error below.

Note: It works fine without authentication enabled.

2016/02/25 09:52:52 [30289] Mongo.pm: 95 ---- Mongo client connection build ---
2016/02/25 09:52:52 [30289] Mongo.pm: 96 ---- host: mongodb://:27021
2016/02/25 09:52:52 [30289] Mongo.pm: 97 ---- port: 27017
2016/02/25 09:52:52 [30289] Mongo.pm: 98 ---- name: scotng-prod
2016/02/25 09:52:52 [30289] Mongo.pm: 99 ---- user: admin
2016/02/25 09:52:53 [30289] Mongo.pm: 776 mongodb://:27021 Reading documents matching $VAR1 = {'match_ref' => {},'collection' => 'users'};
2016/02/25 09:52:53 [30289] DefaultHelpers.pm: 90 MongoDB::DatabaseError: not authorized on scotng-prod to execute command { count: "users", query: {} }

Here are the user named "admin" privileges from the most recent test:

{
"_id" : "scotng-prod.admin",
"user" : "admin",
"db" : "scotng-prod",
"roles" : [
{
"role" : "root",
"db" : "admin"
},
{
"role" : "readWrite",
"db" : "scotng-prod"
},
{
"role" : "dbAdmin",
"db" : "scotng-prod"
},
{
"role" : "userAdmin",
"db" : "scotng-prod"
}
]
}

Can you please advise?

Thank you

—
Reply to this email directly or view it on GitHub
#32 (comment).

[ghub2015]

Todd, here is the resolution:

1. All auth parameters must now be included in MongoDB URI in the format:

                                mongodb://user:password@host:port/databasename

2. Reference: https://www.mongodb.com/blog/post/introducing-the-1-0-perl-driver
3. The password cannot contain any of the URI delimiters (i.e., “@”) … as the URI is parsed
4. Currently, I implemented this in the scot.conf file ('host' parameter); rendering the 'user' and 'pass' parameters superfluous.

I hope this helps you and any others who are searching for this.

[toddbruner]

Awesome! Thanks for posting a follow up.