[OT] JSS API Get Policy Names returns more than just policies

[tron_jones]

Little off topic question here. Using the JSS API to get all the Policy Names and print them out for auditing reasons. That seems to be working fine but was wondering about the output of the results. At the top of the results it prints out lines that read:

<name>2013-10-04 at 10:20 AM | jssUserName | 1 Computer</name>

Substituted real username with jssUserName. We have a little over 800 policies on the JSS and the output prints over a 1000 lines of the above before it lists the policy names.

Where would this be coming from and why is it under Policies/policy/name for the API?

Heres my script:

#!/bin/bash

#Grab JAMF API info for Computer Policies
#2-28-14 T. Siemers

policy=$( curl -s -k -u apiuser:apipass https://jss.company.com:8443/JSSResource/policies 2>&1 | xpath /policies/policy/name )

#Take the output remove <name> add newline to each Computer Policy Name and sed out the </name>$ at the end to make it a readable format for .csv output.

echo $policy | perl -ne 's/<name>/
/g; print' | cat -vte | sed -e 's/<.......//' | tee /Your/File/Path.csv

[mm2270]

Strange. I don't see that at all if I run the same command against our JSS, just the policy names and other -- NODE -- labels the API call spits out. Are you using version 8 or version 9 of the JSS? We're still on 8.73, so I wonder if something changed with version 9 that would be doing that.

[tron_jones]

Running 9.2.4. Easy enough to delete the records once it's in a .csv format just more curious to where and why its grabbing and outputting that data or if its something in just our JSS that is corrupt.

[mm2270]

Yeah, it is odd. FWIW, I ran the same command against our 9.22 dev JSS and I wasn't able to reproduce this. All I get is the policy names, nothing else.

So, I was trying to remember where I've seen that pattern you posted above and I recall it now. I've seen that exact same pattern of:

2013-10-04 at 10:20 AM | jssUserName | 1 Computer

in the jamf.log when I've done something in Casper Remote against a system. Manually pushing a package/script, etc produces an entry exact;y like that in the log. The jssUserName would be my JSS account username for example if I pushed out something manually. The 1 Computer could be a higher number if I targeted more than one Mac. So, while I don't know why that's showing up for you in an API pull, I can say that's what that text indicates.
Does that help any?

[tron_jones]

That helps. Im now wondering if every time somebody uses Remote its not creating a record in the API as a policy for some reason. If it every becomes a problem I'll let our account manager know.

Thanks for the info and insight

[mm2270]

Yeah perhaps that's it. Though I don't see that at all in either our 8.73 or 9.22 setups, so it may be something new in 9.24.
In a way a Casper Remote session is like a temporary on-the-fly policy being created and scoped to the Macs you select, so it would kind of make sense, except not really :) I can't imagine why I'd actually want to see those sessions when calling up policy names from the API. They're not "real" policies as most of us would think of them as. That API call should only be pulling up the policy names as they show up in the GUI if you ask me.

[tron_jones]

FWIW Just an update. Tested the Remote log theory and that is where its coming from. Opened up Remote sent a package to 1 computer and another to 2 computers. Went back and ran the API script and these two lines where added to the output. Would be curious if anyone else running 9.24 is seeing this as well. I agree the only output should be what you see in GUI when pulling form the API for things like this.

2014-02-28 at 12:31 PM | JSSuser | 1 Computer
2014-02-28 at 12:34 PM | JSSuser | 2 Computer

[stevewood]

I'm not on 9.24, but I am seeing it on our 9.21 and 9.22 servers.

[Josh_S]

It makes sense. Technically a Casper Remote session is a policy. The only real difference is that the policy is created and then the administrator attempts to SSH to the machine to tell it to kick off the policy, rather than the client normally checking for policies to run on their own based on internal events.

I was looking for ways of determining if this is a Remote policy from the data returned, and I don't see anything that jumps out at me other than the name (which could be spoofed, if you worry about those things). I looked at the SQL directly, and I think that the JSS looks at the 'created_by' field looking for 'casper', but that value isn't returned by the API. Would be nice if the API returned a value that indicated if it is a remote policy, or a way to exclude them from the results.

[mm2270]

You could look for the pipes in the output. There are always two |'s in the line. Maybe strip out all lines containing two of them? Just thinking out loud more than anything.

I still contend that the API call should not be pulling those up. Yes, technically speaking they are policies, but again, not in the sense that anyone really views them as a policy, so why show them in the output? I could imagine that in an environment where Casper Remote is heavily used you could end up with literally 1000s of entries like that. What's the point? They can't be edited in the GUI and can't even be called again by a policy ID number or anything.