Contents:
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.
The following instructions summarize the steps required to set up these remote systems and make the accessible to Alfred.
See the brief NetRenderMan set-up instructions for details on installing and initializing alfservers on each host in the remote rendering pool.
set alfConfig(maitredHost) {somehost.busy.com}
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.logNote: 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.
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:
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:
Hence one can connect to the maitre_d using a URL of the form
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.
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:
Install-alfred_restart -i -nwhich 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.
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.
Assume that we're configuring the host named ``snappy'' on a network in the ``busy.com'' 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 192.0.1.xxx, and in particular snappy is 192.0.1.42 (these are just examples!).
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:
127.0.0.1 localhost 192.0.1.42 snappy.busy.com snappy
Note that the host entry lists the fully qualified host name "snappy.busy.com" 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 busy.com 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.
domain busy.com nameserver www.xxx.yyy.zzz
See resolver(4) for details. In this case we've explicitly defined the local domain (busy.com); 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 "www.xxx.yyy.zzz" 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 bindThe 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.
hosts: files nis dnsthis setting causes the /etc/hosts file on the local machine is searched first, followed by the NIS database, followed by the DNS server.
|
Pixar Animation Studios
|