Comments on: Tools for Group Administration of Debian Systems?

By: Matthew Edmondson

Matthew Edmondson — Thu, 09 Apr 2009 13:41:32 +0000

I manage several different shared root Debian systems.

I will look into the tools documented above. Thankyou.

For each group we develop a group policy about ‘being root’ and how that impacts on documentation and changes to the system. Words like ‘Absolutely must’ are used. Before work is done, people generally propose the changes, prior to doing any work that may have impact on others. The ethos being responsible co-operation.

Documentation is required and has been done in a variety of ways, inlcuding on an internal facing wikis on the box.

Using sudo is commonly a policy.

This method has enabled me to mentor new admins and thus devolve work in maintaining voluntary projects.

By: reg

reg — Wed, 08 Apr 2009 23:17:39 +0000

In my sysadmin team, we use metche, apt-listchanges, apticron and a custom script which insert changelogs in a central database (script is automatically launched when exit).

By: Marius Gedminas

Marius Gedminas — Thu, 02 Apr 2009 22:04:24 +0000

I don’t use script or shell history — I copy and paste between two terminals, one running a shell, the other running vim. The things I record in /root/Changelog are idealized versions of the actual commands I run, and only those commands that actually make persistent changes (so, things like looking around with ls, reading man pages, fixing command lines arguments after a mistake—these aren’t recorded.)

I also add human-readable comments in places that I think are warranted (e.g. vi /etc/cron.d/somefile, would be followed by “added a line” and the line itself: “0 * * * * * root /usr/local/sbin/somecommand”). Sometimes I use ex commands to indicate simple changes (vi /somefile; :w %.orig; :%s/foo/bar/gc). In other words, it’s more of a collection of recipes for sysadmins than a changelog — and it seems to work pretty well. I use it as a recipe more often (we need to to the same thing for customer X’s instance that we did for customer Y last year — let me look it up) than as a debugging/audit tool (but it is also useful in the latter case—e.g. some mail processing script stopped working last Tuesday, did anybody change anything at that date?).

Sometimes I prepare the commands in vim (e.g. using copy/paste from older historical records) and then paste them into shell, one by one.

By: MJ Ray

MJ Ray — Thu, 02 Apr 2009 16:21:07 +0000

jhr, I wish I did. systraq, diffmon or intrusion detectors will report changes, while slack, cfengine2 or puppet can be used to enforce policy, but I don’t know of a checker quite like lintian. Maybe lintian or linda could be repurposed without too much effort?

By: jhr

jhr — Thu, 02 Apr 2009 16:06:08 +0000

mj, you mentioned fault-finding tolls. do you know please something like lintian, but for system with the posibility to write simple policy checks?

-jhr.

By: Markus Hochholdinger

Markus Hochholdinger — Thu, 02 Apr 2009 14:50:39 +0000

Not the perfect solution but an easy one. All sysadmins (root) have to stand to these rules:
- If a configuration file will be changed the first time, do “cp -a $FILE $FILE.original”
- If a configuration file will be changed if *.original exists, do “cp -a $FILE $FILE.$(date +%Y%m%d)”
- Comment your changes in the configuration file, especially who changed it.
=> locate *.original, diff $FILE.original $FILE, ls -l $FILE, ..
- Only install software with aptitude
=> /var/log/aptitude*

By: MJ Ray

MJ Ray — Thu, 02 Apr 2009 10:05:10 +0000

I’m inclined to start using etckeeper too. I’ve been hearing quite a bit of buzz about it over the last few days.

About writing down the exact shell commands: do you think it’s worth starting up “script” or setting BASH_HISTORY to a one-per-use file, to save all root commands unless told otherwise?

By: Marius Gedminas

Marius Gedminas — Wed, 01 Apr 2009 23:09:07 +0000

I essentially use the dch solution, but mine’s homebrew (a two liner shell script that echoes `date` and $LOGNAME >> /root/Changelog and runs $EDITOR on it). The other sysadmin(s) usually remember to describe their changes, although sometimes I have to recover those descriptions from vim’s .swp files.

BTW it’s really useful to write down the exact shell commands/changes to config files you’ve made — you’ll find out that you need to do the same thing again (e.g. on a different box) and you’ll *love* the ready-made cheat sheet.

I’m planning to look at etckeeper next.

By: taggart

taggart — Wed, 01 Apr 2009 20:48:47 +0000

We use a similar dch method, documented at

http://lackof.org/taggart/hacking/dch/

We’ve started using etckeeper as well, but only letting aptitude do autocommits.

By: -dsr-

-dsr- — Tue, 31 Mar 2009 17:20:23 +0000

If you can enforce a policy, then you need something along the lines of “all changes made by a root user MUST be done through Puppet” where Puppet takes on the value of your favorite systems management automation entity. Yes, this includes and is more authoritarian than your already discarded “force everyone to use the same version control system”.
It is. I think, the only way to make this work.