Gérald Macinenti <[EMAIL PROTECTED]> wrote: > Christopher D. Clausen a écrit : >> Gérald Macinenti <[EMAIL PROTECTED]> wrote: > yes, this is the best way to describe it, two differents servers with > just happen to have the same cell name, my goal is to replace the old > by the new one, so I kept the cell name > >> The correct solution would be to make both servers members of the >> same cell by copying the KeyFile from the original one to the new >> one. And then restart the server processes and vos move from one to >> the other. > > but both servers have there own root.cell, wouldn't it be an issue? > and then which vldb would retain the information of moving the volume > ? and concerning the Keyfile: both servers use their own kerberos > server (as I migrate this one in the process too)
Are the root.cell volumes different between the two servers? If you aren't doing a full migration, than copying data manually might be the best answer. Their own Kerberos server? What does that mean? You set up an additional Kerberos realm with the same name as well? Did you actually migrate the Kerberos KDC? Or did you just setup a new one? >> Is there a particular reason you don't want the two servers to >> communicate? > > yes: the fear to render my old server unusable as I don't master all > the consequences of doing so ;) Adding a server with just an fs instance should not cause any problems. You will want to remove all volumes on the new server and follow the instructions for adding additional fileservers to a cell. Once the fileserver is up, vos move the data to it. You can then go through the process of adding this machine as a full AFS DB server to migrate your pt and vl databases from the old server. Once up, you can then remove things from the old server and change the IP address on the new one to match the IP address of the old one. Can I ask why you are doing this? Its going to be quite a hassle, especially if your cell only has a single AFS DB server. If you need to keep the cell up while doing the migration, I'd stringly recomend having at least 3 AFS DB servers. ----- In theory, restoring the dumps should work. You need to ensure that the PTS database is the same between the two servers as well. I don't know why fs sa is crashing, but I suspect it has something to do with two different cells having the same name. Are you sure your test client is pointed at the correct server? The server and clients have different CellServDB files. <<CDC _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
