|Home -> Administrating VL2|
To configure a system for operation as a relay server, you will need to install (in order):
You will also need to configure the mutex daemon (see below) and arrange for it to start up on boot.
VL2 users are almost the same as regular Unix users; you can add a new VL2 user using any Unix administration tool (e.g. useradd). There are three differences:
usermod -s /usr/bin/relay username
usermod -L username
This invalidates username's existing authorisation file (if any). In the current directory, it creates "username.key" (the new authorisation file) and in the user's home directory, it creates "/home/username/.ssh/authorized_keys" (the SSH public key file). hostname must be the fully-qualified domain used to access the relay server via the Internet.setupuser key hostname username
The setupuser tool automates the process of creating a user, setting up the shell, disabling password authentication and generating a key pair. This can be done by running:
hostname must be the fully-qualified domain used to access the relay server via the Internet. If the user already exists, then this command will delete their account (but not their home directory) and recreate it! If you need to set up many users, then you can specify many user names, e.g.:setupuser user hostname username
setupuser user hostname alice bob charlie dave eve
Having added a user, you will need to give that user permission to use VL2 boards.
To deactivate a user, either delete their user account:
or remove their "/home/username/.ssh/authorized_keys" file.userdel username
The relay server should be a dual-homed machine, i.e. it should be present on two networks. There must be an internal network for board servers; this must not be accessible from the external network, except via the relay server.
Don't allow the VL2 users to log in on the relay server (except using the relay shell). If they can log in, then they can bypass the VL2 security by connecting directly to the board servers (e.g. by telnet). They can also connect to the mutex daemon and disrupt the operation of VL2, e.g. by locking all the boards. VL2 is not secure against this sort of "local user" attack.
To prevent users bypassing VL2 security by SSH forwarding, add the following lines to the end of "/etc/ssh/sshd_config":
AllowTcpForwarding no GatewayPorts no X11Forwarding no
VL2 user permissions are based on Unix groups. The system works as follows:
Then add each student's user account to the group.groupadd s3eskgrp
Then create a statement in /etc/mutexdaemon.conf similar to:usermod -a -G s3eskgrp username
Finally, run[s3esk] address = s3eskboard1 address = s3eskboard2 address = s3eskboard3 address = s3eskboard4 group = s3eskgrp
to update the configuration database. The result: any of the users who are members of the Unix group s3eskgrp can now access the board cluster named "s3esk".mutexdaemon reload
You can revoke the permissions for a single user by removing him/her from the group.
New boards can be brought online by the process described on this page, then configured as on this page. When you have configured a board, you will have given it an IP address, a MAC address, a website URL for updates and an FPGA configuration. The IP address is then added to one of the clusters defined in /etc/mutexdaemon.conf as appropriate.
You can also use a Linux PC as a board server, by running the "embedded" binary from the "bin" directory. It will expect a "/etc/boarddaemon.conf" file, which has the same format as "econfig" in the FX12 version.
You should ensure that all of the boards in a cluster are effectively identical, because if there is more than one board in a cluster, and a user is not already using any other boards in that cluster, then assignment is random.
VL2 has some ability to recover from one type of problem. FPGA board servers may go offline, e.g. because of malfunction or maintenance. After a failed attempt to connect to an offline board, the relay shell will notify the mutex daemon that the board is offline. It will then be taken "out of circulation" for five minutes; other boards in the cluster will be used. If the cluster is large enough, users will not notice. After five minutes, connections are retried. This also allows the VL2 administrator to temporarily remove boards without editing /etc/mutexdaemon.conf.
However, many other problems will require the administrator to
intervene. To help with this, the relay shell and mutex daemon
log commands and status data to the syslog (/var/log/syslog by default).
The logging includes some of the commands sent to the board servers
(up to the "useuart" command if issued). Bit files uploaded by users
are also stored by the relay server. Thus,
if a problem occurs, the administrator has a way to trace it to a
specific user and bit file.
|Copyright (C) Jack Whitham 1997-2011|