vrm(1)

Name

vrm - Remove a file or directory from the Vesta repository

Synopsis

vrm [-q] [-Q] [-v] [-R repos] name [name...]

In the most common usage, only the name argument is given.

Contents

Description

See the vesta-intro man page's Terminology section for definitions of terms, and its Name Interpretation section for an explanation of how names are looked up.

The vrm command removes one or more files or directories from the Vesta repository. Removing an object from an appendable directory leaves a ghost behind. If the object to be removed is a directory, it need not be empty.

This command provides an alternative to removing an object with the normal rm or rmdir commands through the repository's NFS interface. It is needed in cases where your NFS client thinks you don't have permission to remove because it doesn't fully understand Vesta access controls. The vrm command also makes it possible to remove an object from a remote repository that you do not have NFS mounted.

You must have write access to the directory from which name is to be removed.

vrm returns status 0 for success, 1 for parameter syntax errors, or 2 for more serious errors. (Note that if any of the trigger commands fail, vrm returns status 2.)

Flags

-q
Quiet; suppress printing out what is being done.
-Q
Query; print out what the command would do, but don't do it.
-R repos
Remove the object from repos instead of the default local repository. The repository is specified by host name and TCP port number in the format host:port. The :port portion may be omitted; it defaults to [Repository]VestaSourceSRPC_port.
-v
Displays extra information about triggers. Before executing any trigger commands, the environment variables used to provide information to them are printed. Also, each trigger setting is printed before the command is executed. This can be used to help debug trigger problems. When used with the query flag (-Q), the triggers are displayed in their sorted order without actually running them.

Configuration

The following values are obtained from the [UserInterface] section of the Vesta configuration file (vesta.cfg).

AppendableRootName
The filename under which the global root directory of Vesta repositories is mounted. Ordinarily set to /vesta.
MutableRootName
The filename under which the local tree of mutable directories provided by Vesta is mounted. Ordinarily set to /vesta-work.
realm
Global user names are formed by appending @realm to the local name. This setting is optional. If it is not set, [Repository]realm is used.

The following values are obtained from the [Repository] section of the Vesta configuration file.

VestaSourceSRPC_host
The host name of the default (local) repository.
VestaSourceSRPC_port
The default TCP port number for repositories.
realm
Global user names are formed by appending @realm to the local name. This setting is only used if [UserInterface]realm is not set.

Settings in the [vrm pre trigger] and [vrm post trigger] sections of the configuration file are used as commands to be run before and after the repository is modified. See the next section.

Triggers

Users can configure commands in the Vesta configuration file (vesta.cfg) to be executed before and after vrm modifies the repository. Each setting in the [vrm pre trigger] section specifies a command to be run before any action is taken, and each setting in the [vrm post trigger] section specifies a command to be run after all actions are complete.

The value of each setting specifies a command to run. The names of the settings define the order in which these commands are run. The setting names are sorted as strings, but comparing embedded sequences of digits as decimal integers. (So, for example "foo_10_bar" will sort after "foo_2_bar".) The suggested naming convention for trigger settings is to start with an integer, follow with a descriptive name, and follow that with any other text. (This is based on the convention used for System V style init script links typically stored in /etc/rcN.d.)

Here's a simple example of how we suggest naming trigger settings, and how they are ordered for execution:

[vrm pre trigger]
100world = echo World!
9tada    = echo Tada:
50hello  = echo Hello,
Because these all start with numbers, they will be executed in the order "9tada", "50hello", "100world". The output will look like this:
% vrm /vesta/example.com/...
Tada:
Hello,
World!
Deleting /vesta/example.com/...
Trigger commands are executed with system(3). On most operating systems this means "/bin/sh -c command", so simple in-line shell scripts can be used. (Note that each is executed in its own shell process, so environment variables set during one trigger command will not propagate to subsequent ones.)

If any of the commands in the [vrm pre trigger] section exit with error (non-zero) status or are terminated by a signal (e.g. segmentation fault, abort), vrm will exit without deleting.

The commands in the [vrm post trigger] section will only be executed if the deletion is successfully performed. If vrm fails with an error, the commands in the [vrm post trigger] section will not be executed.

Note that all the trigger commands (both pre and post) are executed sequentially. Once a trigger command is started, nothing else happens until it completes. If any of the pre trigger commands runs forever, vrm will not perform a deletion. If any of the post trigger commands runs forever, vrm will not complete. (In other words, a trigger command that hangs will cause vrm to hang.) If any of the pre or post trigger commands exit with error status or are terminated by a signal, vrm will exit without running any more commands from those sections. (In other words, a trigger command that fails will prevent further trigger commands from being run.)

If a single vrm command is given more than one file or directory to delete, the pre and post trigger commands will be run once for each object being deleted. The pre trigger commands command are run just before deleting each object and after deleting any preceding objects, and the post trigger commands are just after deleting each object and before deleting any following objects. If any of the trigger commands (either pre or post) exit with error status or are terminated by a signal, vrm will stop processing immediately, even if there are additional objects to be deleted. (In other words, a trigger command that fails may prevent objects from being deleted.)

If the the query flag (-Q) is given, the trigger commands will not actually be run.

Information about what vrm is going to do or has just done is provided to the trigger commands through the following environment variables:

VESTA_TOOL
The name of the Vesta tool the trigger command has been invoked from. (For vrm, this will always be "vrm".)
VESTA_REPOS
The local repository (host:port) vrm communicates with (either the default from the configuration file or the one specified with the -R flag.
VESTA_PATH
The path being deleted by vrm.
VESTA_QUIET
Set to 1 if the quiet flag (-q) was given, set to 0 otherwise.

(Note that the environment variables are the same for both the pre and post trigger commands.)

Here are some examples using these environment variables:

[vrm pre trigger]
// Disallow any ghosting a master object under /vesta
50no_ghost_master = if echo $VESTA_PATH | grep -q '^/vesta/' && vattrib -q -m $VESTA_PATH; then echo "Ghosting a master object not allowed"; exit 1; fi

[vrm post trigger]
// Add an attribute when an object under /vesta is ghosted
50record_ghosting = if vattrib -q -C ghost $VESTA_PATH; then vattrib -a "deletion-time" "`date`" $VESTA_PATH; fi
If the verbose trigger flag (-v) is given, these environment variables will be printed, and each trigger command will be printed before executing it. This can be useful for debugging trigger problems. If both verbose trigger flag and the the query flag (-Q) are given, the triggers are displayed in their sorted order without actually running them. This can be used to find out what trigger commands are configured without actually running them.

See Also

vesta-intro(1), repos-ui(1), repository(8)

Author

Scott Venier, Tim Mann, and Ken Schalk. Yes, it took three of us to delete enough code from other larger programs to leave this small one.

This page was generated automatically by mtex software.