PLACE

place is a system for keeping track of where system files should be "placed" on the system. place will keep track of any file you tell it to, across multiple systems. The idea is to have a central "place DB" server set up that holds all the system file information for all the systems that you administer, and then you have a "place client" on each server that queries the DB when you need to place files into their live location. Also, place allows you to create an "after script" that will be run after the file is placed to perform any additional tasks that might be needed to make changes take effect.

Well, I don't know if anyone else would need it or not, but I can tell you why I created place. Place is just one part of the process that I use to keep track of system changes on multiple systems, by multiple administrators.
Here's why I created place, and how I use it:

I work as a system administrator, and I maintain multiple linux servers. These servers are running various different linux distros (redhat, fedora, whitebox, gentoo, etc), and they are running different releases of these distros as well (redhat 7.3 - FC2 for example). If you've administered different linux distros/releases, you'll know that sometimes as programs and distros evolve, files tend to move around. Place helps me keep track of where each file belongs on each system.

As I said before though, place is only one part of the system that I have implemented. We keep track of all changes to our system configuration via a CVS repository. Each server has it's own system configuration module in cvs, usually named something like "sysconf-hostname". Whenever an administrator (and there are sometimes multiple) needs to make a change to a system file, they first grab an updated copy of the system config module for that host from the CVS repository. Then the admin would make their changes to the file, (presumably, if possible) test it, and commit the changes back to the repository. Then, the final step to make the changes live would be to "place" the file in the live system location. This is where place comes in. Previous to place, we had to remember to copy the file to the proper location every time. Now that I have created place, I can simply type "place " and the file will automagically be placed in its proper location. If the file isn't known to place, place will ask you if you'd like to add it so that next time it will know about it.

Simple, right?

Well, no... place will work independantly of anything else you use. So if you have a different way of tracking changes to system files, you can keep whatever you are currently using. All place does is keeps track of where files are supposed to go, and places them there when it's told to do that.

Yes, that would be easier. But it's kind of defeating the purpose. The reason that I keep all the system files in CVS is so that we have a record of what changes were made to each and every one of the systems that we're responsible for. We know what changes were made, when the changes were made, and who made them. In addition, if we ever need to restore the system in the event of a crash, we have the latest and greatest config available to us in the CVS repository. This makes restoring or reloading a system a lot easier than trying to re-configure everything again by change and trying to remember all the changes that have been made to the server. (I've had to restore a couple servers from the CVS sysconf module before and it really does make it go a lot smoother)

An after script is a script that gets run after the file has been placed. The reason that place allows for after scripts is that there are some system files that require you to execute a command (or commands) after the file has been placed to make your changes take effect. A couple examples I can think of off the top of my head are bind and sendmail. For bind, when you edit a zone file, you need to issue a command to the bind daemon so that it reloads its zone files. For sendmail, when you make changes to the files in /etc/mail such as virtusertable, access, etc, you need to run a makemap command to update the proper db so that the changes will take effect in sendmail. Both of these are perfect examples of why an after script is convenient. Rather than having to remember the command (and remembering to type it in), you can simply create an after script in place, and then when you place the file, you will be prompted as to whether or not you'd like to run the after script.
NOTE: The after script became available in v0.2, so if you have v0.1, upgrade.

MMMkay... that's not really a question. Send any questions, comments, hate-mail, etc to place@hanser.org.

You can download the latest release of place from the Sourceforge Project Summary Page.