For the sysadmins amongst us: if you've ever worked in a group of sysadmins, and run into a situation where you've been editing some config file, only to find out another sysadmin was editing the same file at the same time and overwrote your changes, then here's the tool for you: http://sourceforge.net/projects/admedit/ This is a little utility, somewhat similar in concept to vipw, that I've been working on VERY sporadically for literally about 3 years, shortly before I left my first job as a Unix sysadmin at Fresenius Medical Care; and it's finally of sufficient quality that I'm not (too) embarrased to tell people about it. :) I hope you find it useful. Feedback and bugfixes are welcome. Note that the locking mechanism is less than ideal (there's a race condition for files on NFS filesystems), but it mostly works... I'll get around to re-working it sometime within the next two years. =8^) O.k. so having been asked the question earlier, why do I think this is better than just using RCS or some other source control tool? - It's easier to learn than a full-blown source control tool Many sysadmins have never been programmers. The first sysadmin group I worked in had only one sysadmin who had ever used a source control tool when I first conceived the idea to write this tool. The only other sysadmin in our group who had even heard of RCS was me, and at the time I'd never used it. This was a group of five admins. If your group is like mine was, it's much easier to teach everyone to use this tool than it is for them to learn the concepts of source control, as well as the mechanics of a source control tool. This is not to say that I think using RCS is a bad idea; quite the contrary. Our group currently uses both RCS and this tool to manage configuration file changes, where RCS is not a hindrance (I'll get to that one shortly). - It's easier to determine who has a file locked The problem is that to edit most configuration files, you must effectively be root. If you check out a file as root with RCS, the lock is owned by root, and it becomes difficult to know which system administrator is actually working on a file. Your best course of action at this point is usually to wander around asking if anyone is working on the file you're trying to edit. At one point, the group I was working in reached a total of 10 people spread out over two floors. If your group is like this, running around yelling "who's got the aliases file locked?!?" isn't a terribly efficient way to determine who is working on the file... This tool circumvents this problem by trying every way I could think of to determine who the user is who is working on the file. About the only time it will fail is if you log in directly as root, which is generally considered a bad system administration practice and should be discouraged anyway. The tool will also complain if you have logged in directly as root and is therefore unable to identify your "real" username. Once the user is determined, that information is saved with the lock file, and admedit will report who the user is upon subsequent attempts to edit the file with admedit. - Some files are not well suited to RCS control Some configuration files can be modified directly by users. A good example of this is the /etc/passwd file. If your users run the passwd command to change their password, in all likelihood the file will not be checked out for editing, and their password will revert back to the old one after the next modification made by a system admin who diligently checks out the file before modification and checks it back in when finished. - RCS and other source control tools allow lock "stealing" RCS will notify you that another user has a file locked, and cheerfully ask you if you would like to steal the lock, leaving it up to the better judgement of the system administrator NOT to do that. You might not even notice that you've been prompted; I'm sure some of you have noticed in the past that I myself have a habit of hitting 'Y' in response to virtually every prompt I'm given... =8^) However, admedit will not allow you to steal locks; if you wish to thwart the efforts of your fellow sysadmins to practice safe editing, you must manually remove admedit's lock file (or avoid using admedit), which is a bit more work than just hitting 'y' and continuing on (unless you simply don't use admedit AT ALL), and hopefully enough so to discourage all but the least concientous system administrators. :) Whether or not these points mean anything to you probably depends a lot on your environment, and in particular the experience and knowledge of the group of admins you're working with. This tool is not a miracle tool; admedit is no better than RCS in that you must USE it, and use it properly, to avoid eating your fellow admins' changes for breakfast. I wrote this tool in order to provide a fairly simple means of identifying that someone was already editing a particular file, and just exactly who that person is. It's designed to encourage team play... :) Use it if you want to. Make suggestions for changes if you like too. By all means, send me patches that make it less broken. -- --------------------------------------------------- Derek Martin | Unix/Linux geek [EMAIL PROTECTED] | GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu ********************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the following text in the *body* (*not* the subject line) of the letter: unsubscribe gnhlug **********************************************************
