Currently, the volserver process doesn't register any signal handlers
for a shutdown sequence. When the fileserver process group is shutdown,
the bosserver sends a SIGTERM to the volserver process, and the
volserver process immediately dies. If any volumes are attached by the
volserver at the time (e.g., for dumping or restoring a volume), the
volume is not cleanly detached, and usually must be salvaged later on
before it can be used. This can be confusing to administrators, since a
volume may need salvage even though we never logged a reason why the
volume got in an unclean/broken state.
To improve this situation, add a signal handler to the volserver so we
can go through a shutdown process. In the future, we can add a more
complex shutdown process that may interrupt running volume transactions,
or wait for transactions to go away, or something else. But for now,
just as a first step, add a very simple shutdown process that just logs
what transactions are being interrupted, so we at least give a clue as
to why some volumes were not cleanly detached.
With this commit, the volserver now logs some messages if transactions
are running when it's shutdown. For example, a VolserLog may look like
this:
Mon Jan 13 10:11:32 2025 Volserver shutting down on signal 15
Mon Jan 13 10:11:32 2025 Interrupting transaction 2 for volume 536871057 partition /vicepa; volume may need salvage
Mon Jan 13 10:11:32 2025 Interrupting transaction 1 for volume 536871052 partition /vicepa; volume may need salvage
Mon Jan 13 10:11:32 2025 Volserver shutdown complete
With this commit, the volserver process also exits with code 0 on a
normal shutdown, instead of being terminated by the SIGTERM signal. The
BosLog entry for shutting down a volserver process used to look like
this:
Mon Jan 13 10:11:32 2025 dafs:vol exited on signal 15
and with this commit, now looks like this:
Mon Jan 13 10:11:32 2025 dafs:vol exited with code 0
This commit just adds the signal handler for the pthreaded volserver;
don't bother adding a code path for the obsolete LWP volserver.
Change-Id: I9f8321f845d45f6b37d9c69d12d54d1830d68b23
Reviewed-on: https://gerrit.openafs.org/16083
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
The current developer pool prefers to always use braces, for the
reasons given in the updated guidance.
This will apply to new code going forward, and does not imply a desire
to do a sweeping pass to change current instances.
Change-Id: If6e157438f222ca805506cc55cd61b969dce63a3
Reviewed-on: https://gerrit.openafs.org/15717
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
We don't really need a "Danger Will Robinson"-style warning at this
point.
Also update the browsing URL to use TLS (https://).
Change-Id: I102b8bd8a8c91c68d6d6383ea146a0cb57b8d571
Reviewed-on: https://gerrit.openafs.org/15716
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Right now, that's just Makefile and plain text.
We'll want to add more eventually.
Change-Id: I10c559fe94c7c634e1de6d98020a1c7a391da2b4
Reviewed-on: https://gerrit.openafs.org/15629
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
The first section was a mix of GNU ident options and build system
guidance. Move the former into the style section and create a new
section for the latter.
Remove specific suggested compiler flags in favor of --enable-checking.
Change-Id: I1fc86ded6faee13575dd4913586a829f75daeef8
Reviewed-on: https://gerrit.openafs.org/15627
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Attempt to enumerate things that reviewers should look for, to ensure
a consistent quality of review. This should be a good start; we can
add to it in the future as we discover more things that we'd like
reviewers to consider.
As a side effect, attempt to enumerate the bits of C99 that we rely on,
past the C89 baseline that we otherwise assume.
Change-Id: I047cc0accc99d2aea7bb7eb1c35ae148bff2ee7d
Reviewed-on: https://gerrit.openafs.org/15611
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: Benjamin Kaduk <kaduk@mit.edu>
Since commit 4505af8002 (aix: add atomic support), rx_atomic.h has used
sys/atomic_op.h on AIX 6.1 and newer, but sys/atomic_op.h is available
as far back as AIX 4.1. So, use sys/atomic_op.h on AIX 4.1+, so older
versions of AIX can use proper atomics instead of the fallback
implementation.
Change-Id: I49e2f257abe05c25aaebe06847c5230392a93780
Reviewed-on: https://gerrit.openafs.org/15975
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Currently, GetLastComponent() always stats (lstat) the file received as
an argument. However, the status information about this file is only
used when 'literal' is false. That said, skip lstat() when 'literal' is
true.
While here, zero out 'statbuff' at the beginning of GetLastComponent()
just to make sure it won't be used uninitialized in the future.
Change-Id: I3f332c53ae688d6f74276bcdbf2f9f61605ec9ad
Reviewed-on: https://gerrit.openafs.org/14840
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, make_kbuild_makefile.pl generates a Makefile for building our
Linux kernel module by listing our various objects in 'openafs-objs',
and symlinking the relevant source file from src/foo/bar.c into
MODLOAD-*/bar.c. For example, src/libafs/MODLOAD-*/afs_init.c is a
symlink to src/afs/afs_init.c.
We determine where each source file lives by looking at our Makefile
rules. This works for all of our source files, except
AFS_component_version_number.c, which has no single location in the
tree, but is built inside every subsystem. For
AFS_component_version_number.c, we don't make a symlink, but instead
copy the rules from Makefile.version so that
AFS_component_version_number.c is generated locally, and does not use a
symlink like our other source files.
The rules in Makefile.version look like this:
AFS_component_version_number.o: AFS_component_version_number.c
AFS_component_version_number.c: [...]/src/config/Makefile.version
[logic to generate AFS_component_version_number.c]
But for the Linux build before Linux 6.13, that doesn't work as-is
because the Linux buildsystem is not running in our MODLOAD directory,
but inside the Linux source tree. So, to make this work,
make_kbuild_makefile.pl modifies the rules so they look like this:
/path/to/src/libafs/MODLOAD-x.y.z/AFS_component_version_number.o: /path/to/src/libafs/MODLOAD-x.y.z/AFS_component_version_number.c
/path/to/src/libafs/MODLOAD-x.y.z/AFS_component_version_number.c: [...]/src/config/Makefile.version
[logic to generate AFS_component_version_number.c]
Which works, before Linux 6.13. After the build runs, our source files
look like this, for example:
$ ls -l src/libafs/MODLOAD-*/AFS_component_version_number.c src/libafs/MODLOAD-*/afs_init.c
-rw-r--r-- 1 [...] src/libafs/MODLOAD-x.y.z/AFS_component_version_number.c
lrwxrwxrwx 1 [...] src/libafs/MODLOAD-x.y.z/afs_init.c -> /path/to/src/afs/afs_init.c
With Linux 6.13, Linux changed how the kbuild process builds external
kernel modules with this commit:
'kbuild: change working directory to external module directory with M='
(13b25489b6f8)
which is followed by additional follow-up changes within the merge
commit:
Merge tag 'kbuild-v6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild updates from Masahiro Yamada:' (6a34dfa15d6e)
With these changes, our working directory is now src/libafs/MODLOAD-*
when building the openafs kernel module, and we try to build
AFS_component_version_number.o instead of
/path/to/.../AFS_component_version_number.o. As a result, 'make' doesn't
know how to generate AFS_component_version_number.c, and the build
fails:
make[8]: *** No rule to make target 'AFS_component_version_number.o', needed by 'openafs.o'. Stop.
make[7]: *** [/usr/src/linux-6.13/Makefile:1989: .] Error 2
make[6]: *** [/usr/src/linux-6.13/Makefile:251: __sub-make] Error 2
make[5]: Leaving directory '/usr/src/linux-6.13/'
FAILURE: make exit code 2
make[4]: Leaving directory '/home/../openafs/src/libafs/MODLOAD-6.13.0-rc2-SP'
make[4]: *** [Makefile.afs:283: openafs.ko] Error 1
To fix this, change make_kbuild_makefile.pl to create a symlink for
AFS_component_version_number.c just like it does for all other source
files. Use a target of src/libafs/AFS_component_version_number.c, and
make sure that AFS_component_version_number.c is generated for the
'setup' libafs target.
We have to hard-code this special case for
AFS_component_version_number.c, since none of our Makefile rules specify
a full path to AFS_component_version_number.c as a dependency for
AFS_component_version_number.o. But otherwise,
AFS_component_version_number.c is now treated the same as all other
source files.
With this commit, our source files now look like this:
$ ls -l src/libafs/MODLOAD-*/AFS_component_version_number.c src/libafs/MODLOAD-*/afs_init.c
lrwxrwxrwx 1 [...] src/libafs/MODLOAD-x.y.z/AFS_component_version_number.c -> /path/to/src/libafs/AFS_component_version_number.c
lrwxrwxrwx 1 [...] src/libafs/MODLOAD-x.y.z/afs_init.c -> /path/to/src/afs/afs_init.c
Remove the make_kbuild_makefile.pl code that copies the Makefile.version
rules, since AFS_component_version_number.c is not generated locally
anymore.
Written in collaboration with cwills@sinenomine.net.
Change-Id: Ia179f760022c9d9102e4357f38b38632d21de23b
Reviewed-on: https://gerrit.openafs.org/16034
Tested-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
In rx_atomic.h, our "fallback" implementation of atomics uses a global
lock, using our afs_kmutex_t/MUTEX_ENTER() abstractions, but rx_atomic.h
doesn't include any headers to define afs_kmutex_t et al. Most callers
include rx_lwp.h or an equivalent before rx_atomic.h, but this is not
guaranteed, and tests/rx/atomic-t.c (for example) does not do this.
If someone tries to build OpenAFS on a platform that doesn't have a more
specific rx atomic implementation, this means that building atomic-t
fails:
In file included from /.../tests/rx/atomic-t.c:34:
/.../include/rx/rx_atomic.h: In function ‘rx_atomic_set’:
/.../include/rx/rx_atomic.h:402:5: error: implicit declaration of function ‘MUTEX_ENTER’ [-Werror=implicit-function-declaration]
MUTEX_ENTER(&rx_atomic_mutex);
^~~~~~~~~~~
/.../include/rx/rx_atomic.h:402:18: error: ‘rx_atomic_mutex’ undeclared (first use in this function); did you mean ‘rx_atomic_set’?
MUTEX_ENTER(&rx_atomic_mutex);
^~~~~~~~~~~~~~~
rx_atomic_set
To fix this, include rx_lwp.h in the "fallback" branch of rx_atomic.h
(or rx_kmutex.h for the kernel, or rx_pthread.h for pthreads). This
should ensure that our locking abstractions are defined appropriately so
we can use the rx_atomic_mutex global lock.
Change-Id: Ie281161f4920a5b6b5b23acd77f7677806245673
Reviewed-on: https://gerrit.openafs.org/16062
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Tested-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Commit e4d8329619 (lwp: Build src/lwp/test) fails to build on Solaris
11.3 or older due to undefined socket and resolver API symbols,
including recv, send, gethostbyname, socket, etc:
Undefined first referenced
symbol in file
recv selsubs.o
send selsubs.o
gethostbyname selclient.o
socket selclient.o
connect selclient.o
ld: fatal: symbol referencing errors
This is because on Solaris, these have historically been supplied via
-lsocket, -lresolv, and other libraries as defined in the OpenAFS
variable XLIBS.
Add XLIBS to the recipes for selclient and selserver to avoid these
errors when building on Solaris 11.3 or older.
On Solaris 11.4, XLIBS is not required to build because the APIs
formerly found via XLIBS are now largely provided in libc.so instead,
with libsocket.so and libresolv.so maintained for compatibility as
filters on libc.so.
Change-Id: I19a5cca20bd9ac335cd0e6424ed8aeb85d574bc8
Reviewed-on: https://gerrit.openafs.org/16033
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
On AIX, there are two kernel extensions, and each
is loaded by a utility in src/export, cfgexport,
and cfgafs. This utility calls the AIX "sysconfig"
system call to load the extension into the kernel.
Historically this usually works so error messages
are not often seen, though the programs have
facilities to display error messages.
Error messages from the loading of kernel extensions
are displayed using the execerror utility. Beginning
with AIX 4.2, this utility was moved from
/etc/execerror to /usr/sbin. The AFS cfg utlities
were never updated. If an error occurs during
loading of one of the extensions, the user receives
the following misleading error:
SYS_KLOAD: No such file or directory
This error is not actually the result of the failed
extension load, but actually the result of the next
source code line:
perror("SYS_KLOAD");
This error is actually a statement that the utility
cannot find execerror.
Update the utilities to call execerror from the
correct location starting with AIX 4.2.
Change-Id: I91bf7d93c35d536c9b3ad0f97f02c5a0289cbf63
Reviewed-on: https://gerrit.openafs.org/16006
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Make the src/lwp/test directory built by default, by 'cd'ing into 'test'
from src/lwp after building the lwp library. Also fix numerous errors
and warnings to get the directory buildable, including:
- Change many functions to be declared with proper prototypes
- Change many functions and variables to be 'static', since they are
only used inside one compilation unit
- Remove several unused variables
- Include stdlib.h for exit() et al, string.h for strcmp(), fcntl.h for
open(), time.h for localtime() et al, and arpa/inet.h for inet_ntoa().
- Make main() return an int
- Change various signal handler callbacks to be the proper type
- Change LWP_CreateProcess callbacks to be the proper type
- Use %p to print various pointers, instead of 0x%x
- Cast various time-based variables to int for printing with %d
- Remove extra prototypes for IOMGR_Select()
- Give accept() a socklen_t* instead of an int*
- Remove the unused make targets 'system' and 'noversion'
- Update the make rule for the 'test' program to use modern conventions
and use AFS_LDRULE, and avoid passing -p to the compiler
- Remove unnecessary links to util.a
- Remove testlwp.c, which has no main() and isn't linked by
anything else
- In selserver.c:handleWrite(), declare 'c' as an unsigned char (so we can
compare against END_DATA, which is larger than a signed char), and use
'c' as the byte read in from read(), so 'c' is not used uninitialized.
- Change test.c to use LWP_WaitProcess() instead of LWP_MwaitProcess().
LWP_MwaitProcess() has no callers outside of lwp, and was declared
static, effectively making it private, in commit ff988ead4e
(lwp-protoize-20080310).
Also add the built test programs to .gitignore.
Change-Id: I6958a78ae271dbcb865df5d7f30019ba05160b56
Reviewed-on: https://gerrit.openafs.org/16014
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Several of the definitions in src/lwp/lwp.h are redundant
between AFS_NT40_ENV and all other platforms. Clean
these up to make lwp.h more readable.
Change-Id: Ieba4bf00c4e7639c6ed0c893de8f26bdb322675b
Reviewed-on: https://gerrit.openafs.org/16031
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
'rw' is an old test program; move it to src/lwp/test with the other old
tests.
While we're here, don't link 'rw' with util.a; it's not needed.
Change-Id: I68e0ed5eb07c7b40d1e1e8069b953157fd1087f3
Reviewed-on: https://gerrit.openafs.org/16013
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
When building rw in src/lwp, some compilers throw a warning that
LWP_TerminateProcessSupport is not declared. Here is an example:
/opt/IBM/openxlC/17.1.0/bin/ibm-clang -g -O -I/home/build/openafs/src/config -I/home/build/openafs/include -I. -I. -o rw.o -c rw.c
rw.c:242:5: warning: implicit declaration of function 'LWP_TerminateProcessSupport' is invalid in C99 [-Wimplicit-function-declaration]
LWP_TerminateProcessSupport();
^
1 warning generated.
Declare LWP_TerminateProcessSupport in lwp.h. Also update the function
signatures in src/lwp/lwp_nt.c and src/lwp/test/testlwp.c to match.
Change-Id: I86c016d7e6000dc341d8cf314173fc55f0a77331
Reviewed-on: https://gerrit.openafs.org/15979
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commit 4392020ba0 (fs: Restrict 'fs flushall' to root) changed the
fs_flushall manpage to document the new behavior, but now the manpage
lacks any information about old versions. Document the old behavior as
well, to be clear that "old" (current stable) versions do not require
root access.
Change-Id: Icbe6843d8ed0a523eb4df7136ad6f336f8b50fa6
Reviewed-on: https://gerrit.openafs.org/16030
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
The lwp test utility "rw" is not built by default. But if someone
builds it explicitly, we should clean it during an clean pass.
Also add it to a .gitignore file.
Change-Id: I0ad90e504dedfaa71268221b443c4414327892d4
Reviewed-on: https://gerrit.openafs.org/15972
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
The NON_SHARED make variable has never been set since commit 838e1eae1a
(build-system-specific-makefile-configuration-from-configure-20011031),
and appears to have been for some DUX build logic. Some references have
still been hanging around; remove them.
Change-Id: I12c917f1f55041c10d6db7a9f18e9ba31bc24f7d
Reviewed-on: https://gerrit.openafs.org/16003
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
LIBSYS_AIX_EXP has been unreferenced since commit 2ec9b1db03
(shlib-overhaul-20060802), where it was replaced by a hard-coded
"afsl.exp". A few places have still been setting LIBSYS_AIX_EXP; remove
them.
Change-Id: I28aad80ac0edde3a71f9e6f7b2817ddf992b2fb4
Reviewed-on: https://gerrit.openafs.org/16004
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Currently, the fileserver does not use the HashTable / "fehash" data
in fsstate.dat; instead, we put FEs on our in-memory HashTable as we
load in the FEs from disk. But if our HashTable has FEHASH_SIZE_OLD
buckets in it, we still write out the HashTable to disk, in case older
fileservers or other utilities want to use it.
In this commit, change the fileserver to never write out the HashTable
data to fsstate.dat, since it's not really useful anymore. And since
we never store the HashTable in fsstate.dat, stop defaulting to
FEHASH_SIZE_OLD hash buckets when the -cb option is less than 64k (the
default from -L). Instead, always start at FEHASH_SIZE_OLD, and count
up until we get a reasonable hash chain length.
Change-Id: I40ee7d20e28fbf73d044546e967e3cc2774fa145
Reviewed-on: https://gerrit.openafs.org/14739
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Several static analysis tools have identified various problems:
- missing checks to ensure *alloc was successful (infer)
- memory leak (infer)
- possible null pointer dereference (cppcheck)
To resolve the above problems:
- add checks to ensure *alloc was successful before using the memory
- free memory before returning
- move pointer based assignment to after a check for NULL
This commit is a reorganization of commits developed by Pat Riehecky,
who ran the static analysis tools and developed the fixes.
afscp_dir.c:606: Memory dynamically allocated by `malloc`, indirectly
via call to `afscp_DupFid()` on line 602 is not freed after the last
access at line 606, column 9
afscp_dirops.c:44: Either the condition 'dir==NULL' is redundant or
there is possible null pointer dereference: dir. Null pointer
dereference
Change-Id: I17c8b7b45d581f7c84d8a2930de73783e2ae18be
Reviewed-on: https://gerrit.openafs.org/14712
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
If we are configured with --enable-kauth and --disable-shared, 'make
install/dest' currently fails for pam, since we never generate the
shared library files:
make[3]: Entering directory '.../src/pam'
if [ "xyes" = "xyes" ]; then \
/usr/bin/install -c -d .../amd64_linux26/dest/lib; \
/usr/bin/install -c -m 644 .libs/pam_afs.so .../amd64_linux26/dest/lib; \
/usr/bin/install -c -m 644 .libs/pam_afs.krb.so .../amd64_linux26/dest/lib; \
fi
/usr/bin/install: cannot stat '.libs/pam_afs.so': No such file or directory
/usr/bin/install: cannot stat '.libs/pam_afs.krb.so': No such file or directory
make[3]: *** [dest] Error 1
Building pam plugins doesn't make sense if shared libraries are
disabled, so just turn off pam if --disable-shared is specified, similar
to what we do if pam headers aren't available.
While we're here, slightly restructure the code for setting HAVE_PAM, to
make it easier to add pam-disabling conditions like this.
Change-Id: I7d1f98267ba342dbd7290de40a07da904e65dbe3
Reviewed-on: https://gerrit.openafs.org/15998
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
When building with --disable-static on AIX, linking various binaries
that call syscall() currently fail:
/bin/sh ../../libtool --quiet --mode=link --tag=CC
/opt/IBM/xlC/16.1.0/bin/xlc_r -static [...] -o afsd afsd.o afsd_kernel.o [...]
ld: 0711-317 ERROR: Undefined symbol: .syscall
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make: The error code from the last command is 8.
There is indeed no symbol 'syscall', because that is a
(confusingly-named) syscall provided by our libafs kernel module. To
tell the linker that syscall() is a syscall, import our afsl.exp by
passing the -Wl,-bI: flag to the linker for all binaries that call it.
To make it easier to see what's going on, add the AIX_ONLY subst var, to
make it easy to create an AIX-only line in the relevant Makefiles.
Change-Id: Id57bf9e6a438c57eded693a1e4ed39b08d36e3c7
Reviewed-on: https://gerrit.openafs.org/15999
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Tested-by: Ben Huntsman <ben@huntsmans.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Since OpenAFS 1.0, src/venus/test/getinitparams has contained a
reference to 'lpioctl', but this is not exported by liboafs_sys.la.sym.
This causes the build to fail with --disable-static:
$ make V=0
LD .../src/venus/test/getinitparams
/usr/bin/ld: getinitparams.o: in function `GetInitParamsCmd':
.../src/venus/test/getinitparams.c:75: undefined reference to `lpioctl'
collect2: error: ld returned 1 exit status
FAILED COMMAND: /bin/bash ../../../libtool --quiet --mode=link --tag=CC gcc [...] -o getinitparams getinitparams.o .../src/sys/liboafs_sys.la [...]
Add the missing symbol to liboafs_sys.la.sym. Note that lpioctl() isn't
a function on AIX (it's a syscall), but on all other platforms it is a
function provided by libsys.
Change-Id: Ie54c46a8eb1de92698472636860186fe274daf1c
Reviewed-on: https://gerrit.openafs.org/15994
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Tested-by: Ben Huntsman <ben@huntsmans.net>
Since OpenAFS 1.0, xstat_fs_test and xstat_cm_test have contained
references to RXAFS_GetXStats and RXAFCB_GetXStats, respectively, but
these are not exported by our liboafs_fsint.la.sym. This causes the
build to fail with --disable-static:
$ make V=0
LD .../src/xstat/xstat_cm_test
/usr/bin/ld: ./.libs/liboafs_xstat_cm.so: undefined reference to `RXAFSCB_GetXStats'
collect2: error: ld returned 1 exit status
FAILED COMMAND: /bin/bash ../../libtool --quiet --mode=link --tag=CC gcc [...] -o xstat_cm_test xstat_cm_test.o liboafs_xstat_cm.la [...]
[...]
LD .../src/xstat/xstat_fs_test
/usr/bin/ld: ./.libs/liboafs_xstat_fs.so: undefined reference to `RXAFS_GetXStats'
collect2: error: ld returned 1 exit status
FAILED COMMAND: /bin/bash ../../libtool --quiet --mode=link --tag=CC gcc [...] -o xstat_fs_test xstat_fs_test.o liboafs_xstat_fs.la [...]
Add the missing functions to liboafs_fsint.la.sym.
Change-Id: If58262eb017fd12819f59edda1e99dd9a6e8042b
Reviewed-on: https://gerrit.openafs.org/15993
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since OpenAFS 1.0, kauth's Andrew_StringToKey() has contained a
reference to crypt(). This is provided by $(LIB_crypt) (usually
-lcrypt), but not all everything that links against liboafs_kauth.la
also links to LIB_crypt. This causes the build to fail with
--disable-static:
$ make V=0
LD .../src/tbutc/butc
/usr/bin/ld: ../../src/kauth/.libs/liboafs_kauth.so: undefined reference to `crypt'
collect2: error: ld returned 1 exit status
FAILED COMMAND: /bin/bash ../../libtool --quiet --mode=link --tag=CC gcc [...] -o butc [...] ../../src/kauth/liboafs_kauth.la [...] -lafshcrypto -lrokenafs -lpthread -lresolv
To fix this, link against LIB_crypt when building liboafs_kauth.la, so
anything linking against liboafs_kauth.la should also link against
LIB_crypt.
Change-Id: I9f46f3c429848b1ae67c8bf28a7698df0c084892
Reviewed-on: https://gerrit.openafs.org/15992
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since OpenAFS 1.0, the fileserver has contained references to
rx_WritevAlloc and rx_WritevProc (via rx_Writev()), but our
liboafs_rx.la.sym has never exported these. This causes the fileserver
to fail to build with --disable-static:
$ make V=0
[...]
LD .../src/viced/fileserver
/usr/bin/ld: afsfileprocs.o: in function `FetchData_RXStyle':
.../src/viced/afsfileprocs.c:6345: undefined reference to `rx_WritevAlloc'
/usr/bin/ld: .../src/viced/afsfileprocs.c:6359: undefined reference to `rx_WritevProc'
collect2: error: ld returned 1 exit status
FAILED COMMAND: /bin/bash ../../libtool --quiet --mode=link --tag=CC gcc [...] -o fileserver [...]
Add the missing symbols to liboafs_rx.la.sym.
Change-Id: I88b73ed4b639e9c128c8d3c80bc60fc99e6aa3e1
Reviewed-on: https://gerrit.openafs.org/15991
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
On Linux and possibly other platforms, if configure is run with the
--disable-static option, anything linking against liboafs_rxkad.la will
fail:
gcc [...] -o afsd [...] .../src/auth/liboafs_auth.la [...] -lafshcrypto -lrokenafs -lpthread -lresolv
/home/build/openafs/src/rxkad/.libs/liboafs_rxkad.so: undefined reference to `rxs_Ref'
/home/build/openafs/src/rxkad/.libs/liboafs_rxkad.so: undefined reference to `rxs_SetRefs'
/home/build/openafs/src/rxkad/.libs/liboafs_rxkad.so: undefined reference to `rxs_DecRef'
collect2: error: ld returned 1 exit status
make: *** [afsd] Error 1
The references to these symbols were added in commit 9d7b94493c (rx: Use
atomics for rx_securityClass refcounts), but that commit didn't add them
to the liboafs_rx.la.sym symbol file. Add them to allow the build to
complete with --disable-static.
Change-Id: I14b348d1be6bf6e8f512d1cac6a70a58fd6f39a1
Reviewed-on: https://gerrit.openafs.org/15988
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Currently, our HashTable for FileEntry structs is a fixed size
(FEHASH_SIZE, 512). If we have a large number of callbacks, this can
lead to very long hash chains, which can cause the fileserver to
consume high amounts of CPU when finding, deleting, or especially
adding new callbacks. This is especially bad since callbacks are
managed under the global H_LOCK.
To improve this, use our configured callback limit (-cb) to build an
appropriately-sized HashTable at initialization, instead of using a
hard-coded size. We compute this by dividing the -cb value by the
desired hash chain length (FE_CHAIN_TARGET, 16), then rounding up to
the nearest power of 2 at least as big as the old FEHASH_SIZE, 512.
For DAFS, a copy of our HashTable is included in the fsstate.dat file
on disk, so changing our hashtable size potentially changes the data
in fsstate.dat. However, we currently do not read in the hashtable
data from fsstate.dat, since it's not very useful; we only write it
out in case other utilities or older fileservers need it.
Older fileservers, however, will not read an fsstate.dat with a
hashtable that does not have exactly FEHASH_SIZE. So if we have a
differently-sized hash table, we're breaking compatibility with those
fileservers anyway, so don't write out our hashtable data at all.
This commit also changes the format of the callback.dump file, since
it did not allow for a variable-length hashtable. We create a new
MAGICV3 magic to define the new format, and add some logic to the
'cbd' utility to understand it. We still write out our hashtable to
this file since it's for debugging, and the hashtable data may be
useful in that context.
Move FEHash to callback.c, since it now relies on the callback.c-only
FEhashsize, and move FEHASH_SIZE_OLD along with it.
[adeason@sinenomine.net: Don't write out non-old-sized hashtable. Move
FEHash &co to callback.c. Various other minor edits.]
Change-Id: I54de91c54c5fcb526f880bc63ba10c1b3eb0aaf0
Reviewed-on: https://gerrit.openafs.org/14731
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Currently, if the fileserver tries to restore fsstate.dat and the
included FE hashtable does not match our in-memory size (FEHASH_SIZE),
we'll discard the entire state file. This is unnecessary, since we
could just add the FEs to our hashtable ourselves; the on-disk
hashtable data is not required.
Furthermore, loading the hashtable from disk isn't even terribly
efficient when the hashtable sizes do match, since any indices need to
be converted from the on-disk values to in-memory values
(fe_OldToNew). So if we're processing the FE hashtable indices anyway,
we might as well just add them to the hashtable like normal, and
ignore the values on disk.
So, ignore loading the "fehash" data from the fsstate file, and just
add file entries to our hashtable as we read them in. This ends up
being slightly faster, simpler, and more flexible, since we don't need
to worry about reflecting any changes to our hashtable in the
fsstate.dat file.
At least for now, we still write our hashtable data to fsstate.dat, in
case other utilities (or older fileservers) need it.
[adeason@sinenomine.net: Converted to always ignore on-disk hashtable
data.]
Change-Id: Ie53a24a5d24906ac55d13eb22713b73dc4bfaab2
Reviewed-on: https://gerrit.openafs.org/14738
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Log how long it took to restore our fsstate.dat data, and how many
FEs/CBs we loaded. This may be of interest to anyone looking at the
impact of different relevant options (such as -fs-state-verify), and
how much callback state is being restored.
Note that we're not adding any new messages, just adding some
additional info to an existing message.
Change-Id: I86bc384919d1c6c141558c23d2c53def2e8916f8
Reviewed-on: https://gerrit.openafs.org/14737
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Some code paths in our state-restoring logic don't log the specific
reason why restoring state failed. These cases shouldn't happen often,
but try to at least log something for them, to try to make sure we
always give a reason.
[adeason@sinenomine.net: Added more messages.]
Change-Id: Ib7c082c4ec221460f7c07be577e78c700f8850a5
Reviewed-on: https://gerrit.openafs.org/14728
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
When verifying the sanity of host and callback state at startup and
shutdown, dafileserver attempts to detect loops in various structures
by imposing arbitrary hard-coded limits (e.g.
FS_STATE_HCB_MAX_LIST_LEN, 100000 callbacks per host).
However, it is possible for AFS clients with heavy RW workloads to
legitimately exceed some of these limits, if the dafileserver itself
is configured with -cb higher than 100000, for instance.
When this occurs, the dafileserver will falsely invalidate the
fsstate.dat file at shutdown:
"cb_stateVerifyFCBList: error: list length exceeds 100000 (h->index=1);
assuming there's a loop"
The dafileserver will then refuse to load the invalid fsstate.dat file
at startup, defeating the callback preservation feature just when it
is most sorely needed - when there are hundreds of thousands of
callbacks.
These arbitrary limits are unnecessary, since we already know the
number of structures we're processing for all of these cases (CBs,
FEs, and hosts). So just get rid of the hard-coded limits, and use the
actual limit for the relevant structure instead:
For CBs and FEs, we can never have more than 'cbstuff.nblks' entries
whether we're loading or saving state, so just use that limit for
simplicity.
For hosts, the number of entries is either in the dump file (when
restoring state), or just in our 'hostCount' global (when saving
state). To make sure a corrupted state file doesn't cause the host
limit to be unreasonably high, impose a new, higher, arbitrary limit
on the number of hosts (FS_STATE_H_MAX_LIST_LEN, set to 100M).
[adeason@sinenomine.net: Raise limits for _all_ structures.]
Change-Id: I525916dc6189b887e4625371e81afac98f12a651
Reviewed-on: https://gerrit.openafs.org/14727
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
When the fileserver saves its callback state to disk on shutdown,
fs_stateCreateDump sets state->mode to FS_STATE_DUMP_MODE. But this is
after some code paths have already looked at state->mode, such as
fs_stateSave -> h_stateVerify -> h_Enumerate_r -> h_stateVerifyHost ->
h_stateVerifyAddrHash. This doesn't cause any problems right now,
since the value of FS_STATE_DUMP_MODE is 0, and we zero the whole
'state' struct when it is initialized.
This is confusing, though, so move the assignment of
FS_STATE_DUMP_MODE to earlier in the state-saving process, before
anything looks at it.
To try to avoid possible uninitialized use of state->mode in the
future, change the FS_STATE_*_MODE constants so that none of them are
0, and make sure that code checking the 'mode' checks that the mode is
a valid constant.
[adeason@sinenomine.net: Added state mode checking.]
Change-Id: Ifa5e5aabdb7c7b4a50a1b397620aafa7c48c223e
Reviewed-on: https://gerrit.openafs.org/14726
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
In a few perl scripts (that happen to be for macOS), we check whether
'$? >> 8' is zero to see whether a command failed. But the value of
'$? >> 8' is just the exit code of the process. If it instead, for
example, was killed by a signal, there is no exit code, and '$? >> 8'
may not be accurate (the terminating signal is in '$? & 127'). We should
check if $? is nonzero at all to see if an error happened.
To avoid any possible issues, update all of our checks for command
failure to check if $? is nonzero, instead of '$? >> 8'. In notarize.pl,
print out the whole status in addition to the exit code, just to be
clear in case the command somehow terminates from a signal.
Change-Id: I07ed145fae45d0bdc77c1249cf4d89bd5ba5cc56
Reviewed-on: https://gerrit.openafs.org/15980
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
To create the OpenAFS client for macOS, the current process involves
building the code, signing the binaries, creating the package, and
notarizing it. Each step is typically performed separately and requires
distinct parameters and credentials, making this process cumbersome and
difficult to follow.
To simplify this process, introduce the following '--with' options:
--with-macos-app-key
--with-macos-inst-key
--with-macos-keychain-profile
These options allow users to specify the credentials needed for signing
and notarizing the package upfront.
With these enhancements, users will be able to perform the entire
workflow - building, signing, creating, and notarizing the package -
with a single 'make packages' command, significantly simplifying this
process.
Change-Id: Ibf114f4f5bbe9bc72f37adc487c046e5243f5a97
Reviewed-on: https://gerrit.openafs.org/15977
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
At WWDC 2021, Apple introduced notarytool, a new utility for interacting
with the Apple notary service. Concurrently, Apple deprecated altool for
notarization purposes, with plans to discontinue its functionality on
November 1, 2023.
Currently, notarize.pl relies on the deprecated altool, which is no
longer supported. This commit updates this script to use notarytool,
ensuring it remains fully functional for notarizing the OpenAFS package.
Note that the arguments for notarize.pl have changed. Users can no
longer provide a plain password or keychain reference using the
@keychain prefix. Instead, a keychain profile for the credentials must
be created first, with the profile name provided as an argument.
This change is mandated by the new notarytool workflow.
Additionally, update pkgbuild.sh.in, as this script calls notarize.pl
if the --apple-id option is provided. Since notarize.pl now requires a
keychain profile name instead of an Apple ID and password, remove the
--apple-id option from pkgbuild.sh.in and introduce a new option,
--keychain-profile, which specifies the name of the keychain profile to
be used by notarize.pl.
Change-Id: I8b513e3eebb38e49f0d7c5ff9ea4e1d46e87aa3f
Reviewed-on: https://gerrit.openafs.org/15976
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Since commit f7ddab6606 (Merge pam into the kauth configure option), we
set enable_pam="yes" if --enable-kauth was given to configure. That
makes sense, but we also do that if --disable-kauth was given to
configure. This doesn't make any sense, since we disable enable_pam and
enable_kauth if no --enable-kauth/--disable-kauth option was given at
all.
This doesn't affect much, since INSTALL_KAUTH will be disabled for
--disable-kauth, so the items in src/pam won't be installed in this case
regardless. But to make our behavior more consistent, and actually avoid
kauth stuff for --disable-kauth, set enable_pam to the same thing as
enable_kauth when an option is given, so pam is disabled when kauth is
disabled.
Change-Id: Ib36e9fdffb93d659e1fadab5f1bb1334770806b8
Reviewed-on: https://gerrit.openafs.org/15995
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Several build artifacts are missing from the gitignore rules when
building on macOS. For example:
$ git status --porcelain
?? src/libafs/afs.x86_darwin_210.plist
?? src/platform/DARWIN/PrivilegedHelper/org.openafs.privhelper
Update the gitignore rules to ignore generated darwin plist files and
the prefpane "privileged helper" binary.
Change-Id: I684ec9edde3da76cc83a644f0150da800f6f3db5
Reviewed-on: https://gerrit.openafs.org/16002
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
OpenAFS builds both shared and static libraries by default. On most
platforms, each library is built as a shared library libfoo.so.x.y.z,
and as a static library libfoo.a. libtool refers to this as the 'svr4'
style of libraries on AIX.
On AIX, traditionally libraries are built with the shared library,
static library, and various versions and 64-bit variants and such all
contained in the same libfoo.a. libtool refers to this as the 'aix'
style of libraries on AIX.
libtool defaults to the 'aix' style on AIX, and so this is how libtool
attempts to build our libraries on AIX. For many of our libraries, even
though the build completes successfully, this results in broken
binaries because our Makefile rules assume the shared and static library
files have different names.
For example, here is the install rule for librokenafs:
install: $(SHARED_LIBS) librokenafs.a
$(LT_INSTALL_DATA) librokenafs.la $(DESTDIR)$(libdir)/librokenafs.la
$(RM) $(DESTDIR)$(libdir)/librokenafs.la
$(INSTALL_DATA) librokenafs.a $(DESTDIR)$(libdir)/librokenafs.a
On AIX, the LT_INSTALL_DATA step will install the shared library
librokenafs.a into $(DESTDIR)$(libdir). Then the INSTALL_DATA step will
install the static library librokenafs.a into the same location,
deleting the shared library file.
When the user tries to run an executable, they get an error, because the
shared library librokenafs is not installed at all:
$ /opt/openafs/bin/pts
exec(): 0509-036 Cannot load program /opt/openafs/bin/pts because of the following errors:
0509-150 Dependent module /opt/openafs/lib/librokenafs.a(librokenafs.so.2) could not be loaded.
0509-152 Member librokenafs.so.2 is not found in archive
To avoid this, the user can run configure with --with-aix-soname=svr4 to
build all of our shared libraries in the 'svr4' style. In the above
example, this causes LT_INSTALL_DATA to install the shared librokenafs
as librokenafs.so.* into $(DESTDIR)$(libdir), and then the static
library is installed as librokenafs.a like normal. The resulting
binaries can then run without issue.
To make it so users don't need to specify --with-aix-soname=svr4 to get
a working build, change the default behavior to --with-aix-soname=svr4
by passing aix-soname=svr4 to LT_INIT.
However, just specifying LT_INIT([aix-soname=svr4]) alone does not work,
due to a bug in libtool: https://savannah.gnu.org/support/?111161
To workaround this bug, also explicitly turn on shared and static
libraries by default in LT_INIT, even though they are already on by
default. Using --disable-shared or --disable-static should still be
honored as normal; the LT_INIT arguments just specify the default
values.
Ideally, we would install our shared libraries in the 'aix' style, so a
single libfoo.a contains all of the necessary .o and .so files for that
library. However, changing our build system to do this is difficult. And
historically, OpenAFS has built shared libraries on AIX in the 'svr4'
style; that is how we built shared libraries in OpenAFS 1.6 and earlier,
before we converted to using libtool.
Change-Id: Ifd2538c635323c568f0d8b2e621cc0b8594721ae
Reviewed-on: https://gerrit.openafs.org/15983
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
When building the libafs kernel module, we pass various flags to the
compiler and linker, some of which no longer work with the clang-based
Open XL C 17.1 and newer:
On XL C 16.1 and below, the -M argument causes a file to be generated
with a listing of all the files upon which the .o is dependent. This
file is created with the same name as the .o file, but with a .u
extension. With the Open XL C 17.1+ compilers, the -M file acts
similarly, but if -o is specified, the dependency file is created
with the name specified by the -o argument. This causes the
dependency file to be created but not the actual object code file.
Because the compiler invocation succeeds, this repeats until it is
time to link, which fails because the .o files are not actually code,
but ascii files containing the dependency information. We don't
actually use the .u files for anything, so to avoid this issue, remove
the -M flag.
The -H8 flag is a linker argument that aligns the text, data, and loader
sections of the output file so that each section begins on a file offset
that is a multiple of 8. On XL C 16.1 and below, the compiler passes
unrecognized arguments to the linker, and so giving -H8 to the compiler
works fine. But with XL C 17.1+, the compiler does not pass unrecognized
arguments to the linker, and throws an error instead. To avoid this,
move -H8 from KDEFS to LDFLAGS, so it's given only to the linker and not
to the compiler.
The -q64 flag no longer exists with XL C 17.1+, and is replaced by -m64.
Use ${XCFLAGS64} instead of -q64, which will choose the correct flag to
use, like we did in commit aa82a8894f (export: Use XCFLAGS64 for -q64).
Change-Id: I2527a604000507ec27adb37338d98a6852ad3131
Reviewed-on: https://gerrit.openafs.org/15974
Reviewed-by: Ben Huntsman <ben@huntsmans.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
clang-19 is flagging a warning/error in rxkad/test/stress.c as
unused-but-set-variables
stress.c:51:9: error: variable 'nonoauth' set but not used [-Werror,-Wunused-but-set-variable]
51 | int nonoauth = 0;
| ^
1 error generated.
The variable nonoauth is initialized and conditionally incremented, but
is not used elsewhere.
Remove the nonoauth variable.
Change-Id: I9a97a3980e5b6ff462f860d7bdae4ee8d7b22971
Reviewed-on: https://gerrit.openafs.org/15984
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Convert the prefpane logic for writing to config files to use
privhelper, so it can work with macOS 10.8+. With this commit, the
"CellServDB Editor" and "Parameter" tabs in the prefpane should now
work.
Specifically, define the privhelper task "write". Define a new variant
to TaskUtil's executePrivTask() called executePrivTaskWrite() to use the
new task type, and convert the prefpane code to use it.
Most files are straightforward, but converting writeAfsdOption() is a
little awkward due to the repeated checking of useAfsdConfVersion. Just
remove the writeAfsdOption() method and make the caller choose between
writeNewAfsdOption() and writeOldAfsdOption().
The new "write" task takes a new argument (data) to indicate what data
to write to the config file in question. Like the "backup" task, it also
takes a "filename" argument that is checked against our list of config
files.
Change-Id: Ib93da5a75a92e3507c15f9ee03eb8f7fbad7d088
Reviewed-on: https://gerrit.openafs.org/15960
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Convert the prefpane logic to backup various config files to privhelper,
so it can work with macOS 10.8+.
Specifically, define the new privhelper task "backup". Define a new
variant to TaskUtil's executePrivTask() called executePrivTaskBackup()
to use the new task type, and convert the prefpane code to use it.
Remove the backupFile() method, since it's now unused.
The new "backup" task has an argument (filename), so we don't need to
define separate tasks for each file we want to backup. But check the
given filename against a short list of files we know we deal with, just
to make sure we don't accidentally mess with some other system file,
since we're running as root.
Change-Id: I066d8e95a50a52f7509487f9228ba03dd027ea36
Reviewed-on: https://gerrit.openafs.org/15959
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Convert the logic to "start/stop OpenAFS" in the prefpane to use
privhelper, so it can work with macOS 10.8+.
Specifically, define these new privhelper tasks:
- afsd_start
- afsd_stop
And convert our start/stop-related code in the prefpane to use them.
Change-Id: I4cc5b500fb09b83a4007e2c7c5045e93fe1f4ced
Reviewed-on: https://gerrit.openafs.org/15958
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Convert the logic for the "start at login" option in the prefpane to use
privhelper, so it can work with macOS 10.8+.
Specifically, define these new privhelper tasks:
- startup_enable
- startup_disable
- startup_check
And convert our startup-related logic in the prefpane to use them.
Get rid of our now-unused method executeTaskWithAuth() and related
methods.
Change-Id: I2cb4c31f964529ab1af43ab7828c14eba7354af0
Reviewed-on: https://gerrit.openafs.org/15957
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
The prefpane for macOS runs as the logged-in user, but needs root access
for some operations: starting/stopping the client, editing various
configuration files like CellServDB, etc. We currently use functions
like AuthorizationExecuteWithPrivileges() to run commands with root
privileges directly, but this approach no longer works as of macOS 10.8
(Mountain Lion); the relevant functions have been removed.
Instead, a new approach exists as of macOS 10.6 (Snow Leopard). The
prefpane application itself cannot gain root privileges, but we can
provide another daemon process that runs as root, and the PrefPane sends
requests to that process to perform the privileged operations we need.
In this commit, create a separate helper program called PrivilegedHelper
(privhelper for short) that serves this purpose. Define the
executePrivTask() method in TaskUtil to handle communicating with
privhelper over XPC.
This commit does not define any of the tasks that privhelper will
actually perform; this just implements privhelper itself. Later commits
will add and use various privileged tasks in privhelper.
In order for privhelper to be able to run as root, both privhelper and
the prefpane itself must be code signed and the relevant apple team id
must be specified in their Info.plist when they are built, as well as
inside privhelper.c. Currently, we have
no way of specifying code signatures info during the build, since all code
signing is done when generating packages (via pkgbuild.sh) after
binaries are built. For now, just put a commented-out section in
src/platform/DARWIN/AFSPreference/Info.plist and
src/platform/DARWIN/PrivilegedHelper/privhelper-info.plist and a
placeholder in src/platform/DARWIN/PrivilegedHelper/privhelper.c to show
how to add this information. The package builder must add their own team
id to these before privhelper can work properly.
The privhelper tool checks that the calling user has authorization to
run commands as root (via AuthorizationCopyRights()), and that the
calling process is either our AFSBackgrounder menu bar or the prefpane.
We use xpc_connection_set_peer_code_signing_requirement() for this where
available, but fallback to using SecCodeCheckValidity() with
SecCodeCreateWithXPCMessage() or
xpc_dictionary_get_audit_token()/SecCodeCopyGuestWithAttributes() if
needed.
Change-Id: I724b6d486ee5397c89c79e589ddcb2a5987a895b
Reviewed-on: https://gerrit.openafs.org/15956
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
The default Xcode compiler options are insufficient to fail the build if
a method is not found. For example, a typo in the name of method
'componentsJoinedByString' results in the following build warning:
/TaskUtil.m:70:62: warning: instance method '-componentsJoinedBySting:'
not found (return type defaults to 'id') [-Wobjc-method-access]
NSLog(@"Task failed: %@ %@ status:%d.", taskName,
[args componentsJoinedBySting:@", "], status);
Because this is only flagged as a warning, the build completes
successfully. When this code runs, the AFSBackgrounder merely logs a
runtime exception every time it passes through the erroneous code. This
is a silent failure, unless you happen to know how to check for
AFSBackgrounder log messages:
$ log show --predicate 'process=="AFSBackgrounder"'
Add compiler flag '-Werror=objc-method-access' to all of our xcode-built
project files to treat this case as an error instead of a warning, so
the build will fail.
[adeason@sinenomine.net: Update all xcode project files.]
Change-Id: I69a9f45deb6710a50590bd79daf07466332a6ad1
Reviewed-on: https://gerrit.openafs.org/14586
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
