Datagerry 2.2.0 upgrade caused database connection errro

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:

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:

# ls -l /etc/datagerry/cmdb.conf
-rw-r--r--. 1 root root 798 Jul  8 11:11 /etc/datagerry/cmdb.conf
# 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?

Hey @sink1

in earlier versions were:
database_name = cmdb

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:

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:

[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?

I thought it was about the default settings

in section [MessageQueueing] use entry:

use_tls = ...

I’m wondering if this entry is compatible with the configuration:
in section [Database]

tls=false

Hi @sink1 ,
we have not changed anything in the cmdb.conf with the last release, we will have a look at it.

BR Adnan

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

1 Like

And now my database is in read only mode :slight_smile:

[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)
1 Like

Hi,

Did you work out what the problem was with the upgrade?

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.

Mongosh 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

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

[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

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

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

[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: <TopologyDescription id: 672cb9cb1791b784bea68852, topology_type: Unknown, servers: [<ServerDescription ('218.g.local', 27017) server_type: Unknown, rtt: None, error=AutoReconnect('SSL handshake failed: 218.g.local:27017: EOF occurred in violation of protocol (_ssl.c:1129) (configured timeouts: socketTimeoutMS: 20000.0ms, connectTimeoutMS: 20000.0ms)')>]> (__main__.py)