1. 08 Apr, 2002 1 commit
    • Leigh B. Stoller's avatar
      Add generation of per-project email lists, as per Dave's request. The · 8cac9c47
      Leigh B. Stoller authored
      lists are stored on users:/etc/mail/lists. For example, you can send
      email to ron-users@users.emulab.net. An alias entry is added (and
      newaliases run) if there is no alias in /etc/mail/aliases (by the proxy
      of course). There are two new options to genelists (on boss):
      	"Use the -a option to generate lists for all projects.\n".
      	"Use the -n option to generate lists for a new user.\n";
      With no options, generate the all users and active users lists
      (renamed to emulab-users and emulab-active-users). With the -n option
      (used by mkacct) regen the lists for all the projects the user is a
      member of.
      It would be nice to archive the email, but that requires a publically
      readable directory and a u+S archive file; the mailer daemon runs as
      user daemon, and the project tree is 770, so it cannot write the
      archive file. At some point we will have to go to majordomo or spam
      filtering, when the first list is spamm'ed. Sigh.
  2. 01 Apr, 2002 1 commit
    • Leigh B. Stoller's avatar
      First cut at supporting RON (or more generally, remote nodes). · bd587829
      Leigh B. Stoller authored
      * tmcd/ron: A new directory of client code, based on the freebsd
        client code, but scaled back to the bare minimum. Does only account
        and group file maintenance. I redid the account stuff so that only
        emulab accounts are operated on. Does not require a stub file, but
        instead keeps a couple of local dbm files recording what groups and
        accounts were added by Emulab. There is a ton of paranoia checking
        to make sure that local accounts are not touched.
        The update script that runs on the client node detaches so that the
        ssh from boss returns immediately. update can also be run from the
        node periodically and at boottime. The script is installed setuid
        root, but checks to make sure that *only* root or "emulabman" has
        invoked it.
      * utils/sshremote: New file. For remote nodes, instead of using sshtb,
        use sshremote, which ssh's in as "emulabman", which needs to be a
        local non-root user, but with an authorized_keys file containing
        boss' public key.
      * web interface changes: Allow user to specify his own public key in
        addition to the emulab key.
        Add option in showexp page to update accounts on nodes in the
        experiment. I was originally intending to do this from approveuser,
        but this was easier and faster. I will add an option to do it on the
        approveuser page later.
      * libdb.pm: Add a TBIsNodeRemote() query to see if a node is in the
        local testbed or a pcRemote node. Currently, this test is hardwired
        to a check for class=pcRemote, but this will need to change to a
        node_types property at some point.
      * node_update: Reorg so that there is a maximum number of children
        created. Previously, a child was forked for each node, but that
        could chew up too many processes, especially for remote nodes which
        might hang up. For the same reason, we need to "lock" the experiment
        so that it cannot be terminated while a node_update is in progress.
        Might be to relax that, but this was easy for now. Also add
        distinction between local and remote, since for remote we use
        sshremote insted of sshtb. Various cleanup stuff
      * mkacct; When generating a new account, include user supplied pub key
        in the authorized keys file, in addition to the eumlab generated
        key. Both keys are stored in the DB in the users table. Anytime we
        update an account, get a fresh copy of the emulab pub key, in case
        user changes it.
  3. 12 Feb, 2002 2 commits
  4. 09 Jan, 2002 1 commit
  5. 03 Jan, 2002 1 commit
  6. 26 Dec, 2001 1 commit
    • Leigh B. Stoller's avatar
      A bunch o' account managment script schanges. I have reworked · 46068860
      Leigh B. Stoller authored
      mkprojdir, mkacct-cntrl, mkgroup, and group-update into a set of new
      scripts that are more specific to their intended operation, and strive
      to do less work.
      1. mkacct - Replaces mkacct-cntrl. This script no longer does any
         group stuff. All it does is create new accounts, or update the
         password and gecos fields of existing accounts. Usage is the same
         as it was: "mkacct <userid>", and is typically invoked from the web
         interface via the approveuser form.
      2. mkgroup - Replaces group-update. This script creates new groups,
         either for the main project when it is approved, or for subgroup
         creation. This script does not alter the group membership. Usage
         is typically from the web interface, but mkgroup can be invoked
         from the command line: "mkgroup [-b | -a] <pid> <gid>" where -b
         puts it in the background and sends email later, while -a just
         captures the log and emails. This "audit" feature is going to find
         its way into more scripts as soon as I figure out a neat and clean
         perl mechanism to make it easy.
      3. setgroups - Replaces group-update. This script modifies the group
         membership of either specific users, or all the users in a
         project. It is typically invoked from the web interface when a
         project leader edits the subgroup membership or when a user is
         first approved to a project or subgroup. Command line usage is:
      	setgroups [-b | -a] -p <pid> [user ...]
              setgroups [-b | -a] [user ...]\n
         The first form is mostly a means to speed things up. The web
         interfaces knows exactly what users have need to be changed, but a
         global project update is nice too.
      4. mkproj - Replaces mkprojdir. Actually, mkproj still has all that
         directory code, but it also handles creating the groups and the
         account for the project leader. Part of my policy to move as much
         random code out of the web interface and into the PERL backend
         where it belongs.