---
name: "vidb"
section: "8"
platform: "linux"
package: "sfs-server"
version: "1:0.8-0+pre20060720.1-1"
release: "Debian 4.0 (Etch)"
platforms: ["linux"]
url: "https://new.carta.tech/vidb"
---

# vidb(8)

manually edit SFS user-authentication database file

## NAME

vidb - manually edit SFS user-authentication database file

## SYNOPSIS

vidb \[-w\] \[-R\] {-S \| -a \[-f *file*\] \| \[-e *editor*\]} *sfs-users-file*

## DESCRIPTION

**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 \[-f *file*\]

  The **-a** option *adds* SFS 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 *editor*

  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 -S** *sfs-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 cat** *sfs-users-file*.

## SEE ALSO

[*dirsearch*(1)](/dirsearch/1.md), [*newaid*(1)](/newaid/1.md), [*rex*(1)](/rex/1.md), [*sfsagent*(1)](/sfsagent/1.md), [*sfskey*(1)](/sfskey/1.md), [*ssu*(1)](/ssu/1.md), *sfs\_config*(5), [*sfs\_hosts*(5)](/sfs_hosts/5.md), [*sfs\_srp\_params*(5)](/sfs_srp_params/5.md), [*sfs\_users*(5)](/sfs_users/5.md), [*sfsauthd\_config*(5)](/sfsauthd_config/5.md), [*sfscd\_config*(5)](/sfscd_config/5.md), *sfsrosd\_config*(5), [*sfsrwsd\_config*(5)](/sfsrwsd_config/5.md), [*sfssd\_config*(5)](/sfssd_config/5.md), [*sfs\_environ*(7)](/sfs_environ/7.md), [*funmount*(8)](/funmount/8.md), *nfsmounter*(8), [*sfsauthd*(8)](/sfsauthd/8.md), [*sfscd*(8)](/sfscd/8.md), *sfsrosd*(8), *sfsrwcd*(8), [*sfsrwsd*(8)](/sfsrwsd/8.md), [*sfssd*(8)](/sfssd/8.md)

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:

```
  set_cachesize 0 134217728 1
  set_lk_max_locks 50000
  set_lk_max_objects 50000
```

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.

## AUTHOR

sfsdev@redlab.lcs.mit.edu