Rocket.Chat - SLACK alternative (with MongoDB as backend)

Docker Rocket.Chat - SLACK alternative (with MongoDB as backend)

Currently reading
Docker Rocket.Chat - SLACK alternative (with MongoDB as backend)

2020-02-08 17_54_16-Window.png

2020-02-08 17_54_34-Window.png
 
Hi,

Question; how do I update the mongodb container?
I have tried the usual way, download image and then clean container. All this goes well and I get a new mongo container, but the version stays the same as before the update (see screenshot)
I have also tried to update through portainer, update goes well new container is created but still the same version??

Is there something I'm doing wrong? Or is there another way to do the update?

Screen_Shot.png
 
Same problem with updating mariadb. The log shows that a new image has pulled but after the update still the same version?!

latest: Pulling from library/mariadb 423ae2b273f4: Already exists de83a2304fa1: Already exists f9a83bce3af0: Already exists b6b53be908de: Already exists 2b41ae57cefb: Pulling fs layer 7ecd5cacc370: Pulling fs layer 9f96ac6b2583: Pulling fs layer 9224e6c8f841: Pulling fs layer 8fdc4c2808be: Pulling fs layer a2ae8752de58: Pulling fs layer 5adda6a0eec5: Pulling fs layer c3b660834848: Pulling fs layer 3ac908ac8219: Pulling fs layer 62be07fe3c17: Pulling fs layer 9224e6c8f841: Waiting 8fdc4c2808be: Waiting a2ae8752de58: Waiting 5adda6a0eec5: Waiting c3b660834848: Waiting 3ac908ac8219: Waiting 62be07fe3c17: Waiting 2b41ae57cefb: Verifying Checksum 2b41ae57cefb: Download complete 9f96ac6b2583: Verifying Checksum 9f96ac6b2583: Download complete 7ecd5cacc370: Verifying Checksum 7ecd5cacc370: Download complete 2b41ae57cefb: Pull complete 9224e6c8f841: Verifying Checksum 9224e6c8f841: Download complete 8fdc4c2808be: Download complete a2ae8752de58: Download complete 5adda6a0eec5: Verifying Checksum 5adda6a0eec5: Download complete 3ac908ac8219: Verifying Checksum 7ecd5cacc370: Pull complete 62be07fe3c17: Verifying Checksum 62be07fe3c17: Download complete 9f96ac6b2583: Pull complete c3b660834848: Verifying Checksum c3b660834848: Download complete 9224e6c8f841: Pull complete 8fdc4c2808be: Pull complete a2ae8752de58: Pull complete 5adda6a0eec5: Pull complete c3b660834848: Pull complete 3ac908ac8219: Pull complete 62be07fe3c17: Pull complete Digest: sha256:05b8bf8e3c5cefddb6e7190ff8a5e720872728a9f6b27e5e90a16ebe984091c1 Status: Downloaded newer image for mariadb:latest mariadb mariadb 265dcccdab608e482f1418e88ccf9bdf9ef5030e8ace9d62ddd8b29c425c4d5e

Screen_Shot 1.png
 
@BobW I have just tested my mongoDB update from version 4.0 to the latest 4.2.3 (thats the latest in the mongo:latest image). I have had 0 problem with the regular, stop, clear, start method.
Thanks for letting me know. That’s indeed strange that I’m having issues with the same update method. I will dive in it see what I can find out. Will report back.
 
So I guess it is a bug or something within my docker, because when I look at the container info with mongo-express I see version 4.2.3 and docker GUI shows version 4.2.1 :sneaky:
Screen_Shot.png

(mongo-express web-interface)


Screen_Shot 1.png

(docker GUI)


So it seems the container is updated but somehow Synology docker GUI doesn't show the right version.
 
@Rusty I'm facing the same symptoms as a couple others in this thread. In the log for rocket.chat:

Code:
MongoNetworkError: failed to connect to server [db:27017] on first connect [MongoError: Authentication failed.

And over in the logs for the mongo container:
Code:
ACCESS   Supported SASL mechanisms requested for unknown user 'root@admin'
SASL SCRAM-SHA-1 authentication failed for root on admin from client 172.17.0.3:36262 ; UserNotFound: Could not find user "root" for db "admin"

I can shell into the mongo instance no problem when it's running and verifythe right DBs and root user exist.

1584681610935.png


I've followed the tutorial exactly and even deleted everything to start over a couple times so far. I'm attaching the configuration screenshots below:

1584680174103.png


1584680246188.png


I've tried the suggestions from other cases in this thread, but nothing has helped! It seems like rocket.chat can see and connect to db but it can't authenticate.
 
@zpoj and you are def not alone in this. I will look into this and get back to you if I have some news on the matter. From what I can see you have done all that's needed, this is something that's troubling a number of users.
 
@Rusty I'm facing the same symptoms as a couple others in this thread. In the log for rocket.chat:

Code:
MongoNetworkError: failed to connect to server [db:27017] on first connect [MongoError: Authentication failed.

And over in the logs for the mongo container:
Code:
ACCESS   Supported SASL mechanisms requested for unknown user 'root@admin'
SASL SCRAM-SHA-1 authentication failed for root on admin from client 172.17.0.3:36262 ; UserNotFound: Could not find user "root" for db "admin"

I can shell into the mongo instance no problem when it's running and verifythe right DBs and root user exist.

View attachment 974

I've followed the tutorial exactly and even deleted everything to start over a couple times so far. I'm attaching the configuration screenshots below:

View attachment 972

View attachment 973

I've tried the suggestions from other cases in this thread, but nothing has helped! It seems like rocket.chat can see and connect to db but it can't authenticate.
Exactly the same problem here...
 
@zpoj and you are def not alone in this. I will look into this and get back to you if I have some news on the matter. From what I can see you have done all that's needed, this is something that's troubling a number of users.

Thank you, appreciate it!

Both of the projects have seen significant changes over the last few months, so it might be worth "pinning" the version numbers instead of pulling the latest images, which have changed command line args, env vars, and configs.
 
I do agree that pulling the latest version could lead to potential problems but in this case I am running with latest versions of both images without any problem. I will get back as soon as I get some time with this error.

This is MongoDB side of the problem. From a quick glance it looks like no matter if the root account is being used, it looks like it still is missing permissions on the admin db. Not really sure why or if that’s the case but giving permissions again on the admin db might solve a problem here.

I’ll definitely looks into this.
 
@zpoj I have taken the time today to have a look at this problem with @wwwampy as well (considering that he has the same problem).

Atm, we have not finished looking into this problem, but I have just tried to set up a clean RC setup with new Mongo instance and got it up in 5min.

So 1st MongoDB side. After the initial setup in the tutorial (up until the point of converting your instance to a replica), there were 35 files/folders in the NAS folder that were mapped to /data/db destination.

Screenshot 2020-03-22 at 14.09.04.png


The reason I'm saying this is that @wwwampy has none. This was my thought the other day that there might be permission problems on the DSM layer and not on the mongo/docker container one.

Now after running the replica command line and listing DBs all is well:

Code:
rs.initiate({ id: 'rs10', members: [ { id: 0, host: 'localhost:27017' } ]})
{ "ok" : 1 }
rs10:SECONDARY>

Listing DBs >

rs10:SECONDARY> show dbs
admin 0.000GB
config 0.000GB
local 0.000GB
rs10:PRIMARY>

Moving on with RC installation. I have not used the DB link option as in the tutorial for this test run, so the variables are a bit different (static IP was entered).

MONGO_URLmongodb://root:[email protected]:27020/rockettest?authSource=admin
HOME/tmp
PORT3000
ROOT_URL
Accounts_AvatarStorePath/app/uploads
MONGO_OPLOG_URLmongodb://root:[email protected]:27020/local?authSource=admin

Also would like to point that rockettest DB (used to store the content) was NOT created before installing RC. So RC installation did it on its own.

As expected RC was up and running just fine:

Screenshot 2020-03-22 at 14.26.55.png


Listing mongo DBs now:

Code:
rs10:PRIMARY> show dbs
admin       0.000GB
config      0.000GB
local       0.001GB
rockettest  0.004GB
rs10:PRIMARY>

Also, the number of files in mongoDB NAS folder has jumped to 313.

Screenshot 2020-03-22 at 14.40.24.png


So to conclude for the moment, I think that anyone who is having problems with RC installation should be sure that mongoDBs initial steps (up until the point of replica creation) do indeed generate some files. If this is not the case, then you are having local NAS/DSM permission problems. Fix that 1st and move on then.

If this is the case and you do get some files created in the 1st place, but still are unable to continue (getting the same error) then the problem is somewhere else.

I Will post some more as well troubleshoot this problem.
 
I discovered the source of my issue: of all the environment variables in the tutorial, MONGO_URLis the only one that you need to update (instead of creating). So when I added a new value there, it was being overwritten by the default one a few lines later and thus the URL was wrong the whole time (no surprise it couldn't auth).

Thank you for all the troubleshooting; it inspired me to go back and very carefully try again! In the screenshot above, the repeated value was cut off at the bottom of the window, otherwise it might have been really obvious.
 
@zpoj
Glad you sorted it out. I can see we have the same NAS model, but I still can't make it work. That MONGO_URL is already inside, so I just update it, then I add MONGO_OPLOG_URL and Save.

Always the same error. Can't connect to mongodb.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top