Wednesday, December 3, 2014

OM12: Monitoring UX & RequireTTY

How I met requiretty…
A few days ago I was asked a question about monitoring UX based systems with SCOM 2012x. Even though I’ve already helped to monitor 500+ UX systems with SCOM 2012x, this question was totally new to me and I even didn’t know at first what it meant Smile.

The question was: ‘We use requiretty on all of our UX systems. However, the OM12x UX Agent doesn’t work with that setting turned on. Does the OM12x UX Agent only function without this setting turned on?

What to do with it…
So it was time to visit the internet in general and one website in particular: Unix & Linux StackExchange, all about UNIX and Linux related stuff. And soon I found two interesting webpages:

  1. Is it okay to disable requiretty?
  2. How to disable requiretty for a single command in sudoers?

But still no clue about what requiretty is
So soon enough I had found what I was looking for. But still requiretty itself eluded me. Gladly I could ask all I wanted to know about requiretty since another customer has this awesome RHEL engineer working for them. He’s a kind of person who would have invented RHEL himself if it wasn’t there already. He eats, drinks and breaths RHEL Smile.

So I asked him whether he knows anything about requiretty. And first he didn’t know what I was talking about until I wrote it down. Even though one writes requiretty it’s pronounced as Require TTY Smile. And as soon as I wrote it down, he recognized it right away and started talking and talking and talking…

What RequireTTY is and does
This is my translation of what I’ve been told. So when I am wrong or not complete mind you I am anything but an UX kind of guy…

As it is pronounced, it’s a security setting in UX, like RHEL based systems. Here you can make the usage of TTY (the RHEL ‘user interface’) a hard requirement. Anything running on that system requires TTY or else it won’t be allowed to run.

However, the SCOM 2012x UX Agent is nothing more but a web service. So it runs in the background and doesn’t use the TTY at all. And when it’s set to use it, or else it’s blocked, it simply won’t run.

How to deal with it when RequireTTY is enabled on the UX system?
Pretty easy actually. For RHEL based systems you can turn RequireTTY off for a certain command or user. So in this case disable it for the SCOM2012x UX Agent and you’ll be just fine. The UX system will keep on running RequireTTY and the SCOM 2012x UX Agent will keep on running.

No comments: