New libtirpc vs fedfs-utils.

New libtirpc vs fedfs-utils.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]



Hi Chuck / Steve,

It seems that fedfs-utils doesn't build with the new libtirpc.

Specifically fedfsd requires symbols

  svcauth_gss_set_svc_name
  svcauth_gss_get_principal

but libtirpc doesn't expose them any longer - it never included them in .h
files or provided documentation.

As far as I can tell fedfs-utils really does need these interfaces, there is
no alternate.
Would it be appropriate to make them "official" with header and doco support?

A simple hack is:

--- libtirpc-0.3.0.orig/src/libtirpc.map
+++ libtirpc-0.3.0/src/libtirpc.map
@@ -284,4 +284,6 @@ TIRPC_PRIVATE {
     __libc_clntudp_bufcreate;
   # private, but used by rpcbind:
     __svc_clean_idle; svc_auth_none; libtirpc_set_debug;
+  # private, but used by fedfsd:
+   svcauth_gss_set_svc_name; svcauth_gss_get_principal;
 };


but I suspect something better is really needed.

Are there other server-side routines that need to be exported?

Thanks,
NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: New libtirpc vs fedfs-utils.

[Chuck Lever]

Hi Neil-


On May 21, 2015, at 11:54 PM, NeilBrown <neilb@suse.de> wrote:

> 
> 
> Hi Chuck / Steve,
> 
> It seems that fedfs-utils doesn't build with the new libtirpc.
> 
> Specifically fedfsd requires symbols
> 
>  svcauth_gss_set_svc_name
>  svcauth_gss_get_principal
> 
> but libtirpc doesn't expose them any longer - it never included them in .h
> files or provided documentation.
> 
> As far as I can tell fedfs-utils really does need these interfaces, there is
> no alternate.

fedfs-utils needs to be updated, now that the new rpc_gss API is merged
into libtirpc, to use rpc_gss_set_svc_name(3t) and rpc_gss_getcred(3t).
That’s on my to-do list.

In the meantime . . .

> Would it be appropriate to make them "official" with header and doco support?

A fix for this issue was proposed yesterday on libtirpc-devel.


> A simple hack is:
> 
> --- libtirpc-0.3.0.orig/src/libtirpc.map
> +++ libtirpc-0.3.0/src/libtirpc.map
> @@ -284,4 +284,6 @@ TIRPC_PRIVATE {
>     __libc_clntudp_bufcreate;
>   # private, but used by rpcbind:
>     __svc_clean_idle; svc_auth_none; libtirpc_set_debug;
> +  # private, but used by fedfsd:
> +   svcauth_gss_set_svc_name; svcauth_gss_get_principal;
> };
> 
> 
> but I suspect something better is really needed.
> 
> Are there other server-side routines that need to be exported?
> 
> Thanks,
> NeilBrown

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: New libtirpc vs fedfs-utils.

[NeilBrown]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

On Fri, 22 May 2015 10:25:20 -0400 Chuck Lever <chuck.lever@oracle.com> wrote:

> Hi Neil-
> 
> 
> On May 21, 2015, at 11:54 PM, NeilBrown <neilb@suse.de> wrote:
> 
> > 
> > 
> > Hi Chuck / Steve,
> > 
> > It seems that fedfs-utils doesn't build with the new libtirpc.
> > 
> > Specifically fedfsd requires symbols
> > 
> >  svcauth_gss_set_svc_name
> >  svcauth_gss_get_principal
> > 
> > but libtirpc doesn't expose them any longer - it never included them in .h
> > files or provided documentation.
> > 
> > As far as I can tell fedfs-utils really does need these interfaces, there is
> > no alternate.
> 
> fedfs-utils needs to be updated, now that the new rpc_gss API is merged
> into libtirpc, to use rpc_gss_set_svc_name(3t) and rpc_gss_getcred(3t).
> That’s on my to-do list.
> 
> In the meantime . . .
> 
> > Would it be appropriate to make them "official" with header and doco support?
> 
> A fix for this issue was proposed yesterday on libtirpc-devel.
> 

Ahh, thanks.  I should have looked in the archives first, shouldn't I ?

I'll go see.

Thanks,
NeilBrown

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]