How to generate a report of all changed config channel files?

Latest response
I'm working on building a report to show all the changed files for all the systems 
in my satellite, but I can't quite seem to find any useful information in the API. 
What I would like is report that mirrors the information found by the scheduled action: 
    "Show differences between profiled config files and deployed config files"

The problem, as usual, is the information in the WebUI is not condusive 
to reporting on large numbers of systems, and the API doesn't have it. 
The closest thing are the system.config methods, but they don't have any 
way to directly compare information. 

I've considered hitting all the client systems and running rhncfg-client verify (yuck), 
or trying to webscrape the WebUI (more yuck). 

I'd like to produce something like the rhncfg-client verify output but 
from the backend that would look something like this for every system:

system: foo
modified_files: {
{name: "/etc/sudoers", type: "file", system_rev: "5", channel: "base-files", sat_rev:"7"}, 
{name: "/etc/sudoers.d", type: "directory", system_rev: "3", channel: "override-files", sat_rev:"5"}

The only thing that appears to have anything related to this level of file comparison is 
the scheduled action to compare files. It doesn't look like this type of data exists normally. 
So looking at scheduleFileComparisons(), that doesn't really help any.
Notwithstanding the problem of having to schedule for each individual file path for 
every server in the list, it's a scheduled action, so I don't know when it's complete. 
Getting the actionId doesn't tell me anything useful, either. So, once that activity is done, 
I can't do anything with the results, and I have to wait X hours to get the info in the first place.  

If it had something in the API like configchannel.getActionResults() 
that allowed me to traverse the details of the action I scheduled, that 
would be useful. eg, 
Method: getComparisonResults() 
Get Detailed Results of a given Action 
 string sessionKey 
 int actionId 
 struct - comparisonDetails 
 int "id" - action Id 
 ... whatever other basic action info ... 
 struct - iterable list of systems to see the actual 
          results of the comparison  

The key part is to be able to actually look at the comparison results 
for a given action, and that doesn't currently exist. What I'm looking 
for is an API equivalent to: 
It shows a list of all servers, where you can drill down on a given server and 
see all the file comparisons, which is exctly what I want, but it's not
something that exists in a report format. 


rhncfg-client diff [filename]

It'll show the diff against local vs Satellite analogus to "rcsdiff -u 'copy in Satellite' 'local_file'". If the local file is not found the filename will be '/dev/null'.  It's not very readable but I'll leave the re-parsing as an exercise.

That's not what I'm asking about, though.  That still involves going to every client and running rhncfg-client.  You've just supplied a different option (diff instead of verify).

In my case, I'm not looking for detailed information about what changed, just that it did change, and I don't think it's unreasonable to be looking to the API for something to generate a report instead of hitting every client to get it.

I've also looked at spacewalk-report to see if I could find something there, but that just gives a view of what was done to clients via satellite.  It doesn't tell me if anything is different on the client itself.

>  looking to the API for something to generate a report

Sorry to have misunderstood you. So you want an API call that will return 'TRUE' if the last run of "compare-files" job found a difference? Obviously Satellite knows the status of this flag because it reports the sum() in my nightly email. If you want the actual diffs you'll have to go find the Java routine that the WebUI uses. I don't believe they exposed that call in the API either. You'll have to de-compile the java files for that task to ascertain exactly what it does. I'm certain there is a database field that stores the flag and the last scrape of the managed files.

That brings up a good point though. There is no "status" display in the WebUI to indicate configuration deviation. That's a pretty big oversight.

[OT: and this is one of my major beefs with the use of Task-o-matic. Cron+AT has worked just fine for 40 years. I wish RedHat would stop introducing unnecessary complexity. If the 'bundles' were python/perl we'd have a prayer of understanding what was going on. Ditto the problem-child that is Jabber. What's so hard about doing a 'wget http://<satellite/jobs/<hostid>/<jobid>" and having the client parse that? Just because all those 1337 botnets use chat servers for command control doesn't mean it should be used. KISS, people!]

Yeah, the entire process around actually monitoring the config files is rough.  

The nightly email isn't very helpful because it just says "yeah, something's different" and doesn't allow for reporting.  Even the WebUI drilldown of the taskomatic job results is hinky because there are often jobs that didn't complete on a client and you are left trying to debug what happened (to your point of taskomatic pain in general).

> So you want an API call that will return 'TRUE' if the last run of "compare-files" job found a difference?

I'd like a bit more than just True on the last run; ideally there would be something to get a list of the files that have diffs.  I'd love to have a method that worked something like this:

results = client.system.config.listChangedFiles(sessionKey, [list of systemids])

where results would contain for each systemid:

filename: path

filetype: file or directory

effective-config-channel : the config channel that the file comes from (in the case where there are multiple channels supplying the same file, which one is actually active).  That way, I can use the API to look up what the file is supposed to look like.

locally modified: True/False (So I can tell if it's just a difference in revisions, or if it's been manually edited on the client)

local-revision: The revision number that is currently on the client (could potentially be used instead of "locally modified", ie, if local-revision is not None, then the file has not been altered locally)


I would even be ok with just having some additional fields in the system.config.listFiles() method that related to the current state of the file ON THE CLIENT, not just a rehash of the file info on satellite.

Actually, I would even be ok with just adding the MD5 checksum to system.config.listFiles(), again for the file ON THE CLIENT.  Then I could check the listed MD5 against the field in the config-channel API output to see if they are different.  It would still be a lot of work to cross-reference, but at least it would be doable.





This'll be flagged as "offensive" probably,  but at the end of the day what you want is Puppet or Chef. ;-)

The configuration channel aspect of Satellite was quite poorly thought out. Even a cursory design of such a system would have allowed for a direct tie-in between host-groups and configuration channels. It would furthermore have had a logic engine such that you could do conditional overrides be it for individual hosts or host-groups. Whomever wrote the code simply didn't think the problem through.