[clo-devel] 2011-04-15: cl-net migration progress

[Stelian Ionescu]

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

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/clo-devel/attachments/20110415/4c962359/attachment.sig>