BESAgent-9.5.20.34 -- Structural issues with RPM?

1

Dear Folks,

We have installed BESAgent-9.5.20.34 in our environment, we could see that BESAgent-9.5.20.34 didn’t have " /bin/systemctl start &> /dev/null " parameter in the rpm.

After the installation of this client, we are starting it manually ie., manual intervention is required here.

[root@sXXXXX XXX]# rpm -iq BESAgent-9.5.20.34-rhe6.x86_64 --scripts | grep -i systemctl
/bin/systemctl daemon-reload &> /dev/null
/bin/systemctl stop besclient &> /dev/null
/bin/systemctl stop besclient &> /dev/null
/bin/systemctl daemon-reload &> /dev/null

Could you please advise why is it structurally not starting the besclient?

2

Please see https://help.hcltechsw.com/bigfix/9.5/platform/Platform/Installation/c_red_hat_installation_instructi.html for details on installing the v9.5 BigFix Agent on Linux, and note systemd support is forthcoming in v10 (current clients use init.d as referenced in the documentation link above).

3

@Aram -Thanks for the update!

The steps referred in the documentation is for new installation. However, what we are doing is update of the existing BES Agent to BESAgent-9.5.20.34 from BESAgent-9.5.14.73.

[root@sXXXXX XXX]# rpm -iq BESAgent-9.5.20.34-rhe6.x86_64 --scripts | grep -i systemctl

                    /bin/systemctl daemon-reload &> /dev/null

                    /bin/systemctl stop besclient &> /dev/null

                            /bin/systemctl stop besclient &> /dev/null

                            /bin/systemctl daemon-reload &> /dev/null

If you look the above output, it is stopping the besclient & does a " daemon-reload" but doesn’t start the besclient.

4

An upgrade should follow similar process…you can rpm -U, then /etc/init.d/besclient start.

By the way, any reason not to use the BigFix Fixlets in BES Support to upgrade the Client?

5

I’d add that while I can’t dig into in detail at the moment, grep’ing these strings out of the RPM may give some misleading results; instead, you’d really have to look at the script as a whole.

When I checked it the other day, some of this is based on the script itself creating new init.d scripts on SLES systems - where even though all the systemd service/unit stuff gets configured, init.d scripts were created for backward-compatibility with older SLES content. I’m not sure whether the lines you are finding were actually commands that would be issued through systemctl, or whether those are the statements we’re echoing out to build the new init.d scripts on-the-fly.

(I’m not saying there isn’t a but here, only that grep’ing for the strings isn’t the way to find it, we’d have to examine the script as a whole, which makes several on-the-fly decisions so the same RPM can be used across several Linux distros)

6

Thanks for your feedback Aram. We use Bladelogic for deploying the package to clients :slight_smile:

I have also raised case with IBM & got the following feedback,

The update of BigFix Agent (or the other components) should be done by using the provided fixlets and the fixlets contain the start of the process after the rpm upgrade.

I think the reason why there is no automatic start process in the post-install is that the same rpm is used for both the installation and the upgrade of the BigFix Agent.

For the reasons I explained in the previous update for the installation, we have not added a step to start the service automatically. At the moment all the BigFix customers are familiar with the current design and changing it to add a step to start the service after the upgrade would cause failure in their custom script.

I would suggest your customer to raise an enhancement request in the HCL BigFix IDEAS portal ( https://bigfix-ideas.hcltechsw.com/ideas ) in case you need to pursue with this design change.

7

Thanks for your feedback Jason :slight_smile: