The Wiretap path translation service converts the syntax of a file path referred by a Wiretap server running on a Linux workstation to a format that the client can understand. This service allows Wiretap clients, who might be running Windows or Mac OS X, to understand file paths that are referenced by an Autodesk Creative Finishing product to clips that have been soft-imported from a NAS, SAN, or any remote mounted storage.
For example, Lustre running on a Windows workstation can work with an Autodesk Creative Finishing product's soft-imported clip on a SAN or NAS.
For the Windows workstation, the syntax of the path to the media files may resemble: N:\myclips\clip1\frame1.dpx
On a Linux workstation, the path to the same media files may resemble: /CXFS1/myclips/clip1/frame1.dpx
When the Wiretap client tries to locate this clip, the path translation service converts the syntax of the path so that the client can access the soft-imported clip from a remote storage device it has mounted locally.
The path translation service uses a translation database. The path translation database contains a set of rules that specify how to convert (or “translate”) a file path referred to by a source workstation (the host running the Wiretap server) into a path that the client can understand. These rules are contained in the /usr/discreet/wiretap/cfg/sw_wiretap_path_translation_db.xml file on each Autodesk Creative Finshing workstation. This configuration file is read by the Wiretap server.
The translation database is an XML file that must be updated by hand as the network configurations change. The file should be created and maintained by a system administrator who is aware of the configuration of the network.
To configure the path translation database:
Do you have many hosts accessing the same storage device? Do they mount the central storage using the same syntax and drive names? Are these hosts running the same application? Are they running the same operating system?
If your network includes groups of hosts that mount their storage using the same syntax, you may be able to use a group or platform rule to translate the syntax for all similar hosts. If, however, all of your hosts use different syntax and mount points for their storage, you will have to create a host/path rule for each source and destination host.
See the sections that follow for a description of the possible path translation rules you can create.
You must respect XML syntax standards when editing the path translation file. For example, the values assigned to attributes must not include ampersands (&) or left angle brackets (<) in their literal form. All instances of these characters, except left and right angle brackets used to delimit XML tags, should be replaced with & and < respectively. Do not concern yourself with the white-space between attributes; it is ignored when the file is parsed.
Create a host/path rule to translate the path syntax used by the source workstation (the workstation running the Wiretap server) to the path syntax used by the destination workstation.
The syntax of the host/path rule is as follows: <map src_host=”<src_host>” src_path=”<src_path>”
dst_host=”<dst_host>” dst_path=”<dst_path> ”>
Enter a value for each attribute. See the following table for a description of the valid values for each attribute.
<map src_host=“flame1” src_path=“/CXFS1”
dst_host=“windows1” dst_path=“N:\”>
Setting up a host-to-host translation for every machine in your network is inefficient. If you have many hosts that will use the same path translation rule, you can set up a group or platform rule. See the sections that follow.
Use the group rule when you have several workstations that will use the same rule to convert the path syntax of a single source or group of source workstations. This rule is effective in larger installations where numerous workstations mount storage using identical syntax.
All hosts in a group rule must mount directories using exactly the same syntax.
The syntax of the group rule is as follows:
<group name=”<group_name>” os=”<os_name>”>
You must enter a value for each attribute. See the following table for a description of the valid values for each attribute.
<group name=“Autodesk_Stations” os=”Linux”>
<group name=“Lustre_Windows_Stations” os=”WindowsNT”>
After you have defined a group, you can use the host/path rule to map all the hosts in the group to the same path by using the group name for either the src_host or dst_host attribute value.
In the following example, all hosts in the Lustre_Windows_Stations group map the Autodesk_Stations storage path to N:\myclips, a mount point they all share:
<map src_host=“Autodesk_Stations” src_path=“/CXFS1/myclips”
dst_host=“Lustre_Windows_Stations” dst_path=“N:\myclips”>
You can also use a platform rule to map all the hosts in a group to the same destination path based on the operating system they all run.
In the following example, the platform rule is used to map all Windows users to N:\ when translating /usr/ from a Linux system:
The platform rule is similar to the group rule in that the rule is applied to all hosts running the same operating system.
All hosts running the same operating system must mount directories using exactly the same syntax. For example, all Windows workstations must mount the NAS on the N:\ mount point to use the same path translation rule for the NAS.
The syntax of the platform rule is as follows:
<map src_os=“<src_os>” src_path=“<src_path> ”
dst_os=“<dst_os>” dst_path=“<dst_path>”>
You must enter a value for each attribute. See the following table for a description of the valid values for each attribute.
| Attribute | Description |
|---|---|
| src_os | The operating system of the workstation to which a client connects |
| src_path | The path to the remote storage as referred to by all hosts using the same operating system |
| dst_os | The operating system of the client that mounts the same storage referred to by the source |
| dst_path | The path to the remote storage as referred to by the hosts running the destination operating system |
When you have many Wiretap servers, you must update the path translation database on each server every time there is a change to the network configuration.
To simplify the management of the database, you can create a symbolic link from the path translation file on all hosts running the Wiretap server to one machine that contains the actual file.
After the path translation database is updated by the system administrator, it must be tested. The sw_wiretap_translate_path command verifies that a path requested from the Wiretap server on the local machine can be translated into a path that can be understood by the client machine.
The syntax of the command is the following:
sw_wiretap_translate_path[-h <host name>] [-p <path>] [-f <file containing paths>] [-H <destination host name>] [-O <destination OS>]
The command options are described in the following table.
| Option | Description |
|---|---|
| -h | Specifies the host name or IP address of the Wiretap server. The default is localhost. |
| -p | Specifies the path on the Wiretap server host to translate. |
| -f | Specifies the file containing the paths on the remote host to translate to the path on the local host, delimited by new lines. |
| -H | Specifies the destination host name. The default is localhost. |
| -O | Specifies the destination operating system (Linux, Windows NT, Mac OSX). |
To test the path translation database:
For example, suppose you have a SAN mounted as “/CXFS1” on your Flame workstation (flame1). A Windows PC (windows1) will mount the SAN as “N:\”. The path translation file contains the following entries:
<map src_host=“flame1” src_path=“/CXFS1”
dst_host=“windows1” dst_path=“N:\”>
From the workstation, open a new terminal and type:
./sw_wiretap_translate_path -h flame1 -p /CXFS1/myclips -H windows1
The result should return the value of the destination path, which represents how “windows1” will mount“/CXFS1” on “flame1”.