In regard to: [Networker] Networker on RHEL 6., Yaron Zabary said (at...:
Recently we started to install RHEL 6 servers. It seems that there is
some problem with rpcbind and Networker 7.6SP2 (even with 7.6.2.3) on
this platform. If I run rpcinfo -p client, I cannot see that the
service is registered. Backups run correctly, but this seems like some
kind of a
problem. Has anyone seen this before or know of a patch for this issue
There's no patch that I'm aware of.
As you know, Fedora ditched "portmap" in favor of "rpcbind", and RHEL 6
follows suit. The problem is essentially caused by that change.
It's been years since I've done any rpc programming, but IIRC there are
different versions of the RPC protocol. If you run
rpcinfo -p rhel5_client
you'll see that the portmapper has "nsrexecd" registered as a version 1
RPC service. This is just a guess, but I'm guessing that the Linux
nsrexecd hasn't been updated to support new versions of the RPC location
protocol, so nsrexecd isn't able to register with rpcbind. Still,
nsrexecd reports the same thing on Solaris, and it successfully registers
with rpcbind there.
In any case, if nsrexecd can't register with the system-wide
portmap/rpcbind, it falls back to binding to its preferred port. It can
even act as a kind of mini-portmapper in some situations, but I doubt
that's what's happening here.
It would be nice if EMC would fix this, as we too would prefer to have
nsrexecd (and other Networker-related services -- none of the server or
storage node processes show up in rpcinfo on a RHEL 6.1-based NetWorker
server) successfully register with the system rpcbind. If you open a
ticket about the issue and share the incident #, I would be happy to add
our site to the list of sites interested in seeing the issue fixed.
We're also seeing complaints on RHEL 6.1 from nsrexecd about lack of
entropy in the random pool, but that's a separate issue.
RHEL 6.1 has been very stable for us so far, but NetWorker's support of
RHEL 6.1 appears to still need some tweaking.
Tim
