Alfred Configuration and Site Administration




Configuring for Basic Operation

Alfred is installed as part of the regular RenderMan Artist Tools installation process. The default installation should be sufficient to support a single artist rendering on their own machine while using MTOR. See the Alfred installation document for a list of installed files.

Most of the configurable Alfred parameters are defined in the Alfred's initialization file: alfred.ini. Most of the following configurations require modifying this file in some way.

Before changing the alfred.ini file, make a back-up copy that you can restore if something goes wrong. Similarly, once you've made significant changes, save a copy of your changed file somewhere; that way if you need to re-install the RenderMan Artists Tools (or if you get an updated version) you can quickly re-modify the settings.

Remember that it is important for all the different Alfred modes (dispatcher, monitor, maitre-d, nimby) to be running from the same configuration data. At many sites this will be made trivial by the fact that every system sees the same NFS-mounted alfred files.



Configuring Servers and the Maitre-d for Remote Rendering

Alfred is usually invoked indirectly to perform all rendering tasks by artists using the MTOR plug-in for Maya. The default settings should provide local rendering on an artist's machine with no additional configuration. At many sites, however, Alfred is also used to support several artists using several shared rendering servers. The only configuration step required for a a single user to access multiple servers is to add server host entries to the alfred schedule. When multiple users will be sharing servers, then a maitre-d host should be chosen and configured as well.

The following instructions summarize the steps required to set up these remote systems and make the accessible to Alfred.



Start the Remote NetRenderMan Servers

See the brief NetRenderMan set-up instructions for details on installing and initializing alfservers on each host in the remote rendering pool.



Choose, and initialize, a Maitre-d Host

  1. Select a host to be the centralized maitre-d. See the scheduling document for a description of this function. Ideally, this machine will not also be used as a remote rendering server or as a clienting host; although for sites with only a few client (artist) systems competing for servers, the maitre-d daemon process will not incur any significant load.
  2. Edit the file "$RATTREE/etc/alfred.ini" with any text editor.
  3. Look for the "alfConfig(maitredHost)" definition, and add your chosen host name. For example:
    set alfConfig(maitredHost) {}
  4. Save the file.

As noted above, the maitre-d host and every user (dispatcher) host must be able to see the same alfConfig(maitredHost) value, either by sharing the same alfred.ini file via NFS or by updating every host with matching copies of the file.

Once the maitredHost value has been set, login to the designated host and start the daemon. For example:

alfred -maitre_d -v -log /usr/tmp/maitre_d.log
Note: this is usually done as a regular user, do not run alfred as root. Be aware that the log file should be renamed or removed before starting a new maitre-d to avoid write-permission problems. Also see the notes below on automatically starting the maitre-d when the host reboots.  



Add the Remote Servers to the Alfred Schedule

The Alfred schedule is similar in concept to a producer or project coordinator's "whiteboard," where people and resources are organized on a project or department basis. The default schedule simply allows everyone to use every remote server at all hours. The schedule is described in broad terms in the Alfred overview, and more specifically in the scheduling document.

Add servers to the schedule:

  1. If Alfred is not already running, start it by typing alfred -v in the console window.


  2. Open the Master Server List from the Scheduling->master schedule menu.


  3. Add the desired servers to the list. Note: in maitre-d mode the name "localhost" isn't meaningful, remember to add your own host if you plan to do any rendering locally.


  4. Press the "Write Schedule" button to save the new definitions to disk. This will automatically update the maitre-d, if there is one running.


  5. The new servers should now be available. You should see them listed in the Scheduling->watch servers and Scheduling->huntgroup dialogs.





Enabling HTTP Access to Alfred

In addition to the regular alfred user-interface (the monitor), it is also possible to use a standard web browser to see job status presented as HTML documents generated by the alfred dispatchers and maitre-d.

There are several important configuration variables in the alfred.ini file which control http access. Since there are some privacy and security considerations at issue in allowing this access, the default configuration disables browser access. There are two steps required to enable web access:

All http connections are directed to dispatchers via the maitre-d, hence there must be a maitre-d server configured and running. The maitre-d and dispatchers respond directly to http requests, without the intervention, or knowledge, of a typical web server. Whereas web servers, such as httpd, typically listen for incoming connections on TCP port 80, the maitre-d listens for connections on the port defined in the alfred.ini file, 9000 by default.

Hence one can connect to the maitre_d using a URL of the form

http://maitredHost:maitredPort, for example: or a more general approach is to install the provided "maitre_d.cgi" script which derives the proper URL directly from the current alfred.ini information and redirects browsers there automatically (also see the fallback maitre-d discussion below).



Wrangler Mode

Sometimes it can be useful for an alfred "superuser" to have access to every user's active job queue. This mode can be useful as a simple mechanism for periodically monitoring all of the active alfred jobs; and it can be especially useful to the "render wranglers" of the world who need to make sure that jobs get done, even after the artists who submit them go home for the day. See the general discussion of Alfred's web interface for more details.

To enable wrangler mode:

See the web interface discussion for details on entering and leaving wrangler mode from a browser.

Authentication using HTTP cookies
Wrangler-mode browsers present authentication credentials to each of the dispatchers on the local network using encrypted HTTP cookies, which provide a moderate level of security.


Most browsers allow you to be notified when a server is sending you a cookie. For example, netscape has a checkbox under Options-Network-Protocols. To learn more about http cookies (or technically: "persistent client state") see the included brief explanation or browse the Netscape technical specification, or visit one of the many other related sites.

Note: due to the domain-scoping rules of the cookie passing mechanism, it is probably a good idea to use fully-qualified maitre-d host names in the alfred.ini file.



Fallback Maitre-d Servers

Sites which need to increase the fault-tolerance of the centralized maitre-d server can specify a list of maitre-d hosts in the alfred.ini file. For example:
	set alfConfig(maitredHost) {tinker tailor animator}
The list order implies a highest-to-lowest preference ranking of these hosts; in this example "tinker" would be the primary maitre-d server, and the others would be tried in sequence if tinker becomes unavailable (crashes, etc).

For this scheme to work, the alfred administrator must ensure that an alfred maitre-d is running on each of the given hosts.

When the current maitre-d becomes unavailable, all of the connected dispatchers and nimbies will reconnect to the next host in the list (if it is responding). The current maitre-d state, such as the list of currently checked-out remote servers, will be reconstructed by the new maitre-d as each new reconnection occurs.

If an administrator restarts a crashed higher-ranking maitre-d, it will automatically cause dispatcher and nimby connections to be broken with the current secondary server and reestablished with itself.

One consequence of this fallback mechanism is that hard-coded http URL's which access the maitre-d will not be valid when a secondary server is in effect. A cgi script is provided with the release which can be used to automatically resolve the current maitre-d and direct browsers to it. Hence users would have a bookmark or link on a homepage which accesses the cgi script rather than the simple hard-coded link to the maitre-d itself; for example: Note that at many sites this will require root permissions to install the script in the web server's cgi-bin directory. The script is written in perl, and should be fairly straightforward for an experienced cgi programmer to analyze for security problems. By default it reads the current alfred.ini file to determine the list of hosts to query and the TCP port to use. If the site is configured such that cgi scripts do not have access to the alfred.ini file (due to firewalls, etc), then these values can easily be hard-coded into the perl script. The script is located at $RATTREE/admin/maitre_d.cgi in the distribution. Several example locations of the cgi-bin directory (on the web server host) are: although the actual location will be very site dependent.



Restart On Reboot: init.d/rc2 scripts

On most Unix(tm) systems the /etc/rc2.d directory contains (links to) scripts which are run while the system is booting up. These scripts are responsible for starting the various important system daemons, such as NFS and mail. An rc2 script is provided with the alfred release which can be configured to automatically start any or all of the following alfred related services at boot time: The actual restart mechanism involves several pieces. The provided script $RATTREE/admin/Install-alfred_restart can be used to copy the components to their proper location and create links, etc. Note that it must be run as root in order to install the files in the system directories. The script assumes an SGI IRIX-like configuration. You can run the script as
	Install-alfred_restart -i -n
which will print the installation commands (-i) without executing them (-n). In addition, the "-u" option will uninstall any previously installed system files.

The (installed) file /etc/config/alfred_restart.options controls the alfred restart process during boot-up, and it will probably be the only file which needs modification. Each of the components (maitre-d, nrmserver, dispatcher) can be toggled on or off with a simple flag variable.

Once installed, the entire alfred restart mechanism can be toggled on or off using the chkconfig(1) mechanism. As root,

	chkconfig alfred_restart on       (or  off)
The /etc/init.d/alfred_restart script runs as root during reboot, but the /etc/config/alfred_restart.options file allows you to specify a user identity for each of the launched components, for example the maitre_d and alfservers might be started as "guest" or as some site-defined user.

If the alfred_restart script determines (during boot) that there are previously saved job checkpoint files on the local machine, it launches an alfred dispatcher which runs as the owner of the job. The dispatcher will pick up the checkpoint file and continue the job from where it was interrupted.




Customizing Dialog Messages

The file $RATTREE/lib/help/ contains the text displayed by alfred in various balloon-help boxes and dialog messages. Some sites may wish to customize portions of this text.




Network Name Service Basics

Alfred frequently needs to convert human-readable hostnames into a TCP/IP Internet addresses. There are three sources of hostname-address information on a typical Unix system: the /etc/hosts file, the NIS ("yellow pages") database, and the DNS (BIND) name service.

Whenever Alfred needs a host address, it calls the gethostbyname() routine. This routine uses the resolver(4) to search through the available sources of name-to-address information and return the required Internet address, see the manual pages for details.

The order in which these three data sources are searched can significantly affect both the accuracy and speed of the answer. The /etc/hosts file will be the quickest source of information, but at many sites it only contains a few minimal entries, the real data resides in the NIS database. The DNS service is usually the slowest, but it is also the most general; it is the mechanism used look up addresses for unknown hosts around the world.

Configuring your name service is a multi-step process that should be done by a system administrator who understands the local network and who is involved in maintaining the name data. The following discussion is intended as a basic guide for a typical small studio environment.

Start with /etc/hosts.  If you are managing a very small number of systems then the simplest approach is to just keep the /etc/hosts files on each system synchronized by hand. Just add the new hostnames and addresses on each system (see below).

Why use NIS?  If you are managing more than just a handful of systems, or your hostnames or addresses change frequently, then the NIS database should be seriously considered. The idea is that you make changes to a single copy of the host data on a master NIS server, then the other hosts on the network are NIS clients: they query the server for the most current data. NIS is also used to manage several other important system databases that tend to change frequently at most sites, such as login and password information, and mail aliases. The set-up chore is non-trivial however, so plan to take your network down while getting it right.

Where does DNS / BIND fit in?   When people use the web, they need access to a DNS nameserver. The question is: should there be one running locally or is the one at the site's ISP sufficient? The DNS protocol allows an application to ask the nearest nameserver for the Internet address of a particular host; if that nameserver doesn't know it asks another, typically higher level, nameserver for the address. Eventually, if the host is properly registered, some nameserver somewhere will know its address. The only reason to set up a local nameserver at a small site is to cache frequently used addresses. In cases where the ISP's nameserver is "on the other side of a modem" this can help to reduce the number of slow, expensive, dial-out DNS queries.


A typical small studio configuration.

The following examples contain name service settings that are generally useful in a small studio environment. As mentioned above, each real site will have its own requirements and quirks, and a system administrator is needed to map out the best solution.

Assume that we're configuring the host named ``snappy'' on a network in the ``'' domain. For the purposes of this example assume that we have obtained a "Class C" domain from our ISP and that all of the hosts in our domain have addresses of the form, and in particular snappy is (these are just examples!).

Edit /etc/hosts
The /etc/hosts file on each machine must contain an entry for "localhost" (as and an entry which defines the local host's name and Internet address.

Even if NIS or DNS are in use, these two entries are used to configure the system during boot-up, before the other name service information is available. Note that a service called "DHCP" can be used during boot-up to dynamically assign host addresses from a pool. DHCP is generally not used in typical Alfred client-server situations since it is important for server names to always map to the same physical hosts.

So, in our example, /etc/hosts will contain at least the following two entries:	localhost  snappy

Note that the host entry lists the fully qualified host name "" first, followed by the shortened alias "snappy". At most sites, using this pattern will prevent many hostname-related problems (including license server problems).

If you are using /etc/hosts as your name service, then add all of the other hosts within the domain to the file. Follow the fully-qualified-name-first pattern.

If you are using NIS, then the host which is the ypmaster should have a complete /etc/hosts file, every other host on the network usually has a very brief /etc/hosts file, containing just the two entries above, and a single plus-sign "+" on a line by itself, as the last line of the file. This indicates to the system that the host entries are "continued" in the NIS database. After making changes to the /etc/hosts file on the ypmaster, remember to "cd /var/yp; ./ypmake" to push the new entries out to the network.


Edit /etc/resolv.conf
This file (note the odd spelling) is used to configure the basic name resolver behavior. An example configuration might be:

See resolver(4) for details. In this case we've explicitly defined the local domain (; we've established an ordering for hostname searches (local nis bind); and we've specified a nameserver host to handle unknown names.

The domain keyword helps simplify searches and to clarify which names and addresses are part of the local network rather than external.

The nameserver keyword defines the Internet address of the DNS server. Replace "" with the appropriate numeric dotted-quad value. If there is a DNS nameserver running on the local network use its address, otherwise use the address provided by your parent domain or ISP. Note: several nameservers can be specified, one per line; they are tried in sequence.

Special Note for IRIX 6.4 and Earlier: Add one additional line to /etc/resolv.conf as follows:

	hostresorder local nis bind
The hostresorder keyword determines the order in which name databases are searched. In this case, the /etc/hosts file on the local machine is searched first, followed by the NIS database, followed by the DNS (BIND) server. Note that the hostresorder keyword is IRIX specific (IRIX 6.4 and below). Most modern systems use nsswitch as described below; some older systems use environment variables to control the resolver.


Edit /etc/nsswitch.conf
(Note: This step does not apply to IRIX 6.4 and earlier). This file controls the order in which various mapping services are tried when resolving a name. As usual, coordinate changes to this file with your system administrator. One recommended ordering of the hostname services is:
	hosts:     files nis dns
this setting causes the /etc/hosts file on the local machine is searched first, followed by the NIS database, followed by the DNS server.


Configure the other systems
Make similar modifications to all of the hosts on the network. It's usually a good idea to reboot everything after making major network address changes. If using NIS, reboot the NIS master server first, then configure other systems to come up looking for NIS data and reboot them.


Test the hostname look-up service
After all the hosts on the network have been configured, perform a few simple tests on your network name service. Assuming that one of your rendering servers is named then try these tests:


ping scrawl
This should look up the proper address for "scrawl" and exchange low-level network test packets. If not, then your host database configuration needs fixing.
If you're running NIS (also known by its former name "yellow pages"), then this command will tell you which NIS server is being queried for your host information.
nslookup scrawl
If you are running DNS locally then this command will query the nameserver hierarchy for scrawl's address. The response will contain the name and address of the particular DNS server which held the information, as well as the address of the host you specifically queried.

Pixar Animation Studios
(510) 752-3000 (voice)   (510) 752-3151 (fax)
Copyright © 1996- Pixar. All rights reserved.
RenderMan® is a registered trademark of Pixar.