On Wed, 2012-07-11 at 13:27 -0400, J. Bruce Fields wrote:
> So, if the issue is: you want to be able to choose, in individual
> containers, which mechanism to use: whatever, we can probably make that
> work.
Please do then.
> If you're instead saying: it's not acceptable to use the gssproxy
> mechanism to authenticate v4.0 callbacks, the client must only ever use
> the existing mechanism: then I'd rather drop this entirely. I don't
> want to merge an rpc server authentication upcall that's not acceptable
> for one of the rpc servers.
If it goes in, I want it to be optional so that it doesn't break working
setups. I also want upgrades/downgrades to be as painless as possible.
See for instance the idmapper changes in 3.5 which are totally
transparent to the user: if the admin sets up /etc/request-key.conf to
use the new id_resolver, then that works, otherwise we just fall back to
using the old rpc.idmapd method. There are no module parameters etc
involved.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
