supporting autocreating and autoloading images. The imageid form now
sports a field to specify a nodeid to create the image from; If set,
the backend create_image script is invoked. Thats the easy part.
Slightly harder is autoloading images based on the osid specified in
the NS file. To support this, I have added a new DB table called
osidtoimageid, which holds the mapping from osid/pctype to imageid.
When users create images, they must specify what node types that image
is good for. Obviously, the mappings have to be unique or it would be
impossible to figure it out! Anyway, once that image mapping is
in place and the image created, the user can specify that ID in the NS
file. I've changed os_setup to to look for IDs that are not loaded,
and to try and find one in the osidtoimageid. If found, it invokes
os_load. To keep things running in parallel as much as possible,
os_setup issues all the loads/reboots (could be more than a single set
of loads is multiple IDs are in the NS file) at once, and waits for
all the children to exit. I've hacked up os_load a bit to try and be
more robust in the face of PXE failures, which still happen and are
rather troublsesome. Need an event system!

Contained in this revision are unrelated changed to make the OS and
Image IDs per-project unique instead of globally unique, since thats a
pain for the users. This turns out to be very messy, since underneath
we do not want to pass around pid/ID in all the various places its
used. Rather, I create a globally unique name and extened the OS and
Image tables to include pid/name/ID. The user selects pid/name, and I
create the globally unique ID. For the most part this is invisible
throughout the system, except where we interface with the user, say in
the web pages; the user should see his chosen name where possible, and
the should invoke scripts (os_load, create_image, etc) using his/her
name not the internal ID. Also, in the front end the NS file should
use the user name not the ID. All in all, this accounted for a number
of annoying changes and some special cases that are unavoidable.

a dropdown menu. Required some changes to TBProjList command return
format, which required changes in newgroup and newimageid.

experiment info page redraw every 30 seconds when the exp state is in
the activating or swapping state. Eventually will stop when the state
changes.

capability. New DB field in the users table (pswd_expires) which is a
date field that initially gets set to one year after the user account
is created. When the password is changed via the web form, it gets
bumped 1 more year into the future *unless* the current uid is
different from the target_uid (ie: you are changing a password for
someone else). In that case, the expiration is set to the current
date, which forces the target user to change his password next time he
logs in. I've changed the menu/auth code to look for password
expiration, and when expired the menu options contain just a single
option to change the password. All other https pages will fail with a
password expired message. Normal text pages will work of course.

sorted view, much like the public listing, with a section for active
and a section for inactive. The alternate view is accessed via a link
at the top of the page that allows you to switch between them.

pages now show the lastlogin info that is gathered from sshd syslog
reporting to users. That info is parsed by security/genlastlog.c, and
entered into the DB in the nodeuidlastlogin and uidnodelastlogin
tables. If not obvious from the names, for each user we want the last time
they logged in anyplace, and for each node we want the last time anyone
logged into it. The latter is obviously more useful for scheduling
purposes. All of the various images have new /etc/syslog.conf files,
and the 6.2 got new sshd_configs (all cvsup'ed with kill -HUP). There
is an entry in boss:/etc/crontab and users:/etc/syslog.conf. All of
this is decribed in greater detail in security/genlastlog.c.

use.

but simply entered into the DB record for the experiment until we know
what to do with them. Add to batchexp script arguments, since all that
stuff is done outside the web interface. Add a swapexp perl script to
swap an an experiment in/out form the command line. Add web links on
the Experiment Information page to do this from the web interface. A
bunch of locking changes. Previously expt_terminating in the
experiment record prevented multiple calls to terminate an experiment,
but now we have a more general locking problem with
start,swapin,swapout, and terminate, so change expt_terminating to
expt_locked (still a datetime field) and add locking to all of
startexp, swapexp, and endexp. Note that batch experiments cannot be
swapped yet because of locking issues still to be resolved. Minor
cleanup in tbreport to make email message look better.

experiment code. No longer uses another table. Rather, the experiment
record contains a couple of extra fields for the batch system. Also
combined some of the backend code (no longer a killbatch script).
Also added scriptable experiments; the batchexp program in the bin
directory can start an experiment from the command line, and in fact
is used from the web page for both batch experiments and immediate
experiments (-i option). All of the DB code that was in the web
interfaces was moved to batchexp.

replaced by the "images" table. New os_info table is added. New web
pages to add and delete OSIDs to/from the os_info table, for use in
the NS file. tb-create-os is gone. handle_os no longer operates on the
tbcmds file, and no longer writes anything into the ir file. Moved the
setting up of os state (nodes table) from os_setup to handle_os, where
it should be. os_load and sched_reload now take a single argument, the
name of the imageid from the images table.

the testbed list.

of all that duplicated goo).
Clean up all the formerror code, calling standard FORMERROR() function.
Get rid of all the inline DB specific constants, moving them to dbdefs.php3
include file.