On Fri, 2011-04-15 at 22:21 +0200, Erik Huelsmann wrote:
My work on cl-net migration got stuck a little on tech.coop internal work this week. However, I'm fully back to the migration and I'm making copies of /project and /home right now. I suppose I'll be creating a copy of much inside /custom too, when the other two transfers have finished.
If you make a backup while the server is still accessible you'll lose data modified after the backup but before the restore and switch to the new server.
Here's how I'd do it: 1a) Start a new SSH server on old.cl.net(with a different RSA key) on a port other than 22 and move the current keys to new.cl.net 1b) Add an iptables redirect of port 22 to new.cl.net but don't start it on new.cl.net until the migration is done and kick out all people logged on the server 1c) Shutdown all services that might try to access /home and /project (apache, git, cvs, svn, etc...) 2a) Move /home and /project to new.cl.net 2b) Export them via a network FS to old.cl.net 3) Start the services and hope they work
If all goes well, all those services should be able to access the projects' data via network and we can start to migrate each service to new.cl.net whenever there's time
BTW, do you think we should use something other than NFS, perhaps CIFS ?
At the same time, I'm trying to figure out how to best migrate /etc/password- and /etc/group-. Anybody here done someting alike before? I mean, I can't just copy it over, because the system accounts shouldn't be overwritten. I suppose a 'grep -v' (for inverse matching) should get us quite far filtering out system (uid<500) accounts.
Human users should maintain their passwd records(and implicitly, their uid). A little awk will do the trick
Another issue I'm thinking about is that we're going to switch to subdomains for hosting our services. However, the benefits of such a change seem low if we don't switch to a structure where our data is also grouped per service. Currently everything is in /project, which is grouped around projects, requiring all services to run on a single server because they need to access specific directories - one in each project. I'm thinking we should reverse the design: grouping data per service and making /project a set of symbolic links into the service directories. That way, all that's required is that the links point to the right locations in the file system, possibly NFS mount points, if the service were to run on a different server.
This is a good idea, especially since it requires very little additional work, just a little care not to break users' existing setups