1. 13 May, 2008 1 commit
  2. 24 Mar, 2008 1 commit
  3. 30 Oct, 2007 1 commit
    • Russ Fish's avatar
      Avoid a problem in newproject.php3. When the DB is locked for daily backup, · 2f373d5b
      Russ Fish authored
      NewNewUser()/newuser would block and then unblock and get done; meanwhile the PHP
      thread went away so we never returned to call NewNewProject/mkproj.  Move the call
      on the newuser script from PHP into the back-end Perl newproj script for atomicity.
      
          www/newproject.php3 - When the project leader is a new user, pass two xml
              files to the newproj backend script, one describing the project and the
              second one (an optional) file describing the newuser.
      
          www/user_defs.php - Factor the xml-making part of NewNewUser into NewNewUserXML.
      
          www/project_defs.php - Remove the required $leader arg of NewNewProject.
              newproj may call newuser, which may generate the leader uid.
      
          backend/newproj.in - Call newuser with an optional 'newuser_xml' XML file.
      
          sql/database-fill.sql - Add 'projects','newuser_xml'.
      2f373d5b
  4. 07 Sep, 2007 1 commit
  5. 05 Sep, 2007 1 commit
  6. 23 Aug, 2007 1 commit
  7. 05 Mar, 2007 1 commit
  8. 01 Mar, 2007 1 commit
  9. 23 Feb, 2007 1 commit
  10. 12 Feb, 2007 1 commit
    • Leigh Stoller's avatar
      * Replace the argument processing code in all pages. Currently we rely on · 48acc8e3
      Leigh Stoller authored
        register_globals=1 to turn POST/GET/COOKIES arguments in local variables.
        This is known to be a terrible security risk, and we keep saying we are
        going to fix it, and now I am. In order to accomplish this on a
        transitional basis (since I don't want the entire web interface to stop
        working while I debug it), and because the code just needs the cleanup, I
        am doing it like this: Each page will sport new declarations at the top:
      
      	RequiredPageArguments("experiment", PAGEARG_EXPERIMENT,
                                    "template",   PAGEARG_TEMPLATE,
                                    "instance",   PAGEARG_INSTANCE,
                                    "metadata",   PAGEARG_METADATA,
                                    "osinfo",     PAGEARG_OSINFO,
                                    "image",      PAGEARG_IMAGE,
                                    "project",    PAGEARG_PROJECT,
                                    "group",      PAGEARG_GROUP,
                                    "user",       PAGEARG_USER,
      			      "node",       PAGEARG_NODE,
      			      "yesno",      PAGEARG_BOOLEAN,
      			      "message",    PAGEARG_STRING,
      			      "age",        PAGEARG_INTEGER,
                                    "cost",       PAGEARG_NUMERIC,
                                    "formfields", PAGEARG_ARRAY,
                                    "unknown",    PAGEARG_ANYTHING);
      
      	OptionalPageArguments("canceled", PAGEARG_BOOLEAN);
      
        The first token in each pair is the name of the global variable to
        set, and the second token is the type. So, for "experiment" we look at
        the URL for a pid/eid or exptidx, etc, sanity check them (safe for a
        DB query), and then try to find that experiment in the DB. If it maps
        to an experiment, set global variable $experiment to the object. Since
        its a required argument, produce an error if not supplied. Similar
        treatment for optional arguments, with the obvious difference.
      
        The goal is to have ALL argument processing in one place, consistent,
        and correct. I've found numerous places where we leak unchecked
        arguments into queries. It also cuts out a lot of duplicated code.
      
      * To make the above easier to deal with, I've been replacing lots of
        hardcoded URLS in the code of the form:
      
      	foo.php3?pid=$pid&eid=$eid ...
      
        with
      
              CreateURL("foo", $experiment)
      
        which creates and returns the neccessary url string, by looking at
        the type of its arguments (experiment, template, instance, etc.)
      
        Eventually plan to replace them all so that URL handling throughout
        the code is all defined in one place (all the new URL code is in
        url_defs.php).
      
      * I have cranked up error reporting to tell me anytime a variable is
        used before it is initialized, plus a bunch of other stuff that PHP
        deems improper. Think of it like -Wall ... and boy we get a lot of
        warnings.  A very large percentage of the diffs are to fix all these
        warnings.
      
        The warnings are currently going to /usr/testbed/log/php-errors.log,
        and I'll be adding a script to capture them each night and mail them
        to tbops. This file also gets errors (this will be a change for
        developers; rather then seeing errors and warnings dumped in the
        middle of web pages, they will go to this file instead).
      
      * Major refactoring of the code. More objects (nodes, images, osids).
        Moving tons of queries into the objects in the hopes of someday
        getting to a point where we can split the web interface onto a
        different server.  Lots of general cleanup.
      48acc8e3
  11. 22 Jan, 2007 1 commit
  12. 16 Jan, 2007 1 commit
    • Leigh Stoller's avatar
      Move the bulk (or guts) of newuser and newproject from the web · 16aaa101
      Leigh Stoller authored
      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.
      16aaa101
  13. 20 Dec, 2006 1 commit
  14. 02 Dec, 2006 1 commit
  15. 27 Nov, 2006 1 commit
    • Leigh Stoller's avatar
      Call this commit "Snow in Corvallis" ... · 4998b2d7
      Leigh Stoller authored
      The major functional change in this revision is converting from user
      selected UIDs to system selected UIDs. This is controlled by the
      variable $USERSELECTUIDS in defs/defs.php3.in which is now set to
      zero, so system selected UIDs is the default.
      
      The algo for creating the uid is to take the email address, strip the
      @whatever from it, squeeze out dots and dashes and underlines, and
      make sure any +foo tokens are removed. Then make sure it is unique by
      taking the first 5 characters and then adding a 3 digit number,
      derived by checking the DB to see what exists.
      
      Since we will want to (more often) change the UID selected, there is a
      new admin only menu option on the Show User page. It calls the backend
      script to do the work (sbin/changeuid).
      
      The login page now defaults to storing and showing the email address
      for login, rather then the UID. It will still accept either one though
      (has for a long time).
      
      Along the way I also reorg'ed a number of pages to use the new user,
      group, and project classes and moved some common functionality into
      the class defs.
      
      Also changed the way addpubkey is called, to avoid some confusion.
      4998b2d7
  16. 03 Nov, 2006 1 commit
    • Leigh Stoller's avatar
      Big set of changes intended to solve a couple of problems with long · ff9061d4
      Leigh Stoller authored
      term archiving of firstclass objects like users, projects, and of
      course templates.
      
      * Projects, Users, and Groups are now uniquely identified inside the
        DB by a index value that will not be reused. If necessary, this
        could easily be a globally unique identifier, but without federation
        there is no reason to do that yet.
      
      * Currently, pid, gid, and uid still need to be locally unique until
        all of the changes are in place (which is going to take a fairly
        long time since the entire system operates in terms of those, except
        for the few places that I had to change to get the ball rolling).
      
      * We currently archive deleted users to the deleted_users table (their
        user_stats are kept forever since they are indexed by the new index
        column). Eventually do the same with projects (not sure about
        groups) but since we rarely if ever delete a project, there is no
        rush on this one.
      
      * At the same time, I have started a large reorg of the code, to move
        all of the user, group, project code into modules, both in php and
        perl, turning them into first class "objects" (as far as that goes
        in php and perl). Eventually, the number of query statements
        scattered around the code will be manageable, or so I hope.
      
      * Another related part of this reorg is to make it easier to move the
        new user/project/group code in the perl backend so that it can be
        made available via the xmlrpc interface (without duplication of the
        code).
      ff9061d4
  17. 17 Jul, 2006 1 commit
  18. 21 Dec, 2005 1 commit
  19. 19 Dec, 2005 1 commit
    • Leigh Stoller's avatar
      Add support for moving deleted users to a deleted users table. This · b4231fbf
      Leigh Stoller authored
      would be no big deal, except that we want to retain user_stats for
      deleted users, and rather then a deleted_user_stats table, I want to
      retain stats for deleted users in the user_stats table, since that
      is a more natural place for them.
      
      The main problem is that we use the login (uid) as the cross table
      reference slot all over the DB, which is fundamentally incorrect, if
      we want to be able reuse uids and still know what historical data
      refers to.
      
      So, I have taken a few baby steps towards weaning us off the uid, and
      towards permanently unique key for users, using the unix_uid integer
      for now, but probably something slightly different later.
      
      The user_stats is now indexed on this new key (called uid_idx in the
      users_stats table) instead of the plain uid.
      
      The unix_uid slot in the users table is no longer an auto_increment
      field, but instead uses the emulab_indicies table for the next
      available index.
      b4231fbf
  20. 28 Nov, 2005 1 commit
  21. 18 Nov, 2005 1 commit
  22. 01 Nov, 2005 1 commit
  23. 16 Aug, 2005 1 commit
  24. 15 Aug, 2005 1 commit
    • Leigh Stoller's avatar
      The bulk of the mailman support. Still not turned on by default (cause · a64593f3
      Leigh Stoller authored
      Jay has "comments"), but I do not want it hanging around in my source
      tree. Here is my mail message:
      
      * The "My Mailing Lists" is context sensitive (copied from Tim's
        changes to the My Bug Databases). It takes you to the *archives* for
        the current project (or subgroup) list. Or it takes you to your
        first joined project.
      
      * The showproject and showgroup pages have direct links to the project
        and group specific archives. If you are in reddot mode, you also
        get a link to the admin page for the list. Note that project and
        group leaders are just plain members of these lists.
      
      * The interface to create a new "user" list is:
      
      	https://www.emulab.net/dev/stoller/newmmlist.php3
      
        We do not store the password, but just fire it over in the list
        creation process.
      
        Anyone can create their own mailing lists. They are not associated
        with projects, but just the person creating the list. That person
        is the list administrator and is given permission to access the
        configuration page.
      
        This page is not hooked in yet; not sure where.
      
      * Once you have your own lists, you user profile page includes a link
        in the sub menu: Show Mailman Lists. From this page you can delete
        lists, zap to the admin page, or change the admin password (which is
        really just a subpage of the admin page).
      
      * As usual, in reddot mode you can mess with anyone else's mailman lists,
        (via the magic of mailman cookies).
      
      * Note on cross machine login. The mailman stuff has a really easy way
        to generate the right kind of cookie to give users access. You can
        generate a cookie to give user access, or to the admin interface for
        a list (a different cookie). Behind the scenes, I ssh over and get
        the cookie, and set it in the user's browser from boss. When the
        browser is redirected over to ops, that cookie goes along and gives
        the user the requested access. No passwords need be sent around,
        since we do the authentication ourselves.
      a64593f3
  25. 13 May, 2005 1 commit
    • Leigh Stoller's avatar
      Automate initial user/project setup from setup-db.txt. Rather then · dd1b57bc
      Leigh Stoller authored
      have the user go through a set of hard to explain steps, just push
      them through it using the web interface.
      
      * New sitevars to control a little state machine used by the web
        interface.
      
      * When first setting up a testbed, the sitevar value will force the
        web interface to present the user with a single menu option "Create
        New Project" and the "Home" link will take the user to that page.
        The user is instructed to login is as elabman.
      
      * The user fills in the form as directed in setup-ops.txt. Even though
        he is logged in as elabman, the newproject form has been altered to
        operate as if no one is logged in. I also default a bunch more of
        the fields in this case.
      
      * The user submits the form. Rather then pend the new project, just
        jump straight into approveproject. That grinds along as usual, and
        when it is done, the elabman account is frozen and the user logged
        out. The user gets a link inviting him to log back in as the user
        just created.
      
      * Side effects of this new process:
      
      	* The user is made an admin user (admin=1) automatically.
      	* The user is added to the emulab-ops project as group_root.
      	* The user verification process is skipped.
      	* The user is added to the unixgroups wheel and tbadmin.
      
      * I reworked this entire section of setup-db.txt ...
      
      * The user still needs to give himself a real shell and password on
        boss, but I left that for the user to do explicitly. I also drop in
        a pointer to the shellonboss.txt. I might automate this part too at
        some point. Not sure yet.
      dd1b57bc
  26. 25 Mar, 2005 1 commit
    • Leigh Stoller's avatar
      Okay, I think I am finally done with WikiWhacking (or WhackingTheWiki?) · 90dcbbe2
      Leigh Stoller authored
      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).
      90dcbbe2
  27. 11 Mar, 2005 1 commit
  28. 20 Jan, 2004 1 commit
    • Robert Ricci's avatar
      Check for an account on boss with the submitted username - this will · e48dc6ba
      Robert Ricci authored
      prevent people from asking for 'root', 'toor', etc. as usernames, and
      will hopefully help with new installations, which may have created
      accounts by hand. Note that this checks boss only, not ops.
      
      Also fixed a bug in newproject.php3 that was incorrectly letting
      through duplicate usernames.
      e48dc6ba
  29. 22 Dec, 2003 2 commits
  30. 19 Dec, 2003 1 commit
  31. 18 Dec, 2003 2 commits
    • Leigh Stoller's avatar
      Added check to make sure that uid does not already exist. This is · 7e50b223
      Leigh Stoller authored
      usually handled via uid cookie we get back from the browser, but if
      the user Clicks stop or maybe has cookies off, we don't that info.
      7e50b223
    • Leigh Stoller's avatar
      First try at solving the problem of validating user input for the · 8dbead16
      Leigh Stoller authored
      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.
      8dbead16
  32. 10 Dec, 2003 1 commit
  33. 01 Dec, 2003 1 commit
  34. 14 Nov, 2003 1 commit
  35. 11 Nov, 2003 1 commit
  36. 12 Sep, 2003 1 commit
  37. 09 Sep, 2003 1 commit
  38. 20 May, 2003 1 commit
    • Chad Barb's avatar
      · 4df405d6
      Chad Barb authored
      Users can, via, moduserinfo, set a preferred shell.
      One of {tcsh, bash, csh, sh}.
      When users are created, they are given tcsh.
      All users which already exist have been given tcsh.
      4df405d6