tmcc ifconfig
The response to this request would be:
INTERFACE=1 INET=10.0.0.1 MASK=255.255.255.0
INTERFACE=2 INET=10.0.1.1 MASK=255.255.255.0
which indicates that interfaces eth1 and eth2 (or perhaps fxp1 and
fxp2) should be configured to the given IP addresses and netmasks.
FREE
ALLOCATED=pid/eid NICKNAME=name
The first form indicates that the node is not currently allocated to
an experiment. The second form says that the node is running as part
of the "eid" experiment in the "pid" project, and was named "name" in
the NS file that described the topology.
INTERFACE=Z INET=X.X.X.X MASK=Y.Y.Y.Y MAC=AA:BB:CC:DD:EE:FF
Which says that the network interface with MAC address "AA:BB:CC:DD:EE:FF"
is assigned to IP address "X.X.X.X" with netmask "Y.Y.Y.Y". The
INTERFACE specification is currently invalid, since there no way to achieve
a consistent ordering of interfaces between various operating systems.
Rather, the MAC address is used to determine which interface to configure.
A utility program called /etc/testbed/findif is provided to map
the MAC address to an interface name suitable for use with the
ifconfig program. On Redhat 7.1, the setup script would take this
information and issue the following shell commands.
iface=`/etc/testbed/findif AA:BB:CC:DD:EE:FF`
/sbin/ifconfig $iface inet X.X.X.X netmask Y.Y.Y.Y
ADDGROUP NAME=pid GID=XXXX
ADDUSER LOGIN=joe PSWD=ABCD UID=YYYY GID=XXXX ROOT=N NAME="Joe User" \
HOMEDIR=/users/joe GLIST=ZZZ0,ZZZ1
The ADDGROUP reply gives the name of the group and the
numeric gid for that group. The ADDUSER reply has
the following fields:
On Linux, this information would be converted into the following commands:
LOGIN     The user/account name. PSWD     The encrypted password string, suitable for direct insertion into the password file. UID     The numeric uid. GID     The primary group for the user, as a numeric gid. ROOT     Indicates whether the user should be granted root access by placing the user into the root group (wheel group on FreeBSD/NetBSD). NAME     The full name of the user, suitable for insertion into the gecos field of the user's password entry. HOMEDIR     The absolute path to be used for the home directory. GLIST     A (possibly null) comma separated list of auxiliary group ids, as numeric gids.
groupadd -g XXXX pid
useradd -u YYYY -g XXXX -p ABCD -G root,ZZZ0,ZZZ1 -d /users/joe -c "Joe User" joe
REMOTE=fs.emulab.net:/users/joe LOCAL=/users/joe
REMOTE=fs.emulab.net:/proj/testbed LOCAL=/proj/myproj
On Linux, this information would be converted into the following
commands:
mkdir /users/joe
/sbin/mount fs.emulab.net:/users/joe /users/joe
mkdir /proj/myproj
/sbin/mount fs.emulab.net:/proj/myproj /proj/myproj
RPM=/path/to/name.rpm
On Linux and Freebsd, each RPM is installed with the rpm
command, which will install the RPM only if it has not already been
installed:
rpm -i /path/to/name.rpm
CMD=/path/to/runme UID=joe
Which says to run /path/to/runme as user joe when
the node boots. The UID is always the experiment creator. On FreeBSD,
Linux, and NetBSD, the command is run once the node is running
multiuser. If the node reboots before the experiment is terminated,
the command will be run again.
tmcc startstatus XX
which sends the numeric value XX back to the TMCD. There is no
response from the TMCD to this command.
READY=N TOTAL=M
which says that N nodes have reported in, of a total number
of M nodes in the experiment. The application can continue to
poll until N==M, but be sure to add some delay between each
poll to avoid livelock at the TMCD. Note that the ready count is
essentially a use-once feature; The ready count cannot be
reinitialized to zero since there is no actual synchronization
happening. If in the future it appears that a generalized barrier
synchronization would be more useful, we will investigate the
implementation of such a feature.
NAME=nodeA-linkX IP=X.X.Y.A ALIASES='nodeA nodeA-0'
NAME=nodeB-linkY IP=X.X.Y.B ALIASES='nodeB nodeB-0'
NAME=nodeC-lanZ IP=X.X.Z.C ALIASES='nodeC-0'
ALIASES is a space-separated list of aliases. The /etc/hosts file that
would be created for this response is:
X.X.X.A nodeA-linkX nodeA nodeA-0
X.X.X.B nodeB-linkY nodeB nodeB-0
X.X.Z.C nodeC-lanZ nodeC-0
Say that nodeA is making this request. NodeA is obviously connected to
itself, so it gets an alias pointing to its own interface. NodeA is
directly connected to NodeB on NodeB's linkY interface, so it too
gets an alias so that an application running on nodeA can just use the name
NodeB. NodeC is not directly connected to NodeA, and nodeA does not have a
route to it (perhaps the network toplogy is disjoint, or perhaps routing
was not enabled in the NS file,) so it does not get an alias. Note that, in
the case of nodes that are not directly connected, no guarantee is made
that the alias is picked for the 'nearest' interface.
tmcc log "This is a log message"
The log file is stored in /proj/pid/logs/eid.log, where
pid is the name of the project and eid is the name
of the experiment. The file is appended to each time; it is the
responsibility of the experimentor to zero the log file when done, or
if a new experiment with the same name is started.