Entries tagged [sametime]
Securing access to MongoDB with Sametime 12 Premium
by Richard Pajerski
Posted on Tuesday February 14, 2023 at 10:58PM in Technology
Setting up a new, fully functional stand-alone Sametime 12.0.1 Premium server on Docker instance is a relatively pleasant experience and HCL has made great strides is presenting a more simplified, compelling UX for the product than what was previously offered. For example, the new interface for creating and customizing meetings gets all the important, relevant bits into a single page (a good introduction to the product can be found here).
But the thrust of this post is on securing the server itself, and more specifically the MongoDB portion where chat histories, contact lists and other details are stored. HCL supports MongoDB versions 4.2 and higher on a best effort basis and I'm using version 6.0.4 on CentOS 8 for purposes of this post. Here's what worked for me.
After installing, we configure our Sametime database using the MongoDB Shell; upon first connecting, there's no prompt for a password and we're plainly told:
"Access control is not enabled for the database. Read and write access to data and configuration is unrestricted"
Well, that's not good. It was now possible to connect using mongosh and fully control the server *from anywhere, without a password*...According to the installation guide, port 27017 should be "permitted bidirectionally". That's understandable since a common strategy is to deploy the MongoDB server on its own host. But even with this installation which has both the MongoDB server and Sametime on the same machine, closing off external access to 27017 caused internal connectivity problems for Sametime (I could no longer create meetings and chat histories were no longer available).
So next I turned to this document on securing MongoDB. That method might work for other versions of MongoDB but it didn't work with 6.0.4 (the MongoDB server refused to start). What I found is that "keyFile" authorization is needed for this version of MongoDB when replica sets are used (which is the default for Sametime).
Create the keyfile:
openssl rand -base64 812 > /opt/st12/mongosec.key
Be sure to also run these two commands on the keyfile or Mongo won't start:
chmod 400 /opt/st12/mongosec.keychown mongod:mongod /opt/st12/mongosec.key
Edit /etc/mongod.conf to tell MongoDB where the file is and enable authorization:
security:
keyFile: /opt/st12/mongosec.key
authorization: enabled
We also need to launch the MongoDB server with "--auth". I've installed MongoDB as a service so that means editing /etc/systemd/system/multi-user.target.wants/mongod.service:
[Service]
Environment="OPTIONS=-f /etc/mongod.conf --auth"
After restarting the MongoDB service (systemctl restart mongod), I can still connect with mongosh but the warnings are gone; if I attempt to run commands, I'm told authentication is required:
To connect with a username:
mongosh mongodb://127.0.0.1:27017 -u sametimeUser
Finally, don't forget to change the default user/pass combination (sametimeUser/sametime) before going live!
Sametime 11 FP2 upgrade - keep MongoDb running
by Richard Pajerski
Posted on Friday August 21, 2020 at 01:51PM in Technology
[Edit August 27, 2020: HCL has updated the documentation to include: "MongoDB needs to remain active during upgrade"]
Quick note on Sametime 11 FP2 which is now available on FlexNet. [The fixlist is located here and the accompanying upgrade instructions are here.]
The instructions tell you to:
-- Close all applications on the server, including the Domino server administrator and the web browser.
-- Stop all Domino and Sametime services.
You might think this includes stopping the MongoDb service as well but you should actually keep that running, at least before you run the proxy upgrade. The reason is that the proxy upgrade script tries to connect to the MongoDb service and if it isn't running the upgrade will not succeed and you'll be asked to:
"Please verify/update dbconfig.properties and stproxyconfig.xml manually."
It's not a major issue... you can simply restart the MongoDb service and rerun the upgrade. However, since the upgrade process makes a backup of the previous Tomcat install, you'll now have a duplicate set of backup files.
Tags: sametime