I kind of follow what you're saying here. However: 1) CellServDB is "where are database servers" 2) what's in the VLDB is "where are the volumes" so just because it appeared in 1, well, that has nothing to do with 2. mantra: "solve the real problem"
CellServDB on each host must list the addresses that the database servers are reachable at from *this* host. not what each believes their own address are. Make it so. e.g. a db server behind a nat would list its internal address for itself; one outside a nat would list the external address which you are port forwarding from. The internal server would include in NetInfo as its first line: f (external address) e.g. f 8.8.8.8 if its external address was 8.8.8.8 then whatever internal address NetRestrict could be used to mask unwanted addresses, *but* you probably want both addresses, the local and the external, so if there are these two only, mask none with NetRestrict. Now, as to fileservers, the same tip(s) with NetInfo/NetRestrict apply. Here, the CellServDB only *needs* to provide an address for at least one server, but ideally you still list, for each server, an address which reaches it. vos delentry is for a VLDB entry, not a server, so you didn't remove any server addresses from the VLDB with it. remsite removes a server for a volume. delentry removes a whole volume entry. changeaddr -remove removes an address but probably still isn't what you want. make the fileserver register the addresses you want (using netinfo and netrestrict), start it and let it register. all will be well. done. On Mon, Jan 17, 2011 at 3:20 PM, Jaap Winius <[email protected]> wrote: > Hi folks, > > After messing around with a couple of multihomed hosts for a while, I get > the impression that AFS, or at least the Debian squeeze install procedure > for it, doesn't like to work this way. It's possible to prevent the file > server from listening to certain interfaces (addresses) by using NetInfo and > NetRestrict, but I wish I knew how to do something similar for the ptserver > and especially for the vlserver. > > When setting up a new database server (which is supposed to replicate via > the Internet), it seems that, by default, AFS scans all of the interfaces on > a new host to end up using the IP addresses associated with them. In my > case, this includes several private addresses that I don't want any of the > database servers to use. However, even if immediately afterwards I remove > these addresses from a new server's CellServDB and restart it, it's too > late: they're already in the VLDB and AFS is already trying to send a new RO > copy of root.cell to the new server... using that server's private range IP > address. Now I've got: > > # vos volinfo root.cell -noresolv > root.cell 536870915 RW 6 K On-line > oost.dapadam.nl /vicepa > RWrite 536870915 ROnly 536870916 Backup 0 > MaxQuota 5000 K > Creation Sun Jan 9 15:32:11 2011 > Copy Sun Jan 9 15:32:11 2011 > Backup Never > Last Access Fri Jan 14 18:17:02 2011 > Last Update Fri Jan 14 18:16:57 2011 > 0 accesses in the past day (i.e., vnode references) > > RWrite: 536870915 ROnly: 536870916 RClone: 536870916 > number of sites -> 3 > server 82.95.170.57 partition /vicepa RW Site -- New release > server 82.95.170.57 partition /vicepa RO Site -- New release > server 192.168.26.10 partition /vicepa RO Site -- Old release > > It seems to be stuck like this. Can it be fixed? > > Before discovering this, I had already used "vos delentry" to remove the > private IP addresses from the VLDB, so "vos listaddrs" currently shows only > the correct (public) IP addresses. > > The last time around, I had succeeded in adding each new server only after > first bringing down the internal interfaces. Once installed, the internal > interfaces were brought up again and AFS ignored them. This afternoon, > bringing down those internal interfaces was not an option, but I was hoping > to get it to work anyway. I had no such luck. > > This is a fresh setup involving two of the servers planned, so I can easily > blow it all away and start over, but I'm wondering if it's possible to > install OpenAFS on multihomed hosts without having to down any internal > interfaces. > > Thanks, > > Jaap > > _______________________________________________ > OpenAFS-info mailing list > [email protected] > https://lists.openafs.org/mailman/listinfo/openafs-info > -- Derrick _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
