Privileged Commands to replace "sudo" and pattern modification

[Jason82]

Our Linux Servers are configured to use "dzdo" instead of "sudo" for elevated privileges. We configured the MID Servers to use both "dzdo" at 100 and "sudo" at 200 as Privileged Commands. I can successfully logon to the servers via SSH and issue all of the "dzdo" commands we require manually with our Credential. 

The Horizontal Discovery Log of a Linux Server pattern shows that some of the commands issued are using "dzdo" as expected, but some are still being issued with "sudo".

For instance, Step 1.1 Get System info uses the "Unix/Linux Name Formatting" shared library to issue a "uname -a" command. This command does not require elevated privileges so I don't understand why "dzdo" is showing up in the log.

Get system info
2020-11-02 22:59:57: Executing SSH command: uname -a
2020-11-02 22:59:57: Executing SSH command: command -v dzdo
2020-11-02 22:59:59: Command result: /usr/bin/dzdo
2020-11-02 23:00:00: Command result: Linux HOSTNAME 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 11 19:12:04 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux
2020-11-02 23:00:00: setAttribute(uname,Linux HOSTNAME 3.10.0-1127.19.1.el7.x86_64 #1 SMP Tue Aug 11 19:12:04 EDT 2020 x86_64 x86_64 x86_64 GNU/Linux)
2020-11-02 23:00:00: Execution time: 2922 ms

The real issue is with the steps that have "sudo" hardcoded into the Set Command Details field such as Step 4.1.1 Get DMI type 1. It uses the "Linux - Hardware Information" shared library and issues the command "sudo dmidecode -t 1 | cat" which will fail as the server is configured for "dzdo".

Get DMI type 1
2020-11-02 23:00:01: Executing SSH command: sudo dmidecode -t 1 | cat

At this point I realize that some Application and Infrastructure patterns may have to be modified but I guess I didn't think I would have to also modify the shared libraries. I assumed Privileged Commands would take care of that.

I'm struggling with how to best make modifications to the patterns that allow both "dzdo" and "sudo". We have some unmanaged systems that may not have "dzdo" configured so we still need to account for them.

Second, is how to make the modifications that don't affect the OBO pattern upgrades. I understand I can create an extension that will not modify the original pattern, but if I need to modify a shared library I don't understand how that is possible.

Any suggestions on how to modify the patterns that don't use the Privileged Commands substitution?

[Jason82]

My first step was to verify I could manually SSH into the Linux Server and execute command -v dzdo to verify it successfully returned the path which was Command result: /usr/bin/dzdo.

Then check the MID Server configuration for Privileged Command an ensure that dzdo is at a hire order then sudo.

Enable the MID Server debugging and run a Quick Discovery on a Linux Server. Open the MID Server agent log and compare with the /var/log/secure from the target Linux Server for the same timeframe.

You should be able to see what is being issue to the Linux Server. You should see successfully DZDO commands with no errors. If you see SUDO commands with errors then there is likely and issue with the MID Server config or Privileged Command.

[Mohit44]

Thank you for your quick reply Jason. I was not sue where I can validate that, DEBUG parameter and agent logs helped me validate the same.