Deploying changes locally

Many QRadar users and admins hit time out or error issue when they are deploying changes in QRadar to the Managed Hosts. Not all of them know how to troubleshoot this problem. I will describe here a simple solution to this problem when qradar not deploying changes.

QRadar has two different approaches to store configuration. Firstly the most of settings are stored in the Postgres database but there are also configuration files ending .conf or .properties (these are usually kept in the /opt/qradar/conf location). Since postgres is replicating itself every single minute to each host (this process is managed by hostcontext), so there is no problem with setting from the database.

The settings kept in the files, from the conf location, have to be distributed between all managed host. Surprisingly for some users, this statement is also valid for the Console. So, even if you have only one appliance (All-In-One) then you still need to deploy changes and move the recent changes from /store/configservices/ the location to /opt/qradar/conf. Therefore editing any file in the conf location is useless because these will be overwritten after deploying changes.

If you ever have any issues with deploying changes and you know that there is existing communication with the managed host but this communication doesn’t have to be as fast as expected. According to the official documentation you have to provide at least 100 Mbps between the console and Managed Host. If you have any slower bandwidth then as a result you can see a time-out or error for the specific host. I suggest to fulfill system requirements, but sometimes due to slower connection at the moment with urgent changes, you can consider the local transformation process.

For this procedure simply download specific packages containing config changes to the timing out managed host and run local transformation on that host.

On the console:

cd /store/configservices/configurationsets/

scp globalset_list.xml <managedhost ip>:/store/configservices/configurationsets

after that just ssh out to the managed host and run the following first test replication and then run transformation because postgres settings need to be aligned with config files on Managed Host.

/opt/qradar/bin/ -download

if the above is successful run:

/opt/qradar/bin/ -l -f

Please note that the same script is used during normal deploying changes, so you should not do anything harmful for the system.

Leave a Reply

Your email address will not be published. Required fields are marked *