On 4/12/2010 5:25 PM, Atro Tossavainen wrote: > Jeffrey, > >> actually it is because that server is reporting multiple addresses: >> >> Server( 128.214.88.114 10.0.0.3 172.16.0.1 172.17.0.1 172.18.0.1 ) >> >> several of which are lower than 128.214.58.174. What are these other >> interface addresses are do you expect them to be used for ubik >> synchronization? > > Private addresses for purposes other than AFS. > > I believe I am using NetRestrict to avoid the servers from picking up > these: > > sun4x_58 # cat /usr/afs/local/NetRestrict > M 10.255.255.255 > M 172.255.255.255 > M 192.168.255.255 > > I don't expect to see the RFC1918 addresses anywhere in connection > with AFS. The NetRestrict file is unaltered as of Feb 13, 2009 and > has been essentially identical for years. > > (I remember needing to raise a bug with IBM over wildcard support. > PMR-73077... late 2004/early 2005. Not that it says anything to anybody > outside IBM, probably. Merely using "255" wasn't enough, it needed > adding "M" in front for wildcards to work and I think this was and is > undocumented.) > > I have not had any database issues for as long as the other sun4x_58 > host was the other database server.
The OpenAFS NetRestrict documentation does not mention the use of a preceding 'M'. http://docs.openafs.org/Reference/5/NetRestrict.html I suspect the change IBM implemented was never passed on to OpenAFS and as far as I can tell from the source its presence will invalidate the address and prevent it from being used as a filter. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
