glibc/libtirpc and future of client RPC code

glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

Hi,

that's a mail for RFC, advice, ideas, or however you want to
call it.
And since it affects glibc and libtirpc, I decided to do a crosspost
on both developer mailing lists.

Last year I implemented the NIS protocol for IPv6. With libtirpc,
this was no problem on server side, ypserv/ypbind are working fine.

But now I run into a lot of problems on the client side.
In the end, this step is quite easy: link the NIS client code
against libtirpc and this is it more or less. The public
interfaces of the client code will stay the same, no API or
ABI changes. The only difference is, that suddenly all applications
using this interfaces can speak with a IPv6 NIS server.
But: the NIS client code is part of glibc, which only comes
with the IPv4 only SunRPC implementation.

So the NIS client code (libnsl, libnss_nis.so, libnss_nisplus.so)
from glibc needs to be moved somewhere else and somehow we need to
be able to disable that code in glibc then, or at least make it
runtime only.

Since libtirpc has code calling YP and NIS+ functions, which are
currently disabled, moving it to libtirpc would be one choice. But
I don't know if we don't run into a license conflict here between the
glibc and tirpc licenses. The second disadvantage is that this would
mean to touch all applications linked against libnsl and calling
yp_*() functions. That's something I want to avoid.

The second solution I see is, to move libnsl, libnnss_nis and 
libnss_nisplus to an own project independent of glibc and link
them against libtirpc. I have already a working proof of
concept, so that's not a problem.
We could use the same soname for libnsl, and we wouldn't even
need to recompile any client library. Or we could bump the
version number and need to recompile, both would be ok for me.
But I would like to avoid to find another name for that library,
since this means, touching all configure files of all applications
using NIS. I tried that as first, but gave up since this is not
really doable.


What are your opinions? Or do you see even another solution
for this problem? And are there more subsystems into glibc,
which currently use SunRPC but who would benefit from TI-RPC?

Thanks,
  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Re: glibc/libtirpc and future of client RPC code

[Mike Frysinger]

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

On 24 Jun 2015 14:44, Thorsten Kukuk wrote:
> that's a mail for RFC, advice, ideas, or however you want to
> call it.
> And since it affects glibc and libtirpc, I decided to do a crosspost
> on both developer mailing lists.
> 
> Last year I implemented the NIS protocol for IPv6. With libtirpc,
> this was no problem on server side, ypserv/ypbind are working fine.
> 
> But now I run into a lot of problems on the client side.
> In the end, this step is quite easy: link the NIS client code
> against libtirpc and this is it more or less. The public
> interfaces of the client code will stay the same, no API or
> ABI changes. The only difference is, that suddenly all applications
> using this interfaces can speak with a IPv6 NIS server.
> But: the NIS client code is part of glibc, which only comes
> with the IPv4 only SunRPC implementation.
> 
> So the NIS client code (libnsl, libnss_nis.so, libnss_nisplus.so)
> from glibc needs to be moved somewhere else and somehow we need to
> be able to disable that code in glibc then, or at least make it
> runtime only.

pretty sure the --disable-obsolete-rpc flag already accomplishes this.  the 
problem is that libtirpc is not a full replacement yet for the API in glibc.

> Since libtirpc has code calling YP and NIS+ functions, which are
> currently disabled, moving it to libtirpc would be one choice. But
> I don't know if we don't run into a license conflict here between the
> glibc and tirpc licenses. The second disadvantage is that this would
> mean to touch all applications linked against libnsl and calling
> yp_*() functions. That's something I want to avoid.

the sunrpc code in glibc should still be under its original license, so i don't 
think moving it over should be a problem.
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

On Thu, Jun 25, Mike Frysinger wrote:

> On 24 Jun 2015 14:44, Thorsten Kukuk wrote:
> > that's a mail for RFC, advice, ideas, or however you want to
> > call it.
> > And since it affects glibc and libtirpc, I decided to do a crosspost
> > on both developer mailing lists.
> > 
> > Last year I implemented the NIS protocol for IPv6. With libtirpc,
> > this was no problem on server side, ypserv/ypbind are working fine.
> > 
> > But now I run into a lot of problems on the client side.
> > In the end, this step is quite easy: link the NIS client code
> > against libtirpc and this is it more or less. The public
> > interfaces of the client code will stay the same, no API or
> > ABI changes. The only difference is, that suddenly all applications
> > using this interfaces can speak with a IPv6 NIS server.
> > But: the NIS client code is part of glibc, which only comes
> > with the IPv4 only SunRPC implementation.
> > 
> > So the NIS client code (libnsl, libnss_nis.so, libnss_nisplus.so)
> > from glibc needs to be moved somewhere else and somehow we need to
> > be able to disable that code in glibc then, or at least make it
> > runtime only.
> 
> pretty sure the --disable-obsolete-rpc flag already accomplishes this.  the 
> problem is that libtirpc is not a full replacement yet for the API in glibc.

Thanks, I will look at that.

> > Since libtirpc has code calling YP and NIS+ functions, which are
> > currently disabled, moving it to libtirpc would be one choice. But
> > I don't know if we don't run into a license conflict here between the
> > glibc and tirpc licenses. The second disadvantage is that this would
> > mean to touch all applications linked against libnsl and calling
> > yp_*() functions. That's something I want to avoid.
> 
> the sunrpc code in glibc should still be under its original license, so i don't 
> think moving it over should be a problem.

It's not about the sunrpc code in glibc, it's about the code in
the nis directory of glibc. This code depends on RPC, but needs
to be compiled/linked against TI-RPC, not SunRPC.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Steve Dickson]

On 06/25/2015 06:05 AM, Mike Frysinger wrote:
>> Since libtirpc has code calling YP and NIS+ functions, which are
>> > currently disabled, moving it to libtirpc would be one choice. But
>> > I don't know if we don't run into a license conflict here between the
>> > glibc and tirpc licenses. The second disadvantage is that this would
>> > mean to touch all applications linked against libnsl and calling
>> > yp_*() functions. That's something I want to avoid.
> the sunrpc code in glibc should still be under its original license, so i don't 
> think moving it over should be a problem.
I was thinking the same thing... 

steved.

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Chuck Lever]

> On Jun 24, 2015, at 8:44 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> 
> 
> Hi,
> 
> that's a mail for RFC, advice, ideas, or however you want to
> call it.
> And since it affects glibc and libtirpc, I decided to do a crosspost
> on both developer mailing lists.
> 
> Last year I implemented the NIS protocol for IPv6. With libtirpc,
> this was no problem on server side, ypserv/ypbind are working fine.
> 
> But now I run into a lot of problems on the client side.
> In the end, this step is quite easy: link the NIS client code
> against libtirpc and this is it more or less. The public
> interfaces of the client code will stay the same, no API or
> ABI changes. The only difference is, that suddenly all applications
> using this interfaces can speak with a IPv6 NIS server.
> But: the NIS client code is part of glibc, which only comes
> with the IPv4 only SunRPC implementation.
> 
> So the NIS client code (libnsl, libnss_nis.so, libnss_nisplus.so)
> from glibc needs to be moved somewhere else and somehow we need to
> be able to disable that code in glibc then, or at least make it
> runtime only.
> 
> Since libtirpc has code calling YP and NIS+ functions, which are
> currently disabled, moving it to libtirpc would be one choice. But
> I don't know if we don't run into a license conflict here between the
> glibc and tirpc licenses. The second disadvantage is that this would
> mean to touch all applications linked against libnsl and calling
> yp_*() functions. That's something I want to avoid.
> 
> The second solution I see is, to move libnsl, libnnss_nis and 
> libnss_nisplus to an own project independent of glibc and link
> them against libtirpc. I have already a working proof of
> concept, so that's not a problem.
> We could use the same soname for libnsl, and we wouldn't even
> need to recompile any client library. Or we could bump the
> version number and need to recompile, both would be ok for me.
> But I would like to avoid to find another name for that library,
> since this means, touching all configure files of all applications
> using NIS. I tried that as first, but gave up since this is not
> really doable.
> 
> 
> What are your opinions? Or do you see even another solution
> for this problem?

I like the second solution: move YP/NIS/NIS+ to one or more
separate upstream projects, and package them independently of
glibc and libtirpc.

What code in libtirpc calls on YP and NIS+ ? Should that be
moved as well?

> And are there more subsystems into glibc,
> which currently use SunRPC but who would benefit from TI-RPC?


--
Chuck Lever
chucklever@gmail.com

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

On Thu, Jun 25, Chuck Lever wrote:

> I like the second solution: move YP/NIS/NIS+ to one or more
> separate upstream projects, and package them independently of
> glibc and libtirpc.

Yes, that's currently my prefered solution, too.
libnss_nis and libnss_nisplus needs to be a drop in replacement,
libnsl could have a higher version number and be installed
in parallel.
This would mean we would need a switch to disable building
the nis directory in glibc, or at least to disable building
and installing libnss_nis and libnss_nisplus and installing
the libnsl header files.

> What code in libtirpc calls on YP and NIS+ ? Should that be
> moved as well?

grep for "YP".
Currently I see src/netnamer.c, src/getrpcent.c, src/getpublickey.c.

netnamer.c: Lookup of /etc/netid via NIS. Don't know if we need that.

src/getrpcent.c: We use the glibc function already if available, don't
know on which OS we compile our own version.

src/getpublickey.c: Similar to netnamer.c: lookup of publickeys
in NIS maps, not only local.

That code is needed for auth_des, so we cannot move it in another library.

  Thorsten

> > And are there more subsystems into glibc,
> > which currently use SunRPC but who would benefit from TI-RPC?
> 
> 
> --
> Chuck Lever
> chucklever@gmail.com
> 
> 

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Ondřej Bílka]

On Thu, Jun 25, 2015 at 05:33:58PM +0200, Thorsten Kukuk wrote:
> On Thu, Jun 25, Chuck Lever wrote:
> 
> > I like the second solution: move YP/NIS/NIS+ to one or more
> > separate upstream projects, and package them independently of
> > glibc and libtirpc.
> 
> Yes, that's currently my prefered solution, too.
> libnss_nis and libnss_nisplus needs to be a drop in replacement,
> libnsl could have a higher version number and be installed
> in parallel.
> This would mean we would need a switch to disable building
> the nis directory in glibc, or at least to disable building
> and installing libnss_nis and libnss_nisplus and installing
> the libnsl header files.
> 
> > What code in libtirpc calls on YP and NIS+ ? Should that be
> > moved as well?
> 
That would be nice. As glibc libnns_nis are in maintainance mode if you
could make stable replacement we would welcome removing these and
telling distros to add dependency on your library for future version.

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Chuck Lever]

Sigh. Try again with a text version.


> On Jun 25, 2015, at 11:33 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> 
> On Thu, Jun 25, Chuck Lever wrote:
> 
>> I like the second solution: move YP/NIS/NIS+ to one or more
>> separate upstream projects, and package them independently of
>> glibc and libtirpc.
> 
> Yes, that's currently my prefered solution, too.
> libnss_nis and libnss_nisplus needs to be a drop in replacement,
> libnsl could have a higher version number and be installed
> in parallel.
> This would mean we would need a switch to disable building
> the nis directory in glibc, or at least to disable building
> and installing libnss_nis and libnss_nisplus and installing
> the libnsl header files.
> 
>> What code in libtirpc calls on YP and NIS+ ? Should that be
>> moved as well?
> 
> grep for "YP".
> Currently I see src/netnamer.c, src/getrpcent.c, src/getpublickey.c.
> 
> netnamer.c: Lookup of /etc/netid via NIS. Don't know if we need that.

I think libtirpc is obligated to provide netname2host() and netname2user()
because these are declared in rpc/auth.h. If YP on Linux doesn't support
/etc/netid, I don't see why Linux libtirpc's version of these functions
would need to.

Perhaps it is safe to simply remove getnetid() and its call sites from
netnamer.c?

> src/getrpcent.c: We use the glibc function already if available, don't
> know on which OS we compile our own version.

According to commit 489912cad88f musl libc does not provide them.

AFAICT nothing in libtirpc calls these functions. They are provided only
for external library consumers. If these functions dip their hands into
the YP maps, then maybe they should be removed from glibc and libtirpc
and be provided by libnsl instead.


> src/getpublickey.c: Similar to netnamer.c: lookup of publickeys
> in NIS maps, not only local.
> 
> That code is needed for auth_des, so we cannot move it in another library.

Note: libtirpc looks incomplete here: there's no getsecretkey() function
defined in libtirpc.

Is there a problem with linking libtirpc with libnsl, which would provide the
NIS lookup functions? I suppose at that point this is equivalent to adding
all of YP/NIS to libtirpc.

It appears that glibc solved these issues by simply piling YP/NIS and
SunRPC into the same library. Solaris might take the same approach,
as user space TI-RPC appears to be in libnsl with YP/NIS.

Or, consider having libtirpc dynamically load libnsl if one of the
auth-des-related functions is invoked by a libtirpc consumer.


--
Chuck Lever
chucklever@gmail.com

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

On Thu, Jun 25, Ondřej Bílka wrote:

> On Thu, Jun 25, 2015 at 05:33:58PM +0200, Thorsten Kukuk wrote:

> > This would mean we would need a switch to disable building
> > the nis directory in glibc, or at least to disable building
> > and installing libnss_nis and libnss_nisplus and installing
> > the libnsl header files.
> > 
> > > What code in libtirpc calls on YP and NIS+ ? Should that be
> > > moved as well?
> > 
> That would be nice. As glibc libnns_nis are in maintainance mode if you
> could make stable replacement we would welcome removing these and
> telling distros to add dependency on your library for future version.

I worked on that last week:

https://github.com/thkukuk/libnsl
https://github.com/thkukuk/libnss_compat
https://github.com/thkukuk/libnss_nis

The NIS+ stuff is not yet complete, I need to rewrite
the callback function for TI-RPC.
Else it's currently only building with TI-RPC, not SunRPC from
glibc, but that should be easy to solve.

But the NIS and compat stuff is working fine with TI-RPC.

Oh, and I forgot: of course you need the latest libtirpc from git
plus some additional patches I did send upstream, but not yet added ...

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Re: glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

On Thu, Jun 25, Mike Frysinger wrote:

> pretty sure the --disable-obsolete-rpc flag already accomplishes this.  the 
> problem is that libtirpc is not a full replacement yet for the API in glibc.

Yes, I learned that now, too, even after fixing some functions
and adding missing compat functions, there are still quite a lot
of small, but important changes. Especially the naming of variables
in structs :(

Is there somewhere a list or something similar with the biggest problems
found out when tryint to disable sunrpc in glibc by default?
With my latest TI-RPC patches, I only see two remaining problems, 
both not solveable and needs adjustement in the applications:
1. programs trying to hook into svc_run().
2. different naming of some variables.

The later may be solveable with some defines.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Chuck Lever]

Hi Thorsten-


> On Jul 6, 2015, at 8:31 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> 
> On Thu, Jun 25, Mike Frysinger wrote:
> 
>> pretty sure the --disable-obsolete-rpc flag already accomplishes this.  the 
>> problem is that libtirpc is not a full replacement yet for the API in glibc.
> 
> Yes, I learned that now, too, even after fixing some functions
> and adding missing compat functions, there are still quite a lot
> of small, but important changes. Especially the naming of variables
> in structs :(
> 
> Is there somewhere a list or something similar with the biggest problems
> found out when tryint to disable sunrpc in glibc by default?
> With my latest TI-RPC patches, I only see two remaining problems, 
> both not solveable and needs adjustement in the applications:
> 1. programs trying to hook into svc_run().
> 2. different naming of some variables.

I’d like to hear details about both issues.

I think everyone on -devel wants to see a libtirpc on Linux that is
fully compatible with glibc. We are waiting for reports of the most
critical issues in this area, so please keep posting.


> The later may be solveable with some defines.

--
Chuck Lever
chucklever@gmail.com

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

Hi Chuck,

On Mon, Jul 06, Chuck Lever wrote:


> > On Jul 6, 2015, at 8:31 AM, Thorsten Kukuk <kukuk@suse.de> wrote:

> > With my latest TI-RPC patches, I only see two remaining problems, 
> > both not solveable and needs adjustement in the applications:
> > 1. programs trying to hook into svc_run().
> > 2. different naming of some variables.
> 

For 2:
sunrpc: rpc/svc.h, struct SVCXPRT is using int xp_sock;
tirpc: rpc/svc.h, struct SVCXPRT is using int xp_fd;

For 1:
We are missing svc_max_pollfd. glibc and Solaris have that.
Something "pseudo" code from the NIS+ code, but some rstatd 
implementations are doing something similar:

  for (;;)
    {
      struct pollfd my_pollfd[svc_max_pollfd];
      int i;

      for (i = 0; i < svc_max_pollfd; ++i)
        {
          my_pollfd[i].fd = svc_pollfd[i].fd;
          my_pollfd[i].events = svc_pollfd[i].events;
          my_pollfd[i].revents = 0;
        }

      switch (i = TEMP_FAILURE_RETRY (poll (my_pollfd, svc_max_pollfd,
                                              25*1000)))
        {
        case -1:
          return NIS_CBERROR;
        case 0:
          if (clnt_call (...
          break;
        default:
          svc_getreq_poll (my_pollfd, i);
          if (data->nomore)
            return data->result;
        }
    }


Between, I found out that libtirpc is still using select,
while everybody else is using poll() today.
I think it's time to forward port the glibc code here.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Chuck Lever]

> On Jul 8, 2015, at 7:52 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> 
> 
> 
> Hi Chuck,
> 
> On Mon, Jul 06, Chuck Lever wrote:
> 
> 
>>> On Jul 6, 2015, at 8:31 AM, Thorsten Kukuk <kukuk@suse.de> wrote:
> 
>>> With my latest TI-RPC patches, I only see two remaining problems, 
>>> both not solveable and needs adjustement in the applications:
>>> 1. programs trying to hook into svc_run().
>>> 2. different naming of some variables.
>> 
> 
> For 2:
> sunrpc: rpc/svc.h, struct SVCXPRT is using int xp_sock;
> tirpc: rpc/svc.h, struct SVCXPRT is using int xp_fd;

Solaris has this in rpc/svc.h:

struct __svcxprt {
        int             xp_fd;
#define xp_sock         xp_fd
        ushort_t        xp_port;

That macro seems reasonable to add to libtirpc’s tirpc/rpc/svc.h.


> For 1:
> We are missing svc_max_pollfd. glibc and Solaris have that.
> Something "pseudo" code from the NIS+ code, but some rstatd 
> implementations are doing something similar:
> 
>  for (;;)
>    {
>      struct pollfd my_pollfd[svc_max_pollfd];
>      int i;
> 
>      for (i = 0; i < svc_max_pollfd; ++i)
>        {
>          my_pollfd[i].fd = svc_pollfd[i].fd;
>          my_pollfd[i].events = svc_pollfd[i].events;
>          my_pollfd[i].revents = 0;
>        }
> 
>      switch (i = TEMP_FAILURE_RETRY (poll (my_pollfd, svc_max_pollfd,
>                                              25*1000)))
>        {
>        case -1:
>          return NIS_CBERROR;
>        case 0:
>          if (clnt_call (...
>          break;
>        default:
>          svc_getreq_poll (my_pollfd, i);
>          if (data->nomore)
>            return data->result;
>        }
>    }

There is no svc_pollfd array either.


> Between, I found out that libtirpc is still using select,
> while everybody else is using poll() today.

The FreeBSD TI-RPC code, which is a direct ancestor of our
libtirpc, still uses select(3) in svc_run().


> I think it's time to forward port the glibc code here.

That would provide svc_pollfd and svc_max_pollfd. I can see a
strong compatibility argument for forward porting.


--
Chuck Lever
chucklever@gmail.com

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

On Wed, Jul 08, Chuck Lever wrote:

> > On Jul 8, 2015, at 7:52 AM, Thorsten Kukuk <kukuk@suse.de> wrote:

> > For 2:
> > sunrpc: rpc/svc.h, struct SVCXPRT is using int xp_sock;
> > tirpc: rpc/svc.h, struct SVCXPRT is using int xp_fd;
> 
> Solaris has this in rpc/svc.h:
> 
> struct __svcxprt {
>         int             xp_fd;
> #define xp_sock         xp_fd
>         ushort_t        xp_port;
> 
> That macro seems reasonable to add to libtirpc’s tirpc/rpc/svc.h.

I submitted a patch to fix that.


> There is no svc_pollfd array either.
> 
> 
> > Between, I found out that libtirpc is still using select,
> > while everybody else is using poll() today.
> 
> The FreeBSD TI-RPC code, which is a direct ancestor of our
> libtirpc, still uses select(3) in svc_run().

Even Solaris is using poll() and not select(). Looks like
glibcs svc_pollfd/svc_max_pollfd is coming from Solaris.

I will create a patch, but that will be binary incompatible :(

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

Hi,

On Thu, Jun 25, Ondřej Bílka wrote:

> That would be nice. As glibc libnns_nis are in maintainance mode if you
> could make stable replacement we would welcome removing these and
> telling distros to add dependency on your library for future version.

Ok, it took much longer than expected, at first I had to wait for a libtirpc release
containing all needed fixes and enhancements, and then had some time problems.
But now there are:

libnsl replacing libnsl from glibc/nis:
git: https://github.com/thkukuk/libnsl
tar archives: http://www.linux-nis.org/download/libnsl/

libnss_compat replacing glibc/nis/nss_compat. There are no changes
or functional differences, it's only standalone:
git: https://github.com/thkukuk/libnss_compat
tar archives: http://www.linux-nis.org/download/libnss_compat/

libnss_nis replacing glibc/nis/nss_nis. This version is now
using the new NIS protocol if compiled and linked against
above libnsl and libtirpc:
git: https://github.com/thkukuk/libnss_nis
tar archives: http://www.linux-nis.org/download/libnss_nis/

libnss_nisplus replacing glibc/nis/nss_nisplus. This required
much more changes than for the rest and I thought. It should
work, but I couldn't test it against a NIS+ server.
git: https://github.com/thkukuk/libnss_nisplus
tar archives: http://www.linux-nis.org/download/libnss_nisplus/

Means we can start replacing the glibc code with external versions.

I also think that libtirpc is now in a much better shape to be
able to replace glibc/sunrpc for new compiled binaries.
Would be interesting to know if and which problems there are
still, beside fixing all the configure/Makefile stuff.

Regards,
Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Roland McGrath]

> > src/getrpcent.c: We use the glibc function already if available, don't
> > know on which OS we compile our own version.
> 
> According to commit 489912cad88f musl libc does not provide them.
> 
> AFAICT nothing in libtirpc calls these functions. They are provided only
> for external library consumers. If these functions dip their hands into
> the YP maps, then maybe they should be removed from glibc and libtirpc
> and be provided by libnsl instead.

The existing glibc implementations use the nsswitch mechanism (as IIRC
these functions do on Solaris).  That can't really be implemented outside
of libc (unless we add a whole new public API for that).  It may well be
that nobody really cares about full nsswitch configurability for getrpc*
and they could be implemented elsewhere (in the new sunrpc library if files
only, or in the new YP implementation if files + YP/NIS+).  We certainly
would prefer to get rid of them from libc altogether along with all sunrpc
and YP related interfaces.  But if what users need is a new implementation
of exactly the same functionality the old libc implementation had, then
that might be difficult.  Fortunately, getrpc* is about the single least
troublesome thing in this whole mess, so if it just sticks around in libc
much longer than the rest, that's not really any burden to us.

Re: [Libtirpc-devel] glibc/libtirpc and future of client RPC code

[Thorsten Kukuk]

Hi,

On Fri, Mar 04, Roland McGrath wrote:

> > > src/getrpcent.c: We use the glibc function already if available, don't
> > > know on which OS we compile our own version.
> > 
> > According to commit 489912cad88f musl libc does not provide them.
> > 
> > AFAICT nothing in libtirpc calls these functions. They are provided only
> > for external library consumers. If these functions dip their hands into
> > the YP maps, then maybe they should be removed from glibc and libtirpc
> > and be provided by libnsl instead.
> 
> The existing glibc implementations use the nsswitch mechanism (as IIRC
> these functions do on Solaris).  That can't really be implemented outside
> of libc (unless we add a whole new public API for that).  It may well be
> that nobody really cares about full nsswitch configurability for getrpc*
> and they could be implemented elsewhere (in the new sunrpc library if files
> only, or in the new YP implementation if files + YP/NIS+). 

My first thought was: there is absolute no reason to put
/etc/rpc into LDAP/NIS/ or whatever else, so removing NSS support
and have only a "files" version in libtirpc would be fine with me.

But looking at our customer configurations/feedback, it looks like
quite a lot of companies are still distributiong /etc/rpc via network...
So we should not remove NSS support.

> We certainly
> would prefer to get rid of them from libc altogether along with all sunrpc
> and YP related interfaces.  But if what users need is a new implementation
> of exactly the same functionality the old libc implementation had, then
> that might be difficult.  Fortunately, getrpc* is about the single least
> troublesome thing in this whole mess, so if it just sticks around in libc
> much longer than the rest, that's not really any burden to us.

Looking at the code, I would let rpc/netdb.h and corresponding functions
stay in glibc.

  Thorsten

-- 
Thorsten Kukuk, Senior Architect SLES & Common Code Base
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)