vidb manually edits an SFS user-authentication file
, acquiring locks to prevent concurrent updates from
overwriting each other. If sfsauthd has been compiled with
Sleepycat database (http://www.sleepycat.com/) support, and the
name of the file ends in .db/, vidb will consider the
user authentication file to be a database directory, and convert the
contents into regular ASCII text for editing. If the name of the file
ends in .db, vidb assumes the user authentication file
is database file (unless the pathname corresponds to an existing
directory). Note that database files (as opposed to directories) are
required to be read-only, and thus cannot be updated by vidb.
OPTIONS
vidb has the following options:
"-a
The -a option addsSFS user records in text form to a
database. The records are taken from standard input, or from
file if specified. Records for an existing user or group will
replace the values already in the database. Unlike vidb's
ordinary mode of operation, -a does not add all records
atomically. In the event of a system crash, some but not all of the
records may have been added to the database. Simply re-running the
same vidb command after a crash is perfectly safe, however,
since previously added entries will just be overwritten (by
themselves) the second time through. For database files, because
-a does not accumulate records into one large transaction, it
can be significantly more efficient than simply adding the records in
an editor, using vidb's ordinary mode of operation.
"-e
Specifies the editor to use for editing the file. The default is to
use the command specified by the environment variable EDITOR.
If there is no environment variable and -e is not specified,
vidb uses vi.
"-w"
One of the points of vidb is to avoid concurrent edits to
the database and the corresponding inconsistencies that might result.
Ordinarily, if the database is already being edited, vidb
will just exit with an error message. The -w flag tells
vidb to wait until it can acquire the lock on the database
before launching the editor.
"-R"
Runs catastrophic recovery on the database environment. (For
those familiar with Sleepycat database software, this corresponds to
the -c flag of the db_recover utility, or the
DB_RECOVER_FATAL flag of the API.) Essentially, -R
replays all of the database log records present in the supporting
files directory. You may need to use this, for example, when
restoring a database from backup tapes if the log files were backed up
more recently than the entire database. The -R has no effect
on flat text databases, or if the -S has been specified.
Warning: The authors have encountered bugs in the
catastrophic recovery code of at least some versions of the Sleepycat
database package. As a precaution, before attempting to use
-R, we strongly recommend salvaging whatever records possible
from the database file itself using vidb -Ssfs-users-file>saved_sfs_users. If, subsequently,
the -R option corrupts the database, you can at least salvage
some of the records from the saved_sfs_users file.
"-S"
Attempt to salvage a database file with corrupt or lost logs by
dumping the contents of the database itself. Ordinarily, databases
use write-ahead logging. Before opening a database file, both
vidb and sfsauthd attempt to recover from any
previous incomplete transactions using the log. The -S
option opens and prints out the contents of a database without regard
to the log files. This is useful if you have lost the log files or
are worried that they are corrupt, or if you wish to examine the
contents of a database you have read but not write permission to.
Ordinarily, however, if you wish to dump the contents of a database to
standard output, use the command vidb -e catsfs-users-file.
The full documentation for SFS is maintained as a Texinfo
manual. If the info and SFS programs are properly installed
at your site, the command info SFS
should give you access to the complete manual.
For updates, documentation, and software distribution, please
see the SFS website at http://www.fs.net/.
BUGS
vidb should really recreate any publicly-readable versions
of user authentication databases (either by parsing
sfsauthd_config for -pub=... options to
Userfile directives or signaling sfsauthd).
Currently you must manually kill sfssd or sfsauthd
for this to happen.
While vidb attempts to make the smallest number of changes
to a database, editing sessions that add or remove a large number of
records can potentially exhaust resources such as locks. Sites with
large user databases can tune the database by creating a file called
DB_CONFIG in the database directory.
The specifics of the configuration file are documented in the
Sleepycat database documentation. As an example, if performance is
slow and you run out of locks, you can set the cache size to 128MB and
increase the number of locks with the following DB_CONFIG file:
When editing a database, vidb creates a temporary text file
in the /tmp directory. For huge databases, it is conceivable
that /tmp does not have enough space. If this happens,
/tmp can be overridden with the TMPDIR environment
variable.