Since there is no user on the console it correctly evaluates to “Constrained”; however, I then logon to the server (Console, not ssh) as root. The user name retrieved property then shows root as the user, but the action never leaves the Constrained status.
Trying to understand why you want to constrain execution on (and only when “User Name” contains “root”)?
Why does it need to be constrained to only run when the User Name property contains root?
Does the User Name property ever update to something that contains root? When you login as root you may be expecting it to update to something that contains root but maybe it never does.
You would want to see if it does by evaluating the relevance on the endpoint through the QnA tool:
BigFixNinja:
The requirement is that this action execute on the client only when ‘root’ is logged in to the computer. That is a customer requirement and by all accounts the product has the ability to do this so I set it up that way. To be honest, the “why” in this case is not really relevant as it is a product feature that does not appear to be functioning as expected.
I posted some screenshots in my OP (I can see them, but definitely let me know if you can’t) where it shows that when ‘root’ logs in, the “User Name” property changes to display root as the value. This should trigger the action to start execution.
This might be due to the fact that on some systems, when no user is logged on, it appears as if root is logged in. It could be that the issue you are running into is due to compensation for this bug that would make it appear that a user is always logged in.
You are right I suppose, but this requirement is very odd. Logging in as root is basically the opposite of a best practice for security, stability, and many other reasons.
You should try constraining it with regular relevance instead of that option in the dialog and see if that works, because it should.
Try adding this to a blank action to test:
exists names whose(it as lowercase = "root") of (current users; logged on users)
I believe you will have to target a system dynamically for this to work well.
If this were the case wouldn’t the action just run instead of showing Constrained from the get-go? I defined no other constraint so it appears that this is the only one it’s reading.
I agree and I have made this case to the customer. I suppose when you are a full-time employee at a company you have more freedom to challenge requirements that come down from on-high; however, as a consultant I need to abide by the customer’s requirements (if they are supported by the software)…
For the record, the requirement for ‘root’ to be logged in is because the customer wants to make sure that the patching is done while a ‘root’ user is logged in and that they reboot the box manually right after the action completes. To ask ‘why’ they want it done this way could be met with: “because that’s what we want, plain and simple”…
so that’s why I said the question as to ‘why’ is not important in this case.
So here’s where your answer helped:
One of the behaviors I’ve got set is ‘start client downloads before constraints are satisfied’ so the payloads are pre-cached…Then when ‘root’ logs in the ‘execution’ constraint kicks in and the patching is done. If I use your relevance in the baseline itself I would have to dynamically target the action so that when the baseline relevance becomes true it starts on the applicable endpoint. This would mean that the ‘client downloads’ would only begin once the baseline itself becomes relevant and the action starts to execute on a now ‘relevant’ endpoint.
But what you said got me thinking: The “User Name” field is is a STRING that can have any of a number of values. The relevance for that field is similar to the one you posted except that the result of yours is a BOOLEAN type…I figured, can’t hurt to try so I created a new retrieved property that instead of displaying the logged in user just checks for ‘root’ being logged in and displays TRUE/FALSE…
BOOM! THAT WORKED! I started the action with the constraint based on the new ‘Boolean-type’ property (when matches True). The endpoint has no user logged in so the action correctly showed ‘Constrained’, then I logged on as root and it kicked off right away (with the already pre-cached content).
So while that’s not what you meant in your reply, your re-writing the relevance in Boolean rather than String format made me look at the process in a different way.
Thanks again…And also thanks to ‘BigFixNinja’. Problem solved.
I definitely get that, but I also feel as a consultant it is a good idea to push back a little bit, or at least make it clear that it is less than ideal.
This sounds like they are just not comfortable with BigFix yet, especially considering BigFix runs as root and can reboot the system once things have completed.
I disagree. Often the why helps frame the question and answer better. Knowing that you are stuck doing it this way helps.
This was the bug that excluding root from the constraints was meant to solve. If you constrained an action to only run when a user is logged in, but it always appears that root is logged in, then it always runs instead of waiting for a user to log in. I know this issue happened on the Mac.
