Re: Removal of RPC from glibc

"Dustin J. Mitchell" <[email protected]> Mon, 8 Jan 2018 15:57:57 -0500
Newsgroups gmane.comp.archivers.amanda.devel
Message-ID <CAJtE5vRFn-Qv_TzvRGncK6X+jTM9veRfJPKUq9Nip0qN4YRgLA@mail.gmail.com>
NDMP is a protocol for controlling remote storage devices over TCP.  It
allows Amanda to "stream" a backup from, say, a NetApp filer in one rack to
a NetApp tape drive in another.  It's pretty specific to Netapp, as far as
I can tell -- it was originally developed as a standard, but at the time I
wrote that support, nothing else used it and there was only one (reference)
implementation.

This was developed by Zmanda for customers who were running large NetApp
installations.  I'm not sure if it ever "caught on" among the
non-enterprise users.

I think building by default without NDMP is probably fine.

I'm not sure were Amanda bugs are tracked these days, but it'd be good to
get something on file to support RPC via libtirpc as you suggest -- that
said, i don't think it's urgent.

Dustin

2018-01-08 15:32 GMT-05:00 Jason L Tibbitts III <[email protected]>:

> So glibc upstream has removed the RPC interfaces, and this has made its
> way into Fedora rawhide.  (It's actually been on its way out for many
> years and was "obsoleted" in glibc 2.14 which was releases in 2011.)  In
> any case, after this change, amanda fails to build unless I pass
> --without-ndmp.
>
> Configure as expected fails to find various RPC-related things:
>
> checking for rpcgen... no
> checking rpc/rpc.h usability... no
> checking rpc/rpc.h presence... no
> checking for rpc/rpc.h... no
>
> So, my questions:
>
> What do we lose by not shipping ndmp (amndmjob/ndmjob) in Fedora?  I
> honestly don't even know what it is, but I don't want to just remove it
> without understanding what it does.
>
> Shouldn't --without-ndmp turn on automatically if there's no rpc headers
> instead of failing the compilation?
>
> ndmos_glib.h:51:2: error: #error rpc/rpc.h is required to compile ndmp-src
>
> And finally, the solution is just to use libtirpc, but it puts its
> headers in /usr/include/tirpc/rpc.  This could change in the future
> since glibc is no longer conflicting, though.  Best would be to use
> pkgconfig to get the proper locations for the libtirpc things, but
> hacking autoconf to do that is a bit beyond me.
>
>  - J<
>