Hi all. I'm working on devising a system to keep my RH Linux servers up to date in all aspects. I have a decent system set up using rsync which keeps master copies of config files in different hierarchical directory trees based on common files, role-based files, and host-specific files. It works very well, thanks to rysnc. What I am curious about is what issues would be involved with using rsync to keep installed software up to date across many servers. Here are my pros/cons: Assumptions: - Groups of identical servers in terms of hardware configuration and server role. - Each distinct hardware config/role will have its own root directory tree on the master rsync server. - Installation of software will occur on a clean machine; the changes will be rsync'd into the appropriate directory tree. - Multiple passes through more specific directory trees will allow for customization. Example: PASS1: rsyncs the common/rhl62/ root tree. PASS2: rysncs the role/webserver/ root tree. PASS3: rsyncs the host/foo/ root tree. Each pass will update the previous one, resulting in a host configured as a webserver named foo. Pro: - I only install software/configs/patches once into the appropriate master rsync directory tree (an oversimplification, but more or less true). Any server that should have this configuration installed will rsync to this tree and have the binaries copied over. For new software, this should work great. - Allows for an extremely minimalist install of Linux. I can then rsync the rest of the filesystems to the box to make it into whatever server it is supposed to be. - I don't need to acquire or build RPMs to distribute and update software automatically. Con: - For updating software, it could cause a problem if rsync updates a file as it is being accessed. - Possible increased complexity re: maintaining the master copy. However, this should be outweighed by not having to build and distribute our software and RPM updates across many servers. - Using multiple passes as described above will preclude being able to delete local files that are extraneous; i.e. I could end up with files on a server that aren't being used. Careful construction of the master directory trees should reduce or eliminate this problem. This seems way too simple. What am I missing? I came up with the idea for doing this while testing RPMs that I was building. I gave each of them a different prefix and figured out what files where going where. Theoretically, I could make a script which would build each piece of software twice: the first time would be the real install, the second would be to a special root. Then I could check that special root for filesystem mods, feed the results to rsync, and let it rsync the files from the real root to the corresponding fake root on the master rsync server. Are you with me? FWIW, the problem I ran into while building my own packages was that figuring out which files to include in the RPM is a tedious process. Compounding that problem is the fact that not every install target supports alternative install prefixes (if you change the --prefix, you may end up with binaries that won't function properly when placed relative to the real root of the target filesystem). Finally, once I get the package ready to go, I still have to distribute it and get it to install/upgrade properly. If anyone thinks that my rsync idea above is a bad one, can you please let me know if you have a better way to do this using rpm or scripts? I'd love to hear it. Feel free to send any magic spec file creators along with your reply. :) Thanks. =-Rob
