libtirpc and nis

libtirpc and nis

[Mike Frysinger]

the libtirpc package is self described as a "standalone package".  i wonder 
how far that actually goes.  wrt NIS, it requires the system C library to 
provide NIS functionality or you get a build failure in a few files.  would be 
nice if libtirpc were usable without any NIS baggage at all.
-mike

Re: libtirpc and nis

[Steve Dickson]

Mike Frysinger wrote:
> the libtirpc package is self described as a "standalone package".  i wonder 
> how far that actually goes.  wrt NIS, it requires the system C library to 
> provide NIS functionality or you get a build failure in a few files.  would be 
> nice if libtirpc were usable without any NIS baggage at all.
NIS used RPC procedures to communicate. As it stands today
NIS is currently using the RPC procedures glibc. In the
future there is a very good chance that NIS will start
using the RPC procedures in libtirpc especially if 
IPV6 support is needed...   

So I'm a bit confused on what you mean by "NIS baggage"
in the libtirpc package. 

steved.

Re: libtirpc and nis

[Mike Frysinger]

On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
> Mike Frysinger wrote:
> > the libtirpc package is self described as a "standalone package".  i
> > wonder how far that actually goes.  wrt NIS, it requires the system C
> > library to provide NIS functionality or you get a build failure in a few
> > files.  would be nice if libtirpc were usable without any NIS baggage at
> > all.
>
> NIS used RPC procedures to communicate. As it stands today
> NIS is currently using the RPC procedures glibc. In the
> future there is a very good chance that NIS will start
> using the RPC procedures in libtirpc especially if
> IPV6 support is needed...
>
> So I'm a bit confused on what you mean by "NIS baggage"
> in the libtirpc package.

you cannot build libtirpc on a system that doesnt provide NIS functionality.  
realistic RPC usage today is NFS related services only (i.e. a NFS client 
mounting a share on a NFS server).  i might be missing something (since i'm no 
RPC/NIS expert), but if this scenario doesnt require NIS in any way, then 
having libtirpc require/use it is bloat that should have an option to disable.
-mike

Re: libtirpc and nis

[Chuck Lever]

On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:

> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
>> Mike Frysinger wrote:
>>> the libtirpc package is self described as a "standalone package".  i
>>> wonder how far that actually goes.  wrt NIS, it requires the  
>>> system C
>>> library to provide NIS functionality or you get a build failure in  
>>> a few
>>> files.  would be nice if libtirpc were usable without any NIS  
>>> baggage at
>>> all.
>>
>> NIS used RPC procedures to communicate. As it stands today
>> NIS is currently using the RPC procedures glibc. In the
>> future there is a very good chance that NIS will start
>> using the RPC procedures in libtirpc especially if
>> IPV6 support is needed...
>>
>> So I'm a bit confused on what you mean by "NIS baggage"
>> in the libtirpc package.
>
> you cannot build libtirpc on a system that doesnt provide NIS  
> functionality.
> realistic RPC usage today is NFS related services only (i.e. a NFS  
> client
> mounting a share on a NFS server).

Mike, it would help if you could provide the build output so we can  
see exactly what's failing.

> i might be missing something (since i'm no
> RPC/NIS expert), but if this scenario doesnt require NIS in any way,  
> then
> having libtirpc require/use it is bloat that should have an option  
> to disable.

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

Re: libtirpc and nis

[Mike Frysinger]

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

On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
> > On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
> >> Mike Frysinger wrote:
> >>> the libtirpc package is self described as a "standalone package".  i
> >>> wonder how far that actually goes.  wrt NIS, it requires the
> >>> system C
> >>> library to provide NIS functionality or you get a build failure in
> >>> a few
> >>> files.  would be nice if libtirpc were usable without any NIS
> >>> baggage at
> >>> all.
> >>
> >> NIS used RPC procedures to communicate. As it stands today
> >> NIS is currently using the RPC procedures glibc. In the
> >> future there is a very good chance that NIS will start
> >> using the RPC procedures in libtirpc especially if
> >> IPV6 support is needed...
> >>
> >> So I'm a bit confused on what you mean by "NIS baggage"
> >> in the libtirpc package.
> >
> > you cannot build libtirpc on a system that doesnt provide NIS
> > functionality.
> > realistic RPC usage today is NFS related services only (i.e. a NFS
> > client
> > mounting a share on a NFS server).
>
> Mike, it would help if you could provide the build output so we can
> see exactly what's failing.

libtirpc does not provide rpcsvc/nis.h
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: libtirpc and nis

[Steve Dickson]

Mike Frysinger wrote:
> On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
>> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
>>> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
>>>> Mike Frysinger wrote:
>>>>> the libtirpc package is self described as a "standalone package".  i
>>>>> wonder how far that actually goes.  wrt NIS, it requires the
>>>>> system C
>>>>> library to provide NIS functionality or you get a build failure in
>>>>> a few
>>>>> files.  would be nice if libtirpc were usable without any NIS
>>>>> baggage at
>>>>> all.
>>>> NIS used RPC procedures to communicate. As it stands today
>>>> NIS is currently using the RPC procedures glibc. In the
>>>> future there is a very good chance that NIS will start
>>>> using the RPC procedures in libtirpc especially if
>>>> IPV6 support is needed...
>>>>
>>>> So I'm a bit confused on what you mean by "NIS baggage"
>>>> in the libtirpc package.
>>> you cannot build libtirpc on a system that doesnt provide NIS
>>> functionality.
>>> realistic RPC usage today is NFS related services only (i.e. a NFS
>>> client
>>> mounting a share on a NFS server).
>> Mike, it would help if you could provide the build output so we can
>> see exactly what's failing.
> 
> libtirpc does not provide rpcsvc/nis.h

Hmm... I wonder what it would take to incorporate that file into
libitrpc... 

steved.
 

Re: libtirpc and nis

[Trond Myklebust]

On Thu, 2009-06-04 at 06:03 -0400, Steve Dickson wrote:
> 
> Mike Frysinger wrote:
> > On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
> >> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
> >>> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
> >>>> Mike Frysinger wrote:
> >>>>> the libtirpc package is self described as a "standalone package".  i
> >>>>> wonder how far that actually goes.  wrt NIS, it requires the
> >>>>> system C
> >>>>> library to provide NIS functionality or you get a build failure in
> >>>>> a few
> >>>>> files.  would be nice if libtirpc were usable without any NIS
> >>>>> baggage at
> >>>>> all.
> >>>> NIS used RPC procedures to communicate. As it stands today
> >>>> NIS is currently using the RPC procedures glibc. In the
> >>>> future there is a very good chance that NIS will start
> >>>> using the RPC procedures in libtirpc especially if
> >>>> IPV6 support is needed...
> >>>>
> >>>> So I'm a bit confused on what you mean by "NIS baggage"
> >>>> in the libtirpc package.
> >>> you cannot build libtirpc on a system that doesnt provide NIS
> >>> functionality.
> >>> realistic RPC usage today is NFS related services only (i.e. a NFS
> >>> client
> >>> mounting a share on a NFS server).
> >> Mike, it would help if you could provide the build output so we can
> >> see exactly what's failing.
> > 
> > libtirpc does not provide rpcsvc/nis.h
> 
> Hmm... I wonder what it would take to incorporate that file into
> libitrpc... 

rpcgen support. We already have the nis.x file in glibc's copy of the
rpcsvc directory.

Trond

Re: libtirpc and nis

[Steve Dickson]

Trond Myklebust wrote:
> On Thu, 2009-06-04 at 06:03 -0400, Steve Dickson wrote:
>> Mike Frysinger wrote:
>>> On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
>>>> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
>>>>> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
>>>>>> Mike Frysinger wrote:
>>>>>>> the libtirpc package is self described as a "standalone package".  i
>>>>>>> wonder how far that actually goes.  wrt NIS, it requires the
>>>>>>> system C
>>>>>>> library to provide NIS functionality or you get a build failure in
>>>>>>> a few
>>>>>>> files.  would be nice if libtirpc were usable without any NIS
>>>>>>> baggage at
>>>>>>> all.
>>>>>> NIS used RPC procedures to communicate. As it stands today
>>>>>> NIS is currently using the RPC procedures glibc. In the
>>>>>> future there is a very good chance that NIS will start
>>>>>> using the RPC procedures in libtirpc especially if
>>>>>> IPV6 support is needed...
>>>>>>
>>>>>> So I'm a bit confused on what you mean by "NIS baggage"
>>>>>> in the libtirpc package.
>>>>> you cannot build libtirpc on a system that doesnt provide NIS
>>>>> functionality.
>>>>> realistic RPC usage today is NFS related services only (i.e. a NFS
>>>>> client
>>>>> mounting a share on a NFS server).
>>>> Mike, it would help if you could provide the build output so we can
>>>> see exactly what's failing.
>>> libtirpc does not provide rpcsvc/nis.h
>> Hmm... I wonder what it would take to incorporate that file into
>> libitrpc... 
> 
> rpcgen support. We already have the nis.x file in glibc's copy of the
> rpcsvc directory.
I'm thinking more of licensing issues..

steved.
 

Re: libtirpc and nis

[Trond Myklebust]

On Thu, 2009-06-04 at 10:15 -0400, Steve Dickson wrote:
> 
> Trond Myklebust wrote:
> > On Thu, 2009-06-04 at 06:03 -0400, Steve Dickson wrote:
> >> Mike Frysinger wrote:
> >>> On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
> >>>> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
> >>>>> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
> >>>>>> Mike Frysinger wrote:
> >>>>>>> the libtirpc package is self described as a "standalone package".  i
> >>>>>>> wonder how far that actually goes.  wrt NIS, it requires the
> >>>>>>> system C
> >>>>>>> library to provide NIS functionality or you get a build failure in
> >>>>>>> a few
> >>>>>>> files.  would be nice if libtirpc were usable without any NIS
> >>>>>>> baggage at
> >>>>>>> all.
> >>>>>> NIS used RPC procedures to communicate. As it stands today
> >>>>>> NIS is currently using the RPC procedures glibc. In the
> >>>>>> future there is a very good chance that NIS will start
> >>>>>> using the RPC procedures in libtirpc especially if
> >>>>>> IPV6 support is needed...
> >>>>>>
> >>>>>> So I'm a bit confused on what you mean by "NIS baggage"
> >>>>>> in the libtirpc package.
> >>>>> you cannot build libtirpc on a system that doesnt provide NIS
> >>>>> functionality.
> >>>>> realistic RPC usage today is NFS related services only (i.e. a NFS
> >>>>> client
> >>>>> mounting a share on a NFS server).
> >>>> Mike, it would help if you could provide the build output so we can
> >>>> see exactly what's failing.
> >>> libtirpc does not provide rpcsvc/nis.h
> >> Hmm... I wonder what it would take to incorporate that file into
> >> libitrpc... 
> > 
> > rpcgen support. We already have the nis.x file in glibc's copy of the
> > rpcsvc directory.
> I'm thinking more of licensing issues..

I know. I'm saying that we're already distributing it through glibc. We
don't need to distribute it again in libtirpc; we can just make use of
the existing .x file.

Trond

Re: libtirpc and nis

[Chuck Lever]

On Jun 4, 2009, at 6:03 AM, Steve Dickson wrote:
> Mike Frysinger wrote:
>> On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
>>> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
>>>> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
>>>>> Mike Frysinger wrote:
>>>>>> the libtirpc package is self described as a "standalone  
>>>>>> package".  i
>>>>>> wonder how far that actually goes.  wrt NIS, it requires the
>>>>>> system C
>>>>>> library to provide NIS functionality or you get a build failure  
>>>>>> in
>>>>>> a few
>>>>>> files.  would be nice if libtirpc were usable without any NIS
>>>>>> baggage at
>>>>>> all.
>>>>> NIS used RPC procedures to communicate. As it stands today
>>>>> NIS is currently using the RPC procedures glibc. In the
>>>>> future there is a very good chance that NIS will start
>>>>> using the RPC procedures in libtirpc especially if
>>>>> IPV6 support is needed...
>>>>>
>>>>> So I'm a bit confused on what you mean by "NIS baggage"
>>>>> in the libtirpc package.
>>>> you cannot build libtirpc on a system that doesnt provide NIS
>>>> functionality.
>>>> realistic RPC usage today is NFS related services only (i.e. a NFS
>>>> client
>>>> mounting a share on a NFS server).
>>> Mike, it would help if you could provide the build output so we can
>>> see exactly what's failing.
>>
>> libtirpc does not provide rpcsvc/nis.h
>
> Hmm... I wonder what it would take to incorporate that file into
> libitrpc...

Does auth_des require the use of the NIS time service?  Why not  
replace this with something else?

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

Re: libtirpc and nis

[Chuck Lever]

On Jun 4, 2009, at 6:03 AM, Steve Dickson wrote:

>
>
> Mike Frysinger wrote:
>> On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
>>> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
>>>> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
>>>>> Mike Frysinger wrote:
>>>>>> the libtirpc package is self described as a "standalone  
>>>>>> package".  i
>>>>>> wonder how far that actually goes.  wrt NIS, it requires the
>>>>>> system C
>>>>>> library to provide NIS functionality or you get a build failure  
>>>>>> in
>>>>>> a few
>>>>>> files.  would be nice if libtirpc were usable without any NIS
>>>>>> baggage at
>>>>>> all.
>>>>> NIS used RPC procedures to communicate. As it stands today
>>>>> NIS is currently using the RPC procedures glibc. In the
>>>>> future there is a very good chance that NIS will start
>>>>> using the RPC procedures in libtirpc especially if
>>>>> IPV6 support is needed...
>>>>>
>>>>> So I'm a bit confused on what you mean by "NIS baggage"
>>>>> in the libtirpc package.
>>>> you cannot build libtirpc on a system that doesnt provide NIS
>>>> functionality.
>>>> realistic RPC usage today is NFS related services only (i.e. a NFS
>>>> client
>>>> mounting a share on a NFS server).
>>> Mike, it would help if you could provide the build output so we can
>>> see exactly what's failing.
>>
>> libtirpc does not provide rpcsvc/nis.h
>
> Hmm... I wonder what it would take to incorporate that file into
> libitrpc...

Alternately, you could disable auth_des on systems that don't already  
have NIS.

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

Re: libtirpc and nis

[Trond Myklebust]

On Thu, 2009-06-04 at 10:28 -0400, Chuck Lever wrote:
> On Jun 4, 2009, at 6:03 AM, Steve Dickson wrote:
> 
> >
> >
> > Mike Frysinger wrote:
> >> On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
> >>> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
> >>>> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
> >>>>> Mike Frysinger wrote:
> >>>>>> the libtirpc package is self described as a "standalone  
> >>>>>> package".  i
> >>>>>> wonder how far that actually goes.  wrt NIS, it requires the
> >>>>>> system C
> >>>>>> library to provide NIS functionality or you get a build failure  
> >>>>>> in
> >>>>>> a few
> >>>>>> files.  would be nice if libtirpc were usable without any NIS
> >>>>>> baggage at
> >>>>>> all.
> >>>>> NIS used RPC procedures to communicate. As it stands today
> >>>>> NIS is currently using the RPC procedures glibc. In the
> >>>>> future there is a very good chance that NIS will start
> >>>>> using the RPC procedures in libtirpc especially if
> >>>>> IPV6 support is needed...
> >>>>>
> >>>>> So I'm a bit confused on what you mean by "NIS baggage"
> >>>>> in the libtirpc package.
> >>>> you cannot build libtirpc on a system that doesnt provide NIS
> >>>> functionality.
> >>>> realistic RPC usage today is NFS related services only (i.e. a NFS
> >>>> client
> >>>> mounting a share on a NFS server).
> >>> Mike, it would help if you could provide the build output so we can
> >>> see exactly what's failing.
> >>
> >> libtirpc does not provide rpcsvc/nis.h
> >
> > Hmm... I wonder what it would take to incorporate that file into
> > libitrpc...
> 
> Alternately, you could disable auth_des on systems that don't already  
> have NIS.

Why? It isn't using any NIS functionality here. All that is being done
is to store information in a structure. The following definition is
literally all that should be needed in order to make auth_des work:

typedef char *nis_name;
struct nis_server {
        nis_name name;
        struct {
                u_int ep_len;
                endpoint *ep_val;
        } ep;
        uint32_t key_type;
        netobj pkey;
};
typedef struct nis_server nis_server;

If you want, I can write you a spec, and you can sit down and reverse
engineer it...

Trond.

Re: libtirpc and nis

[Chuck Lever]

On Jun 4, 2009, at 11:17 AM, Trond Myklebust wrote:
> On Thu, 2009-06-04 at 10:28 -0400, Chuck Lever wrote:
>> On Jun 4, 2009, at 6:03 AM, Steve Dickson wrote:
>>> Mike Frysinger wrote:
>>>> On Wednesday 03 June 2009 19:59:09 Chuck Lever wrote:
>>>>> On Jun 3, 2009, at 6:44 PM, Mike Frysinger wrote:
>>>>>> On Wednesday 03 June 2009 11:14:44 Steve Dickson wrote:
>>>>>>> Mike Frysinger wrote:
>>>>>>>> the libtirpc package is self described as a "standalone
>>>>>>>> package".  i
>>>>>>>> wonder how far that actually goes.  wrt NIS, it requires the
>>>>>>>> system C
>>>>>>>> library to provide NIS functionality or you get a build failure
>>>>>>>> in
>>>>>>>> a few
>>>>>>>> files.  would be nice if libtirpc were usable without any NIS
>>>>>>>> baggage at
>>>>>>>> all.
>>>>>>> NIS used RPC procedures to communicate. As it stands today
>>>>>>> NIS is currently using the RPC procedures glibc. In the
>>>>>>> future there is a very good chance that NIS will start
>>>>>>> using the RPC procedures in libtirpc especially if
>>>>>>> IPV6 support is needed...
>>>>>>>
>>>>>>> So I'm a bit confused on what you mean by "NIS baggage"
>>>>>>> in the libtirpc package.
>>>>>> you cannot build libtirpc on a system that doesnt provide NIS
>>>>>> functionality.
>>>>>> realistic RPC usage today is NFS related services only (i.e. a  
>>>>>> NFS
>>>>>> client
>>>>>> mounting a share on a NFS server).
>>>>> Mike, it would help if you could provide the build output so we  
>>>>> can
>>>>> see exactly what's failing.
>>>>
>>>> libtirpc does not provide rpcsvc/nis.h
>>>
>>> Hmm... I wonder what it would take to incorporate that file into
>>> libitrpc...
>>
>> Alternately, you could disable auth_des on systems that don't already
>> have NIS.
>
> Why? It isn't using any NIS functionality here. All that is being done
> is to store information in a structure.

src/auth_time.c appears to assume IPv4.  It handles its own universal  
address translation, duplicating code that can be found in other parts  
of the library.  The AUTH_DES code might call rpcb_gettime() instead,  
and simply drop auth_time.c, but the RPCB_GETTIME call won't work  
against our legacy portmapper.  It looks like no-one has visited this  
code in quite some time.

In addition, my impression was that AUTH_DES, the only caller of  
__rpc_get_time_offset, has been deprecated in favor of AUTH_GSS.  I  
don't think Linux kernel RPC supports AUTH_DES, for instance.

So, why spend any effort trying to make this work?  I'm suggesting we  
can shit-can AUTH_DES support in libtirpc at least if NIS headers  
aren't present on the system, and perhaps even for all configurations.

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

Re: libtirpc and nis

[Steve Dickson]

Trond Myklebust wrote:
>>>>> libtirpc does not provide rpcsvc/nis.h
>>>> Hmm... I wonder what it would take to incorporate that file into
>>>> libitrpc... 
>>> rpcgen support. We already have the nis.x file in glibc's copy of the
>>> rpcsvc directory.
>> I'm thinking more of licensing issues..
> 
> I know. I'm saying that we're already distributing it through glibc. We
> don't need to distribute it again in libtirpc; we can just make use of
> the existing .x file.
Understood... But the ultimate goal here is to completely wean ourself
from the any of the glibc RPC code... so having similar header files
in a couple places is the price we are going to have to pay... IMHO...

steved.