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?

Responses

> You can't rename a file in the config channel on satellite

another of those *really dumb* mistake by those who wrote Satellite. The proper way to handle this is for a job to get scheduled on all channel-subscribed systems to rename the file. In the case of a Delete, the admin needs to be prompted if he means delete the file on the subscribed clients, or just remove it from Satellite.

The workaround is to zero-byte the file in Satellite. So even if you still have "101_helpdesk", it has nothing useful in it. You can of course schedule your own "delete it everywhere" job.

> So, how do you clean this mess up?

1. Don't cause the mess in the first place. ;-)

2. Use vastly better software than Satellite for this sort of thing (eg. Chef or Puppet). Satellite is IMO only useful for trivial file management at the time of a host's birth. Anything past that should be managed with a properly designed tool.

>  Is there a way with satellite to not cause this problem in the first place?

No. Satellite was written by disturbingly naive programmers with a penchant for not thinking a given problem all the way through.

> how do you identify the files (that you may not even know exist) and clean them up?

1. SOL

2. use tools like 'mtree' and armed with a clean profile, see what pops up

3. Prevent BIT-rot by re-kickstarting hosts every 6mo to 1 year (or every couple weeks like our friends in big-data and big-finance seem want to do)