UMC Connection to Database

I have an older tree that is now in process of being upgraded and migrated to new OES 24.4 servers.    Like most systems, an OES 2023 server at some point was introduced into the tree and UMC installed on it. I believe it was the first version of OES with UMC.  During this process, it configured that server as the main UMC server and owner of the database.    However this was more of a test server and never went into production.     I have since added a new server that is the tree's CA, replica master, and now runs the UMC Database as well as the primary instance of UMC.    I had to go through the "umc cleanup" process to get that to work, and on this new server it works fine.

My problem currently is that a 2nd server, which is a production server, also had UMC installed on it and it was connecting to the database on that initial test server.  That all worked until I reset the UMC configuration and installed it on the new Master server.   I cannot get the 2nd UMC server to connect to the correct database.  It appears to be trying to still connect to that old test server.   I have gone through the reconfigure of the "OES Database" and the "Unified Management Console" on this server and made sure everything in the available dialogs is pointing to the correct server. But something is lingering within the configuration of the services that still tries to connect to the wrong database.

On a side note, from the console I am able to manually connect to the database on the correct server just fine, so it must be in the configs somewhere.


Would anybody know what config files I might look in where this is configured? I assume it would be a simple manual update to the correct server path. The Documentation for UMC is very sparse.

This is what I see repeatedly in my /var/log/messages

2025-01-23T12:26:02.445281-05:00 xxxx bash[6518]: (Use `umc-server --trace-warnings ...` to show where the warning was created)
2025-01-23T12:26:02.498089-05:00 xxxx bash[6518]: [ 2025-01-23T12:26:02-05:00 ] : error : Unable to connect to the database. Retrying (1)...
2025-01-23T12:26:05.517398-05:00 xxxx bash[6518]: [ 2025-01-23T12:26:05-05:00 ] : error : Unable to connect to the database. Retrying (2)...
2025-01-23T12:26:08.531094-05:00 xxxx bash[6518]: [ 2025-01-23T12:26:08-05:00 ] : error : Unable to connect to the database. Retrying (3)...
2025-01-23T12:26:11.546057-05:00 xxxx bash[6518]: [ 2025-01-23T12:26:11-05:00 ] : error : Unable to connect to the database. Retrying (4)...
2025-01-23T12:26:14.560371-05:00 xxxx bash[6518]: [ 2025-01-23T12:26:14-05:00 ] : error : Unable to connect to the database. Retrying (5)...

Tags:

Parents
  • 0  

    Hey Marvin,

    /opt/novell/umc/apps/umc-config.py

    They provide a python script for messing with the umc config, though I haven't tried to use it to flip the db at all, but is on my todo as I'd like to move to an external db and point all umc servers there.

    running with a get_config will give you basics of current configured servers and db instance.

    the update_umc_config likely allows us to change the config but I'm not sure what the steps are on this.  yast umc will call this script so should reconfigure right from there, but sounds like you may have already tried this.

    Can you confirm access from server2 to the new umc db port 5432?

    Is your pg_hba.conf on the db host umc server allowing ipv4 remote connections to it, same with the firewall on OES?

    Rodney

    If you found this post useful, give it a "Like" or click on "Verify Answer" under the "More" button.   This helps others.

Reply
  • 0  

    Hey Marvin,

    /opt/novell/umc/apps/umc-config.py

    They provide a python script for messing with the umc config, though I haven't tried to use it to flip the db at all, but is on my todo as I'd like to move to an external db and point all umc servers there.

    running with a get_config will give you basics of current configured servers and db instance.

    the update_umc_config likely allows us to change the config but I'm not sure what the steps are on this.  yast umc will call this script so should reconfigure right from there, but sounds like you may have already tried this.

    Can you confirm access from server2 to the new umc db port 5432?

    Is your pg_hba.conf on the db host umc server allowing ipv4 remote connections to it, same with the firewall on OES?

    Rodney

    If you found this post useful, give it a "Like" or click on "Verify Answer" under the "More" button.   This helps others.

Children
  • 0 in reply to   

    Hey thanks for the response..    That is good information.    This whole situation is difficult because the logs say the connection fails but doesn't say where it's trying to connect or why it fails.

    I ran that script and the output was to the correct new server. So that looked good. So I then decided to run a packet trace between the two servers, and found that all traffic on port 5432 was in fact going to the correct server. So this was a surprise.  It does appear to be going to the right place. So my initial hunch was wrong.  So my issue must be something in the postresql config.

    To answer your other questions, that is what is weird.  From the command line on this server where I see the failures,  I am able to login to postgres database and see everything. That does not error out, it works perfectly.   So something about how the UMC services are logging in are different. I will need to test more...  

    I'm wondering if something is messed up with Docker. I've seen that before where packets don't route out of the container's private address correctly.  Now I'm suspecting this may be the case. The only solution I have found when this happens is to reboot the server. I'm assuming the service making the database calls is using docker.