Andrew Deason [Tue, 10 Jun 2014 19:47:31 +0000 (14:47 -0500)]
doc: Document fs listquota 2TB partition limit
We have previously documented that volumes over 2TB can result in
inaccuracies, but this documentation does not say how the 'partition'
field in "fs listquota" can be inaccurate. It is confusing to see a
usage of 0% for a partition that you know is being used, so try to
briefly explain in what way this field is inaccurate.
The reason we _under_-report the partition usage is that the
fileserver actually gives back PartBlocksAvail and PartMaxBlocks (not
"blocks used" and "blocks total"). So 1TB used and 4TB total is
truncated to 2TB and given back as 2TB free and 2TB total. One we hit
3TB used we'll report it as 1TB free 2TB total (50%) when the actual
usage is 75%.
Andrew Deason [Tue, 18 Feb 2014 19:00:38 +0000 (13:00 -0600)]
vol: Make FindLinkHandle static and namei-only
FindLinkHandle is only referenced inside vol-salvage.c. Also, the
concept of a link table only exists on namei, so the function is only
used for the namei server (and it's only called by other namei-only
code).
So, make the function static, and put it inside the AFS_NAMEI_ENV
ifdef, to be a little more clear about where it can be used. Moving it
inside the AFS_NAMEI_ENV ifdef also avoids a warning if FindLinkHandle
is made static, since otherwise the function would be defined but
unused on non-namei.
This change should incur no difference in behavior; it is just code
reorganization.
Andrew Deason [Tue, 14 Oct 2014 18:17:27 +0000 (13:17 -0500)]
ubik: Unlock version lock before udisk_end
Currently, BeginTrans calls udisk_end with UBIK_VERSION_LOCK held when
it gets an error from DISK_Begin. However, udisk_end itself acquires
UBIK_VERSION_LOCK to update the database flags, so this causes a
deadlock.
So, unlock UBIK_VERSION_LOCK before calling udisk_end. Also unlock it
before calling DISK_Abort, udisk_abort, and DISK_Begin, as well, since
none of those modify fields protected by UBIK_VERSION_LOCK. (Any read
access is allowed because we DBHOLD the database.) This commit unlocks
the lock immediately after we are done modifying versioning
information, which is right after we change writeTidCounter for write
transactions.
Andrew Deason [Mon, 13 Oct 2014 20:06:36 +0000 (15:06 -0500)]
ubik: Convert DoProbe 'i' to 'nconns'
DoProbe was using the variable 'i' to keep track of how many
connections we have in the conns array. Keep track of this separately
using a variable called 'nconns' instead, to make this function a bit
less confusing.
Michael Meffie [Fri, 14 Nov 2014 03:28:08 +0000 (22:28 -0500)]
libafs: remove "Please install afsd with check server daemon" warning
Apparently, ancient versions of afsd did not start the check server
daemon (AFSOP_START_CS). The afs_Daemon tries to detect when the check
server daemon is not running and issues a warning to upgrade afsd. The
afs_Daemon waits for the cache initialization to complete (AFSOP_GO)
before detecting if the cache server daemon is started.
Unfortunately, when running with memcache, the cache initialization is
fast enough to race with the start of the check server daemon, and the
"Please install afsd with check server daemon" message is sometimes
printed to the syslog.
Since all modern versions of afsd do start the check server daemon, this
error message is no longer needed, so just remove the message and the
flag used to print it on only once.
VolForward and VolForwardMulti create rx security objects, but
never free them. The RXS_Close's are positioned where they are
to limit the need for conditionals
Change-Id: Iec6879270ad54c30c1fea571cea583afaca9364b
Reviewed-on: http://gerrit.openafs.org/9527 Reviewed-by: D Brashear <shadow@your-file-system.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com>
Sami Kerola [Wed, 19 Jun 2013 20:15:19 +0000 (21:15 +0100)]
build-sys: fix m4 quotation to make upstream autotools to work
Macro arguments for AC_ARG_WITH, such as AC_CHECK_PROGS, need to be
quoted. Unless they are the latest version of autoconf will expand
macros slightly wrong way making the configure to fail at line where
there are only two ticks.
$ ./regen.sh
[...]
$ automake -a -f
[...]
automake: error: no 'Makefile.am' found for any configure output
$ ./configure
[...]
checking pkg-config is at least version 0.9.0... yes
./configure: line 13348: syntax error near unexpected token `newline'
./configure: line 13348: ` '''
Notice that the 'automake' run is needed in order to avoid later
configure error, which would look something like.
configure: error: cannot find install-sh, install.sh, or shtool in build-tools "."/build-tools
Andrew Deason [Sun, 20 May 2012 22:20:54 +0000 (17:20 -0500)]
FBSD: Drop afs_xvcache for vgone()
For FreeBSD, osi_TryEvictVCache was calling vgone() without dropping
afs_xvcache. Prior to aad83a30a82407bfa6ac15b49fd31d69b563e898, this
is what osi_TryEvictVCache did, and since the 'slept' pointer
represents whether we dropped xvcache (not whether we dropped glock),
it seems like this is the intention of the code.
Andrew Deason [Sun, 20 May 2012 22:16:37 +0000 (17:16 -0500)]
FBSD: Do not vgone() in osi_VM_FlushVCache
osi_VM_FlushVCache just needs to remove VM references to the given
vcache; calling vgone() entirely should be unnecessary. Remove the
call to vgone() and other osi_TryEvictVCache-ish stuff, and just try
to cache_purge the vnode, like the other BSD implementations do.
Benjamin Kaduk [Wed, 28 May 2014 14:47:32 +0000 (10:47 -0400)]
Rewrap some long lines in the toplevel Makefile
Only rewrap long lines in make scope; long lines in shell scope
are untouched.
We are inconsistent about whether continuation lines for listing
the dependencies of a target are indented by one or two tabs,
which this commit does not fix.
Change-Id: I2e438a0f42faa2ef7922d2c3b143e14bc82de826
Reviewed-on: http://gerrit.openafs.org/11178 Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: BuildBot <buildbot@rampaginggeek.com>
Andrew Deason [Thu, 29 Aug 2013 20:33:49 +0000 (15:33 -0500)]
namei: IH_REALLYCLOSE special inode on delete
When we delete a special inode, we should IH_REALLYCLOSE it, to ensure
no other cached file handles are open for that special inode. However,
currently PurgeHeader_r does this, and then IH_DECs the special
inodes. On namei, calling IH_DEC on a special inode causes the inode
to be opened, so we create a cached file handle right after we closed
all cached file handles for that inode with IH_REALLYCLOSE.
Making namei IH_DEC not open an FdHandle_t for the given file is
non-trivial, at least when dec'ing the linktable. So instead, just
make namei IH_DEC itself issue the IH_REALLYCLOSE right before the
actual unlink() call.
With this, we can keep the cached file handle open for special inodes
until right before they are actually deleted, so we don't issue extra
unnecessary open()s and close()s.
Andrew Deason [Thu, 29 Aug 2013 20:16:00 +0000 (15:16 -0500)]
namei: Remove redundant linktable SetLinkCount
If we're setting the linktable linkcount to 0, we're about to delete
the whole linktable. So, don't bother setting the link count. Still
make sure we unlock the linktable, as we still have it locked at this
point, from the previous GetLinkCount call.
The return value of asprintf() is the number of bytes printed, or -1 if there
was an error allocating a large enough buffer. In the latter case, the value
of the result string is undefined, and so it cannot be counted on to be NULL.
This change fixes numerous places where the result of asprintf is checked
incorrectly (by examining the output pointer and not the return value) or not
at all.
Change-Id: I9fef14d60c096795d59c42798f3906041fb18c86
Reviewed-on: http://gerrit.openafs.org/9978 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: BuildBot <buildbot@rampaginggeek.com>
Benjamin Kaduk [Wed, 8 Oct 2014 20:51:33 +0000 (16:51 -0400)]
Clean up our cleaning
'make clean' and 'make maintainer-clean' still leave around a fair
number of droppings, prior to this commit.
We were not descending into the 'tests' top-level directory while
cleaning. Furthermore, tests/opr/Makefile needed $(LT_CLEAN), and
tests/rx/Makefile needed to spell it correctly.
The libtoolization places a lot of files to be removed in the
'pristine' target.
The processing used to implement the =include directive in the pod
sources for the man pages leaves around the non-.in versions of
files; we should clean that up in the 'pristine' target as well.
The 'pristine' target should likewise remove the man pages which
are generated from the pod files.
Additionally, the documentation build uses a Doxyfile which is
output by configure; that should be removed (if present) by the
'distclean' target.
When hcrypto was converted to libtool, the use of ${OBJECTS} in
the clean target was missed, so we were leaving around most of the
actual object files -- $(LT_CLEAN) does not handle this for us.
Change the rule to remove *.o as is done elsewhere.
The conversion of libafsrpc to libtool added a convenience library
libafsrpc_sys.la, and changed how syscall.o was generated on
most architectures, to be the result of compiling an empty .c file
(instead of just an empty .o file). This introduced a new
intermediate file, syscall.c, which must be cleaned up.
tvolser was only listing volserver and not vos in its list of
executables to remove while cleaning.
The conversion of venus/test to libtool was not done quite right.
Makefile.libtool and the .lo suffix are only needed when libtool
is being used to link *libraries*; just Makefile.pthread suffices
when libtool is being used to link executables. As such, remove
the inclusion of Makefile.libtool, and change the .lo targets back
to regular .o ones, and add back *.o to the list of files to remove
in the 'clean' target (it was needed there even without the
other changes to that Makefile).
Andrew Deason [Wed, 24 Sep 2014 22:50:02 +0000 (17:50 -0500)]
afs: Consolidate fheader initialization
We were initializing an afs_fheader structure in two different places,
with the same values. Consolidate these into a single function, so
updating the structure is easier. Also zero the whole structure, just
to make sure everything is initialized, even if the structure changes.
This commit should have no behavior impact; it is just code
reorganization.
Change-Id: If90757166d8490eaa053aa086c7b95349a62332e
Reviewed-on: http://gerrit.openafs.org/11510 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Tested-by: BuildBot <buildbot@rampaginggeek.com>
Michael Meffie [Thu, 20 Nov 2014 21:54:25 +0000 (16:54 -0500)]
vos: fix crash when getting a non-loopback host address
Fix a crash in vos when trying to find a non loopback server address.
The struct hostent h_addr_list field is a null terminated array of
pointers to addresses, in network byte order. The struct hostent length
field is not the length of the h_addr_list array (as one would expect),
but rather the length of an address in bytes, which is always 4 for IP
version 4 addresses.
Verify the returned addresses are IPv4 and take care to not iterate
beyond the end of the address pointer array.
Garrett Wollman [Wed, 13 Aug 2014 01:56:22 +0000 (21:56 -0400)]
FBSD: osi_vcache: remove support for unsupported FreeBSD releases
Support for FreeBSD 7.x terminated in early 2013, and it's highly
unlikely that anyone was successfully using OpenAFS in that
environment. OpenAFS has not been tested on 7.x since at least that
time, probably longer. This removes the #ifdefs that support pre-8.0
releases.
Currently, vos.c leaves a gap of 12 in the argument handling array
before its common operations (-verbose, -noauth, etc.); 'vos each'
will take more, so move that to 25.
While here, switch to named constants for these arguments, which
should make it easier to do this again, if ever necessary.
Change-Id: Idc4424e5fe4efd78389ea8421db000a361b461ec
Reviewed-on: http://gerrit.openafs.org/11332 Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Andrew Deason [Tue, 2 Sep 2014 22:51:46 +0000 (17:51 -0500)]
systemd: RemainAfterExit in openafs-client.service
Currently, if the client is started without any options that require
an extra thread (like -afsdb), all processes spawned by afsd will
exit. There may be some kernel threads still active, but those are
spawned by the kernel module, and are not child processes of the
parent afsd process, or anything like that.
Since we are a Type=forking service in systemd, systemd interprets
this situation to mean that the service has stopped successfully, and
then runs the ExecStop commands. So, for example, if our AFSD_ARGS in
our sysconfig is "-fakestat -afsdb", the service starts as normal. But
if it is changed to "-fakestat", then when openafs-client.service is
started, it immediately stops again.
To avoid this, turn on the systemd option RemainAfterExit, which tells
systemd that the service has not stopped if all of our processes have
exited. The client service will thus remain running until it is
stopped.
Issue reported by Rich Sudlow.
Change-Id: If760d3617d4afbcfac923df726eb58b03ce25771
Reviewed-on: http://gerrit.openafs.org/11440 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Andrew Deason [Wed, 5 Nov 2014 16:22:00 +0000 (10:22 -0600)]
LINUX: Avoid check for key_type.match existence
Commit b5de4a9f removed our key_type 'match' function for kernels that
do not have such a 'match' function pointer. However, this added a
configure test where we are supposed to fail for the "new" behavior,
which is discouraged.
This causes an actual problem, because this test will fail on at least
RHEL5, due to arguably unrelated reasons (the header file for the
relevant struct is in key.h instead of key-type.h). And so, in that
situation we avoid defining a 'match' function callback, meaning our
'match' function callback is NULL, which causes a panic when we try to
actually look up keys for a PAG.
To fix this, transform the 'match' config test into one where we
succeed for the "new" behavior. We do this by testing for the
existence of the new functionality that replaced the old 'match'
function, which is the match_preparse function (specifically, the
'cmp' field in the structure accepted by match_preparse). This should
cause unrelated compilation errors to cause us to revert to the "old"
behavior instead of the "new" behavior. At worst, this should cause
build issues if we get the config test wrong (since we will try to use
the 'match' function definition that does not exist), instead of
panicing at runtime.
Note that while we test for key_type.match_preparse, we don't actually
use that function, since our 'match' functionality is the same as the
default behavior (according to b5de4a9f). So, we can avoid defining
any such function for newer kernels.
Thanks to Stephan Wiesand for bisecting this issue.
Change-Id: If6f93d6b5340fa738a55adeb7778d26ff5dbacc1
Reviewed-on: http://gerrit.openafs.org/11589 Reviewed-by: Marc Dionne <marc.c.dionne@gmail.com> Reviewed-by: Stephan Wiesand <stephan.wiesand@desy.de> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Benjamin Kaduk [Wed, 15 Oct 2014 19:03:36 +0000 (15:03 -0400)]
Allow compiling with KERNEL and AFS_PTHREAD_ENV
Add the necessary preprocessor conditionals to allow building
libuafs with AFS_PTHREAD_ENV defined.
A follow-up commit will switch to building libuafs using libtool,
which will set the pthread compiler/linker flags. UKERNEL is already
using the pthread primitives for its internal kernel synchronization,
so there should not be any harm from additionally specifying the
pthread build arguments.
This change was produced mostly in a mechanical fashion, attempting
to perform such a build, and eliminating compiler and linker errors
in an iterative process. No concerted effort has been made to audit
the whole kernel codebase for correctness of conditionals, but the
linktest executable does link (that is, the overall build succeeds).
Jeffrey Altman [Wed, 15 Oct 2014 16:19:44 +0000 (12:19 -0400)]
klog: make krb5_524 non-fatal for native K5 tokens
The krb5_524_conv_principal() function should fail whenever the Kerberos
v5 principal cannot safely be mapped onto a Kerberos v4 principal, and
does fail on some Kerberos v5 principals used in real-world AFS
deployments.
Prior to this patchset a failure was treated as a fatal error that
in turn prevents an AFS token from being generated or set into the
cache manager.
The krb5_524_conv_principal() function as applied to AFS tokens is
just a local guess. How the username in the token is interpreted by
the AFS server is up to the server.
krb5_524_conv_principal() is only used for Krb5 native tokens. For Krb4
tokens the krb5_524_convert_creds() function is used to obtain both the
Kerberos v4 ticket and the converted names from the KDC. Many
organizations used the krb524d service to perform name translation. When
the krb524d service is used, the name translation is performed by the KDC,
so there is no local call to krb5_524_conf_principal() which might fail.
As a result, disallowing the use of a native Krb5 token due to a failed
local name translation is a needless loss of functionality; the local name
translation is not an essential part of obtaining a token.
This patchset modifies the behavior such that krb5_524_conv_principal()
errors are non-fatal.
1. If -noprdb is not specified the error message is generated
and a NULL username is used.
2. If the username is NULL the prdb lookup is disabled.
3. If the username is NULL the informational messages do not
include a username.
4. If the username is NULL the username info provided to the
cache manager in the token description is the nul string.
Credit to Ben Kaduk for assistance with the wording of this
commit message.
Change-Id: Ib07131fc0ff4bf5319815213198c3f0adac17b10
Reviewed-on: http://gerrit.openafs.org/11542 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com>
Rename process.s to process.default.s so that the name "process.s" is free
for use, and switch to using that as the ephemeral file name. This enables
the use of gcc for ${AS}, despite gcc's ignoring files with extensions that
it does not recognize.
Change-Id: Idc0716547770fe4fc94bc3fa2c223966f3f76c3b
Reviewed-on: http://gerrit.openafs.org/11535 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: D Brashear <shadow@your-file-system.com>
Andrew Deason [Mon, 6 Oct 2014 17:47:13 +0000 (13:47 -0400)]
tests: Fix fmt-t.c warning
'main' in fmt-t.c was declared as a prototype-less function, which
triggers a warning, which is an error with --enable-checking. Fix it
by declaring 'main' properly.
Michael Meffie [Fri, 24 Oct 2014 21:17:07 +0000 (17:17 -0400)]
vldb_check: fix false mh block error message
Fix a false error message about invalid mh blocks when the vldb has more
than one mh block. To add insult to injury, vldb_check complains about
the wrong address and block number.
The flags field in the mh block header is in network byte order, in all
of the blocks, not just the first one. Be sure to convert all of them
to host byte order so the VLCONTBLOCK flag check works. Fix the error
message on the secondary blocks to show the correct address and block
number.
Example bogus error messages:
vldb_check ./vldb.DB0
address 132120 (offset 0x20458): Multihomed Block 0: Not a multihomed block
address 132120 (offset 0x20458): Multihomed Block 0: Not a multihomed block
address 132120 (offset 0x20458): Multihomed Block 0: Not a multihomed block
Benjamin Kaduk [Mon, 6 Oct 2014 21:19:44 +0000 (17:19 -0400)]
Finish deorbiting libjuafs.a
Change I2074d5bc26e326db36b16e055431818ef1c69210 removed the separate
compilation/link of a libjuafs.a (since it was functionally identical
to the libuafs.a already being built), but retained a libjuafs.a in
TOP_LIBDIR for use by src/JAVA/libjafs/.
This commit adjusts src/JAVA/libjafs to refer to libuafs.a directly,
and removes references to libjuafs.a which are no longer relevant.
Benjamin Kaduk [Thu, 16 Oct 2014 04:04:14 +0000 (00:04 -0400)]
Make afs_usrops.h more closely resemble reality
Remove prototypes for many routines which are not implemented.
(I thought some toolchains would complain about this sort of thing?
Maybe we disable it.)
Benjamin Kaduk [Sat, 20 Sep 2014 03:04:10 +0000 (23:04 -0400)]
Build libuafs with libtool
Use the standard program for building PIC and non-PIC object files,
instead of rolling our own. This allows us to pull the build rules
into the Makefile.common, leaving just compiler flags and similar
in the MakefileProtos.
This does change the build flags being used to compile these files
somewhat -- the old CRULE1 and CRULEPIC used CC instead of CCOBJ
or MT_CC, and did not pass MT_CFLAGS, but it should be safe to
move to the standard compiler invocations. We can also eliminate
the libuafs-specific 'OPTF' variable which expands to OPTMZ almost
everywhere.
Rename our COMMON_INCLUDE to MODULE_INCLUDE so it's picked up properly
by the standard build rules; this will let us remove
${TOP_OBJDIR}/src/config and ${TOP_INCDIR} once the rest of the
build rules in this Makefile are converted to use libtool, as those
include directories are already added by COMMON_INCL in Makefile.config.
As a side effect, we get rid of the LIBUAFS make variable -- all sites
were defining it to libuafs.a anyway, so we can just hardcode it.
We can also build a shared libuafs.la "for free". Don't install
it anywhere just yet, though.
Benjamin Kaduk [Wed, 15 Oct 2014 23:49:12 +0000 (19:49 -0400)]
(Partially) unify XDR for libuafs and libafs
The libuafs build was getting xdr_vector() from both afsaux.c and
xdr_update.c, but because of the rules for creating static libraries,
this did not cause build errors.
The libafs build is sensitive to duplicate symbols, and was only
getting xdr_vector() from afsaux.c; libafs was not building xdr_update.c
or xdr_refernce.c (that is not a typo).
Remove duplicate xdr_vector() from afsaux.c, and build xdr_update.c
and xdr_refernce.c into libafs.
Benjamin Kaduk [Wed, 15 Oct 2014 21:52:22 +0000 (17:52 -0400)]
Avoid AFS_version conflicts in uafs
libuafs links in both afsd.o and AFS_component_version_number.o;
afsd.c #includes AFS_component_Version_number.c, which causes
symbol conflicts when linking shared.
Don't include the version file when compiling for UKERNEL, to
avoid the conflict.
Benjamin Kaduk [Tue, 8 Apr 2014 01:54:46 +0000 (21:54 -0400)]
Do not install kauth manpages when kauth is disabled
Commit 5afe7a882b0bb90a515e505d9ffce4f644633f06 added a configure
option to disable the installation of the kauth suite, but did not
add any logic to disable the installation of the corresponding man
pages, so those man pages were always installed regardless of the
options to configure.
Add logic to doc/man-pages/Makefile.in to create .noinstall files
for man pages which should not be installed in the current configuration.
Depend on the Makefile (which will be regenerated by configure) in
this target so as to attempt to behave properly if configure is re-run
with different arguments in the same working tree.
Andrew Deason [Tue, 14 Oct 2014 22:02:55 +0000 (17:02 -0500)]
auth: Fix GetNthIdentityOrUser EOF return code
Before commit 0af17e7e, afsconf_GetNthUser always returned 1 on
failure, to indicate to the caller that they should stop traversing
over the list. After commit 0af17e7e, when reaching the end of the
list, we return EIO or -1. This causes 'bos listusers' invocations to
always fail, since 'bos' clients expect to get the code 1 when
reaching the end of the SUsers list.
To fix this, make GetNthIdentityOrUser always return -1 when searching
beyond the end of the list. For the newer interface
afsconf_GetNthIdentity, we return this as-is, to have a separate
return code specifically for EOF, but still allowing us to return any
positive error code in case of an error.
For the older interface afsconf_GetNthUser, return 1 in this
situation, to retain compatibility with the old interface (both at the
libauth level and on the wire).
Change-Id: I2db4760440d7846dc290a05fa24e24ec97a02f12
Reviewed-on: http://gerrit.openafs.org/7377 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com>
Benjamin Kaduk [Thu, 30 Oct 2014 23:38:50 +0000 (19:38 -0400)]
Attempt to make the server install bits current
Avoid using -noauth, and mention both the rxkad.keytab (1.6)
and the KeyFileExt (as 1.8, though it's only master at present).
To support these, move forward the use of kadmin to extract
the afs/cell principal's keytab.
Move the buserver's creation to the end of the list and mark it
as optional (many sites do not run the AFS backup suite).
Deindent some programlisting blocks so they don't flow off the
page as much in the PDF version.
Drop vos syncserv and vos syncvldb from the tasks for setting
up a new server; they should not be needed, as the new db server
should pick up the existing database when it joins the quorum.
Benjamin Kaduk [Mon, 3 Nov 2014 21:46:20 +0000 (16:46 -0500)]
Drop the non-DA fileserver
The instructions are clearer when we just tell people what
to do, and we think that dafs should be right for almost
everyone. Mention that the traditional fileserver is an
option and where to read about it, but nothing more.
Benjamin Kaduk [Mon, 3 Nov 2014 17:57:08 +0000 (12:57 -0500)]
Deorbit "Getting started on IRIX systems"
IRIX is mostly gone as an upstream. The case for removing this
is less clear than the case for removing the HP-UX docs, but
it still feels like clutter in this document.
Michael Meffie [Tue, 4 Nov 2014 00:06:15 +0000 (19:06 -0500)]
avoid writing loopback addresses into CellServDB
Do not use loopback addresses for the server side CellServDB file. Use
getaddrinfo() instead of gethostbyname() to look up a list of IPv4
addresses for a given hostname, and take the first non-loopback address.
This avoids writing a loopback address into the CellServDB on systems
such as Debian, which map the address 127.0.1.1 to the hostname in the
/etc/hosts file.
Andrew Deason [Tue, 28 Oct 2014 05:10:56 +0000 (00:10 -0500)]
LINUX: Avoid d_revalidate failure on mtpt mismatch
Currently, if afs_linux_dentry_revalidate is given an inode that
corresponds to a mtpt vcache ('vcp'), it resolves the mtpt to its root
dir if it's easy to do so (mvid and CMValid are set). Later on, we run
afs_lookup to see if looking up our dentry's name returns the same
vcache that we got; afs_lookup presumably will also resolve the mtpt
if it's easy to do so.
However, it is possible that afs_linux_dentry_revalidate and
afs_lookup will make different decisions as to whether or not they
resolve a mtpt to a dir. Specifically, if CMValid is cleared after
afs_linux_dentry_revalidate checks for it, but before afs_lookup does,
then afs_lookup will return a different vcache than
afs_linux_dentry_revalidate is expecting, even though the relevant
directory entry has not changed. That is, tvc is not equal to vcp, but
tvc could be a mtpt that resolves to vcp, or vice versa. CMValid can
be cleared by another thread at virtually any time, since this is
cleared in some situations when we're not sure if the mtpt resolution
is still valid (callbacks are broken, vldb cache entries expire, etc).
afs_linux_dentry_revalidate interprets this situation to mean that the
directory entry has changed, and so it eventually d_drop's the
associated dentry. The way that this manifests to users is that a
"fakestatted" mtpt can appear to be deleted effectively randomly, even
when nothing has changed. This can be a problem because this causes
the getcwd() syscall to return ENOENT when the working directory
involves such an affected directory.
To fix this situation, we just detect if afs_lookup returned either
'vcp' (our possibly-resolved vcache), or the original inode associated
with the dentry we are revalidating. If the returned vcache matches
either of these, then the entry is okay and we don't need to
invalidate or drop anything.
FIXES 131780
Change-Id: Ide1dd224d1ea1e29a82eb7130a010877cf4e9fc7
Reviewed-on: http://gerrit.openafs.org/11559 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: Anders Kaseorg <andersk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com>
Marc Dionne [Thu, 23 Oct 2014 15:27:55 +0000 (11:27 -0400)]
Linux 3.18: key_type no longer has a match op
Structure key_type no longer has a match op, and
overriding the default matching has to be done
differently.
Our current match op doesn't do anything special so there's
no need to try to override the defaults; just remove the
assignment of .match and the associated function.
Jeffrey Altman [Thu, 12 Jun 2014 00:53:09 +0000 (20:53 -0400)]
viced: kill CLIENT_TO_ZERO macro
Move all struct client fields that are to be zeroed upon structure
reuse to a new struct client_to_zero. Include the new structure
within struct client and call memset() on that structure.
Change-Id: I0f83f5f18b41bc0d4f8e1f7f8e04cd5508cbe4e1
Reviewed-on: http://gerrit.openafs.org/11288 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: D Brashear <shadow@your-file-system.com>
Jeffrey Altman [Wed, 11 Jun 2014 23:37:34 +0000 (19:37 -0400)]
viced: move host tmay fields before index
The index field and those after it in struct host do not get zeroed
when a host is reused. The placement of the tmay fields after index
in commit 9a0a8ca4d186cf953b87d9fae1a35f66090b060c results in the
use of uninitialized memory.
This change moves the tmay fields before index which permits
the HOST_TO_ZERO() macro to compute the correct size to be memset()
to zero.
Change-Id: I1f93bebb23c99eaa7826dafa8cd7497d1b49bb53
Reviewed-on: http://gerrit.openafs.org/11286 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com>
D Brashear [Tue, 14 Oct 2014 18:03:40 +0000 (14:03 -0400)]
libafs: avoid contaminating the return of lookup vnop
when we resort to checking the inlinebulk errors to see if a retry
is needed, do not overwrite the lookup return code; only decide if
a retry is needed.
problem case was where the first vnode returned EACCES and so
all vnodes were assumed to have failed, when just one did.
Andrew Deason [Mon, 27 Oct 2014 21:39:34 +0000 (16:39 -0500)]
rx: Reset lastSendData when resetting call
Currently we use call->lastSendData to attempt to detect a stalled
call, if it's been too long since the last time the call sent any
data. However, we never initialize lastSendData to anything when
creating a new call.
This means that when rx_NewCall (or rxi_NewCall) returns, lastSendData
can be nonzero. This can happen if we reuse a DALLY call, or if we
pull a call off of rx_freeCallQueue. This can be a time very far in
the past, since the lastSendData time has not changed since the last
time the call was used; it will remain unchanged until a user of the
new call writes something to the call stream.
This can be a problem between the time when a caller creates a new
call with rx_NewCall and when the caller actually writes something to
the stream. Between those two times, if lastSendData happens to be set
to a time in the past, we may call rxi_CheckCall on that call, and
abort the call for being idle. The call will thus be aborted before it
even sent any data on the wire.
This is of particular concern for multi_Rx calls, since those can
create a large number of call structures, possibly introducing a delay
between calling rx_NewCall and writing anything to the stream (if one
of the later rx_NewCall invocations blocks waiting for an open call
channel, for instance, all of the previous allocated calls will stick
around unused for potentially a long time).
One such multi_Rx call is done by the cache manager, where it
periodically uses multi_Rx to call RXAFS_GetCapabilities to probe
fileservers for reachability. If this issue occurs during that
operation you can see a large number of servers get marked down for
code -9 (RX_CALL_IDLE), and then get marked as coming back up.
To fix this, set lastSendData to 0 when resetting a call, along with
most of the other fields in a call, to indicate that the call has
never sent any data. As long as lastSendData is 0, the call will never
get aborted with RX_CALL_IDLE, and this situation will be avoided.
This ensures that this issue cannot happen, since rxi_ResetCall is
guaranteed to be called at some point whenever we reuse a call
structure for any reason.
Benjamin Kaduk [Mon, 6 Oct 2014 17:31:23 +0000 (13:31 -0400)]
Merge pam into the kauth configure option
Realistically, you shouldn't be using either kauth or pam. The
pam functionality provided by the module in our tree is only
useful in a kaserver-style environment, so it makes sense to merge
the two knobs.
Retain a separate enable_pam variable so that it can be overridden
on a per-architecture basis where it is known to not work. Consolidate
the two places where we did such checks, as well.
Change-Id: I6bf39ee5002f943548c51d089fe612f7e2f0501b
Reviewed-on: http://gerrit.openafs.org/11524 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: D Brashear <shadow@your-file-system.com>
Marc Dionne [Thu, 25 Sep 2014 10:52:12 +0000 (07:52 -0300)]
Linux 3.17: Deal with d_splice_alias errors
In 3.17 the logic in d_splice_alias has changed. Of interest to
us is the fact that it will now return an EIO error if it finds
an existing connected directory for the dentry, where it would
previously have added a new alias for it. As a result the end
user can get EIO errors when accessing any file in a volume
if the volume was first accessed through a different path (ex:
RO path vs RW path).
This commit just restores the old behaviour, adding the directory
alias manually in the error case, which is what older versions
of d_splice_alias used to do.
Change-Id: I5558c64760e4cad2bd3dc648067d81020afc69b6
Reviewed-on: http://gerrit.openafs.org/11492 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: D Brashear <shadow@your-file-system.com>
Marc Dionne [Tue, 9 Sep 2014 13:39:55 +0000 (10:39 -0300)]
Linux 3.17: No more typedef for ctl_table
The typedef has been removed so we need to use the structure
directly.
Note that the API for register_sysctl_table has also changed
with 3.17, but it reverted back to a form that existed
before and the configure tests handle it correctly.
Change-Id: If1fd9d27f795dee4b5aa2152dd09e0540d643a69
Reviewed-on: http://gerrit.openafs.org/11455 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> Reviewed-by: D Brashear <shadow@your-file-system.com>
Benjamin Kaduk [Wed, 17 Sep 2014 16:07:02 +0000 (12:07 -0400)]
Fix disk name initialization in scout
Scout needs to initialize names in scout_disk structures to prevent
the use of uninitialized data. However, '\0' is a NUL character
constant, i.e., the integer value 0, which is interpreted as NULL
(the pointer constant) in a pointer context, such as when assigned to
a variable of type char*. Since the name field in these structs is
passed to printing routines, the safe initialization value is the
empty string constant "", not a zero value.
Benjamin Kaduk [Wed, 17 Sep 2014 02:57:53 +0000 (22:57 -0400)]
Build fixes for recent FreeBSD -current
Let's try a new paradigm of using flag checks in the main code,
which are based off of precise version checks in the FreeBSD-specific
param.h file. It's not quite configure checks, but is much more
granular.
Benjamin Kaduk [Mon, 8 Sep 2014 17:47:33 +0000 (13:47 -0400)]
Tweak AFSDIR_PATH_MAX definition
On recent Debian, we run into runtime errors in the test suite
because _POSIX_PATH_MAX is only 256, and that buffer is too small
for a call to realpath(). Use PATH_MAX if it's available and larger
than _POSIX_PATH_MAX, in a way that should be safe even when PATH_MAX
is not defined.
Change-Id: I39127e88d92b358245ece21131219380ca4be98a
Reviewed-on: http://gerrit.openafs.org/11453 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: Chas Williams - CONTRACTOR <chas@cmf.nrl.navy.mil> Reviewed-by: Perry Ruiter <pruiter@sinenomine.net> Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: D Brashear <shadow@your-file-system.com>
Benjamin Kaduk [Mon, 8 Sep 2014 17:42:27 +0000 (13:42 -0400)]
Let mancheck_utils ignore version subcommands
We don't have a man page for the 'version' subcommand, which has
"always" been present but only recently was exposed to the usage.
It's okay to not have a man page for it, so tell the test infrastructure
to not complain about its absence.
Change-Id: Ife834d41797d1d1efe403b204736ac85d62724e9
Reviewed-on: http://gerrit.openafs.org/11452 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com> Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: D Brashear <shadow@your-file-system.com>
Benjamin Kaduk [Fri, 19 Sep 2014 18:39:04 +0000 (14:39 -0400)]
Build hcrypto with libtool
Or rather, with lwptool, since we need a LWP version as well as
the various pthreaded versions.
The previous version was the initial version, 1.1, but since we're
switching to libtool, bump the version to 2.0 just to be safe.
Libtool abstracts away the extra logic that had previously been needed
to build different copies of rand-fortuna for the pthreaded and LWP
libraries.
As for roken, we must install both shared and static libraries
to $(TOP_LIBDIR) for unity of consumption, but remove the libtool
archive after instllation.
Change-Id: Ibc530a1fa4baa7a38b44eb3e0719e1905a6fe269
Reviewed-on: http://gerrit.openafs.org/11482 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: D Brashear <shadow@your-file-system.com>
Benjamin Kaduk [Tue, 23 Sep 2014 22:19:09 +0000 (18:19 -0400)]
Allow external hcrypto
Put the configure checks into a separate file in src/cf, following
the same general structure as the roken checks.
Allow explicitly requesting the internal version, or checking
what's in the default paths, or providing a specific hcrypto root
or lib/include dirs for Debian compatibility.
We must still always compile libafshcrypto_lwp.a for use by LWP
binaries, from the bundled sources, but other binaries will use
the system version.
The hcrypto headers have an unfortunately large number of dependencies,
including depending on being able to find each other by including
<hcrypto/foo.h> paths. As such we must pass both the user-supplied
directory and $dir/hcrypto to the preprocessor in order for things
to work, and we also may need to revisit the includes used in the
configure check for use on non-linux systems due to the dependencies
on system headers.
Change-Id: Idcba1418a19a7b562335524c911d69dc84268177
Reviewed-on: http://gerrit.openafs.org/11481 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: D Brashear <shadow@your-file-system.com>
Benjamin Kaduk [Tue, 23 Sep 2014 20:58:08 +0000 (16:58 -0400)]
Link aklog against LIB_hcrypto
This was the last place where libafshcrypto.a was explicitly referenced,
preventing the use of an out-of-tree hcrypto library.
We will continue to need to build the in-tree code to produce a
libafshcrypto_lwp.a library for use in LWP applications, until we
do not have any more LWP applications, but some systems (such as
Debian) have a desire to avoid bundled libraries, so we should
facilitate the use of an external libhcrypto where possible.
Many consumers of libafshcrypto_lwp.a will be removed when the
LWP versions of various modules are removed after 1.8 is branched.
Change-Id: I23049866caae9c16ffb2ec32c5e7b058465a26ba
Reviewed-on: http://gerrit.openafs.org/11480 Reviewed-by: Benjamin Kaduk <kaduk@mit.edu> Reviewed-by: D Brashear <shadow@your-file-system.com> Tested-by: D Brashear <shadow@your-file-system.com>