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
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.
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
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
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
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.
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
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.
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
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
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
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.
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