Contents
Advice for Administrators
This section is a collection of advice for Vesta administrators.
Run the weeder automatically
Build results accumulate until you run the weeder. It's a good idea to arrange for this to be done automatically (e.g. via cron) to avoid running out of disk space.
The Linux installable packages include a simple cron script to run the weeder every week (/etc/cron.weekly/vestaweed). This is probably fine for casual users, but a large installation may need something more. For example, you might want a script that ran more often (perhaps every hour) and did things like:
- Monitoring free space on the volume(s) where the repository and cache store their data
- Sending e-mail when free space starts to get low
- Running weeder automatically if space gets really low
Keep RunToolServer host lists up to date
The evaluator gets a list of candidate hosts which can run individual build steps from the configuration file. (See "Runtool Host Selection" in the evaluator man page.) Each evaluator process will contact the hosts on this list when trying to find a RunToolServer to use. If one of the hosts is down, or unreachable, or not running a RunToolServer, the evaluator will remember this and will not try to contact it again. However, there's no way to preserve this information between different builds. This makes it a good idea to keep the host lists in the configuration file up to date.
You can automate this with a script to be run via cron:
- Get a list of candidate hosts from some known location. (Hopefully you have a list of all your hosts which might be Vesta clients.)
Use the RunToolProbe utility on each candidate host to check for the presence of a RunToolServer. (The exit status of RunToolProbe indicates whether it was able to contact a RunToolServer on the specified host.)
Generate a partial vesta.cfg containing the list of hosts which are up and have RunToolServers to be included by your main vesta.cfg.
Auto-generate alias/group files for peer sites
The repository gets information about all local users and their group memberships from the host operating system. However, it has no way to automatically get information about remote users and groups. If you have multiple sites which interact with each other (i.e. by replication and remote checkout/checkin), you'll need to keep peer repositories informed about your users and groups.
You tell the repository about group memberships with its group file. You can also tell the repository about user equivalences with its alias file. Both of these files allow you to include other files (with ". otherfile").
You can write a simple script to generate partial repository alias/group files by reading the OS user/group information (e.g. reading NIS user/group data with ypcat). You can send these files to peer sites and have them included by the main repository alias/group files.
It's a good idea to automate this. You'll want to use vaccessrefresh in such a script to get the repository server to re-read its alias and group files.
Don't let people use /vesta-work as a general scratch area
To inexperienced Vesta users, /vesta-work looks like an ordinary NFS disk. In a large installation, it may have a lot of storage space available. People may not understand that they shouldn’t use it as a general scratch disk.
Users are able to create directories and store files in /vesta-work. This consumes storage space in the same pool that source files and derived files (build results) are stored in. The I/O traffic for using /vesta-work competes for resources in the repository server with source editing and build doing work.
Another important issue is that there's no backup in /vesta-work (except through vadvance).
A good rule of thumb is:
If you can't vadvance it, it doesn't belong under /vesta-work