Detecting cowboy'd changes in a Juju Env

[Michael Nelson]

On Wed, May 14, 2014 at 4:06 AM, Mark Canonical Ramm-Christensen
<mark.ramm-christensen at canonical.com> wrote:
> On Tue, May 13, 2014 at 10:45 AM, Joey STANFORD <joey at canonical.com> wrote:
>>
>> Howdy,
>>
>>
>> On Tue, May 13, 2014 at 08:04:14AM +0400, John Meinel wrote:
>>>
>>> I actually think this isn't about someone doing "juju set-env" but
>>> someone
>>> just ssh'ing into the machine and changing things with a text editor.
>>
>>
>> Yes, this is my top concern.
>
>
> If you want this, there are tools that can help (puppet being one, the
> already mentioned tripwire being another) both of which can be used with
> juju.

I know it doesn't help in the general charm case, but just as an
example, any charm which uses the ansible helpers can do this quite
easily, as ansible allows you to check a playbook and print any diffs
that it finds, which can be run on a unit:

ansible-playbook --check --diff
--tags=install,upgrade-charm,config-changed /path/to/playbook.yaml

This is demo'd in the following (private, sorry) example, I've run the
playbook for one instance using --check
--diff so that all the tasks for the install, upgrade-charm and
config-changed hooks are checked. The output ends with a count of
tasks which were OK and those which have changed. I then manually
change a configuration file and re-run to show the output with the
diff of the changed file.

https://pastebin.canonical.com/110164/

This could be made even simpler with `juju run` and a helper in the
charm... so `juju run --all check-for-diffs` would check all units
etc.

It will of course not find any manual changes made to the unit that
are outside the scope of the charm itself.

-Michael

>
> Once we have full modeling of a charms storage and installed "resources" we
> might be able to do *more* in juju itself.  But for now the way to prevent
> this would be to write charms using puppet and doing enforcement that way,
> deploying a properly configured tripwire like subordinate, or for properly
> "scale out" workloads, just adding a new unit and killing any unit with any
> SSH sessions that might have resulted in questionable activity.
>
> --Mark Ramm
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>