How to extend kadmin
ghudson at MIT.EDU
Tue Oct 27 11:36:24 EDT 2009
* 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
* 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.
* 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
* 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'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.
More information about the krbdev