1. 14 Feb, 2003 3 commits
  2. 13 Feb, 2003 14 commits
  3. 12 Feb, 2003 2 commits
  4. 11 Feb, 2003 5 commits
    • Mac Newbold's avatar
      Fix IPalias to match db. · 61559311
      Mac Newbold authored
      61559311
    • Leigh B. Stoller's avatar
      Checkpoint my DB changes so I can do some testing on boss. · 77e45dff
      Leigh B. Stoller authored
      * Add vnode0,vnode1 slots to the delays table. This will allow us to
        match ipfw pipes to nodes after swapin, hopefully allowing us to
        control the delays for lans in addition to duplex links.
      
      * Add IPaliases to interfaces table. Used in assign_wrapper when
        constructing "emulated" links, which will share a link via the use
        of aliases on the interface. This is a comma separated list of IP
        addresses (no, I refuse to make this a separate table!).
      
      * Add virtnode_capacity slot to node_types, defaults to zero. This is
        used in ptopgen for determining how many virtnodes fit on a real
        node. I have not thought this through completely, but it allows me
        to make progress on other fronts.
      
      * Add linkdelays delays, which sorta resembles the delays table, only
        this table stores oneway delays links, to be set up on the endpoints
        of a link or lan. Also, instead of being based on ipfw bridge rules,
        it is based on IP address/mask rules. At some point this table may
        merge witk the delays table, but will take time to work out the
        details and I do not want to mess up existing experiments by
        changing the delays table! Anyway, a duplex link gets one of these
        for each endpoint (a xmit ipfw rule). To mimic our lan setup, lan
        links get two, an xmit *and* a recv rule. My hope is that link
        delays will look just like normal delays (a packet leaving a node
        for a lan will get the outgoing delay, and a packet arriving gets
        the incoming delay).
      77e45dff
    • Leigh B. Stoller's avatar
      Move addpubkey from the utils to account directory. Note that I copied · 2a534d88
      Leigh B. Stoller authored
      the RCS control file in the repository so the history is left intact.
      
      Two new modes, which used to be in the old mkacct. There is an init
      mode, which is used on new users to create the initial pub key. There
      is also a write mode, which is used regenerate the authkeys files for
      people after they add/delete keys via the web interface. Used to be
      that addpubkey wold add the key to the DB, but mkacct would deal with
      creating the authkeys files. All this functionality is now localized
      in this one script.
      2a534d88
    • Leigh B. Stoller's avatar
      This mirrors the addpubkey stuff, although not really. Eventually the · 292d16c8
      Leigh B. Stoller authored
      parsing will move from php to this script, like addpubkey (ssh), but
      for now all it does is invoke the script to rebuild sfs_users on ops.
      292d16c8
    • Leigh B. Stoller's avatar
      Minor fix. · 150de3c3
      Leigh B. Stoller authored
      150de3c3
  5. 10 Feb, 2003 3 commits
  6. 09 Feb, 2003 1 commit
    • Leigh B. Stoller's avatar
      Checkpoint (still neads testing and tweaking) vastly rewritten mkacct · b9ef7da1
      Leigh B. Stoller authored
      script, which is now called tbacct, and lives in the account directory
      instead of tbsetup (all account scripts are moving into this
      directory). The command line is different:
      
      	Usage: tbacct <add|del|mod|freeze|thaw|sfskey> <name>
      
      However, it is not really intended to be called from the command line,
      but if it is, it always does the right thing based on the DB. All of
      the ssh commands are localized here as well (mkproj and others will
      invoke this script instead of doing pw commands themselves on ops).
      
      My experience with this indicates a couple of things.
      
      * We should probably not invoke these backend scripts (which are
        setuid) as the user driving them from the web. This complicates
        things, especially in light of having to deal with users with no
        accounts (say, a new user, unapproved, who wants to change their
        password). Not sure what the right model is, but since the script
        always does the right thing, it really makes no difference who
        invokes it.
      
      * The actual pw commands should be driven from a script on the other
        side. This would make it easy to retarget to linux or whatever. I
        thought about doing that, but the shell quoting is a pain in the
        butt, and its not like I'm supposed to be doing this stuff.
      b9ef7da1
  7. 08 Feb, 2003 4 commits
  8. 07 Feb, 2003 5 commits
  9. 06 Feb, 2003 3 commits