The propel application maintains various databases to hold and query the information specific to the application's needs.

When you install propel, the host database is initialized automatically. If you wish to reinitialize the database at any time, enter the following command while logged in as root:

dbredit host init 

Remember that this command will eliminate all current entries in your Host database.

All systems using the propel software must have a record in the propel Host database. The easiest way to place all your systems in the database is to parse the standard system files /etc/hosts and /etc/ethers, and load the system names directly into the database. There are a pair of scripts provided with the propel software that parse these files and load the database. The first is a perl script, /usr/propel/sample/host_parser that reads through these system files, and outputs one line for each system name that it finds. The output format is that of a TCL keyed list, which can be inserted into the host database using the dbredit command. Running the script /usr/propel/sample/add_hosts works for many sites. You may edit the host_parser script to make changes to fit your local needs.

The propel database has one entry for each “host,” but each host can have multiple network interfaces, and therefore multiple entries in the hosts file. The standard host_parser script recognizes the extra interfaces of hosts if they have a comment of the format GATE(hostname) or if the primary name for these interfaces is of the form gate3-hostname. The test for such names is clearly marked within the script and can be changed to fit local conventions.

The most useful script available for populating your propel Host database is /usr/propel/sample/find_hosts. Invoked with an IP subnet number (in the form 123.45.67) as an argument, this script sends an ICMP echo (ping) request to each possible node (0-255) on the specified subnet. When a remote host responds, it sends an SNMP request to the remote host and creates a record in the Host database with any data that is returned.

Once a record exists in the Host database for each host, it is a good idea to fill in the remaining information for each host. This can be done by completing each entry in an editor, or as a batch update. There is a very simple script that attempts to attach to each system using the rsh(1) command, and reading information from the uname(1) command to glean the standard information. This script is /usr/propel/sample/host_info, and it outputs a line for each system that successfully completes the process. There is a simple perl wrapper program, /usr/propel/sample/batch_update, that takes a file of host_info output lines and performs the updating in the Host database. A more powerful script, /usr/propel/sample/update_hosts, updates the records of each host in the database by parsing the result of an SNMP request for the sysDescr variable. If you are running SNMP on the client hosts then this script should provide the best automatic updating.

If you are administering a network of Silicon Graphics systems, the following steps will initialize and populate your Host database. If you are administering a heterogeneous network, not all hosts may be located and entered in the database through this process. If this happens, you may need to edit the databases with the hostedit editor, as described in “Editing the Host Database.” Follow these steps to populate your database:

You can also use the /usr/propel/sample/find_hosts script, which performs many of the same functions. This script searches your network for other hosts and populates the database using SNMP responses. Obviously this command is only useful when the SNMP daemon is running on all your systems. The command has the syntax:

find_hosts subnet 

The script pings each possible address on the given subnet. For example, if given the subnet argument 127.0.0, find_hosts returns the following:

Trying: 127.0.0.1
Address 127.0.0.1 pings, but is not in database.
Does not answer SNMP request.
Trying: 127.0.0.2
Trying: 127.0.0.3
Trying: 127.0.0.4

And so on up to address 127.0.0.255. IP address 127.0.0.1 is the standard loopback interface. The ping response received was from the local host. When this command is used on a valid subnetwork, the database is populated using the SNMP responses from the hosts. You must be logged in as root to use find_hosts.

Once you have populated your Host database, you should create your first set of collections of hosts. Instructions for creating and modifying collections are found in the section titled “The Collection Database”.

The script used to automatically populate both the User and Group databases at once is /usr/propel/sample/add_users. This script parses the /etc/passwd and /etc/group files to build these databases. The script is sophisticated enough to bypass NIS entries in these files, but does generate entries for accounts such as uucp and demonstration users.

As root, enter the command:

/usr/propel/sample/add_users 

Initially, you must create a set of files that can be distributed to client hosts. The creation process includes putting the files into the /var/propel/data directory, and creating a File database entry for each file. Files can also be automatically generated before they are distributed by setting a generator command in the File database record. Scripts are included in your propel application for generating the files /etc/hosts, /etc/ethers, and the DNS maps, using information from the Host database. Each of these sample scripts must be edited to deal with local naming conventions at your site.

Files can be distributed from locations other than the /var/propel/data directory if slave servers are not used, that is, only if files are distributed from the original server system directly to the final client systems. By default, only the data directory can be distributed to slave servers, which subsequently distribute the files to client systems. This behavior can be changed, however, by editing the /usr/propel/bin/runpropel script.

The licensing for propel is managed by flexlm. This license is usually specified in the file /var/flexlm/license.dat or by a file specified by the environment variable LM_LICENSE_FILE.

The runpropel program uses the industry standard utility rdist to distribute files from master servers to slave servers, and from slave servers to client hosts. The rdist utility originates from the BSD releases and is a standard utility under most UNIX operating systems. It is also freely available on the Internet in source form so that it can be ported to most other systems. The purpose in using a standard file distribution program is to make propel useful in a heterogeneous environment. The rdist utility is distributed with propel in a gifts installation package. When installed, the source is placed in the /usr/people/4Dgifts/rdist-6.1.0 directory.

The rdist program pushes files using a generalized configuration file to control the distribution. The runpropel program generates the necessary rdist configuration files (known as Distfiles), and then runs rdist on the Distfiles.

All propel servers and clients must have the 6.1 version of the rdistd daemon installed, at a minimum. The propel software works with any version of rdist, but the version shipped with propel is rdist 6.1. The use of rdist 6.1 is strongly recommended for its extended logging, improved security, and improved performance. There are, however, some sites that cannot build the new rdist software but have the BSD software running. These sites must use the old distribution software on the master, and a modified master runpropel script. If you would like to use propel with an older version of rdist, you must first unset the LOGERRS variable in the /usr/propel/bin/runpropel command script. To set the LOGERRS variable, edit the runpropel command script and change the line that reads:

LOGERRS=”-l syslog=warning,nerror,ferror:file=/usr/propel/rdist/log.$FREQUENCY=all:stdout=warning,nerror,ferror -L syslog=all”

to read as follows:

LOGERRS=””

The propel application currently uses rdist for its distribution mechanism, which means that every client system must trust at least one other system on the network as its server. If files are to be pushed directly from the master server to client systems, then each client system must place the master server's hostname in its /.rhosts file. If a hierarchical push strategy is used then each client must have the hostname of the slave server from which the client will receive files in the client's /.rhosts file, and the slave server must have the hostname of the master server in its /.rhosts file. Files may be pushed with the UID of a user other than root, in which case the .rhosts file in that user's home directory needs to include the server's system name.

In order to use many of the utilities and features of propel, each system on your network should be running the snmpd daemon. This daemon provides support for SNMP (Simple Network Management Protocol) and allows other systems to query the host for information about its configuration.

To obtain SNMP support, the provision distribution packages to install on each station are:

snmpd          01/04/95 SNMP Daemon with HP MIB Support
snmpd.sw       01/04/95 SNMP Daemon with HP MIB Support
snmpd.sw.agent  01/04/95 SNMP Daemon with HP MIB Support

To configure a workstation so that snmpd is started automatically when the system is rebooted, install the packages listed above, and enter this command on the system while logged in as root:

chkconfig -f snmpd on 

To check to see if the daemon is already running, enter this command:

ps -e | grep snmpd 

If there is no output from this command, snmpd is not running. Become root and enter this command to start snmpd:

snmpd & 

There are six databases that hold the information needed by propel. The databases hold information about:

A graphical tool and command-line interface is provided for editing each database, as well as an example script that shows how to build the initial Host database from the standard system files. The command

propel 

brings up a standard desktop view of the propel tools. The desktop view appears similar to this, shown in Figure 1-1:

Figure 1-1. The propel Directory View

Alternately, you can invoke each tool on its own with one of the following commands:

/usr/propel/bin/coledit 
/usr/propel/bin/fileedit 
/usr/propel/bin/groupedit 
/usr/propel/bin/hostedit 
/usr/propel/bin/ruleedit 
/usr/propel/bin/useredit 

These commands bring up the graphical tools for the Collection, File, Group, Host, Rule, and User databases, respectively.

Icons in any propel tool window can be dragged and dropped on other propel tool windows to fill needed fields. For example, you may populate a collection by dragging host icons from the Host database editor and dropping them in the appropriate window of the Collection manager.

The command line interface for editing databases is dbredit(1M). This command allows you to edit the database of your choice. The dbredit utility is completely described in the dbredit(1M) reference page, but an overview is also provided in this guide in the section titled “Using the dbredit Utility”.

The propel software package is highly flexible. In fact, the individual administrator who uses propel defines virtually every parameter of the operation. As an example, propel does not come with a preconfigured set of rules concerning the frequency with which files are propagated. The terms “Daily” and “Weekly” mean nothing to propel until you define them. You enter terms as parameters in the propel databases, and then use different commands to query the databases and execute the distributions based on those terms. It is therefore vitally important that you plan your propel strategy in advance to avoid confusion.

It is this flexibility that makes propel a powerful tool. Because there is not a predefined set of rules about concerns such as the frequency of the distribution and the naming conventions of files and packages of files, you are not restricted in your use of propel to simple hourly, daily, or weekly updates, though these might form the bulk of your usage.

You will probably start your propel databases by listing the host systems to which you will distribute files. This is a straightforward process of listing the names of the systems and their network addresses and other pertinent information about them. This is where you start defining your propel environment. The fields in the Host database that describe the manufacturer, Operating System revision level, and other such information can be vitally important when you wish to target a very small subset of a great number of hosts for distribution. There are no preset entries for these fields, so you can use them (especially the comment field) as you wish. The Fill button on the hostedit window is provided to assist you in populating your database. If you list the hostname or IP address of a workstation on the network and use the mouse to click the Fill button, propel uses SNMP to query the host itself for answers to as many of the other fields as possible.

The Collection database is used to make collections of hosts from the Host database. This is done through making queries to the Host database. All hosts that match the query parameters you select will compose the collection. To prepare for these queries, it is recommended that you fill in all fields in each Host database record.

The User database allows you to list all the users at your site and manage that information from a central server. Since all user information is managed at one place, you can be sure that user names and UID numbers are not duplicated, and that departing users will be removed from all systems at the site. You can also use this database to provide access to new systems for existing users. The /etc/passwd and /etc/group files can be generated for and distributed to any system on your network by this database.

The Group database performs the same function for users that the Collection database provides for hosts. This database allows you to make groups of users with related needs or other common factors. The groupedit tool allows you to edit and visualize your user groups.

The File database allows you to list the files that are to be distributed in much the same manner that you listed your host systems and users. There is a field in each file entry called “Package” that lists the name of a file package (a group of related files.) There can be more than one entry in the File database for each file you wish to distribute. You may wish to place a file in more than one package, or you may wish to have a file generated by one program for some hosts and another program for other hosts. In these cases, you make two entries in the File database that both point to the same file, but with different file-generating programs or in different packages.

The most flexible of all the tools is the Rule database. By itself, the Rule database takes no action. The runpropel command searches the Rule database for the parameters given on the runpropel command line and executes any rules that match those command line parameters. Thus, you may create a rule that says that files A and B and file package C are to be distributed to host collection “engr” and to any client host with a hostname beginning with the letter “Q,” and the frequency of the distribution is to be “walnuts.” That frequency has no meaning until you assign it a meaning by the way you use runpropel.

Typically, distributions of a regular frequency are managed through the cron(1) facility of your workstation or server. The cron utility does define regular time frequencies, so it is possible to simply tell cron to execute the command

runpropel -f walnuts 

every day at exactly 2 PM. Thus, “walnuts” means “daily at 2 PM” because you set it up to have that meaning. This may seem like a lot of work to perform a simple task, but the advantage comes when you want to change the meaning of “walnuts.” You then have only to change your cron command, and not the database entries of every rule that runs with a frequency of “walnuts.”

Once you become comfortable with the concepts behind propel, you can configure the software to suit your needs exactly. The graphical tools make this configuration easy and intuitive. There is a command line interface available through the dbredit(1M) command for server users with no graphics capability.

This section contains some information on using propel to simplify the management of a large network domain.

inst -a -f system:/location_of_package -F config-file 

runpropel gcc `model~Ind*' 

The Host database contains information about all of the systems in an administrative domain. Each record in this database contains the following fields:

00:00:A7:10:91:03

The standard system host databases, such as /etc/hosts, /etc/ethers, and the named maps in /var/named can all be generated using this database as input. Under the propel distribution system, administrators need maintain only one list of host information. System data files can be generated from this list, thus simplifying large domain host administration. For more information on file generation using propel, see “The propel File Generation System”.

Editing the Host Database

To edit the Host database, enter the command:

/usr/propel/bin/hostedit

You see the following initial screen, shown in Figure 1-2:

Figure 1-2. The Host Database Editor

When you first see this screen, there are no hosts listed and only the Clear button is functional.

To add a host to your database, you must fill in the following fields (which appear in red in the hostedit window):

• Hostname

• IP address (at least one)

• Domain

When there are entries in these three fields, the Add, Search, and Fill buttons become functional. You can see a change in their visual presentation. If possible, you should enter all the fields. Once entered, you can use each field as a query parameter for that record in the Host database.

Records in the Collection database have the following fields:

Editing the Collection Database

The coledit utility allows you to define collections of hosts for propel. A collection of hosts is simply a group of hosts that you have defined. Usually, collections are made of hosts with some common factor, such as manufacturer or usage. Since you specify the attributes of a host by using the hostedit utility, you can prepare hosts to be part of a collection when you enter them in your Host database. For example, you can enter several hosts in your Host database with the comment “engineering lab” in the comment field. Then, when you use coledit to create a collection, you specify the “engineering lab” comment as the query field when creating the collection. The syntax for these queries is described in “Additional Database Query Techniques”. All hosts that you entered with that comment becomes part of the collection. Then you name the collection, and use the Rule database to specify how and when the collection should receive files. The names of collections and the Host database queries that define the collection are stored in the Collection database.

Once defined, the coledit utility stores the parameters of the collection in a database. Enter the command:

/usr/propel/bin/coledit

and you see the following window, shown in Figure 1-3:

Figure 1-3. The Collection Manager

When you bring up the Collection Manager window after your database is populated, you see an icon and a name for each collection in the database.

Adding a Collection of Hosts to the Collection Database

To use the coledit tool to add a host collection to your Collection database, place the mouse cursor inside the coledit window and use the right button of the mouse to bring up the popup menu. There are several options:

Help		Brings up a help card.
Add Collection		Brings up the Add Collection window.
Add Host		Adds a host to an existing collection.
Add Query		Brings up the Add Host Query window, and allows you to add an additional query parameter to select hosts for an existing collection.
Remove Selected		Removes the selected collection.
Edit Selected Hosts		Brings up the hostedit tool with the selected host's information displayed. To select a host, you must have a collection displayed in a collection display window.
Preview		Shows you the list of hosts currently selected in a collection.

Select the Add Collection option to create a new collection of hosts. When you select this option, you see the new window, shown in Figure 1-4.

Figure 1-4. The Add Collection Window

You must enter a name for the collection, then use the left mouse button to press the Accept or Apply button to create your new collection. The Apply button creates your new collection, and retains the Add Collection window, so you can continue to create more collections conveniently. The Accept button creates your collection and removes the Add Collection window. The Cancel button cancels the operation without creating the new collection.

Once you have created the collection, you must specify hosts to be part of the collection. You should notice that an icon has appeared in the coledit window. If you made two collections and called one ``first collection,” and the other ``second collection,” the window now looks like Figure 1-5.

Figure 1-5. A Populated Collection Manager Window

To add a list of hosts, a list of collections, a host query, or any combination of these things to your new collection, double-click the left mouse button with the mouse cursor over the icon for the new collection. You see a new window that looks something like Figure 1-6.

Figure 1-6. A Collection Display Window

Now use the right mouse button to bring up the popup menu, and select either the Add Host, Add Collection, or Add Query options to populate your collection.

The Add Host option brings up the Add Host window, shown in Figure 1-7, with the entire list of hosts from your Host database.

Figure 1-7. The Add Host Window

To place a host in your new collection, place the mouse cursor over the name of the host you wish to select and double-click the left mouse button. When you are finished selecting individual hosts, click the Accept button to secure your changes and remove the Add Hosts window.

The Add Collection option brings up the Add Collection window, previously shown in Figure 1-4. All your currently configured collections are shown in this window (although in this example, you are creating your first collection, so no collections may appear at this time). As with the Add Host window, double-click the name of a collection you wish to add to your new collection and complete your changes by pressing the Accept button.

The Add Query option brings up the Add Host Query window, shown in Figure 1-8.

Figure 1-8. The Add Host Query Window

This window allows you to enter a query to the Host database. You must formulate your query according to the rules outlined in “Additional Database Query Techniques”.

When you have used these various windows to populate your collection, the collection display window looks something like the window shown in Figure 1-9.

Figure 1-9. A Populated Collection

The collection shown in Figure 1-9 has a single host, a pair of host queries, and another collection as its elements. This is to demonstrate the various items that may go into a collection.

Once you have entered all the information and created your collections, press the Apply button in the Collection Manager window to place your collections in the Collection database.

The File database contains all the necessary information about the files that are to be distributed to systems on your network.

Records in the File database have the following fields:

Editing the File Database

This database contains the names of the files that are propagated to systems in your propel network. The File database also contains instructions for commands to be run on the client system before and after the file is transmitted, and information about file packages of which this file is a member.

The command /usr/propel/bin/fileedit invokes this tool, and you see the following screen, shown in Figure 1-10.

Figure 1-10. The File Database Editor

Adding a File to the File Database

To use the fileedit tool to add a file to your File database, you must enter the following information in the fields provided:

• Source pathname

• Destination pathname

The remaining fields are optional, but you should fill them in, if at all possible, for use in file queries. The source pathname field is where you list the location of the file to be propagated. Typically, all files are located in the directory /var/propel/data. If you have many files and file packages to propagate, this directory may have many subdirectories or may be linked to a separate directory altogether. Only source files in this directory structure may be distributed to slave distribution servers for further distribution to client hosts. If you are distributing a file directly to the final client host, you need not have the source file in this directory structure, though it is recommended for convenience and organization.

Once you have entered the file's information, press the Add button by placing the cursor over the button and pressing the left mouse button. You see the information appear in the window in a slightly different format. This tells you that your entry has been accepted into the database.

To obtain a listing of all source files, packages, or destination locations in your database, use the right mouse button to bring up a popup window with the cursor over the appropriate field. For example, if you choose the List option from the popup menu over the Source field of the File database editor, you see a window very much like that shown in Figure 1-11.

Figure 1-11. A List of Source Files in the File Database

This database holds a set of rules that control the distribution of files and packages to host systems. This file uses a very simple rule set to describe which files should be pushed to which systems, and under what conditions the push takes place.

The fields in this database are:

Editing the Rule Database

The ruleedit command allows you to specify which files or packages of files are pushed out to a list of client hosts. The Rule database stores the rules you have created with the ruleedit command. Enter the command:

ruleedit

You see the following screen shown in Figure 1-12.

Figure 1-12. The Distribution Rules Editor

Adding a Distribution Rule to the Rule Database

To use the ruleedit tool to add a distribution instruction to your Rule database, you must enter the following information in the fields provided:

Frequency of the distribution		This is a frequency parameter of your choice, as discussed in “How propel Works”.
A Name for the rule		Every rule must have a name.
File query parameters		This must be a query formed according to the rules described in “Additional Database Query Techniques”.
Host query parameters		This must be a query formed according to the rules described in “Additional Database Query Techniques”.

Once you have entered the rule's information, press the Add button by placing the cursor over the button and pressing the left mouse button. You see the information appear in the window in a slightly different format. This tells you that your entry has been accepted into the database.

The ruleedit window with a prepared entry looks something like the window in Figure 1-13.

Figure 1-13. A Prepared Distribution Rule

The User database contains all the necessary information about the users on your network. For more information on users and groups and the contents of these fields, see the IRIX Admin System Confirutation Site and Server Administration Guide.

Records in the User database have the following fields:

Editing the User Database

This database contains the names and vital information of the users on your network. The command /usr/propel/bin/useredit invokes this tool, and you see the following screen.

Figure 1-14. The User Database Editor

Records in the Group database have the following fields:

Editing the Group Database

The groupedit utility allows you to define groups of users for propel. A group of users is simply a selection of users that you have defined. Usually, groups are made of users with some common factor, such as a common project or organization. Since you specify the attributes of a user by using the useredit utility, you can prepare users to be part of a group when you enter them in your User database. For example, you can enter several users in your User database with the comment “advanced engineering lab” in the comment field. Then, when you use groupedit to create a group, you specify the “advanced engineering lab” comment as the query field when creating the group. The syntax for these queries is described in “Additional Database Query Techniques”. All users with that comment become part of the group. The names of individual users, User database queries, and other groups that define the new group are stored in the Group database.

Once defined, the groupedit utility stores the parameters of the group in a database. Enter the command:

/usr/propel/bin/groupedit

you see the following window, shown in Figure 1-15:

Figure 1-15. The Group Manager

When you bring up the Group Manager window after your database is populated, you see an icon and a name for each group in the database.

Adding a Group of Users to the Group Database

To use the groupedit tool to add a user group to your Group database, place the mouse cursor inside the groupedit window and use the right button of the mouse to bring up the popup menu. There are several options:

Help		Brings up a help card.
Add Group		Brings up the Add Group window.
Add User		Adds a user to an existing group.
Remove Selected		Removes the selected group.
Edit Selected Users		Brings up the useredit tool. To select a user, you must have a group displayed in a group display window.
Preview		Shows you the list of users currently in a group. All User database queries and other groups that are part of the current group are fully expanded.

Select the Add Group option to create a new group of users. When you select this option, you see the new window, shown in Figure 1-16.

Figure 1-16. The Add Group Window

You must enter a name for the group, then use the left mouse button to press the Accept or Apply button to create your new group. The Apply button creates your new group, and retains the Add Group window, so you can continue to create more groups conveniently. The Accept button creates your group and removes the Add Group window. The Cancel button cancels the operation without creating the new group.

Once you have created the group, you must specify users to be part of the group. You should notice that a new icon has appeared in the groupedit window. If you have previously used the add_user script, (described in “Populating the User and Group Databases”) your Group Manager window will already show many icons representing your existing user group. If you make two new groups and call one ``irixpro” and the other ``user” the window looks similar to Figure 1-17.

Figure 1-17. A Populated Group Manager Window

To add a list of users, a list of groups, a User database query, or any combination of these things to your new group, double-click the left mouse button with the mouse cursor over the icon for the new group. You see a new window that looks something like Figure 1-18.

Figure 1-18. A Group Display Window

Now use the right mouse button to bring up the popup menu, and select either the Add User or Add Group options to populate your group.

The Add User option brings up the Add User window, shown in Figure 1-19, with the entire list of users from your User database.

Figure 1-19. The Add User Window

To place a user in your new group, place the mouse cursor over the name of the user you wish to select and double-click the left mouse button. When you are finished selecting individual users, click the Accept button to secure your changes and remove the Add User window.

The Add Group option brings up the Add Group window, previously shown in Figure 1-16. All your currently configured groups are shown in this window. As with the Add User window, double-click the name of a group you wish to add to your new group and complete your changes by pressing the Accept button.

Once you have entered all the information and created your groups, press the Apply button in the Group Manager window to place your groups in the Group database.

The propel databases can be queried using query language rules and glob expressions. The rules regarding glob expressions are based on the Bourne shell glob expressions. See the section of the sh(1) reference page titled File Name Generation for additional documentation on glob expressions.

There are two basic ways to query from the graphical utilities: direct and indirect queries.

Direct queries are queries to the current database made through the editor for that database. For example, to query the Host database through the hostedit utility, you clear the screen with the Clear button on the utility, then enter your query parameters in the appropriate fields and press the Query button using the mouse.

Indirect queries are queries to a database other than the current database. For example, an indirect query would happen if you are editing the Rule database and you wish to query the Host database for a list of hosts to use in the rule you are creating.

The principal difference between the two forms of database query is that in the direct query, you simply fill in the desired parameter in the provided field and press the Query button using your mouse. To make an indirect query, you must fill in the field name from the database you are querying and also fill in the desired parameter value. For example, a simple indirect query in the host query field of the Rule database has the form:

fieldname = value

Any propel query menu allows you to form a query in this manner, and all query fields have an option available from the popup menu (brought up by pressing the rightmost button on the mouse while the cursor is within the query window) to expand the query immediately.

If you use this form to query for a host named pickett, you would form the actual query like this:

hostname = pickett

You cannot immediately see the results of your query on an indirect query unless you explicitly expand it. The results are not printed in the display window of the database editor. The query takes place only when propel executes and performs the distribution based on your query.

The advantage to this method is that you do not need to rebuild your databases if you add a new file or host that will be subject to a query. For example, if you have set a distribution to be sent to all hosts with the model of “Indy” on a regular basis, you do not need to remake the distribution rule if you add another “Indy” host. The new host is automatically selected by the existing query. If you wish to check to see if your query parameters will produce the desired results, use the editor for the database you are querying indirectly or the dbredit command to make a test query using the same parameters.

A glob expression in this type of query has the format:

fieldname ~ expression 

For example, an actual query would be similar to this:

model ~ indigo* 

or similar to this:

os ~ “IRIX 5.*” 

You can use several query parameters at once on both direct and indirect queries. In a direct query, simply fill in as many fields as you like before you press the Query button on your database editor. For an indirect query, you must form the query according to query language rules. For example, to query for all hosts whose manufacturer is “SGI” or whose model name begins with the characters “Ind” use the following query:

manufacturer = SGI, model ~ Ind*

With the above query, you have selected all hosts whose manufacturer is listed as “SGI” as well as all hosts whose model name begins with “Ind.” This is known as a logical ``OR” query.

To select only those hosts whose manufacturer is listed as “SGI” and whose model is listed as “Indy,” use the following logical ``AND” query:

manufacturer = SGI && model = Indy

The difference is that the second query selects only those hosts that fulfill both requirements, while the first query selects those hosts that fulfill either requirement.

You can further expand your queries by incorporating more parameters. For example, to select those hosts whose manufacturer is “SGI” and whose model is “Indy,” and also the host named “callahan,” and any host with the comment “Universal,” use the following query:

manufacturer = SGI && model = Indy, hostname = callahan,
comment = universal

all && !labmachine 

iplist = 192.27.3.0 to 192.27.3.255 

manufacturer = SGI && ! hostname = bragg 

manufacturer != SGI 

manufacturer = SGI && model = Onyx 

manufacturer = SGI || owner = armistead 

(model = Indy && ! os = 5.2), model = indigo 

The dbredit(1) utility is a command-line interface to the propel databases designed for use in server environments where the graphical utilities cannot be used. All functions that are performed by the graphical utilities can also be performed with dbredit. Complete information on the dbredit command is provided in the dbredit(1) reference page. The basic syntax of dbredit is:

dbredit database command information 

where database is the name of the propel database to be manipulated or queried, command is an operation corresponding to the operations performed through the graphical editors, and information is the information to be entered into the database or the query parameters.

The database variable can be one of host, file, rules, or collect. The command variable can be one of classes, init, list, insert, query, delete, or update. The information variable is a set of

arguments specific to each command. The arguments for each command are listed below:

dbredit host list 

{hostname {sherman}} {manufacturer {SGI}} {os {IRIX 5.3}} {domain {engr.com}} {model {IRIS Indigo2}} {iplist {127.0.0.1 192.999.888.7}} {maclist {{} 08:00:69:07:94:D7}} {mxlist {{}}}
{hostname {maguire}} {manufacturer {SGI}} {os {IRIX 5.3}} {domain {wpd.sgi.com}} {model {IRIS Indy}} {iplist {192.555.444.2}} {maclist {08:00:69:06:C1:95}} {mxlist {{}}}

{hostname {sherman}} 

{mxlist {{}}}

dbredit file add source=/tmp/localfile \ destination=/tmp/remotefile 

dbredit host query manufacturer=SGI 

dbredit host delete manufacturer=Tredegar 

dbredit host modify os=”IRIX 5.2” os=”IRIX 5.3” 

dbredit host destroy owner 

dbredit host destroy 

dbredit host names 

dbredit names 

All rules about query structure and glob expressions that apply to the graphical database editing utilities also apply to dbredit. If you have trouble creating the correct syntax, try issuing a dbredit names command and entering the field names exactly as they are displayed.

There is a shell command, runpropel(1M), available to force a distribution to a host (or collection of hosts) immediately. Command line arguments are available to specify a direct push or a periodic push of any standard frequency. For complete information on runpropel(1M), see the runpropel(1M) reference page.

The runpropel command can be run by cron(1M) regularly. Each time cron executes runpropel, the program reads and interprets the various databases and then generates or modifies all necessary files.

An example entry from a distribution system's crontabs file would be:

runpropel -f week

The frequency of the push is configurable at any time by changing the command in your crontabs file and restarting cron. For complete information on cron, see the cron(1M) reference page, as well as the section titled “Automating Tasks with at(1), batch(1), and cron(1M)” in the IRIX Advanced Site and Server Administration Guide.