I’m sure I’m not alone in this request. As a Bigfix admin we don’t always have the required access we need for crafting relevance. I know I will run into the problem (especially on Solaris as I’ve never administrated them) where we need information on services running but I have to ask a Unix admin to tell me what the service name is. Anyone who deals with any admin on a regular basis knows you could be waiting a while.
My request is an add-on or new fixlet debugger that allows a Bigfix admin to connect to remote Bigfix client to run relevance clauses against them. Seems like it would be a nifty addition to the admin toolbox.
@jmaple, thanks for the request, and no I don’t think you’re alone, either. Just so I’m clear on your use cases here:
You want to evaluate relevance immediately against any machine with an agent on it, without e.g. creating an analysis or fixlet via the Console, because that would be too heavyweight. It sounds like in your case this would be primarily to answer one-off questions about machines. Would you also use it in the development of new content?
This came up in the User Meetup as a suggestion as well. After thinking about it one (Stanford) use case would we are asked by jr. console operators or depts. with no CO if we can write inventory properties for software local to their dept. Quite often we never see the person, the computer and don’t have copies of the same software locally so this can be handy in these cases. If this capability is added it should be a separate right assignment to the role or operator (could be couple with Custom Creator as a option). We have taken steps to not allow custom creator rights from COs to address privacy concerns with possible inappropriate use by console operators to pull data from machines.
To that point, if some type of authentication can be performed similar to the console, the rights could be assigned based on their role in the console.
Just to clarify this more (as there is a lot the Fixlet Debugger can do) what would give the most functionality
1 - Remote Relevance Expression evaluation (same as Fixlet Debugger can do locally but on a remote machine)
2 - Remote Client Relevance Expression evaluation (same as the evaluate using local client but on a remote client)
3 - Remote Action debugging
I know the answer will probably be everything but if we could do only one…
I know that I would need to have an IBM provided solution for this because of my business owner. When my contract is up, I have to turn it over to their IT and I don’t think they’d be comfortable with a solution without real support provided.
I spoke up about this at the UG meeting (I’m the guy from Irvine). I’d like the ability, while writing/debugging a relevance or action, to “execute remotely now” on a designated machine.
IIRC, Client Relevance is a bit richer than Fixlet Debugger, correct? In that case, if force to choose, I’d vote for #2.
Just as often, though, it’s remote action debugging that’s driving me more nuts.
The relevance language is the same in both, but the availability of the data is somewhat different due to privileges and the state machines of the client itself. You can’t have the Fixlet Debugger/QnA in its native state examine the relay the client is using because its not part of its state machine. That’s when you get the “No Inspector Context” type of errors. Other inspectors use a higher privilege than even Administrator has to get some of its data so you may see a Windows error in those cases.
I think we already have all, or nearly all, of the pieces we need for this in the form of the Client Compliance API. I’ve just started this myself, so I haven’t explored it fully yet.
As an Administrator on the client, we can add the XML Compliance Document to the client’s actionsite folder, then use the COM API from VBScript or Powershell or higher-level languages to evaluate the relevance in the Compliance Document.
I believe it’s only a short hop from there to creating a QNA-like shell that will create, and then evaluate, the Compliance Document on the fly.
In fact I suspect this is what the Fixlet Debugger is doing when in Client Evaluation Mode. The only thing I see limiting the Fixlet Debugger is that we can’t run it via psexec because it’s a Win32 GUI application.
(For anyone who wants to play with this, the sample VBScript in the Client API evaluates much faster if you modify it to avoid setting the CPU limit flag)
Personally I accomplish “remote” relevance debugging this way:
I test relevance in the FixletDebugger or QnA on a test machine, then I put it into an Analysis Property. The Analysis lets me see the results of that relevance query across many (or all) machines. I then add more and more and more analysis properties as I refine my relevance. I then delete all of the redundant properties once I have what I needed and that is often used for reporting, or I could just delete the analysis altogether.
I typically have an analysis specific to every thing I am working on just so I can see how well it is actually working.
That works if the machine you’re doing the initial test on is the same OS you’ll be enacting the analysis against. My current situation does not prohibit me from logging into other systems with the same OS as my workstation to do testing. I more run into the issue of, when writing analysis for Linux or Solaris servers in my environment, I have to go back and forth with our admins on what something is called or the path to something because I don’t have the rights to log in myself.
You don’t need to write the relevance against production systems. You should have a Linux/Solaris Test VM that you do have rights over that does not have the data, but does have the environment in general for you to test against. This will enable you to write relevance most of the way, and use Analysis as a supplement.
When it comes to writing relevance to parse a file, I get a copy of that file either with the real or fake data, then figure out how to parse it using relevance on windows, then just change the path to point to the file on Linux and test it through an Analysis.
