QRadar can work in the Deployment Model which is master and slave environment. The single master is the console, which manages the configuration updates for all the managed hosts (slaves) available in the deployment set. The console only has the ability to read and write to Postgres database, while the all managed hosts have read-only database access. After doing any change in configuration on the console, managed hosts needs to reflect the same settings as in console. Process of sending changes can be incremental or full. The most common one (Deploy Changes) includes both database replication updates (through hostcontext) and flat file configuration changes. There is also Full Deploy Changes, which contains full configuration set and also restarting of QRadar services.
Hostcontext service and its role in deploying
The hostcontext process is the primary process, that runs on each managed host as well as on console. This service controls all the core qradar processes. On the contrary, it does not control tomcat, imq or postgres. Nevertheless, hostcontext is also responsible for executing deploy requests from the console and reporting status updates on deploys in the Deployment Model kept on the Console. The hostcontext controls also downloading configuration sets, when changes occur and execute “replication” processes each minute. Replication is different from deploying changes because it happens automatically and it tracks only changes in Postgres database but not with the configuration files. The Hostcontext reports also the status of the HA (High Availability) peer if a Managed Host running in HA.
Any time you would have a problem with deploying changes – the first thing to check, is the hostcontext running on affected Managed Host. You can quickly check the status of all hostcontext instances running on each Managed Host using the following command:
/opt/qradar/support/all_serversh.sh -C “systemctl status hostcontext”
Please keep in mind that the switch -C stands for running the command on the Console as well as on the other existing in the Deployment Model Managed Hosts. On the screenshot below I use only standalone All-in-One Console Appliance type 3199
What actually is “Deploy Changes” in the Deployment Model
When the admin tab detects changes required to send out to managed hosts in the Deployment Model, it will show up in the admin tab a notification. Despite the number of changes have done up to the moment (one or more changes), you can not select only one change from others to process, but all of them have to push out from the Console during deployment.
QRadar stores any changes made on the Console in the “staging” area. This let to notify a user about the need to deploy changes. Copying changes over to the “runtime” or “deployed” area of qradar (proper tables in postgres, /opt/qradar/conf/ directory on each host) occurs after clicking the appropriate button. Finally, the hostcontext will tell the components to reload or restart.
A user may initiate the Deploy Changes Action or Full Deploy Changes from the main UI interface. You can also do a full deploy of changes from the command line using do_deploy.pl script. Using the same script, deploying occurs automatically after system installation or its patching. It is also executed during Add Managed Host action.
Please keep in mind, if you are still using the older version prior 7.3.1, that during full deploy changes, a service interruption is expected. Since the introduction of ecs-ec-ingress service, this is not a problem anymore.
Execution of the “Deploy Changes” process step by step
The Tomcat creates the archive of changed configuration files, which is applicable to all managed hosts. The archive contains results of comparison files found in staging and deployed folder and all their subfolders. We call this archive a Globalset. Each Globalset has two archives of configuration sets and one is for Full Deploy and the other for Incremental Deploy. There are also similar archives for QVM applicable only for separate QVM components. Tomcat creates also globalset_list.xml file, which contains checksums of each package and token of the current deployment. In the file /store/configservices/configurationsets/IP.deploymentToken.txt we can find recently installed archives configurationset on each Managed Host.
When Managed Host hostcontext (Console is also Managed Host from this perspective) finds that a new global set is ready then it downloads the globalset_list.xml file. Based on that Managed Host knows which archive is to process. MH downloads it and unzips in the /store/configservices/deployed/GLOBALSET/ folder.
After that, Managed Host runs local transformers. These ones will create new final configuration files for the host in the /store/configservices/deployed/LOCALSET/ folder. Finally, hostcontext copies LOCALSET/* files to /opt/qradar/conf/ on Managed Host and informs all components about a change. It also reports to the Console current deployment token and lets it know that the process was successful.