On 4/13/2010 1:43 AM, Atro Tossavainen wrote:

> Jeffrey,
> 
>> The OpenAFS NetRestrict documentation does not mention the use of a
>> preceding 'M'.
> 
> Neither does the IBM documentation, which is what I said, I think.

The OpenAFS Reference Manual has been thoroughly updated to document
how OpenAFS behaves.  It is derived from the content of the IBM AFS
man pages but is not the same as them.  There is no reference to 'M'
prefixing because OpenAFS does not support it.

>> 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.
> 
> On the IBM AFS sun4x_58 server where it was explicitly recommended
> by IBM AFS support in early 2005? :-)  I'm not running the OpenAFS
> db servers.  In fact, I seem to be running a mishmash of IBM AFS
> servers - the various components aren't even all the same version.
> 
> From my reading of IBM AFS patch READMEs, it appears that "M" appeared
> in AFS 3.6 Patch 13 (aka Build Level 2.57) (APAR IY77101).  This seems
> to have been released in December 2005, but IBM support have indicated
> its use in a support ticket conversation in January 2005 already.  It
> did not work, and in connection with another support ticket in September
> 2005, IBM made available a patched version of the 3.6 2.56 *fileserver*
> only where it finally did work.  So I don't think I've ever had any
> database servers that are even supposed to obey "M" in NetRestrict,
> but at the same time, I haven't had a problem with this so I haven't
> noticed.  What the...

I can't speak to the IBM patches.  I can speak to the OpenAFS sources.
You can read them to see how the NetRestrict file is parsed.

http://git.openafs.org/?p=openafs.git;a=blob;f=src/util/netutils.c;h=03a90e3b6d89e6f1c781b7324f0f661280ceeaa6;hb=HEAD

See parseNetRestrictFile().  There is no reference to 'M' anywhere.
In OpenAFS, "255" should be a mask by itself.

The question OpenAFS is now left with is whether to add support for the
IBM behavior change.

Jeffrey Altman



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to