How do I run a cat command under sudo in a linux SSH probe?

[HugoFirst]

I have a need to capture the contents of some files on Linux systems using Discovery probes.

I succeeded in using "cat filename"   for files which are openly accessible.

I now need to capture some files which are secured for root access.

I'm trying to use SUDO with the command, but it's not working.

The most common error I get back is "User has no right to use this command with sudo: sudo /bin/cat /etc/grub.conf".

Note that I have logged on as the discovery user and manually run just that command with no problem.

I added probe parameters for debug and debug_ssh, but so far, I'm finding nothing in the log file and there is no ssh.log file under .../agent/logs/

I've tried combinations of values in the ECC Queue Name of "/bin/cat /etc/grub.conf" and "sudo   /bin/cat /etc/grub.conf" and I've varied the use of the probe parameter "must_sudo".

All to no avail.

So I'm open to whatever advice you are willing to lend.   Whether to fix or to help debug.

Thanks in advance for your help.

[tony_barratt]

Hi Ankush,

Your suggestion does not take into account Tim's advice - as it facilitates the cat'ting of all files.

:Be *super* careful about cat permissions and wildcards. This is a very touchy area, and you don't want to inadvertently allow cat'ting files like /etc/shadow."

I agree with Tim, it is very important not to allow cat'ting files like /etc/shadow

Best Regards

Tony

[Ankush13]

I think you can limit it to that file that you are trying to read. Ofcourse I too agree with Tim. 🙂

[HugoFirst]

Just wanted to give everyone an update.

One hurdle I just overcame is related to the fact that we are not using the Post Processor Script in the probe.   We are just passing the output along to the sensor.

There is an   "undocumented feature" whereby if you _EVER_ enter text in the Post Processor Script, the probe will NOT return output.

This is the case even if you delete the text and make the Post Processor Script appear to be empty.   Because, once it has ever held text, it will continue to hold a null CDATA element, which is not the same as "no text" and the output is squelched!   ( e.g. <![CDATA[ ]]> )

Another hurdle is not related to sudo. It is related to the fact that we are currently on Eureka Patch 12 in our prod instance and we are evaluating Fuji Patch 10 in our dev instance.   The dev instance is where I am working to develop the sudo probes.   In Fuji, probes and sensors are assigned Major and Minor version numbers.   Each probe/sensor pair must match.   If they don't the probe doesn't launch.     Now for some reason, many probes had version 1.0 assigned to them while the sensors were assigned version 2.0.   So they don't run.   The version file says that I customized the probes, but I did not do so. Comparing the various versions of the probe show no difference between the   OOB version of the probe and the version that I supposedly customized.   there is a new version of the probe for Fuji, so I am reverting the probes to that version.

Sp it's still a work in process, but I am making progress.

[tim_broberg]

Hmm... I went to a fuji instance, cloned the Linux CPU probe, emptied the post-processor script, and did test probe. I got lots of nice fluffy cpuinfo. I would love to know how you reproduce that behavior so we can kill it with fire. If it persists for you, can you open an incident so support can work with you to make it reproducible?

Sounds like the easiest approach on the fuji probes. You can do that, you can export the probe as xml / update the version / import, or you can use the advanced view in the probe form to see and modify the version #'s.

    - Tim.

[HugoFirst]

Very interesting Tim!

I repeated your action with the Linux - CPU probe and guess what?   I got the same results as you did!   Wow!

So I opened the probe and did "Show XML" and I noticed that the post processor script was NULL.

When I had a problem, the post processor script looked like it was null on the form, but when I did "Show XML" it looked like this:

<post_processor_script>

<![CDATA[ ]]>

</post_processor_script>

No amount of editing would change it.

So I now wonder how did I get in a state where the post processor script was NULL on the form, but had the CDATA tag in it's contents.

WRT: The major and minor versions of the probes and sensors bnot matching.   I'm reverting to the Fuji versions for all of these.   I hadn't knowingly customized any of them and it seems odd that somehow versions were created that showed me as the updated_by. I compared "my version" to the OOB version and no changes show up.   So this will be another mystery for me to wonder about.