[Lustre-devel] GSS cross-realm on MDT -> OST

Bernd Schubert bs at q-leap.de
Wed Jul 9 14:10:13 PDT 2008


On Wed, Jul 09, 2008 at 02:29:38PM -0600, Andreas Dilger wrote:
> On Jul 09, 2008  11:25 -0600, Eric Mei wrote:
> > Yes Ben is right, currently in a same realm any MDS could authenticate 
> > with any MDS and OSS. But afaics the problem is nothing to do with 
> > Kerberos. It's because currently Lustre have no config information about 
> > the server cluster membership, each server target have no idea what 
> > other targets are.
> > 
> > So solve this, we can either place the configuration on each MDS/OST 
> > nodes - as Ben proposed in last mail; or probably better centrally 
> > managed by MGS, thus MDT/OST would be able to get uptodate server 
> > cluster information. Would it work?
> 
> I think that MDT/OST addition to the filesystem needs to be managed
> properly at the MGS, regardless of whether Kerberos is in use or not.
> 
> Please see bug 15827 with some details of the problem.
> 
> For the non-kerberos case having administrator action at the MGS is
> the most secure.  Enabling a shared secret key passed to mkfs.lustre
> like "--mgs-key e85021aee637f7250e482a9a5b23cb0d" sent from the
> MDT/OST to the MGS at first connect time at least provides some
> restriction on adding new devices to the filesystem.

Hmm, is a secret key really neccessary, for me this sounds a bit like
security by obscurity. Wouldn't it be better to to have a two way
MDT/OST registration?

1.) As it is, simply mount the filesystem on the MDT/OST. But this will
put this filesystem into a registered, but unconfirmed state on the MGS.

2.) Introduce a lctl command for the MGS to list all
registered-but-unconfirmed systems. And another command to confirm the 
registration.

On on the other hand, this approach might conflict with the writeconf concept.


Cheers,
Bernd



More information about the lustre-devel mailing list