Privileged Commands to replace "sudo" and pattern modification

Jason82
Tera Guru

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?

1 ACCEPTED SOLUTION

SiD2
ServiceNow Employee
ServiceNow Employee

Hi Jason,

I don't think this should be possible with your scenario as you want both your customization and OOB upgrades to go hand in hand but these 2 contradict each other.

At present on top of my mind, I see only way is to duplicate the pattern and shared libraries and implement your customization's and have a frequent sync [Manual effort] with the OOB pattern updates. But this is a very troublesome and worst solution but I could only visualize this.

Let's see what others have to say...

Please mark Helpful / Accept Solution so that it helps others with similar questions.

View solution in original post

6 REPLIES 6

SiD2
ServiceNow Employee
ServiceNow Employee

Hi Jason,

I don't think this should be possible with your scenario as you want both your customization and OOB upgrades to go hand in hand but these 2 contradict each other.

At present on top of my mind, I see only way is to duplicate the pattern and shared libraries and implement your customization's and have a frequent sync [Manual effort] with the OOB pattern updates. But this is a very troublesome and worst solution but I could only visualize this.

Let's see what others have to say...

Please mark Helpful / Accept Solution so that it helps others with similar questions.

That is what I was think which seems untenable. I don't want to manage 2 sets of patterns for everything. I think I there was a miscommunication with the HI engineer that suggested I need to modify them all. I opened another HI case rephrasing my question and the 2nd engineer said I don't have to and Privileged Command should take of the substation prior to command execution.

I enabled debug logging for the MID Server and watched a few pattern come through on the agent log and /var/log/secure on the target Linux server. I can see the SUDO command being issues, then a function called PrivCredCheck or something similar is called, then immediately after that a privileged command is issued with DZDO instead. The Linux log does show the command was accepted and executed successfully.

So it seems that patterns do replace the Privileged Command prior to sending the command to the target IP address.

SiD2
ServiceNow Employee
ServiceNow Employee

Hi Jason,

That's great to hear...

That should be the back end code indeed which does a check before actually running the command and this is something could be on back end java code and unfortunately I'm not part of that team so unaware.

Please mark your response as correct as it resolves so that this thread gets closed and will be helpful for others.

Please mark Helpful / Accept Solution so that it helps others with similar questions.

Mohit44
Tera Contributor

I also tried to configure my MID Server to used dzdo, however it is not working. I can see still sudo being used in all the commands. Any suggestions?