GitLab

see this new page. That allows me to inflict pain on testbed
developers while we work out any kinks. These new pages implement an
XML interface to experiment creation.

Some new files:

beginexp_html.php3: A wrapper for the actual beginexp form. This page
includes the form, and then invokes the XMLRPC backend page.

beginexp_form.html: The original form code, split out from beginexp
and turned into a module that can be included into another file.  It
is slightly reorganized to make it easier to include as a module.  The
idea is that the plab_ez form will be recast in this model, reducing
some redundant complexity.

beginexp_xml.php3: The XML backend. The idea is that the html page
packages up the form arguments as an XMLRPC message, and invokes this
page with the XML goo encoded in the URL. It also passes along the
uid/cookie so that the authentication happens properly (https of
course). The page decodes the URL into PHP datatypes, and does much of
the same argument checking that beginexp used to do. Errors are stored
up in the same manner, but instead of spitting back html, it now spits
back a "structure", encoded in XML so that the _html page can put up a
new form. Basically, all output is sent back via an XML encoded
structure and displayed in a form that the invoking script deems
appropriate.

This gives us a pure XMLRPC interface, which we wrap with a form interface
so that it looks just like it did before.

The next step is to provide an alternate front end, but that will require
some certificate stuff that I have not worked out yet.

Oh, one more item. The syntax check stuff has been altered a bit.
Instead of invoking the beginexp page, which meant a zillion special
tests, I now invoke nscheck.php3 directly from the button. Took a few
extra lines of Javascript to do this, so watch out for problems there
too.

our source and DB that need to be made on boss and ops. Things like
changes to ports or system configuration files should go into this
file.

development.

swapexp took to mean the experiment was swapped. I hate 8 bits of
status!

us correlate better with log entries on plab nodes.

value under some circumstances, which would result in not actually
timing out children that were taking too long.

There is a race there with pump and its setting of the domain
(via setting the hostname)

If set to zero, we never consider data stale, we use it anyway.
Nodes which don't report any data are still considered unusable.

Also, consider nodes that don't report disk usage as 100% free so that
we will consider them.

group - using the link in the group list doesn't seem to be intuitive
for people without subgroups.

some browsers.

a bit of whitespace so that the menu is easier to read, and shrink
the font down a bit.

Move all admin options to one place in the menu.

All users now the link to the planetlab_ez page.

Comment out the survey for now - we can resurrect it if we ever have
new questions to ask.

top down to the profile section of the page.

message telling them how to ask for permission.

user has only one project.

versions of the module don't support the old-ass version of perl
that FreeBSD still uses, so they had to fork the port.

allows real PCs to run any OS instead of being constrained to FreeBSD. A
detailed discussion on this topic can be found in the testbed-dev mailing
list under the thread "links between vnodes and real PCs"

wrong.

that an interface of an allocated node belongs to. Value is NULL when
the pnode is not allocated to an experiment.

I didn't know was to be done until Leigh pointed me to it.

Fix up revision ordering that got messed up by two revisions by Shashi
but with no corrsponding entries in database-mirgrate (204 and 198).

though.

since otherwise the warning goes into the XML output and confuses
the converter.

invovling testbed ops. Split into two parts:

* password.php3 gives the user a form to specify their email address
  and their phone number. We look for a match in the DB, with the
  phone number stripped of all non-numeric characters and the email
  addresses lowercased. If we find a matching user in the database,
  generate a unique key and store that into the DB along with a
  timestamp that allows the key to be used for a short time period
  (currently 30 minutes). The key is split into two parts, with half
  stored in the users browser (secure mode), and the other half sent
  to the user in an email message that contains a URL that allows the
  user to reset their password.

* chpasswd.php3 does the rest of the operation. It takes half the key
  from the URL, and sucks the other half from the user's browser,
  combining the two halves and matching it against the key that is
  stored in the DB. If the key matches and the timeout has not
  expired, the user is given a form to specify a new password. From
  this point on its just a standard change password operation.

Both pages are audited with email sent to the user, tbops and the
audit list.

arguments).