Firewalled experiments (see tbsetup/elabinelab.in for the other stuff).

* To support firewalled experiments, needed to add a new virt_firewalls
  table to split the existing firewalls table up, which included both
  virtual and physical stuff. There are the usual frontend changes and a
  few other things scattered around, including tmcd.c.

* The firewall code in tbswap got some beefing up to support adding and
  deleting nodes from the its special control net vlan. Note that I have
  not made any progress on containment of deleted nodes, just as we do not
  do anything now for teardown (unless its paniced, in which case the
  experiment cannot be modified anyway).

* ptopgen and assign_wrapper got some interesting modifications: Unlike
  regular swapmod, we cannot just tear down all the vlans since that would
  interrupt everything inside the inner elab. Instead, leave the vlans as
  is. The problem is that when assign runs, it can just as easily pick
  different interfaces on the same nodes, which would be a royal pain in
  the ass to deal with! So, ptopgen got a new option (-u) that assign
  wrapper uses to tell ptopgen that it should prune out unused interfaces
  from nodes that are already allocated to the experiment. This is, at
  best, as pathetically gross hack, but it makes sure that all the
  interfaces stay the same across swapmods.

* The unrelated revision of elabinelab has a bunch of new code for adding
  and deleting nodes from the inner elab. Mostly it deals with dhcpd (inner
  and outer, waiting for nodes to reboot, etc). It also deals with updating
  the vlans table in the DB, pruning out any nodes (ports) that are deleted
  but for which there are still interfaces in existing vlans. Said ports
  are them moved back to the default vlan with calls to snmpit. Also under
  another revision a a couple of weeks ago are the web interface changes to
  support the newnode MFS inside an inner Emulab.

* swapexp and endexp got some more checks for firewalled and paniced
  experiments, which were missing.

some additional privs; allowed to view/edit node logs and histories of
all nodes, plus some others.

for the near future. Two big changes:

* Add WikiOnly accounts. An external user can register for an account on
  the wiki. Rather then use the registration stuff that comes with TWiki,
  redirect to new Emulab web page so we can manage all of the wiki accounts
  from one place. I modified the joinproject page to spit out a subset of
  the required fields so that its simple to get a wiki only account (just a
  few things to fill in).

  In keeping with current security practices, we still generate a
  verification email message to ensure the email address works. However,
  when the user completes the verification, the wiki account is created right
  away, rather then waiting for someone to approve it (since that would
  defeat the entire point of the wiki).

  Aside: I have not thought much about the conversion from a wiki-only
  account to a real account. That is going to happen, and it would be nice
  if that step did not require one of use to go in and hack the DB. Will
  cross that moat later.

  Aside: Rather beat up on the modify user info page too much, I continue
  to spit out the same form, but mark most of the fields as not required,
  and allow wiki-only people to not specify them.

* Both the joinproject and newproject pages sport a new WikiName field so
  that users can select their own WikiName. I added some JavaScript to
  both pages that generate a suitable wikiname from the FullName field, so
  that as soon as the user clicks out of the FullName, a default wikiname is
  inserted in the field.

  Both pages verify the wikinames by checking to make sure it is not
  already in use, and that it meets the WikiRules for WikiTopic names.
  (someone please shoot me if I continue to use WikiNotation).

message requesting information about an experiment (why has it been
swapped in for 6000 hours, tell us before we swap it out).

table that will prevent an experiment from being swapped/modified. The
toggle is on the showexp page, and the toggle is *not* admin
over-ridable; you must turn the toggle off (and of course, you must be
an admin to do that).

* Add new DB table "webcams" which hold the id of the webcam, the
  server it is attached to, and the last update time.

* Add new sitevars webcam/anyone_can_view and webcam/admins_can_view.
  Should be obvious what they mean.

* Add trivial script grabwebcams (invoked from cron) to grab the images
  from the servers and stash in /usr/testbed/webcams. The images are
  grabbed with scp, protected by a 5 second timeout. Fine for a couple
  of cameras.

* Add web page stuff to display webcams, linked from the robot mape page.

Permission to view the webcams is currently admin, or in a project that is
allowed to use a robot. We can tighten this up later as needed.

A bunch of engineering on the robot code.  I'm sure I've broken something,
but the majority of it is done and I wanted to get a checkpoint in.

	* GNUmakerules: Add rpcgen rules.

	* Makeconf.in: Add PATH and host_cpu variables so
	cross-compilation works properly.  Add JAVAC and JAR for java
	compilation.  Add BRAINSTEM_DIR that refers to a brainstem build
	directory to be used for the robot build.

	* configure, configure.in: Prepend the arm cross-compile dir to
	PATH.  Detect java for building applets.  Add --with-brainstem to
	specify the brainstem build dir.  Add --enable-mezzanine to turn
	on the mezzanine build.

	* robots/GNUmakefile.in: Add client target that builds the
	subdirs.

	* robots/emc/GNUmakefile.in, robots/emc/emcd.h, robots/emc/emcd.c,
	test_emcd.sh.in, robots/rmcd/GNUmakefile.in, robots/rmcd/rmcd.c,
	robots/rmcd/test_rmcd.sh.in, robots/vmcd/test_vmc-client.sh.in,
	robots/vmcd/test_vmcd.sh.in, robots/vmcd/test_vmcd2.sh,
	robots/vmcd/test_vmcd3.sh, robots/vmcd/test_vmcd4.sh,
	robots/vmcd/vmc-client.c, robots/vmcd/vmcd.c: Updates for the mtp
	switch to using rpcgen.

	* robots/emc/test_emcd.config: Restore missing config line.

	* robots/mtp/GNUmakefile.in, robots/mtp/global_bound.java,
	robots/mtp/mtp.h, robots/mtp/mtp.c, robots/mtp/mtp.java,
	robots/mtp/mtp.x, robots/mtp/mtp_command_goto.java,
	robots/mtp/mtp_command_stop.java, robots/mtp/mtp_config_rmc.java,
	robots/mtp/mtp_config_vmc.java, robots/mtp/mtp_control.java,
	robots/mtp/mtp_dump.c, robots/mtp/mtp_garcia_telemetry.java,
	robots/mtp/mtp_opcode_t.java, robots/mtp/mtp_packet.java,
	robots/mtp/mtp_payload.java, robots/mtp/mtp_recv.c,
	robots/mtp/mtp_request_id.java,
	robots/mtp/mtp_request_position.java,
	robots/mtp/mtp_robot_type_t.java, robots/mtp/mtp_role_t.java,
	robots/mtp/mtp_send.c, robots/mtp/mtp_status_t.java,
	robots/mtp/mtp_telemetry.java, robots/mtp/mtp_update_id.java,
	robots/mtp/mtp_update_position.java, robots/mtp/robot_config.java,
	robots/mtp/robot_position.java, robots/mtp/test_mtp.sh: Replace
	hand-generated stubs with xdr stubs for C and java.  Java stubs
	were generated by "remotetea's" jrpcgen.

	* robots/primotion/GNUmakefile.in,
	robots/primotion/buttonManager.hh,
	robots/primotion/buttonManager.cc, robots/primotion/dashboard.hh,
	robots/primotion/dashboard.cc, robots/primotion/flash-user-led.cc,
	robots/primotion/garcia-pilot.cc, robots/primotion/garciaUtil.hh,
	robots/primotion/garciaUtil.cc, robots/primotion/ledManager.hh,
	robots/primotion/ledManager.cc,
	robots/primotion/pilotButtonCallback.hh,
	robots/primotion/pilotButtonCallback.cc,
	robots/primotion/pilotClient.hh, robots/primotion/pilotClient.cc,
	robots/primotion/watch-user-button.cc,
	robots/primotion/wheelManager.hh,
	robots/primotion/wheelManager.cc: Replace gorobot with
	garcia-pilot, a beefed up daemon for controlling the robots.
	Improvements include: making use of the user LED and button to
	give some feedback and let the wrangler run a test sequence,
	reboot, and shutdown the robot; Logging of the battery level, how
	often the robot has moved and for how long, and the distance
	traveled; telemetry is sent back to emulab clients; movements are
	now just pivot-move instead of pivot-move-pivot, since the second
	pivot ends up being extra work most of the time; the robot will
	move backwards to cut down on the amount of rotation; and just
	generic cleanups to the code.

	* robots/primotion/garcia.config: The configuration file currently
	used on the garcias.

	* www/GNUmakefile.in: Add garcia-telemetry subdir to the build.

	* www/dbdefs.php3.in: Add TBNodeClass and TBNodeStatus functions.

	* www/garcia-telemetry/Base64.java,
	www/garcia-telemetry/GNUmakefile.in,
	www/garcia-telemetry/GarciaTelemetry.java,
	www/garcia-telemetry/UpdateThread.java,
	www/garcia-telemetry/main.xml: A telemetry applet for the garcia,
	it displays readouts for the various sensors and other bits of data
	gathered by the garcia-pilot daemon.  Hopefully, it will make a
	handy debugging tool.

	* www/garcia-telemetry.jar, www/mtp.jar, www/oncrpc.jar,
	www/thinlet.jar: Java jars used by the robot telemetry applet.

	* www/servicepipe.php3: A slightly enhanced version of
	ledpipe.php3 that can be used for other services, like robot
	telemetry.

	* www/shownode.php3: Add "Show Telemetry" menu item to robot
	nodes.

	* www/telemetry.php3: Telemetry page for the garcia-telemetry
	applet.

* tbsetup/panic.in: New backend script to implement the panic button
  feature. When used, it will cut the severe the connection to the
  firewall node by using snmpit to disable the port. Sets the panic
  bit (and date) in the experiments table, and changes the state of
  the experiment from "active" to "paniced" to ensure that the
  experiment cannot be messed with (swapped out or modified). Sends
  email to tbops when the panic button is pressed.

  Used with -r option, reverses the above. State is set back to
  active, the panic bit is cleared, and the port is renabled with
  snmpit.

* tbsetup/tbswap.in: During swapout, a firewalled experiment that has
  been paniced will get a cleaning; The nodes are powered off, then
  the osids for all the nodes are reset (with os_select) so that they
  will boot the MFS, and then the nodes are powered on. Then the
  control network is turned back on, and then I wait for the nodes to
  reboot (this is simply cause we do not record in the DB that a node
  is turned off, and if I do not wait, the reload daemon will end
  hitting the power button again if they do not reboot in time. We can
  fix this later.

  I am not planning to apply this to general firewalled experiments
  yet as the power cycling is going to be hard on the nodes, so would
  rather that we at least have a 1/2 baked plan before we do that.

* www/showexp.php3: If experiment is firewalled, show the Panic
  Button, linked to the panic button web script. If the experiment has
  already had the panic button pressed, show a big warning message and
  explain that user must talk to tbops to swap the experiment out.
  Also fiddle with menu options so that the terminate link is gone,
  and the swap link is visible only in admin mode. In other words, only
  an admin person can swap an experiment once it is paniced. And of
  course, an admin person can the backend panic script above with the
  -r option, but thats not something to be done lightly.

* db/libdb.pm.in: Add "paniced" as an experiment state (EXPTSTATE_PANICED).
  Add utility functions: TBExptSetPanicBit(), TBExptGetPanicBit(), and
  TBExptClearPanicBit().

* tbsetup/swapexp.in: Minor state fiddling so that an experiment can
  be swapped while in paniced state, but only when in admin mode. Also
  clear the panic bit when experiment is swapped out.

* www/dbdefs.php3.in: Add "paniced" as an experiment state. Add a
  utility function TBExptFirewall() to see if experiment is firewalled.

* www/panicbutton.php3: New web script to invoke the backend panic
  script mentioned above, after the usual confirm song and dance.

* www/panicbutton.gif: New gif of a red panic button that I stole off
  the net. If anyone has sees/has a better one, feel free to replace
  this one.

* utils/node_statewait.in: Add -s option so that I can pass in the
  state I want to wait for (used from tbswap above to wait for nodes
  to reach ISUP after power on).

TBImageIDAccessCheck, otherwise they seem to return true all the
time...

currently available to only people with stud=1 status in the DB.

* www/tbauth.php3: Add a STUDLY() function to check that bit.

* www/linktest.php3: New page to run linktest on the fly. The level
  defaults to the current level in the experiments table, but you can
  override that via the form on the page.

* www/showexp.php3: Add link to aforementioned page. STUDLY() only.

* www/beginexp_form.php3: Add an option (selection) to set the linktest
  level for create/swapin. Defaults to 0 (no linktest). STUDLY() only.

* www/editexp.php3: Add an option to edit the default linktest level
  for an experiment. STUDLY() only.

* tbsetup/batchexp.in and tbsetup/swapexp.in: Add code to optionally run
  the linktest, sending email if it fails (exists with non-zero status).
  Failure does not affect the swapin.

Change ptopgen to look at the eventstate of a node; a node is not considered
free unless it is ISUP or PXEWAIT.

Add TBAvailablePCs() to libdb, removing the corresponding code from
assign_wrapper. This routine does the equiv of ptopgen, returning the
number of PCs that are available for use (looking at eventstate).

Change TBFreePCs in the web interface accordingly.

The above changes correspond to an upcoming change in stated.

error - it's too hard to destingish a string from 0 in php, and every
place we call this function, we've already made sure the group exists
anyway.

account, and direct user to Forgot Username/Password page.

Changed the Forgot page to allow user to *either* reset password, or
just find out their username if that is what they forgot.

zillions of DB fields that we have to set. My solution was to add a
meta table that describes what is a legal value for each table/slot
for which we take from user input. The table looks like this right
now, but is likely to adapt as we get more experience with this
approach (or it might get tossed if it turns out to be a pain in the
ass!).

	CREATE TABLE table_regex (
	  table_name varchar(64) NOT NULL default '',
	  column_name varchar(64) NOT NULL default '',
	  column_type enum('text','int','float') default NULL,
	  check_type enum('regex','function','redirect') default NULL,
	  check tinytext NOT NULL,
	  min int(11) NOT NULL default '0',
	  max int(11) NOT NULL default '0',
	  comment tinytext,
	  UNIQUE KEY table_name (table_name,column_name)
	) TYPE=MyISAM;

Entries in this table look like this:

	('virt_nodes','vname','text','regex','^[-\\w]+$',1,32,NULL);

Which says that the vname slot of the virt_nodes table (which we trust the
user to give us in some form) is a text field to be checked with the given
regex (perlre of course), and that the min/max length of the text field is
1 and 32 chars respectively.

Now, you wouldn't want to write the same regex over and over, and since we
use the same fields in many tables (like pid, eid, vname, etc) there is an
option to redirect to another entry (recursively). So, for "PID" I do this:

        ('eventlist','pid','text','redirect','projects:pid',0,0,NULL);

which redirects to:

	('projects','pid','text','regex','^[a-zA-Z][-\\w]+$',2,12,NULL);

And, for many fields you just want to describe generically what could go
into it. For that I have defined some default fields. For example, a user
description:

        ('experiment,'usr_name','text','redirect','default:tinytext',0,0,NULL);

which redirects to:

	('default','tinytext','text','regex','^[\\040-\\176]*$',0,256,NULL);

and this says that a tinytext (in our little corner of the database
universe) field can have printable characters (but not a newline), and
since its a tinytext field, its maxlen is 256 chars.

You also have integer fields, but these are little more irksome in the
details.

	('default','tinyint,'int,'regex','^[\\d]+$',-128,127,NULL);

and you would use this anyplace you do not care about the min/max values
being something specific in the tinyint range. The range for a float is of
course stated as an integer, and thats kinda bogus, but we do not have many
floats, and they generally do not take on specific values anyway.

A note about the min/max fields and redirecting. If the initial entry has
non-zero min/max fields, those are the min mac fields used. Otherwise they
come from the default. So for example, you can do this:

    ('experiments','mem_usage','int','redirect','default:tinyint',0,5,NULL);

So, you can redirect to the standard "tinyint" regular expression, but you
still get to define min/max for the specific field.

Isn't this is really neat and really obtuse too? Sure, you can say it.

Anyway, xmlconvert now sends all of its input through these checks (its
all wrapped up in library calls), and if a slot does not have an entry, it
throws an error so that we are forced to define entries for new slots as we
add them.

In the web page, I have changed all of the public pages (login, join
project, new project, and a couple of others) to also use these checks.
As with the perl code, its all wrapped up in a library. Lots more code
needs to be changed of course, but this is a start.

devel tree.

select the default user interface for a project. The choice is current
'emulab or 'plab', defaults to 'emulab'. New users that join emulab
get the default user interface from the first project they join.

Also generalize the plab_user bit as new "user_interface" slot of the
users table, which is an enum of interface tokens, currently either
'emulab' or 'plab', defaults to 'emulab'. The plab_user bit will be
removed later.

planetlab nodes.

of the CHECKEMAIL function as a result.

state machine (state). All of the stuff that was previously handled by
using batchstate is now embedded into the one state machine. Of
course, these mostly overlapped, so its not that much of a change,
except that we also redid the machine, adding more states (for
example, modify phases are now explicit. To get a picture of the
actual state machine, on boss:

		stategraph -o newstates EXPTSTATE
		gv newstates.ps

Things to note:

* The "batchstate" slot of the experiments table is now used solely to
  provide a lock for batch daemon. A secondary change will be to
  change the slot name to something more appropriate, but it can
  happen anytime after this new stuff is installed.

* I have left expt_locked for now, but another later change will be to remove
  expt_locked, and change it to active_busy or some such new state name in
  the state machine. I have removed most uses of expt_locked, except those
  that were necessary until there is a new state to replace it.

* These new changes are an implementation of the new state machine,
  but I have not done anything fancy. Most of the code is the same as
  it was before.

* I suspect that there are races with the batch daemon now, but they
  are going to be rare, and the end result is probably that a
  cancelation is delayed a little bit.

for key upload). Add more regexes and addslashes().

* Use superglobals for page/form arguments.

* Add regex functions for email and phone number.

* Remove stripslashes calls; not needed and actually incorrect for
  data returned from the DB.

* Add TBvalid_uid() function to regex uid's. To be used throughout the
  system. Eventually add routines for checking other things like pids
  and eids, etc.

* Regex the uid value we get from the cookie, and switch to $_COOKIE
  superglobal.

* Strict regex checking in DOLOGIN() of uid.

* Change login.php to use superglobals, and general tightening of
  parameter checking.

* install-rpm, install-tarfile, spewrpmtar.php3, spewrpmtar.in: Pumped
  up even more! The db file we store in /var/db now records both the
  timestamp (of the file, or if remote the install time) and the MD5
  of the file that was installed. Locally, we can get this info when
  accessing the file via NFS (copymode on or off). Remote, we use wget
  to get the file, and so pass the timestamp along in the URL request,
  and let spewrpmtar.in determine if the file has changed. If the
  timestamp it gets is >= to the timestamp of the file, an error code
  of 304 (Not Modifed) is returned. Otherwise the file is returned.

  If the timestamps are different (remote, server sends back an actual
  file), the MD5 of the file is compared against the value stored. If
  they are equal, update the timestamp in the db file to avoid
  repeated MD5s (or server downloads) in the future. If the MD5 is
  different, then reinstall the tarball or rpm, and update the db file
  with the new timestamp and MD5. Presto, we have auto update capability!

  Caveat: I pass along the old MD5 in the URL, but it is currently
  ignored. I do not know if doing the MD5 on the server is a good
  idea, but obviously it is easy to add later. At the moment it
  happens on the node, which means wasted bandwidth when the timestamp
  has changed, but the file has not (probably not something that will
  happen in typical usage).

  Caveat: The timestamp used on remote nodes is the time the tarfile
  is installed (GM time of course). We could arrange to return the
  timestamp of the local file back to the node, but that would mean
  complicating the protocol (or using an http header) and I was not in
  the mood for that. In typical usage, I do not think that people will
  be changing tarfiles and rpms so rapidly that this will make a
  difference, but if it does, we can change it.

* node_update.in, client side watchdog, and various web pages:
  Deflated node_update, removing all of the older ssh code. We now
  assume that all nodes will auto update on a periodic basis, via the
  watchdog that runs on all client nodes, including plab nodes.

  Changed the permission check to look for new UPDATE permission (used
  to be UPDATEACCOUNT). As before, it requires local_root or better.
  The reason for this is that node_update now implies more than just
  updating the accounts/mounts. The web pages have been changed to
  explain that in addition to mounts/accounts, rpms and tarfiles will
  also be updated. At the moment, this is still tied to a single
  variable (update_accounts) in the nodes table, but as Kirk requested
  at the meeting, it will probably be nice to split these out in the
  future.

  Added the ability to node_update a single node in an experiment (in
  addition to all nodes option on the showexp page). This has been
  added to the shownode webpage menu options.

  Changed locking code to use the newer wrapper states, and to move
  the experiment to RUNNING_LOCKED until the update completes. This is
  to prevent mayhem in the rest of the system (which could be dealt
  with, but is not worth the trouble; people have to wait until their
  initiated update is complete, before they can swap out the
  experiment).

  Added "short" mode to shownode routine, equiv to the recently added
  short mode for showexp. I use this on the confirmation page for
  updating a single node, giving the user a couple of pertinent (feel
  good) facts before they comfirm.

plus a lock field. The lock field was a simple "experiment locked, go away"
slot that is easy to use when you do not care about the actual state that
an experiment is in, just that it is in "transition" and should not be
messed with.

The other two state variables are "state" and "batchstate". The former
(state) is the original variable that Chris added, and was used by the tb*
scripts to make sure that the experiment was in the state each particular
script wanted them to be in. But over time (and with the addition of so
much wrapper goo around them), "state" has leaked out all over the place to
determine what operations on an experiment are allowed, and if/when it
should be displayed in various web pages. There are a set of transition
states in addition to the usual "active", "swapped", etc like "swapping"
that make testing state a pain in the butt.

I added the other state variable ("batchstate") when I did the batch
system, obviously! It was intended as a wrapper state to control access to
the batch queue, and to prevent batch experiments from being messed with
except when it was really okay (for example, its okay to terminate a
swapped out batch experiment, but not a swapped in batch experiment since
that would confuse the batch daemon). There are fewer of these states, plus
one additional state for "modifying" experiments.

So what I have done is change the system to use "batchstate" for all
experiments to control entry into the swap system, from the web interface,
from the command line, and from the batch daemon. The other state variable
still exists, and will be brutally pushed back under the surface until its
just a vague memory, used only by the original tb* scripts. This will
happen over time, and the "batchstate" variable will be renamed once I am
convinced that this was the right thing to do and that my changes actually
work as intended.

Only people who have bothered to read this far will know that I also added
the ability to cancel experiment swapin in progress. For that I am using
the "canceled" flag (ah, this one was named properly from the start!), and
I test that at various times in assign_wrapper and tbswap. A minor downside
right now is that a canceled swapin looks too much like a failed swapin,
and so tbops gets email about it. I'll fix that at some point (sometime
after the boss complains).

I also cleaned up various bits of code, replacing direct calls to exec
with calls to the recently improved SUEXEC interface. This removes
some cruft from each script that calls an external script.

Cleaned up modifyexp.ph3 quite a bit, reformatting and indenting.
Also fixed to not run the parser directly! This was very wrong; should
call nscheck instead. Changed to use "nobody" group instead of group
flux (made the same change in nscheck).

There is a script in the sql directory called newstates.pl. It needs
to be run to initialize the batchstate slot of the experiments table
for all existing experiments.

tmcd (which is bad, since tying up the tmcd threads blocks all nodes
in the testbed). The old functionality is left in tmcd for now.

On the server side, a new web page (www/spewrpmtar.php3) receives a
request for a file, along with the nodeid (pcXXX) making the request,
and the secret key that is generated for each new experiment and
transfered to the node via tmcd. If the key matches, the operation is
handed off to tbsetup/spewrpmtar.in which verifies that the file is in
the list of rpm/tar files for that node, and then spits it out to
stdout. The web page uses fpassthru() to send the file out to the
client. The client is using wget, and is required to use https (the
web page checks).

At present, the external script is run as the creator of the
experiment, and gid of the experiment. Perhaps this is not a good
idea. In any event, the file must be in the list of rpm/tarfiles,
either owned by the experiment creator or with a group of the
experiment, and the file must reside in either /proj or /groups.
I use the realpath() function to make sure there are no symlink tricks
pointing to outside those filesystems. I use the standard NFS read goo to
prevent transient mount problems that we all know and love.

nodetypeXpid_permissions table, since most users will be confused
to see free PCs that they cannot actually use.

This query is starting to become a bit complicated to be doing on
every page.

based page that looks like the original Begin Experiment page. Be sure
to look at the page in both admin mode and non-admin mode since I had
some trouble determining how swappable is treated these days.

Oh, added the ability to convert non-batch experiments into batch, and
back. The experiment must be unlocked and in the swapped state to go
in either direction.

Also added the cpu_usage and mem_usage slots for editing. I added a
comment about planetlab only, since otherwise we would just confuse
normal users who have no idea what they mean. I could conditionalize
them on having plab nodes, but thats difficult to figure out in the
web page when the experiment is swapped out, so lets not worry about
it.

are couple left in the newnodes code that Rob will need to help me
with.

Soon image when the image is not available (cause the renderer is not
finished yet).

The default thumbsize is now 160, so do not call out to the renderer
to generate the thumb on the showexp page; just take it from the DB.

showexp page that its a batch experiment, by the menu options. Same
deal in the swapexp output, plus some other minor cleanup. The only
bug I found while trying to figure out the batchmode problem reported
this morning by the FileMover people, is that the cancelflag is not
cleared after swaping a running batch experiment out, so even after
reinjecting it into the queue, it will not run. Still, that does seem
to be what the FileMover people reported.

can I say? This page is public, and linked from various places.

Added site variables ('sitevars').
These are stored in the sitevariables database table.
Each one has a name, a description (NOT OPTIONAL!), a
default value, and a current value.
If the current value is NULL, the default value is used.

Soon, a mechanism will be added to the install process to
ensure all needed site variables exist before installing;
more on that when it is committed.

 - Added 'editsitevars.php3' page, accessable to admins
   via the 'Edit Site Variables' menu option.

 - Added 'setsitevar' script,
   an interface for listing, viewing in detail, and setting
   site variables.

 - Web interface now uses 'web/nologins' and 'web/message'
   instead of one-off database tables.

NOTE that setting a variable to the default value and
setting a variable to a value which is string-identical
are NOT the same thing.
(This doesn't matter yet, but when we push default values out to
 remote sites as part of our install, it will.)

the number of hours correctly. (Was using idlehours mod 24.)