GitLab

to all of the API functions, and prefer that to any UUID argument.
There are a lot of little changes.

At this point, the CH and SA will no longer accept certificates that
do not have URNs in them. The CH will send email to the email address
listed in the certificate.

since it has to be aware of the CM version. Add a Version() call to
GeniAuthority with goes asks the CM what version it is exporting.
Based on that, we know how to do a resolve of a component. Refactored
the code that was used in GeniAggregate when creating tunnels, since
that is where we have to Resolve components. This also turns up in
cooked mode.

Continuine moving towards a urn-only world. If a GeniAuthority or a
GeniComponent does not have the URN set locally in the DB, go back to
the clearinghouse and get it. Error if it is not known, and go bang on
the remote site to update and rerun register_resources.

turn off CMs at the clearinghouse, as when they are in test mode
or not usable. Note that you have to set/clear this git in the
geni-ch database on boss, for ListComponents() to be affected.

1. You cannot unregister a slice at the SA before it has expired. This
   will be annoying at times, but the alphanumeric namespace for slice
   ames is probably big enough for us.

2. To renew a slice, the easiest approach is to call the Renew method
   at the SA, get a new credential for the slice, and then pass that
   to renew on the CMs where you have slivers.

The changes address the problem of slice expiration.  Before this
change, when registering a slice at the Slice Authority, there was no
way to give it an expiration time. The SA just assigns a default
(currently one hour). Then when asking for a ticket at a CM, you can
specify a "valid_until" field in the rspec, which becomes the sliver
expiration time at that CM. You can later (before it expires) "renew"
the sliver, extending the time. Both the sliver and the slice will
expire from the CM at that time.

Further complicating things is that credentials also have an
expiration time in them so that credentials are not valid forever. A
slice credential picks up the expiration time that the SA assigned to
the slice (mentioned in the first paragraph).

A problem is that this arrangement allows you to extend the expiration
of a sliver past the expiration of the slice that is recorded at the
SA. This makes it impossible to expire slice records at the SA since
if we did, and there were outstanding slivers, you could get into a
situation where you would have no ability to access those slivers. (an
admin person can always kill off the sliver).

Remember, the SA cannot know for sure if there are any slivers out
there, especially if they can exist past the expiration of the slice.

The solution:

* Provide a Renew call at the SA to update the slice expiration time.
  Also allow for an expiration time in the Register() call.

  The SA will need to abide by these three rules:
  1. Never issue slice credentials which expire later than the
     corresponding slice
  2. Never allow the slice expiration time to be moved earlier
  3. Never deregister slices before they expire [*].

* Change the CM to not set the expiration of a sliver past the
  expiration of the slice credential; the credential expiration is an
  upper bound on the valid_until field of the rspec. Instead, one must
  first extend the slice at the SA, get a new slice credential, and
  use that to extend the sliver at the CM.

* For consistency with the SA, the CM API will changed so that
  RenewSliver() becomes RenewSlice(), and it will require the
  slice credential.

record to CMs when they asked for the Slice Authority (by prefix).
This will all get flushed when URNs are fully pushed out.

communication with the clearinghouse, and modifications to the
certificate format (put the URN in subjectAltName and move any
URL to a private OID under subjectInfoAccess).

Moved this in from the Resolve() function in the CH
module.

Add a demonstration of getting lists from the ClearingHouse.

to the Geni Public License at http://www.geni.net/docs/GENIPubLic.pdf,
whose expansion at this time is:

-----
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and/or hardware specification (the "Work") to
deal in the Work without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Work, and to permit persons to whom the Work
is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Work.

THE WORK IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE WORK OR THE USE OR OTHER DEALINGS
IN THE WORK.

its really a hugely stripped down Emulab boss install, using a very
short version of install/boss-install to get a few things into place.

I refactored a few things in both the protogeni code and the Emulab
code, and whacked a bunch of makefiles and configure stuff. The result
is that we only need to install about 10-12 files from the Emulab
code, plus the protogeni code. Quite manageable, if you don't mind
that it requires FreeBSD 6.X ... Still, I think it satisfies the
requirement that we have a packaged clearinghouse that can be run
standalone from a running Emulab site.