I’m not quite familiar with mongodb authentication mechanisms, but this value was set there to avoid a crash when it is undefined. This variable describes just the authentication mechanism, not the credentials. The latter are defined by the MONGODB_USERNAME and MONGODB_PASSWORD Tutor settings.
@regis yes, username and password can be passed in.
I am running on k8s and using a mongdb service, and in previsous tutor version, forum can connect to mongodb. With v10.2.2 built image, mongodb cannot be connected util I set
MONGOID_AUTH_MECH env to “:scram” in deployments.yml.
Interesting. I suggest you pass the MONGOID_AUTH_MECH environment variable to the forum container. You can do this by defining a custom docker-compose.override.yml file:
W, [2021-01-11T14:28:12.604779 #13] WARN – : Overwriting existing field _id in class User.
W, [2021-01-11T14:28:12.711481 #13] WARN – : MONGODB | Unsupported client option ‘max_retries’. It will be ignored.
W, [2021-01-11T14:28:12.711931 #13] WARN – : MONGODB | Unsupported client option ‘retry_interval’. It will be ignored.
W, [2021-01-11T14:28:12.712137 #13] WARN – : MONGODB | Unsupported client option ‘timeout’. It will be ignored.
/openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/auth/cr/conversation.rb:130:in `validate!’: User root is not authorized to access cs_comments_service. (Mongo::Auth::Unauthorized)
Do you have idea on how to fix this?
I used the docker image: overhangio/openedx-forum:10.0.11
Hey @vthily I was facing the same issue, and I just happened to follow @regis’s post #6 suggestion. One should override two docker-compose files that is docker-compose.yml & docker-compose.jobs.yml files, by following @regis’s recommended approach to override the default docker-compose files. Also make sure that MongoDB server’s user is using the same authentication mechanism that which you are passing in the docker-compose files.
Hi @vaunramesh26 ,
This solution works for local deployment . How we can implement this for k8s deployment? @vthily Do this solution works for you? How ?
Hi @vthily, @imantaba, all,
Were you able to fix this? If I try with an empty MONGODB_AUTH it works well, but when I set a username and password I get the same problem.
I tried to run the job to build the indexes without success:
Waiting for mongodb/elasticsearch...
2021/09/14 13:12:12 Waiting for: tcp://mongodb:27017
2021/09/14 13:12:12 Waiting for: http://elasticsearch:9200
2021/09/14 13:12:12 Connected to tcp://mongodb:27017
2021/09/14 13:12:12 Received 200 from http://elasticsearch:9200
/openedx/cs_comments_service/lib/tasks/flags.rake:6: warning: already initialized constant ROOT
/openedx/cs_comments_service/lib/tasks/deep_search.rake:7: warning: previous definition of ROOT was here
/openedx/cs_comments_service/lib/tasks/kpis.rake:7: warning: already initialized constant ROOT
/openedx/cs_comments_service/lib/tasks/flags.rake:6: warning: previous definition of ROOT was here
/openedx/cs_comments_service/models/constants.rb:2: warning: already initialized constant COURSE_ID
/openedx/cs_comments_service/lib/tasks/db.rake:28: warning: previous definition of COURSE_ID was here
rake aborted!
Mongo::Auth::Unauthorized: User mongouser is not authorized to access cs_comments_service.
/openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/auth/scram/conversation.rb:489:in `validate!'
...
I tried adding manually the user in mongodb with the same result:
I think you can start with ssh to that mongodb instance and test with the connection string to make sure it works in cli. You can inspect the list of users, database.
Other thing: user was added to the admin database, but the connection string doesn’t seems to include that as the authDatabase. You might need to check that too.
I think I made it.
I am not expert in MongoDB (or in any other thing), but this is what I’ve learned.
MongoDB uses the admin DB to store users. There you can grant permissions to all or other specific DBs. Usually clients should authenticate users using the admin DB, and then access whatever DB that holds the data. However, it’s possible to store users in a specific DB.
In the connection URL, the authentication DB is specified after the slash, and it’s not necessarily the DB where the data is. If no DB is specified there, the admin DB is used for authentication by default (see the url sepec)
In some cases, the LMS, CMS and Forum may authenticate using the default, and in others using a specific DB. I had to replicate the user in admin, cs_comments_service and openedx databases to have everything working properly.
If you want to connect to an external MongoDB, you may be required to provide user authentication. By default, Tutor leaves authentication empty and doesn’t work with Mongo in another place.
When you use user authentication, at least SCRAM method must be specified in the connection.
I have created PR #493 to add MONGOID_AUTH_MECH as parameter and to the jobs and deployments.
Hi all! @regishas found that the problem was that setting MONGOID_AUTH_MECH="" in the forum dockerfile actually prevented Ruby to use the default “:scram” value. This is because an empty env var would not be nil, while an unset var yes.
Now the PR with the fix was merged to master. Please check if it solves the issues reported before.
@regis@andres Still i had authentication problem with external MongoDB for k8s deployment
tutor, version 12.1.6
Waiting for mongodb/elasticsearch...
2021/11/08 06:51:38 Waiting for: tcp://edx-mongo-mongodb.edx-mongo.svc.cluster.local:27017
2021/11/08 06:51:38 Waiting for: http://elasticsearch:9200
2021/11/08 06:51:38 Received 200 from http://elasticsearch:9200
2021/11/08 06:51:38 Connected to tcp://edx-mongo-mongodb.edx-mongo.svc.cluster.local:27017
W, [2021-11-08T06:51:40.630423 #13] WARN -- : Overwriting existing field _id in class User.
W, [2021-11-08T06:51:40.673717 #13] WARN -- : MONGODB | Unsupported client option 'max_retries'. It will be ignored.
W, [2021-11-08T06:51:40.673795 #13] WARN -- : MONGODB | Unsupported client option 'retry_interval'. It will be ignored.
W, [2021-11-08T06:51:40.673820 #13] WARN -- : MONGODB | Unsupported client option 'timeout'. It will be ignored.
/openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/auth/scram/conversation.rb:489:in `validate!': User admin is not authorized to access org2-cs_comments_service. (Mongo::Auth::Unauthorized)
from /openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/auth/scram/conversation.rb:484:in `validate_first_message!'
from /openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/auth/scram/conversation.rb:113:in `continue'
from /openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/auth/scram.rb:60:in `login'
from /openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/server/connection.rb:249:in `block in authenticate!'
from /openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/server.rb:267:in `handle_auth_failure!'
from /openedx/cs_comments_service/vendor/bundle/ruby/2.5.0/gems/mongo-2.5.3/lib/mongo/server/connection.rb:248:in `authenticate!'
Thanks for the report @imantaba. It’s really difficult for me to help you troubleshoot this, as I don’t have access to a remote mongodb cluster. Do you think you could investigate the issue?