Detecting cowboy'd changes in a Juju Env

[John Meinel]

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.
Joey is the type of guy to be very concerned about people making changes
out of band that we wouldn't know about even if we had audit logging.
(Which we sort of do if you turn on debug level logging today.)

I don't think we have even modeled the concept of what the state on disk
"should" look like, to be able to tell if it is different.

There are a few things that might come into play as we progress forward.
We've had some discussions about "image based workflows" which would let
you snapshot the system at various points (do install, configuration, and
then snapshot, so that future add-units can start from a known state,
instead of starting from scratch again). That potentially gives you a point
to hook something like this in. (what has changed relative to my base
snapshot).

There can certainly be logging for *if* someone runs "juju ssh" or if they
run "juju run". However, we don't currently prevent them from just doing
"juju status" finding the IP address and then ssh'ing directly to that
machine.

Part of the problem is that each charm is given root access on the machine
to configure whatever services are actually needed. And there isn't part of
the spec that has them define where the configuration files are going, what
things they are installing, etc.

I wonder if there would be a good use case for a subordinate charm that
would essentially version '/' and make it possible for you to see what
things are being changed.

Certainly there are things like "etckeeper" that you could just install and
make use of.

John
=:->


On Tue, May 13, 2014 at 3:54 AM, Ian Booth <ian.booth at canonical.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Joey
>
> >
> > I'm curious to know if there is any reliable mechanism to detect a
> > cowboyed change inside a juju environment and then report them.
> >
> > A non-juju synonym of what I'm trying to accomplish would be with puppet
> > managing a system's /etc directory. If that directory is under some RCS
> > you can diff it and tell what changes have been made. I'd like to do
> > something similar within a juju environment.
> >
>
> I assume you are talking about someone using the juju set-env command to
> change
> an environment value, and knowing that that has happened. Right now, AFAIK,
> there's no tooling in Juju that provides a packaged solution for what you
> want.
>
> Currently, Juju's initial environment state comes from the
> environments.yaml
> file at bootstrap, which is transformed into a yaml <envname>.jenv file
> inside
> the $JUJU_HOME/environments directory. Each set-env invocation also leaves
> information in the server side log files. So theoretically you could
> determine
> if changes have been made and who did it, by combining information from
> get-env
> with the sources just mentioned. Clearly, this is not ideal.
>
> A topic of discussion at the recent Juju sprint was to add audit logging to
> Juju. I *think* that topic has slipped off the todo list for the next
> cycle. So
> I don't personally  have a good answer for you right now. Perhaps someone
> else
> can chime in with a better answer?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iJwEAQECAAYFAlNxXzoACgkQCJ79BCOJFcYdNQP/QZp8MIC5uG1eaEvGh20GR6v1
> 50FLMmpjw4/BjMGvSxmJDaahocHYGhAeuasSbzRUpkT7s0CRk2g5SkfhxSL3ZXsa
> 6hV3+kTzbl1yshSNWcyWcHIHTW3JAE3N7+aoQaXsPTOxpzryTrAUfqgyITZs1nqf
> iQzYk9EGCUYw0+sGmzc=
> =+Oom
> -----END PGP SIGNATURE-----
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140513/af074e0b/attachment.html>