GitLab

from tbacct, which happens in the context of the project/group root,
not as the user.

* When generating an encrypted SSL certificate, derive an SSH public
  key from the private key and store in the pubkeys table for the
  user. Note that SSH version 2 RSA keys are actually just openssl RSA
  keys, and that ssh-keygen can extract an ssh compatible public key
  from it.

* Change getsslcert.php3 to return the ssh private and public key when
  give the "ssh" boolean argument. This is mostly for the benefit of
  Flack; we probably need a better UI for the user to get this stuff. 

* Remove the requirement that users must upload an SSH key to use
  protogeni, since we now create one for them when they create their
  encrypted SSL certificate.

* Some cleanup; instead of looking at the comment field to determine
  what pubkeys are Emulab created (and should not be deleted), use new
  internal and nodelete flags.

on the join/start project pages. At the moment this is conditional
under the PROTOGENI flag, since users on non-protogeni sites rarely
need an encrypted SSL certificate. The initial passphrase has to be
store someplace since we cannot built the certificate until the user
is approved, so put it into the users table, and delete when the first
certificate is built (at approval).

tools stuff when set.

users that have their "nocollabtools" bit set (elabman, geniuser,
etc).

except the creator now start out as frozen, to save lots of time
when setting up the elabinelab. To thaw:

myboss> wap tbacct -u thaw <user>

The -u option says to ignore the current status, and set the status to
what it should be. This should eventually be the default operation so
that this script is independent of the web interface.

that not all accounts are created, saving time. If a frozen user
is then thawed, the account is created.

related to protogeni config.

creation.  Only runs on the CMU emulab.

fully integrated Trac. I put a new installation in /usr/local/www/data/trac
and I added all the hooks for adding users and doing the cross machine
login. Only STUDLY() users will actually see the new option in the collab
dropdown menu.

I have not done anything to make the trac installation look like Emulab.

 GNUmakefile.in configure configure.in  - Add the testbed/backend directory.
 www/moduserinfo.php3 - The reworked PHP page.
 www/user_defs.php - Add a ModUserInfo method bridging to the script via XML,
     and remove the ChangeProfile method that is being replaced.
 backend/{moduserinfo,GNUmakefile}.in - Add the Perl script.
 db/User.pm.in - Add a ModUserInfo worker class method for script arg checking.
     Also SetUserInterface, SetWindowsPassword, and AccessCheck methods,
     and a copy of the escapeshellarg fn.
 sql/database-fill.sql - Add some to the table_regex 'users' checking patterns.

Support stuff:
 account/tbacct.in - Update the UpdateWindowsPassword() function.
 db/libdb.pm.in - Add TBDB_USER_INTERFACE_EMULAB and TBDB_USER_INTERFACE_PLAB().
 tbsetup/libtestbed.pm.in - Add TB*EMAIL, TBMAIL_* vars (OPS, WWW, AUDIT).

unencrypted, not to mention useless.

helping remote sites setup and update.

* Added a V2 (DSA) key to the install directory that us inserted into
  the pubkeys table for the elabman. This key is encrypted and stored in
  /root/.ssh/elabman_dsa on Utah's boss.

* elabman now starts out as webonly=0,status='active' with a real
  shell on both boss and ops.

* freeze/thaw user now treat elabman as special, giving elabman a real
  account on boss and ops when thawed.

* Addeda "notes" entry to the user profile that indicates the account
  can be frozen once the remote emulab is up and running.

interface to the backend. There are new scripts that can be called
from the command line:

	newuser xmlfile
	newproj xmlfile

They both run from small xmlfiles that are generated by the web
interface from the form data. I also moved user verification to the
backend so that we do not have duplicated email functions, but that
was a small change.

Upon error, the xmlfile is saved and sent to tbops so that we can
rerun the command by hand, rather then force user to fill out form
again. I also do a better job of putting the form back up intact when
there are internal errors.

If the user provides an initial public key, that is put into the xml
file as well and addpubkey is called from newuser instead of the web
interface. A more general change to addpukey is that it is now
*always* called as "nobody". This script was a morass of confusion
cause of having to call it as nobody before the user actually
exists. In fact, another of my ongoing projects is to reduce the
number of scripts called as a particular user, but thats a story for
another day. Anyway, the script is always called as nobody, but we
pass along the implied user in the environment so that it can do
permission checks.

most of the rest of the tables in the system (still a few exceptions).
Bound to be some bugs ...

for email changes. Currently, the hash is passed in on the command
line from the web interface, and there is no method for invoking it on
the command line and providing a text password, but that is an easy
change now that the bulk of the code is in the backend instead of the
web interface.

Note that this change took longer cause we allow inactive,frozen, and
wikionly users to change their password, but since they do not have
accounts (yet) the operation is invoked as user "nobody" and tbacct
about to me made aware of that possibility.

Also add equivalent auditing email message that goes to the user when
password is changed.

Also more cleanup and conversion to objects.

address is changed by an admin, but in the process I decided to
implement the entire operation in the backend, since that is what we
want to do anyway for all operations. Email is sent from the backend
script as well.

Two-day boondoggle to support "/scratch", an optional large, shared filesystem
for users.  To do this, I needed to find all the instances where /proj is used
and behave accordingly.  The boondoggle part was the decision to gather up all
the hardwired instances of shared directory names ("/proj", "/users", etc.)
so that they are set in a common place (via unexposed configure variables).
This is a boondoggle because:

1. I didn't change the client-side scripts.  They need a different mechanism
   (e.g., tmcd) to get the info, configure is the wrong way.

2. Even if I had done #1 it is likely--no, certain--that something would
   fail if you tried to rename "/proj" to be "/mike".  These names are just
   too ingrained.

3. We may not even use "/scratch" as it turns out.

Note, I also didn't fix any of the .html documentation.  Anyway, it is done.
To maintain my illusion in the future you should:

1. Have perl scripts include "use libtestbed" and use the defined PROJROOT(),
   et.al. functions where possible.  If not possible, make sure they run
   through configure and use @PROJROOT_DIR@, etc.

2. Use the configure method for python, C, php and other languages.

3. There are perl (TBValidUserDir) and php (VALIDUSERPATH) functions which
   you should call to determine if an NS, template parameter, tarball or
   other file are in "an acceptable location."  Use these functions where
   possible.  They know about the optional "scratch" filesystem.  Note that
   the perl function is over-engineered to handles cases that don't occur
   in nature.

present the per-experiment stuff is not hooked in, but will be for
templates later. Anyway, each user gets a mysql account on ops, with
password set to the same as their mailman password (which is also
their jabber password, etc). Each project gets a DB named by the
project, and each group gets a DB named by pid,gid. Users are placed
on the access lists for the DBs as you would expect.

There is a little bit of complexity to make sure that we can create
DBs on ops outside the Emulab path and grant access to them, without
Emulab getting confused or mucking things up.

I'll get a news item done ...

so that collab tool accounts get created.

addresses in the list, use real email addresses. Why? Well, cause I'm
a dope.  Oh, the real reason is that people cannot post to the lists
if we use their @emulab.net addresses cause we close the lists (to
avoid spammers). I did it this way originally cause it was easier;
there is a lot more bookkeeping to do if using real addresses, and I
never consider problem of not being able to post.

is thawed.

Ready for local people to play with.

The current implementation is that we munge the mysql DB on ops directly,
underneath jabberd. We add/del users from the authreg table, and set up
buddy lists in the roster-items and roster-groups tables. modgroups will
invoke the modjabberbuddies whenever a user is added or removed from a
group, although currently I am building buddy lists for just the top level
projects.

The "My IM" link in the collaboration menu will tell the user their
jabber ID on the Emulab chat server (jabber.emulab.net) and also give
them their plain text password to plug into their chat client.

I also installed a java applet (Jeti) that is a simple chat client that
I found off the jabberware page. Like all applets, it exhibits a degree
of flakiness, but I really do not expect too many people to use it.

the time, and does not get a wiki account.

The reason for these changes is that we are making elabman a real
daemon user so that Tim can run the repositioning daemon as a real
user that can access the XMLRPC server.

I fixed a couple of minor problems, but mostly this worked fine. Note that
I have tested this with the installed perl, *NOT* perl 5.8. I am just
making sure this stuff gets committed before too much more bitrot sets in.

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).

Wiki support is turned on in the defs file with a WIKISUPPORT=1 directive.

every new user during a elabinelab setup. Save it all for the end.

the big power down when I changed sshtb to not invoke a subshell
wrapper, but to exec ssh directly. Built into tbacct was an extra pair
of \\ escapes to protect the outer double quotes from that extra
subshell.  When I removed that subshell, the extra escapes wreaked
havoc.

Needless to say, I really want to change how accounts are built on ops
to use tmcd like a regular experimental node. We can almost do that
now, except for the little detail that sending over 800 users would be
a lot of traffic for single updates. I've been meaning to extend the
protocol to allow for single updates, but have not had time yet!