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:

  • 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.

  • 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.  

  • Verified Answer

    +2  

    Hi ,

    In OES 24.4 Set SERVICE_CONFIGURED="no" in /etc/sysconfig/novell/oes-db and /etc/sysconfig/novell/umc

    Then run yast2 oes-db and enter the db details you want to connect that UMC server ,make sure to select it is a local database or remote database and provide the database details. 

    Once OES DB is configured, run yast2 umc and proceed with the configuration. Once you have configured it, you can check DB_URL in /opt/novell/umc/apps/umc-server/prod.env and verify it is pointing to the correct DB.

    Note:  Do not modify/edit  /opt/novell/umc/apps/umc-server/prod.env file this gets generated during configuration time.

    Let me know if this helps.

  • 0 in reply to   

    Hello.   Thanks for the response, I've been out of the office so am just now circling back on this. I thought I had already gone through both of the processes (oes-db and umc) that you mention from yast.  However I did it again just now and this does seem to have corrected it.  I'm able to login now to UMC and not getting any database errors.

    With the previous PROD.ENV file, the db server appeared to be listed correctly. I did check for differences between the old prod.env file and the one after running the yast commands.   Here's what is different, but I'm not sure how it uses these items (I've changed the server urls to hide sensitive info):

    diff prod.env prod-old.bak
    2c2
    < DB_URL=postgres://umc:6pjBEr2At27zD8pqtDCzD0M1zo8658ET36RtVKuEkCkCXY-6@dbserver.company.com:5432/umc_company
    ---
    > DB_URL=postgres://umc:XKmHCdd1s23JExVqgiNTZvHFyz8FYuBQLg==@dbserver.company.com:5432/umc_company
    4c4
    < PROVIDER_ID=ce35db64-e243-11ef-805a-506b8dc9c041
    ---
    > PROVIDER_ID=93449a66-d484-11ef-8056-506b8dc9c041

    Thank you for your response and help. Marvin