|
spencer If the shell running the test has been started with SSL, and is using the X509 client certificate, you should be able to run db.auth against the $external database. On master, you don't need to provide the username of the X509 user, so if you're using jstests/libs/client.pem you can run either:
MongoDB Enterprise > db.auth({user: "C=US,ST=New York,L=New York City,O=MongoDB,OU=KernelUser,CN=client", mechanism: "MONGODB-X509"})
|
1
|
for tests running on older versions of the shell/server, or
MongoDB Enterprise > db.auth({mechanism: "MONGODB-X509"})
|
1
|
You can also connect using server.pem to become the __system user.
|
|
The alternative is if there's some way to authenticate connections within the shell with x509 (that doesn't involve launching a new shell process for every connection), then we could probably figure out in sharding test from the options we're given whether we're using keyfile or x509, and authenticate the connections to the config servers appropriately before calling awaitReplication(), though it may be tough to figure out from the options what the keyfile/x509 credentials are in every possible configuration. I also don't think there is such a way to authenticate connections in the shell with x509 - spencer.jackson, can you confirm?
|
|
In lieu of a complete solution for SERVER-14017, the easiest and quickest way to work around this issue I can think of is to introduce a new method on ReplSetTest that basically does what awaitReplication/awaitLastOpCommitted do, but use isMaster (which doesn't require an authenticated connection to use) instead of replSetGetStatus.
|
|
This is actually trickier than it seems like, because of the ssl and auth tests, there's no good way to call awaitReplication() on the config server ReplicaSetTest since awaitReplication uses replSetGetStatus which requires authentication, and there's no good generic way to authenticate the connections used that works in all configurations we run ShardingTests under.
|