How to extend kadmin

[Nicolas Williams]

On Tue, Oct 27, 2009 at 11:36:24AM -0400, Greg Hudson wrote:
> Summary response:
> 
> * Nico, Ken, and (in previous off-list conversation) Tom have expressed
> displeasure at an approach which requires more hand-editing of XDR code.
> So the way we've extended kadmin for lockout support on the trunk (the
> api 2->3 bump and conditionalization of xdr_kadm5_policy_ent_rec) is
> controversial.
> 
> * However, Nico notes that the way we marshal krb5_principal is
> problematic for using rpcgen.  I looked into this myself: we call
> krb5_unparse_name on encode and krb5_parse_name on decode.  Does rpcgen
> support app-defined encoding functions for particular fields?  If not, I
> am doubtful that we will ever be in the position of being able to use
> a .x file to define the kadmin protocol without starting over.

No, you can't, but what you could do is declare the kadm5 krb5 princ
data type to be "opaque" and then do the parsing/unparsing at the
application layer.

Ah, so, yes, you can handle krb5 princ names the Right Way (tm).

> * Personally, I don't think hand-editing XDR code is a big deal, as long
> as it wasn't my fault that we got into this position in the first place.
> For better or for worse, rpcgen generates pretty readable and hackable
> code.

I agreed with this already: more of the same is the expedient way to go.
If you could bring yourself to rev the program, great, if not, oh well.

> * There've been some ideas for the future of kadmin that don't involve
> ONC RPC, such as LDAP.  Lacking specific plans and resources allocated
> to such a reboot, I have to assume that we'll be making evolutionary
> changes to the current kadmin architecture for an indefinite period.

I agree.

> * I'm going to resist the temptation to get into a wide-ranging
> discussion of network protocol architecture at this juncture.  Just
> pretend I didn't say anthing about my personal like or dislike of
> RPC-style network protocols.

Heh.

Nico
--