To paraphrase Mr Krizak on a different occasion, "think voluntary cooperation". It works for politics as well as technical work. This is how cfengine began the notion of autonomy in the first place -- at a university where everyone wanted to control their own box.
When you have people who need to feel in control, you give the them power to override and engage them with voluntary cooperation. No one want to feel they are being overrun by "The Man", but controlling everything yourself is exhausting and most people lose interest in the end. You could present cfengine as something that helps them in their lives, reduces their burdens, and brings order and documentation. There are many ways to use cfengine. If I could just count the number of times I've read that "Cfengine forces you to...." and cringed. Cfengine doesn't force you to do anything, but admins often have poor imaginations and use it to carpet bomb their systems into compliance. I tend to believe in a lighter touch - less is more. Unless you have mandatory compliance issues (The Law -- did you say the Lieu?), I don't recommend controlling anything that doesn't show signs of running wild. You can insert new mounts without destroying old ones, for instance. Justin, you are a skilled power-user. With great power ... ;-) Mark Justin Lloyd wrote: > Hi all, > > > > For those of you who are part of a team that manage a Cfengine-based > environment, how do you prevent people from making local changes to > things that are managed by Cfengine, thus causing local changes to get > wiped out? For example, if Cfengine manages all NFS mounts in /etc/fstab > on Linux systems and someone manually adds such an entry to a host which > Cfengine later wipes out when enforcing just its specified NFS mounts. > Things that come to mind are: > > > > · Change Control - well-defined dept/company procedures for > change approval, and all changes to systems should be done only through > Cfengine policy, never locally on any system > > · Automated Comments - have Cfengine add comment headers to > files it manages > > · Documentation - thoroughly and clearly comment the policy > files and also create external documentation, such as an easily > searchable wiki, that people can read to find out what is managed by > Cfengine > > · Training and Communications - teach the team what is managed > by Cfengine and have good communications channels (email list, team > meetings, etc.) to review when the policy is updated to manage new things > > > > Let me know if you have other ideas and how well they’ve worked for you. > > > > Thanks, > > Justin > > > > This electronic communication and any attachments may contain confidential > and proprietary > information of DigitalGlobe, Inc. If you are not the intended recipient, or > an agent or employee > responsible for delivering this communication to the intended recipient, or > if you have received > this communication in error, please do not print, copy, retransmit, > disseminate or > otherwise use the information. Please indicate to the sender that you have > received this > communication in error, and delete the copy you received. DigitalGlobe > reserves the > right to monitor any electronic communication sent or received by its > employees, agents > or representatives. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Help-cfengine mailing list > Help-cfengine@cfengine.org > https://cfengine.org/mailman/listinfo/help-cfengine -- Mark Burgess ------------------------------------------------- Professor of Network and System Administration Oslo University College, Norway Personal Web: http://www.iu.hio.no/~mark Office Telf : +47 22453272 ------------------------------------------------- _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
