| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
The value is from the list general, call, auth, parse, all.
Most daemons recognise this in their dedicated section.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
The significant value of allowing this is that it means that
for default operation, systemd unit files do not need to pass any
options to any programs. The purpose of this will become apparent in
the next patch.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
| |
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
| |
Some options appear in the [lockd] section.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
POSIX.1-2008 only specifies that file descriptor numbers
from 0 to 9, inclusive, are supported. The number 200 works
in the bash shell, but not in dash. This patch changes the file
descriptor number from 200 to 9. Reported in Debian bug #848277
Signed-off-by: Daniel Pocock <daniel@pocock.pro>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
xstrdup() prints a messages and exits, except in statd where
is prints a message and fails. So there is no point printing
an extra message when xstrdup() fails, and except in statd,
no point calling exit() as well.
So remove some pointless code.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
To once and for all stop multiple rpc.statd from
being started (mostly in HA environments), use
flock to serialize the running of the script
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 76f8ce8c (statd: Update existing record if we receive SM_MON with
new cookie) added some logic to unconditionally delete some existing
on-disk monitor records. That works fine in an HA-NFS setup where
there's a good chance of monitor files being left around after service
failovers, but in the case where there isn't an existing monitor file
statd emits a scary looking message like this:
Jun 15 14:14:59 hostname rpc.statd[1368]: Failed to delete: could not
stat original file /var/lib/nfs/statd/sm/nfs.smayhew.test: No such file
or directory
That message can be suppressed.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If rpc.statd is running but slow to respond, mount.nfs will
run "start-statd" which might start a new statd. This is not a good
ideas as can result in lots of rpc.statds.
So inf start-statd check the pid file and if rpc.statd seems to be
running, exit with success.
(also "cd /" before running rpc.statd, just in case).
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to an empty
Certain name resolution misconfigurations (for example, a hosts file
entry with an ip address but no hostnames) can cause get_nameinfo() to
return an empty string in buf, which will lead to this cryptic failure:
Dec 7 09:37:44 hostname rpc.statd[8024]: Failed to insert: creating
/var/lib/nfs/statd/sm/: Is a directory
Dec 7 09:37:44 hostname rpc.statd[8024]: STAT_FAIL to
hostname.example.com for SM_MON of 192.168.1.2
Dec 7 09:37:44 hostname kernel: lockd: cannot monitor 192.168.1.2
It's better in that case to just go ahead and use the presentation
address instead.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
This prevents rpc.statd's in-memory (and on-disk) monitor lists from
winding up with multiple records for the same peer with outdated
cookie values. This happens in some HA-NFS configurations where
rpc.statd is always running.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a hack which uses the bottom-level RPC improperly as below
in the current statd implementation: insert a socket in the
svc_fdset without a corresponding transport handle
and passes the socket to the svc_getreqset subroutine,
this usage causes a segfault of statd on a huge amount of sm-notifications.
Fix the issue by separating the non-RPC-server socket from RPC
dispatcher.
Signed-off-by: Shan Hai <shan.hai@windriver.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tastky <tastky@gmail.com> reports:
> There appears to be a bug in nfs-utils exposed by musl, which
> makes rpc.statd loop with:
>
> my_svc_run() - select: Bad file descriptor
OpenGroup says getservbyport(3) is supposed to return NULL when
no entry exists for the specified port. But musl's getservbyport(3)
never returns NULL (likely a bug).
Thus statd_get_socket() tries bindresvport(3) 100 times, then gives
up and returns the last socket it created. This should work fine,
but there's a bug in the retry loop:
Rich Felker <dalias@libc.org> says:
> The logic bug is the count-down loop that closes all the temp
> sockets. In the case where the loop terminates via break, it
> leaves the last one open and only closes the extras. But in the
> case where where the loop terminates via the end condition in the
> for statement, the close loop closes all the sockets _including_
> the one it intends to use.
(emphasis mine). The closed socket fd is then passed to select(2).
See also: http://www.openwall.com/lists/musl/2015/08
The fix is to perform the loop termination test before adding sockfd
to the set of fds to be closed. As additional clean ups, remove the
use of the variable-length stack array, and switch to variable names
that better document the purpose of this logic.
Reported-by: Tastky <tastky@gmail.com>
Fixes: eb8229338f06 ("rpc.statd: Fix socket binding loop.")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rpc.statd may crash if it receives both a notification reply and a
client connection at the same time. It crashes because it adds
sockfd to SVC_FDSET and that violates the API contract.
The SVC_FDSET is to be considered read-only and must not be modified
by user code. The daemon modifies it for expediency to avoid
having to maintain two distinct fd lists and select on each one.
It is a practical choice that makes sense.
Thus, if a notification reply arrives by itself everything works,
or if a client connection arrives by itself everything works. Both
must arrive at the same time for sockfd to be set in SVC_FDSET
and to be processed by svc_getreqset because more than one of
readfds is ready.
It is the processing by svc_getreqset that will crash when it finds an
unregistered fd in the list that doesn't correlate to any of the
internal book keeping done by the library. At present the glibc
SunRPC library will crash, but TIRPC does not (it is robust against
invalid API usage in this case). However, future RPC libraries
may be implemented differently, and the questionable API usage
should be fixed.
The simplest fix is for process_reply to *clear* sockfd from the
ready-to-read fds, since it was never registered with xprt_register.
This works because the code always calls process_reply before handing
the fd set to the RPC layer for processing.
Compile-tested on x86_64 against master.
Signed-off-by: Carlos O'Donell <carlos@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
daemon_init parameter has the opposite sense
to code removed in commit 7addf9d
Signed-off-by: Chris Mayo <aklhfex@gmail.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The daemonization init/ready functions have parameters that are never used,
require the caller to keep track of some pipefds that it has no interest in
and which might not be used in some scenarios. Cleanup both functions a bit.
The idea here is also that these two functions might be good points to
insert more systemd init code later (sd_notify()).
Also, statd had a private copy of the daemonization code for unknown
reasons...so make it use the generic version instead.
Signed-off-by: David H?rdeman <david@hardeman.nu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Use the approved way, define in
http://www.freedesktop.org/software/systemd/man/sd_booted.html
to check if systemd is installed and running
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add mention of new files, remove mention of old files,
and cause "make dist" to create something very similar to
the current distributions.
systemd files are not currently included in "make dist" and some
files generated by "rpcgen" are (though they aren't in official
distribution).
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the event that there no hosts to be notified after a reboot, there's
no real reason to force lockd to wait the entire grace period before
handing out locks. We're not expecting any reclaim requests to come in
that situation.
Have sm-notify do a write to /proc/fs/lockd/nlm_end_grace if that file
is present. That informs the kernel that it's OK to go ahead and lift
lockd's grace period early.
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you don't have systemd, then this script dumps:
/usr/sbin/start-statd: line 8: systemctl: command not found
This isn't terribly useful since we ultimately fall back to running
the daemon ourselves, so probe for systemd's existence before we try
to use it.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a callback for incoming sm_notify to better handle
stale lock issue in client crash recovery in HA-NFS environment
1. "sm-notify" - callout name
2. monitored client name as in the SM_NOTIFY request
3. IP of the sender of the SM_NOITFY request.
4. state value in the SM_NOTIFY request
This new interface can be used by different HA-NFS product
in its specific configuration and environment to
recover from the client crash and stale lock scenarios.
Signed-off-by: Rong Zeng <rongzeng@us.ibm.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
| |
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 1.3.0 release adds a call to systemctl fails for it's in /usr/bin.
[root@localhost nfs-utils]# start-statd
/usr/sbin/start-statd: line 9: systemctl: command not found
Statd service already running!
Reported-by: Allan Duncan <amd1234@fastmail.com.au>
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
| |
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Even though lockd is a totally separate process to statd, they
depended on each other: statd much be running for lockd to be useful.
So an easy way to set the port numbers used by lockd is to get statd
to set them.
This patch add --nlm-port and --nlm-tcp-port to that end.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
| |
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
Moves nfs_probe_statd from mount to nfs support lib to share with statd.
Acked-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Marc Eshel reports that using the -v command line option on the
sm-notify command stopped working after nfs-utils 1.2.2, when IPv6
support was added. If nfs-utils is built without IPv6 support, it
still works. Marc specified a hostname with a single A record.
smn_bind_address() must construct a bind address with the same
family as the RPC socket's protocol family. Add an AI_V4MAPPED hint
so an appropriate IPv6 bind address is constructed even if -v
specifies an IPv4 presentation address, or a hostname with only IPv4
mappings.
We still use an IPv4 bind address if IPv6 support is compiled out or
the host does not support IPv6.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
Cc: Marc Eshel <eshel@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
From: Hemmo Nieminen <hemmo.nieminen@iki.fi>
Instead of closing the sockets before requesting a new one, keep them
open until a suitable one is found. Otherwise bindresvport will return
the same port over and over again.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
| |
Some init systems actually expect daemons to return 0 on success.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is essentially the same as the previous version, but has
been respun to fix up some merge conflicts with some of Chuck's
recent changes.
When we first added tirpc support, we took a "big hammer" approach, and
had it add libtirpc to $LIBS. That had the effect of making it so that
that library was linked into every binary. That's unnecessary, and
wasteful with memory.
Don't let AC_CHECK_LIB add -ltirpc to $LIBS. Instead, have the autoconf
tests set $(LIBTIRPC) in the makefiles, and have the programs that
need it explicitly include that library. In the event that we're not
using libtirpc, then set $LIBTIRPC to a blank string.
This necessitates a change to the bindresvport_sa check too. Since that
library is no longer included in $LIBS, we need to convert that check
to use AC_CHECK_LIB instead of AC_CHECK_FUNCS.
This patch also fixes a subtle bug. If the library was usable, but the
includes were not, the test would set $enable_tirpc to "no", but
HAVE_LIBTIRPC would still be true. That configuration would likely
fail to build.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sm-notify fails to remove monitor records from sm.bak when it has
finally notified a host. This is because of a recent change to send
two SM_NOTIFY requests for each monitored peer: one with the local
host's FQDN, and one with an unqualified version of same. This was
commit baa41b2c: "sm-notify: Send fully-qualified and unqualified
mon_names" (March 19, 2010).
Because of the March 2010 commit, sm-notify modifies the "my_name"
string during notification, but then uses this modified string to try
to find the monitor record to remove. Of course the search for the
record fails. So a persistent monitor record is left in sm.bak.
Aside from leaving trash around, this causes the same hosts to be
notified after every reboot, even if they successfully responded to
the previous SM_NOTIFY and they had no contact with us during the last
boot.
I also noticed that the trick of truncating the argument of SM_NOTIFY
doesn't work at all if a substitute "my_name" was specified via the "-v"
command line option. This patch attempts to address that as well.
sm-notify should preserve the original my_name string so that
nsm_delete_host() can find the correct monitor record to delete. Also
add some degree of protection to the mon_name and my_name strings in
each nsm_host record to prevent a future change from breaking this
dependency.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic in notify_host() watches the host->retries counter to see if
progress is not being made. If progress stalls, notify_host() tries
another IP address. This means sm-notify will generate a fresh
rpcbind query.
After an RPC succeeds, be sure to reset host->retries so sm-notify
doesn't start walking down the host's addrinfo list when we _are_
making progress. In the common case, if the host responds, we avoid
extra rpcbind queries and send all requests for the host to the same
IP address.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
An RPC retransmit timeout should start out the same for each new RPC
request. Don't increase the retransmit timeout after receiving the
reply to the rpcbind query.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Clean up: refactor the logic in recv_rpcbind_reply() that re-schedules
an nsm_host into a separate helper function
Adjust debugging messages so it's always apparent when an nsm_host is
rescheduled.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like the existing algorithm for verifying the passed-in bind
address is as broken as statd_matchhostname() used to be: for IP
addresses, AI_CANONNAME is useless. We need to have getnameinfo(3) or
equivalent in there.
Clean up: extract the logic that verifies the command line bind
address into its own function, and make it handle canonical name
lookup correctly.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The job of statd_matchhostname() is to work hard at matching two
hostnames or presentation IP addresses that may refer to the same
host.
statd_matchhostname() turns the hostname of the local system into a
list of addresses containing only the loopback address. The actual
DNS registered address of the system does not appear in that list.
Presentation IP addresses, on the other hand, are soundly ignored by
the AI_CANONNAME option of getaddrinfo(3). The ai_canonname string
that is returned is just the same presentation IP address. And the
resulting list of addresses contains just that IP address.
So if the DNS registered IP address of the local host is passed in as
one argument, and the local hostname is passed as the other argument,
statd_matchhostname() whiffs and believes there is no match. To fix
this, the logic needs to be smarter about deriving a hostname from an
IP address.
This appears to cause no end of trouble: monitor records pile up in
/var/lib/nfs/sm and sm.bak, notifications are missed, and so on. This
has likely been around since commit cbd3a131 "statd: Introduce statd
version of matchhostname()" (Jan 14, 2010).
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
statd's "-F" flag disables syslog output, and specifies sm-notify's
"-d" option when it runs it. sm-notify's "-d" option should therefore
also disable syslog output.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
Fix a debugging message to report correctly the count of hosts loaded
when statd starts up.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
License texts contain multiple address for FSF, some wrong.
So update them and replace COPYING file with
http://www.gnu.org/licenses/gpl-2.0.txt
which has a few changes to preamble and commentary.
Also remove extra COPYING file from utils/statd/
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
sh -p is not guaranteed to be provided by POSIX shells. dash for
instance does not provide this, so use bash explicitly.
Signed-off-by: Luk Claes <luk@debian.org>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
Fix syntax for line starting with 'visible' according to a patch from
Simon Paillard <spaillard@debian.org> in Debian bug #624261.
Signed-off-by: Luk Claes <luk@debian.org>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the past, rpc.statd posted SM_NOTIFY requests using the same socket
it used for sending downcalls to the kernel. To receive replies from
remote hosts, the socket was bound to INADDR_ANY.
With commit f113db52 "Remove notify functionality from statd in
favour of sm-notify" (Mar 20, 2007), the downcall socket is no longer
used for sending requests to remote hosts. However, the downcall
socket is still bound to INADDR_ANY.
Thus a remote host can inject data on this socket since it is an
unconnected UDP socket listening for RPC replies. Thanks to f113db52,
the port number of this socket is no longer controlled by a command
line option, making it difficult to firewall.
We have demonstrated that data injection on this socket can result in
a DoS by causing rpc.statd to consume CPU and log bandwidth, but so
far we have not found a breach.
To prevent unwanted data injection, bind this socket to the loopback
address.
BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=177
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
At RHEL, if user set port for mountd at /etc/services as
"mount 12345/tcp", mountd should be bind to 12345, but the
latest nfs-utils, mountd get a rand port, not 12345.
This patch make sure mountd be bind to the port which was set
at /etc/service.
Signed-off-by: Mi Jinlong <mijinlong@cn.fujitsu.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The synopsis of rpc.statd in its man page lists "-w" as a valid
option. There is currently no support in the source code for a "-w"
option.
BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=199
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gabor Papp reports nfs-utils-1.2.3 doesn't build on his system that
uses glibc-2.2.5:
make[3]: Entering directory
`/home/gzp/src/nfs-utils-1.2.3/utils/statd'
gcc -DHAVE_CONFIG_H -I. -I../../support/include -D_GNU_SOURCE -Wall
-Wextra -Wstrict-prototypes -pipe -g -O2 -MT sm-notify.o -MD
-MP -MF .deps/sm-notify.Tpo -c -o sm-notify.o sm-notify.c
sm-notify.c: In function 'smn_bind_address':
sm-notify.c:247: error: 'AI_NUMERICSERV' undeclared (first use in this
function)
sm-notify.c:247: error: (Each undeclared identifier is reported only
once
sm-notify.c:247: error: for each function it appears in.)
make[3]: *** [sm-notify.o] Error 1
According to the getaddrinfo(3) man page, AI_NUMERICSERV is available
only since glibc 2.3.4. getaddrinfo(3) seems to convert strings
containing a number to the right port value without the use of
AI_NUMERICSERV, so I think we can survive on older glibc's without it.
It will allow admins to specify service names as well as port numbers
on those versions.
There are uses of AI_NUMERICSERV in gssd and in nfs_svc_create(). The
one in nfs_svc_create() is behind HAVE_LIBTIRPC, and the other is a
issue only for those who want to deploy Kerberos -- likely in both
cases, a more modern glibc will be present. I'm going to leave those
two.
Fix for:
https://bugzilla.linux-nfs.org/show_bug.cgi?id=195
Reported-by: "Gabor Z. Papp" <gzp@papp.hu>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was reported that, if only "lo" is up,
mount.nfs 127.0.0.1:/export /mount
fails with "Name or service not known".
"man 3 getaddrinfo" says this:
If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4
addresses are returned in the list pointed to by res only if the
local system has at least one IPv4 address configured, and IPv6
addresses are only returned if the local system has at least
one IPv6 address configured.
The man page oversimplifies here. A review of glibc shows that
getaddrinfo(3) explicitly ignores loopback addresses when deciding
whether an IPv4 or IPv6 address is configured.
This behavior around loopback is a problem not just for mount.nfs,
but also for RPC daemons that have to start up before a system's
networking is fully configured and started. Given the history of
other problems with AI_ADDRCONFIG and the unpredictable behavior it
introduces, let's just remove it everywhere in nfs-utils.
This fix addresses:
https://bugzilla.linux-nfs.org/show_bug.cgi?id=191
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 8ce130c4 switched in the new statd_canonical_name() function
that constructs a "unique" name statd can use to uniquely identify a
monitor record.
The legacy statd would monitor a client that sent an IP address with
no reverse map as its caller_name. To remain bug-for-bug compatible,
allow this case in the new statd.
This shouldn't be a problem: statd_canonical_name() needs to create
a unique name for the monitored host so it can keep track of monitor
requests from the same remote. The IP address itself should work as
well as the host's canonical name, in case there is no reverse
mapping.
We still enforce the requirement that a mon_name that is a DNS name
must have a forward map to an IP address.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During any file locking interaction between an NFS client and server,
the client tells the server what hostname it will use as the mon_name
argument of the SM_NOTIFY request sent by the client when it reboots.
This is the "caller_name" argument of an NLMPROC_LOCK request.
The server, however, never tells the client what mon_name argument
it will use when sending an SM_NOTIFY request. In order to recognize
the server, clients usually guess what mon_name the server might
send, by using the server hostname provided by the user on the mount
command line.
Frequently, the user provides an unqualified server name on the mount
command. The server might then call the client back with a fully
qualified domain name, which might not match in some cases.
Solaris, and perhaps other implementations, attempt to mitigate this
problem by sending two SM_NOTIFY requests to each peer: one with an
unqualified mon_name argument, and one with a fully qualified mon_name.
Implement such a scheme for sm-notify.
Since my_name is almost always the fully-qualified hostname associated
with the local system, just wiping the left-most '.' in the my_name
argument and sending another SM_NOTIFY is nearly always sufficient.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|