Dear Dave, I'm looking into the topic of OpenPKG Instance migration for quite a while. My goal was to automate this. Unfortunately, some conceptual enhancements of OpenPKG into the "configuration management" area would be required to achieve full automation. Today, human brainpower is absolutely required for migration and post adjustment. I dump some of my experiences here. You'll quickly find out that preparatory planning makes, or would have made, life easier. Here is a list of issues to consider:
Almost everything regarding an OpenPKG instance is stored below the prefix. Only a few connection points exist between the instance and the operating system. If the destination machine is binary compatible with the source and the environment, including prefix, user/group-names/ids are the same, then just shut down the services on the source machine, transfer everything below the prefix to the target machine and start the services there. Make sure you copy special files like sockets, symlinks, permissions and ownership. It's also a good idea to retain file dates and hardlinks. The tar and cpio commands are your friends. That's it. Well, almost. If you move the services, you need to move the network configuration before the service start, something unrelated to OpenPKG. Also, you need to take care about the six connection points between OpenPKG and the OS: prefix (already discussed), presence file (/etc/openpkg), users (/etc/passwd+/etc/shadow, NIS ...), groups (/etc/group, NIS, ...), rc/init scripts (OS dependent), crontab (usually /etc/crontab but for some OS crontab of root user). A comfortable way of dealing with that connection points is to run the binary bootstrap shell script on the target machine before the copy. Order is important because the binary.sh overwrites the RPM database. In case you did not save (remember "preparatory planning") the binary.sh from the source installation, you can pull all the options required out of a live installation as described in "cloning OpenPKG bootstrap" [1]. Things become harder if the target machine uses different prefix, user/group-names/ids, hardware architecture, operating system or OpenPKG series. I think this thread will consume some more of my time :-| The projection is that any of the criteria listed in the paragraph above will almost always end up in a rebuild of all packages. Only few exceptions like same arch-os and packages known not to have user/group information built into their executables or config files and setups not leveraging RPM integrity testing via "openpkg rpm -Va" may avoid rebuilding - practically that statement never becomes true. [1] http://www.lotterer.net/blog/en/41 -- http://thomas.lotterer.net ______________________________________________________________________ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
