| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So that exportfs can eventually support IPv6 addresses, copy statd's
getaddrinfo(3)-based matchhostname to exportfs, with adjustments for
dealing with export wildcards and netgroups. Until exportfs has full
IPv6 support, however, we want to ensure that IPv6 addresses continue
to remain blocked in the address comparison code used by exportfs. At
a later point we'll replace much of this with the generic functions
in sockaddr.h.
Since it contains special logic for handling wildcard and netgroups,
this function is specialized for exportfs, and does not belong in
one of the shared libraries.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct hostent can store either IPv4 or IPv6 addresses, but it can't
store both address families concurrently for the same host. Neither
can hostent deal with parts of socket addresses that are outside of
the sin{,6}_addr field.
Replace the use of "struct hostent" everywhere in libexport.a, mountd,
and exportfs with "struct addrinfo". This is a large change, but
there are so many strong dependencies on struct hostent that this
can't easily be broken into smaller pieces.
One benefit of this change is that hostent_dup() is no longer
required, since the results of getaddrinfo(3) are already dynamically
allocated.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Clean up: Reduce code duplication by introducing a goto label for
freeing hp and exiting. This will make replacing "struct hostent *"
with "struct addrinfo *" more straightforward in this code.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce DNS query helpers based on getaddrinfo(3) and
getnameinfo(3). These will eventually replace the existing
hostent-based functions in support/export/hostname.c.
Put some of these new helpers to immediate use, where convenient.
As they are part of libexport.a, I've added the forward declarations
for these new functions in exportfs.h rather than misc.h, where the
hostent-based forward declarations are currently.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you export two subvolumes of a btrfs filesystem, they will both be
given the same uuid so lookups will be confused.
blkid cannot differentiate the two, so we must use the fsid from
statfs64 to identify the filesystem.
We cannot tell if blkid or statfs is best without knowing internal
details of the filesystem in question, so we need to encode specific
knowledge of btrfs in mountd. This is unfortunate.
To ensure smooth handling of this and possible future changes in uuid
generation, we add infrastructure for multiple different uuids to be
recognised on old filehandles, but only the preferred on is used on
new filehandles.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
| |
mount.nfs should display some type of error diagnostics when
the network protocol can not be determined.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
mount.nfs should not only fail when an invalid option values
are supplied (as it does), it should also print a diagnostic
message identifying the problem
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and one for NFSv3 (MOUNTv3)
When --no-nfs-version requests an NFS version to be disabled, the
code actually disabled the MOUNT version. This works is several cases,
but requires --no-nfs-version 1 to completely disable NFSv2, which
is wrong.
So if we do disable 1, 2, and 3. mountd complain and won't run, it
is not possible to run just v4 - i.e. not listening for MOUNT requests
at all (as v4 doesn't need them).
So change the handling of "--no-nfs-version 2" it disable MOUNTv1 as
well as
MOUNTv2, and allow mountd to continue running as long as one of
NFSv2 NFSv3 NFSv4 is enabled.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To store non-AF_INET addresses in the nfs_client structure, we need to
use more than in_addr for the m_addrlist field. Make m_addrlist
larger, then add a few helper functions to handle type casting and
array indexing cleanly.
We could treat the nfs_client address list as if all the addresses
in the list were the same family. This might work for MCL_SUBNETWORK
type nfs_clients. However, during the transition to IPv6, most hosts
will have at least one IPv4 and one IPv6 address. For MCL_FQDN, I
think we need to have the ability to store addresses from both
families in one nfs_client.
Additionally, IPv6 scope IDs are not part of struct sin6_addr. To
support link-local IPv6 addresses and the like, a scope ID must be
stored.
Thus, each slot in the address list needs to be capable of storing an
entire socket address, and not simply the network address part.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
| |
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
| |
Sends a new format of context information to the kernel.
(Requires kernel support to do anything useful.)
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
This patch replaces a hard-coded list with a function to obtain
the Kerberos encryption types that the kernel's rpcsec_gss code
can support. Defaults to old behavior if kernel does not supply
information.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
cleanup: Move function limit_krb5_enctypes() from the section
containing static functions into the section containing
externally visible functions.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if a server is up but not responding (ie, it answers ARP
requests, but not NFS or RPC requests), mount retries or backgrounds
itself waiting for the server.
If the server is not responding on the network at all, mount fails
the mount request immediately.
Users might find it more useful if mount retried in both cases.
Note that this change means attempting to mount using a misspelled
server name will "hang" for the retry amount. I suppose the error
message isn't very helpful whether it fails immediately or waits
a couple of minutes, though I imagine that an unreachable server is a
much more common occurrence than a misspelling.
Reported-by: Daniel Goering <g_daniel@gmx.net>
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The mon_name argument of an SM_NOTIFY request is a string that
identifies the rebooting host.
sm-notify should send the my_name provided by the local lockd at the
time the remote was monitored, rather than cocking up a mon_name
argument based on the present return value of gethostname(3). If the
local system's hostname happened to change after the last reboot, then
the string returned by gethostname(3) will not be recognized by the
remote. Thus the remote will never initiate lock recovery for the
original named host, possibly leaving stale locks.
The existing behavior of using the -v command line option as the
mon_name argument is preserved, but we now prevent sending an IP
presentation address, as some non-Linux implementations don't
recognize addresses as valid mon_names.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Part of the reason for the previous bug was confusion between "subpath"
and "path"; which is the shorter path, and which the longer?
"child" and "parent" seem less ambiguous.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
| |
This was obviously wrong, since path[strlen(path)] == '\0'
should always be true.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A uid or gid should be represented as unsigned, not signed.
The conversion to signed here could cause a hang on access by an unknown
user to a server running mountd with --manage-gids; such a user is
likely to be mapped to 232-1, which may be converted to 231-1 when
represented as an int, resulting in a downcall for uid 231-1, hence the
original rpc hanging forever waiting for a cache downcall for 232-1.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current mount, umount and showmount code uses
authunix_create_default to get an auth handle. The one provided by glibc
returned a truncated list of groups when there were more than 16 groups.
libtirpc however currently does an abort() in this case, which causes
the program to crash and dump core.
nfs-utils just uses these auth handles for the MNT protocol, so the
group list doesn't make a lot of difference here. Add a new function
that creates an auth handle with a supplemental gids list that consists
only of the primary gid. Have nfs-utils use that function anywhere that
it currently uses authunix_create_default. Also, have the caller
properly check for a NULL return from that function.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In nfs_nfs_proto_family(), *family is never set if the legacy
"udp" or "tcp" mount options are specified. The result is an error
message at umount time, for example:
umount.nfs: DNS resolution failed for
2001:5c0:1101:2f00:250:8dff:fe95:5c61: ai_family not supported
even if mount was built with IPv6 support.
The man page says that "udp" is a synonym for "proto=udp", and
likewise for "tcp". Thus, we don't look at config_default_family
here, but always use AF_INET explicitly, to be consistent with the
meaning of proto=.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
| |
Have nfs_nfs_proto and nfs_mount_proto set errno to EPROTONOSUPPORT on
error. This helps default_value to display sane warning messages.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
supported
Right now, there's nothing that expressly forbids someone from
specifying proto=tcp6 for instance, even when nfs-utils it built without
IPv6 support. This may not work well if (for instance) they are using
NFSv3, since statd won't support IPv6. Explicitly return an error if
someone specifies an IPv6 proto= or mountproto= option and IPv6 isn't
supported.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
SM_SIMU_CRASH isn't used, so this warning is never seen today.
However, if we ever wanted to use SM_SIMU_CRASH, this warning
is unnecessarily alarming, and serves no real purpose.
At some point in the near future I'd like us to consider using
SM_SIMU_CRASH, so let's get rid of this message now.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is that this one has default_value call nfs_nfs_proto_family regardless
of whether IPV6_SUPPORTED is set.
When IPv6 is enabled, the Proto= config file option is treated as a
netid, and the address family for lookups is selected based on that
setting. The Defaultproto= option however still only affects the
protocol setting for the sockets (IPPROTO_*) and not the address family.
This patch makes it so that if someone sets the "Defaultproto=" option
in the nfsmount.conf, it's used to determine the default address family
for lookups as well as the protocol type.
This gives users a way to force a particular address family to be used
universally for mounts and brings the behavior of the Defaultproto=
option in line with the Proto= option.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
| |
Don't leak this file descriptor if stat should fail.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Jeff Layton pointed out that the current negotiation logic in
stropts.c simply doesn't handle the case where a server may have an
IPv6 address and an IPv4 address, but only NFS/IPv4 is supported.
This is typical of all currently deployed Linux servers.
Add support for trying all addresses returned from DNS when
"proto=" is not specified on the command line.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When retrying a mount request with a different server address, the
addr= option may change each time through the fg/bg loop.
Instead of setting the addr= option in nfs_validate_options(), set it
in nfs_try_mount_v2v3() and nfs_try_mount_v4(). This is much the
same thing we did recently with the version-specific mount options
which might change each time through the fg/bg retry loop.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally I thought it would be best to share the DNS query code
between the legacy mount code and the new text-based code, hence
the introduction of nfs_lookup(). However, it now appears we want
the text-based code to do a little more than take the first address
returned by the query.
So, let's invoke getaddrinfo(3) directly in stropts.c, and save
the returned addrinfo struct until the end of processing.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want new default behavior from mount.nfs when the server refuses a
connection. Since connection refusal can be spurious (for example,
if the server is rebooting), mount.nfs should retry.
NFS shares that are automatically mounted by /etc/fstab at boot
time may be problematic. The new behavior can be disabled by
specifying the "retry=0" mount option, or these mounts can be changed
to background mounts by specifying the "bg" option.
A kernel code change is still required for the mount(2) system call to
return ECONNREFUSED for NFSv4 mounts (see 2.6.33). For v2/v3, the
version and transport negotiation logic in mount.nfs should drive a
retry if the server's rpcbind can't be reached.
Note that if a v2/v3 mount request encounters an unregistered NFS
service, it will still fail immediately. That wouldn't be too hard
to change as well, but there are many more corner cases there where
failing immediately is appropriate.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Benny Halevy <bhalevy@panasas.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
| |
Signed-off-by: Benny Halevy <bhalevy@panasas.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/proc/fs/nfsd/versions was extended to allow turning on/off minor
versions by echoing "+4.1" or "-4.1" to /proc/fs/nsfd/versions.
Unfortunately, pre-2.6.30 kernels just stop parsing at first non-digit,
so "-4.1" is interpreted as "-4". If new nfs-utils (on old kernel)
writes "+2", "+3", "+4", then "-4.1", result therefore is to turn off
4.1.
Given that historical behavior, it may have been a mistake to extend the
interface the way we did; but at this point we're probably stuck with
it. So, just reverse the order we write versions in.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
| |
files which ensure the S_ISDIR() macro is defined.
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
| |
libnfsidmap library git tree
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
When the protocol version is set on the command line,
none of the variables set in the configuration file
are passed down to the kernel due to a bug in the
parsing routine.
Tested-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Assuming the tcp_wrappers library can actually support IPv6 addresses,
here's a crack at IPv6 support in nfs-utils' TCP wrapper shim.
Some reorganization is done to limit the number of times that @sap
is converted to a presentation address string.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eliminate these compiler warnings:
tcpwrapper.c: In function logit
tcpwrapper.c:225: warning: unused parameter procnum
tcpwrapper.c:225: warning: unused parameter prognum
Actually, @procnum is not used anywhere in our tcpwrapper.c, so
let's just get rid of it.
Since there is only one logit() call site in tcpwrapper.c, the macro
wrapper just adds needless clutter. Let's get rid of that too.
Finally, both mountd and statd now use xlog(), which adds an
appropriate program name prefix to every message. Replace the
open-coded syslog(2) call with an xlog() call in order to
consistently identify the RPC service reporting the intrusion.
Since logit() no longer references "deny_severity" and no nfs-utils
caller sets either allow_severity or deny_severity, we remove them.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expand and clarify the explanation of NSM operation on Linux, and
provide the same text in both man pages.
Update descriptions of the command line options to match the operation
of the current implementation.
Introduce sections discussing security and operational issues, and
IPv6 operation.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If TI-RPC is available, use it to create statd's svc listener. If
not, use the old function, rpc_init(), to create statd's listener.
IPv6 can be supported if TI-RPC is available. In this case,
/etc/netconfig is searched to determine which transports to advertise.
Add the new listener creation API in libnfs.a since other components
of nfs-utils (such as rpc.mountd) will eventually want to share it.
A little re-arrangement of when the statd listener is created is done
to make unregistration of the statd service more reliable. As it is
now, the statd service is never unregistered when it exits. After it
is gone, other programs usually hang when trying to access statd or
see if it's running, since the registration is still there but statd
itself does not respond.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm about to switch the order of listener creation and dropping root
privileges. rpc.statd will drop privileges first, then create its
listeners. The reason for the new ordering is explained in a
subsequent patch.
However, for non-TI-RPC builds, rpc_init() needs to use a privileged
port to do pmap registrations. For both TI-RPC and non-TI-RPC builds,
CAP_NET_BIND is required in case the admin requests a privileged
listener port on the statd command line.
So that these requirements are met, nsm_drop_privileges() will now
retain CAP_NET_BIND while dropping root.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clean up: The contents of NL_ADDR are fixed: they are always the IPv4
loopback address. Some time ago, the use of NL_ADDR() was stubbed out
of the NLM downcall forward path, replaced with a constant IPv4
loopback address.
Stub it out of the reply path as well, and then remove NL_ADDR
entirely.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
| |
SM_STAT is usually not used by most contemporary NSM implementations,
but for consistency, it gets the same treatment as sm_mon_1_svc(),
since both should use the same logic to determine whether a mon_name
is able to be monitored.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
| |
Replace deprecated gethostbyname(3) and gethostbyaddr(3) calls in
monitor.c, and address a couple of memory leaks.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
| |
Provide a shared function to generate canonical names that statd
uses to index its on-disk monitor list. This function can resolve
DNS hostnames, and IPv4 and IPv6 presentation addresses.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To support IPv6, statd must support multi-homed remote peers. For our
purposes, "multi-homed peer" means that more than one unique IP
address maps to the one canonical host name for that peer.
An SM_MON request from the local lockd has a "mon_name" argument that
statd reverse maps to a canonical hostname (ie the A record for that
host). statd assumes the canonical hostname is unique enough that
it stores the callback data for this mon_name in a file named after
that canonical hostname.
Because lockd can't distinguish between two unique IP addresses that
may be from the same physical host, the kernel can hand statd a
mon_name that maps to the same canonical hostname as some previous
mon_name. So that the kernel can keep this instance of the mon_name
unique, it creates a fresh priv cookie for each new address.
Note that a mon_name can be a presentation address string, or the
caller_name string sent in each NLMPROC_LOCK request. There's
nothing that requires the caller_name to be a fully-qualified
hostname, thus it's uniqueness is not guaranteed. The current
design of statd assumes that canonical hostnames will be unique
enough.
When a mon_name for a fresh SM_MON request maps to the same canonical
hostname as an existing monitored peer, but the priv cookie is new,
statd will try to write the information for the fresh request into an
existing monitor record file, wiping out the contents of the file.
This is because the mon_name/cookie combination won't match any record
statd already has.
Currently, statd doesn't check if a record file already exists before
writing into it. statd's logic assumes that the svc routine has
already checked that no matching record exists in the in-core monitor
list. And, it doesn't use O_EXCL when opening the record file. Not
only is the old data in that file wiped out, but statd's in-core
monitor list will no longer match what's in the on-disk monitor list.
Note that IPv6 isn't needed to exercise multi-homed peer support.
Any IPv4 peer that has multiple addresses that map to its canonical
hostname will trigger this behavior. However, this scenario will
become quite common when all hosts on a network automatically get both
an IPv4 address and an IPv6 address.
I can think of a few ways to address this:
1. Replace the current on-disk format with a database that has a
uniqueness constraint on the monitor records
2. Create a new file naming scheme; eg. one that uses a truly
unique name such as a hash generated from the mon_name, my_name, and
priv cookie
3. Support multiple lines in each monitor record file
Since statd's on-disk format constitutes a formal API, options 1 and 2
are right out. This patch implements option 3. There are two parts:
adding a new line to an existing file; and deleting a line from a file
with more than one line. Interestingly, the existing code already
supports reading more than one line from these files, so we don't need
to add extra code here to do that.
One file may contain a line for every unique mon_name / priv cookie
where the mon_name reverse maps to the same canonical hostname. We
use the atomic write facility added by a previous patch to ensure the
on-disk monitor record list is updated atomically.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
| |
Currently sm-notify does not use the mon_name and my_name strings
passed to smn_get_host(). Very soon we're going to need the mon_name
and my_name strings, so add code to store those strings in struct
nsm_host, and free them when each host is forgotten.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
| |
Ensure that SM_SIMU_CRASH does not allow non-AF_INET callers to
bypass the localhost check.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the time being, statd is not going to support receiving SM_MON
calls from the local lockd via IPv6.
However, the upcalls (SM_MON, etc.) from the local lockd arrive on the
same socket that receives calls from remote peers. Thus
caller_is_localhost() at least has to be smart enough to notice that
the caller is not AF_INET, and to display non-AF_INET addresses
appropriately.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|
|
|
|
|
|
|
|
|
|
| |
We have all the pieces in place, so update sm_notify_1_svc() to handle
SM_NOTIFY requests sent from IPv6 remotes.
This also eliminates a memory leak: the strdup'd memory containing the
callers' presentation address was never freed.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
|