# Datagerry 2.2.0 upgrade caused database connection errro **URL:** \ **Category:** Community Support\ **Created:** [July 8, 2024, 9:12am UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616 "2024-07-08T09:12:00Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![sink1](https://dub1.discourse-cdn.com/flex013/user_avatar/community.datagerry.com/sink1/32/790_2.png) [@sink1](https://community.datagerry.com/u/sink1)\ **Post date:** [July 8, 2024, 9:12am UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/1 "2024-07-08T09:12:00Z")
Hi, I upgraded the 2.2.0 release from 2.1.0 on RHEL9. Then I copied my cmdb.conf file back into the /etc/datagerry/cmdb.conf, started datagerry, and got: ```auto Jul 5 14:10:04 uat1 datagerry[2267801]: [2024-07-05 14:10:04][INFO] --- DATAGERRY starting... ( __main__.py) Jul 5 14:10:04 uat1 datagerry[2267801]: [2024-07-05 14:10:04][INFO] --- Checking database connection with cmdb.conf data ( __main__.py) Jul 5 14:10:04 uat1 datagerry[2267801]: [2024-07-05 14:10:04][CRITICAL] --- CMDBError: The section Database does not exist! ( __main__.py) Jul 5 14:10:04 uat1 datagerry[2267801]: [2024-07-05 14:10:04][INFO] --- DATAGERRY stopped! ( __main__.py) ``` This is weird because the cmdb.conf contains the settings: ```auto # ls -l /etc/datagerry/cmdb.conf -rw-r--r--. 1 root root 798 Jul 8 11:11 /etc/datagerry/cmdb.conf ``` ```auto # cat /etc/datagerry/cmdb.conf [Database] host = 127.0.0.1 port = 27017 database_name = datagerry tls=false [WebServer] host = 0.0.0.0 port = 4000 [MessageQueueing] host = 127.0.0.1 port = 5672 username = guest password = NothingHereToSee exchange = datagerry.eventbus connection_attempts = 2 retry_delay = 6 ``` Did the format change between 2.1.0 and 2.2.0? ---
**Author:** ![marcinw](https://avatars.discourse-cdn.com/v4/letter/m/eb8c5e/32.png) [@marcinw](https://community.datagerry.com/u/marcinw)\ **Post date:** [July 8, 2024, 9:56am UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/2 "2024-07-08T09:56:51Z")
Hey @sink1 > [@sink1](#): > > `database_name = datagerry` in earlier versions were: `database_name = cmdb` ---
**Author:** ![sink1](https://dub1.discourse-cdn.com/flex013/user_avatar/community.datagerry.com/sink1/32/790_2.png) [@sink1](https://community.datagerry.com/u/sink1)\ **Post date:** [July 8, 2024, 11:53am UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/3 "2024-07-08T11:53:36Z")
Hi, Our database name did not change. In 2.1.0 we have a database called _datagerry_ in mongod. In 2,.2.0 we have a database called _datagerry_ in mongod. Nothing changed on any of our mongodb databases: ```auto test> show dbs admin 40.00 KiB config 72.00 KiB datagerry 39.38 MiB local 72.00 KiB test> use datagerry; switched to db datagerry ``` I copied a known working configuration into the 2.2.0 installation that has this: ```auto [Database] host = 127.0.0.1 port = 27017 database_name = datagerry tls=false ``` Or do you mean that Becom have hardcoded the database names into 2.2.0? ---
**Author:** ![marcinw](https://avatars.discourse-cdn.com/v4/letter/m/eb8c5e/32.png) [@marcinw](https://community.datagerry.com/u/marcinw)\ **Post date:** [July 8, 2024, 12:02pm UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/4 "2024-07-08T12:02:25Z")
I thought it was about the default settings in section [MessageQueueing] use entry: ```auto use_tls = ... ``` I’m wondering if this entry is compatible with the configuration: in section [Database] ```auto tls=false ``` ---
**Author:** ![adnan.smajic](https://dub1.discourse-cdn.com/flex013/user_avatar/community.datagerry.com/adnan.smajic/32/754_2.png) [@adnan.smajic](https://community.datagerry.com/u/adnan.smajic)\ **Post date:** [July 17, 2024, 6:29am UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/5 "2024-07-17T06:29:02Z")
Hi @sink1 , we have not changed anything in the cmdb.conf with the last release, we will have a look at it. BR Adnan ---
**Author:** ![witt](https://dub1.discourse-cdn.com/flex013/user_avatar/community.datagerry.com/witt/32/843_2.png) [@witt](https://community.datagerry.com/u/witt)\ **Post date:** [August 11, 2024, 5:59pm UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/6 "2024-08-11T17:59:41Z")
Not sure if its related, but I am getting upgrade failures in the logs with updating via Docker also going from 2.1.0 to 2.2.0 ![image](https://europe1.discourse-cdn.com/flex013/uploads/datagerry/original/1X/a18eed55f6478bd1e341e8956cbfc6ec07717e8b.jpeg) ---
**Author:** ![witt](https://dub1.discourse-cdn.com/flex013/user_avatar/community.datagerry.com/witt/32/843_2.png) [@witt](https://community.datagerry.com/u/witt)\ **Post date:** [August 13, 2024, 2:11pm UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/7 "2024-08-13T14:11:33Z")
And now my database is in read only mode 🙂 ```sh [2024-08-13 14:13:11][ERROR] --- Something went wrong during the generation of the updater module. Error: An empty update path is not valid., full error: {'index': 0, 'code': 56, 'errmsg': 'An empty update path is not valid.'} ( __main__.py) [2024-08-13 14:13:11][WARNING] --- The update did not go through as expected - Status UpateStatus.ERROR ( __main__.py) ``` ---
**Author:** ![sink1](https://dub1.discourse-cdn.com/flex013/user_avatar/community.datagerry.com/sink1/32/790_2.png) [@sink1](https://community.datagerry.com/u/sink1)\ **Post date:** [October 29, 2024, 10:28am UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/8 "2024-10-29T10:28:37Z")
Hi, Did you work out what the problem was with the upgrade? ---
**Author:** ![sink1](https://dub1.discourse-cdn.com/flex013/user_avatar/community.datagerry.com/sink1/32/790_2.png) [@sink1](https://community.datagerry.com/u/sink1)\ **Post date:** [November 7, 2024, 1:15pm UTC](https://community.datagerry.com/t/datagerry-2-2-0-upgrade-caused-database-connection-errro/616/9 "2024-11-07T13:15:35Z")
Hi, # 1. _ **RPM problems** _ Something is wrong with the new release: The RPM logic seems wrong. Clients modify their cmdb.conf for their environments. This is normal. We have to. Usually when an rpm installs new client customisable configuration files, the process either prompts the if the new files hsiould clobber the existing file or should it be backed up. If iInteractive is not meant to happen then the RPM process should write the new configuration file with a suffix. Thus the /etc/datagerry/cmdb.conf should be left **untouched** by the RPM. Unfortunately, this does **not** happen. The Datagerry RPM just writes the distribution over the existing file. Which means for many, the datagerry instances will _fail_ because the configuration is now broken. For examples, our mongodb database is called datagerry. The config file has: `database_name = datagerry` The RPM deletes our cmdb.conf now we have got `database_name = cmdb` so the app will not start after the new RPM is installed. So,Best to back up your datagerry configuration files before you upgrade datagrerry. and put these back afterwards. Else, datagrerry will not start. # 2. _ **Exernal Mongo datbase servers problems with and without TLS** _ I tried again to use mongodb on an external servers with and without TLS again on version 2.2.0, but it still won’t connect. _Mongo **sh** _ works just fine with the same credentials from the VM running the Datagerry instance, so I can deduce the problem lies with Datagerry. Because otherwise mongodh connection would not work, but it does. Here are the configurations used and error messages: # **Config with TLS Disabled** # Mongod /etc/mongod.conf ```auto systemLog: destination: file logAppend: true path: /var/log/mongod/mongod.log storage: dbPath: /data/mongodb/mongodbdata journal: enabled: true processManagement: timeZoneInfo: /usr/share/zoneinfo net: port: 27017 bindIpAll: true tls: mode: enabled security: authorization: enabled ``` # /etc/datagerry/cmdb.conf ```auto [Database] host = 218.g.local port = 27017 database_name = datagerry username = datagerry_user password = xxxxxx tls = false [WebServer] host = 0.0.0.0 port = 4000 [MessageQueueing] host = 127.0.0.1 port = 5672 username = guest password = xxxxxx exchange = datagerry.eventbus connection_attempts = 2 retry_delay = 6 ``` # Errors with TLS disabled ```auto Nov 7 14:05:10 dg-server datagerry[221556]: [2024-11-07 14:05:10][INFO] --- Checking database connection with cmdb.conf data ( __main__.py) Nov 7 14:05:10 dg-server datagerry[221556]: [2024-11-07 14:05:10][CRITICAL] --- CMDBError: Authentication failed., full error: {'ok': 0.0, 'errmsg': 'Authentication failed.', 'code': 18, 'codeName': 'AuthenticationFailed'} ( __main__.py) Nov 7 14:05:10 dg-server datagerry[221556]: [2024-11-07 14:05:10][INFO] --- DATAGERRY stopped! ( __main__.py) ``` # **Config with TLS Enabled** # Mongod /etc/mongod.conf ```auto systemLog: destination: file logAppend: true path: /var/log/mongod/mongod.log storage: dbPath: /data/mongodb/mongodbdata journal: enabled: true processManagement: timeZoneInfo: /usr/share/zoneinfo net: port: 27017 bindIpAll: true tls: mode: enabled security: authorization: enabled ``` # /etc/datagerry/cmdb.conf ```auto [Database] host = 218.g.local port = 27017 database_name = datagerry username = datagerry_user password = xxxxxx tls = true tlsCertificateKeyFile=/etc/pki/tls/private/mongodb-chain-218.pem tlsCAFile=/etc/pki/tls/certs/mongodb-218.pem [WebServer] host = 0.0.0.0 port = 4000 [MessageQueueing] host = 127.0.0.1 port = 5672 username = guest password = xxxxxx exchange = datagerry.eventbus connection_attempts = 2 retry_delay = 6 ``` # Errors with TLS enabled from /var/log/datagerry `Nov 7 14:00:25 dg-server datagerry[214406]: [2024-11-07 14:00:25][CRITICAL] --- DatabaseConnectionError: Could not connect to database SSL handshake failed: 218.g.local:27017: EOF occurred in violation of protocol (_ssl.c:1129) (configured timeouts: socketTimeoutMS: 20000.0ms, connectTimeoutMS: 20000.0ms), Timeout: 30s, Topology Description: ]> ( __main__.py)`