Lustre discuss - Jul 2009 - Block clients from mounting a Lustre filesystem

Dear list,

with versions <= 1.8.0.1 is there a more elegant way of blocking
clients from mounting a Lustre fs than configuring IP tables accordingly?

Is it correct that with versions >= 2.0 Kerberos will deliver this
''functionality'' as I can enforce the client to authenticate
(which
it can''t if I refused to give it keytab in the first place)?

TIA,
  Arne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6380 bytes
Desc: S/MIME Cryptographic Signature
Url :
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20090727/1616b21f/attachment-0001.bin

On Jul 27, 2009  12:01 +0200, Arne Wiebalck wrote:
> with versions <= 1.8.0.1 is there a more elegant way of blocking
> clients from mounting a Lustre fs than configuring IP tables accordingly?
I don''t think there is any other easy way to do this.  I believe LLNL
had a patch to essentially implement xinetd-like allow/deny inside the
LNET code, but I don''t think it was merged.
> Is it correct that with versions >= 2.0 Kerberos will deliver this
> ''functionality'' as I can enforce the client to
authenticate (which
> it can''t if I refused to give it keytab in the first place)?
Right, though Kerberos will not yet be a supported feature in 2.0.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

On Mon, Jul 27, 2009 at 01:53:02PM -0600, Andreas Dilger
wrote:
> On Jul 27, 2009  12:01 +0200, Arne Wiebalck wrote:
> > with versions <= 1.8.0.1 is there a more elegant way of blocking
> > clients from mounting a Lustre fs than configuring IP tables
accordingly?
> 
> I don''t think there is any other easy way to do this.  I believe
LLNL
> had a patch to essentially implement xinetd-like allow/deny inside the
> LNET code, but I don''t think it was merged.
It''d be nice to have a way to evict clients at any time and stop them
from re-connecting.  Client addresses don''t mean much; some time after
a
client is banned some other client may replace it and use the same
address.  This argues for a UI (and API) that allows one to ban/un-ban
addresses.
> > Is it correct that with versions >= 2.0 Kerberos will deliver this
> > ''functionality'' as I can enforce the client to
authenticate (which
> > it can''t if I refused to give it keytab in the first place)?
> 
> Right, though Kerberos will not yet be a supported feature in 2.0.
Client principal names are a lot more meaningful than client addresses,
so being able to blacklist clients by principal name is a lot more
useful than blacklisting them by address.  But you''d still want this to
be a function of the Lustre servers, not a function of denying Kerberos
credentials to clients.

Nico
--