How to identify or manage orphaned config channel files?

Latest response

Well, this one is interesting.

What do you do if you remove a file from a config channel?  Let's, for example, say that you are creating separate sudoers.d files to organize your sudo entries:

-r--r-----  1 root root 267 Mar 15 19:20 100_admin

-r--r-----  1 root root 267 Mar 15 19:20 101_helpdesk

and you decide that you want to change the name of the helpdesk portion:

 

-r--r-----  1 root root 267 Mar 15 19:20 100_admin

-r--r-----  1 root root 267 Mar 15 19:20 110_helpdesk

This causes a problem.  You can't rename a file in the config channel on satellite, you have to delete the file and re-add it as the new name.  The problem is, your clients don't know about this, and you end up with the following situation:

 

-r--r-----  1 root root 267 Mar 15 19:20 100_admin

-r--r-----.  1 root root 267 Mar 15 19:20 101_helpdesk

-r--r-----  1 root root 267 Mar 15 19:20 110_helpdesk

That 101_helpdesk file is no longer managed by satellite.  

 

One thing that may be of use here that isn't immediately obvious is the period after the file modes on the now-unmanaged file.

ls -l
-r--r-----  >.<  1 root root 267 Mar 15 19:20 101_helpdesk

That means there is an SELinux security context on the file:

ls -Z
-r--r-----. root root system_u:object_r:etc_t:s0       101_helpdesk

 

 

So, how do you clean this mess up?  Is there a way with satellite to not cause this problem in the first place?  Removing all the files while they are still managed isn't really an option because they may be critical config files.  That's why you are managing them in the first place, right?

So assuming you already have the problem, how do you identify the files (that you may not even know exist) and clean them up?  Is there something within SELinux to query all files with a context?  Is there a context identifier that you can reliably relate to satellite?

DR

Responses