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. Ian: Thanks for your comments and explanation. Those were helpful to me since I don't play around with the juju internals much.
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.
Bingo. :-) I conceptually think about this as "deployed charm integrity checking".
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.
Right. This a feature but also a bit of a challenge to detect when something has been changed by hand.
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.
Yes that's possible. I'd obviously need it to scale to a large volume of charms in a large environment. That might take some thinking. A subordinate charm that versions /etc and possibly the juju environment might work better but that may not scale either. If there was an environment variable that we could turn on to enable versioning and then do a ~ "juju check" which would output only differences, that would be ideal. I assume that's quite a bit of non-blueprinted core hacking though. J
signature.asc
Description: Digital signature
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
