> On Nov 10, 2024, at 5:12 AM, Hirste <[email protected]> wrote: > > Hi all, > > I have to update an existing single server installation from 1.6. to 1.8. > > A brief overview of the situation: > > Existing Machine: Ubuntu Xenial, AFS Version 1.6.23 (through PPA) =afsA > > Target Machine: Ubuntu Noble with AFS Version 1.8.10 (from Distro Repo) afsB > > The Data ar provided via a handful of vdisks, each beeing a single AFS > volume, summing up to +3 TB. > > Clients: Ubuntu Focal, AFS Client Version 1.8.10 (through PPA, ugly Kerberos > hack to allow weak crypto) > > This is an inherited setup, I would describe my AFS abilities and knowledge > as weak / not to good. > I would describe the stated goals as follows: Migrate the single server cell to new hardware Upgrade from OpenAFS 1.6 to OpenAFS 1.8
Are there unstated goals? For example, Changing the IP address and hostname assigned to the database services Mitigating Brute force DES attacks: https://www.openafs.org/pages/security/#OPENAFS-SA-2013-003 Switching from afs@<REALM> service principal names to afs/<cell>@<REALM> service principal names Since you describe your AFS expertise as weak I will assume that you are unaware that UNIX OpenAFS clients rely upon the IP addresses of the database services not changing. Any change to the IP address or hostname of the database services will require distribution of new configuration files to all clients UNLESS all clients are obtaining the service information solely from DNS AFSDB or SRV records. You mention a weak crypto hack which implies that the cell server has either not been upgraded to 1.6.5 (or later) OR at the very least the Kerberos service principal was never rekeyed to deploy aes256-cts-hmac-sha1-96 service principal key in place of des-cbc-crc. If that is the case, I would suggest upgrading to 1.8 and then performing the rekeying to a non-DES encryption type. Switching from afs@<REALM> to afs/<cell>@<REALM> will make the client authentication faster because all versions of aklog shipped in the last 15 years try to acquire a ticket for afs/<cell>@<REALM> before afs@<REALM>. > What I would have done without advise or help: > > Setup the new server, add vdisks as the origin machine has, rsyncing the > data, repointing DNS entries > so that no changes on the clients are needed (some of them beeing road > warriors on laptops), demoting afsA. > > This will lead to a significant downtime since rsync will take its time. > Since there are no changes in Client Configuration > there could ba an easy way back. > The upside of this approach is that the clients require no configuration changes. If there are no DNS AFSDB or SRV records for the cell and all of the clients maintain local configuration with hard coded IP addresses, then it is really important that the IP address currently assigned to afsA remain an active database server even if it is not a fileserver. There are other downsides of this approach in addition to the downtime. It makes assumptions that the vice partition content consists of normal file data whereas the AFS vice partitions should really be thought of as a proprietary database of object stores where the fileserver and related processes (volserver, salvager) which operate as “root” are permitted to violate the normal filesystem rules to encode metadata. As such, volume level operations should always be performed using “vos” initiated operations. For example, “move”, “addsite”, “remsite”, “remove”, “release”, etc. > Instead I think it would be better to > > add afsB to the existing cell (beeing only an additional file server) As Jose mentioned, AFS is designed to be a reliable service which permits maintenance to be performed without cell-wide outages. Three database instances are required to ensure that there isn’t a single point of failure which interrupts services. I would suggest that you add two database service instances as the first step. Database service instances can in general be relatively small. VMs are perfectly fine as would be Intel NUC class servers. Separating the database servers from the fileservers is also beneficial. Unless the goal is to run the service as a single server. > Migrating the AFS Volumes in an AFS manner to afsB (does this work online?) Yes. “vos move”, “vos addsite”, “vos remove”, “vos remsite”, “vos release”. > move the other AFS roles (database server, binary distribution machine, > system control machine) > from afsA to afsB see above > demote afsA As mentioned the IP addresses and hostname assigned to afsA are the only place the existing deployed clients will look to. Therefore, any shutdown or removal of services from this address will result in an outage. > I am currently reading and trying to understand > https://docs.openafs.org/AdminGuide but would appreciate > help from experienced users. > Once you have the new servers in place you should tackle the Kerberos service principal rekeying. OpenAFS 1.8 requires the use of the akeyconvert tool. > Is it possible to have mixed fileserver versions ( 1.6 vs. 1.8) in a Cell? > What are caveats? > The intra cell protocol messages used between cell services in 1.6 and 1.8 are unchanged. Mixing 1.6 and 1.8 is just fine. > Is there a better strategy with less risk to migrate the server? > > Appreciate any help and advise. > > Hirste > Good luck. Jeffrey Altman AuriStor, Inc.
smime.p7s
Description: S/MIME cryptographic signature
