1. 08 May, 2002 3 commits
    • Leigh B. Stoller's avatar
      f3b2d956
    • Leigh B. Stoller's avatar
      63d2612e
    • Leigh B. Stoller's avatar
      Support for vnodes, plus some other changes: · 386c2778
      Leigh B. Stoller authored
      1) Merge in the accounts code that I did for ron. Instead of resetting
         the password file on each reboot, look at the node status to
         determine if the password/group file should be reset. If the
         node is free, reset it. Otherwise, we track changes to the password
         and group file now, so that users can change it and not have their
         changes wiped out at each reboot. I had to do this for the ron
         nodes so that the testbed software would not alter or delete
         already existing accounts; I keep a couple of little dbm files
         listing all the accounts/groups added. The only downside right now
         is if a node is reallocated before it is wiped clean; I plan to add
         an os_teardown phase to experiment termination asap.
      
      2) Add tunnels support. New DB table (tunnels) provides information
         for running vtund to link up to remote nodes. Creates a vtund.conf
         file on the fly, and fires them off. The complication is that you
         cannot do the ifconfigs or the routes until the tunnels are
         connected, so that stuff has to be configured within the vtund.conf
         file on a per tunnel basis. vtund.conf has some sections for
         running commands when tunnels are brought up or down.
      
      3) Damage the routing configuration code that Mike did. To support
         tunnels, as noted above, rc,route is no longer a simple list of
         commands, but a program that adds/dels routes based on the netmask,
         with a special "enable" section for the other stuff. This allows me
         to call it from vtund.conf for up/down on each tunnel'ed
         interfaces, as needed. Quite gross, but no way around it.
      
      4) For remote nodes, add a vnodesetup script, invoked from boss when
         experiments are setup/torndown. This gets the tunnel/route/trafgen
         configuration and runs them. It then goes into the background
         waiting for a death signal, at which time it brings them down and
         cleans out the vnode state.
      386c2778
  2. 07 May, 2002 2 commits
  3. 06 May, 2002 1 commit
  4. 02 May, 2002 2 commits
  5. 01 May, 2002 1 commit
  6. 30 Apr, 2002 2 commits
  7. 29 Apr, 2002 1 commit
  8. 24 Apr, 2002 2 commits
    • Leigh B. Stoller's avatar
    • Leigh B. Stoller's avatar
      Some virtual node support. In order to distinguish what virtual node · c2d82df7
      Leigh B. Stoller authored
      (on the physical node the tmcd request is coming from) look for a
      VNODE= tag in the request (similar in operation to VERSION=). If there
      is a vnode tag, then check for that mapping (in the nodes table). The
      vnode must map to the physical node making the request (in iptonodeid()).
      If so, replace the nodeid with the vnodeid for the remainder of the
      session. Currently no permission checking, so a vnode could ask for
      another vnode's account data (on the same physical node of course). At
      some point we need to either generate per vnode certs (perhaps on the
      fly) or just cons of a secret key and pass it over. Not going to worry
      about it for now, since the only people who will be allowed to
      allocate virtual nodes are trusted anyway.
      c2d82df7
  9. 21 Apr, 2002 1 commit
  10. 16 Apr, 2002 2 commits
  11. 15 Apr, 2002 2 commits
    • Mike Hibler's avatar
      set the ready bit for traffic nodes · ead321b5
      Mike Hibler authored
      ead321b5
    • Leigh B. Stoller's avatar
      Add static routing support: · d881770b
      Leigh B. Stoller authored
      	# Turn on manual routing.
      	$ns rtproto Manual
      
      	# Set manual routes
      	$nodeA add-route $nodeC $nodeB
      	$nodeC add-route $nodeA $nodeB
      
      results in this information being returned from the tmcd routing
      command:
      
      	ROUTERTYPE=manual
      	ROUTE DEST=192.168.2.3 DESTTYPE=host DESTMASK=255.255.255.0 \
      		NEXTHOP=192.168.3.2 COST=0
      
      The reason for DESTTYPE and DESTMASK is so that we can also support
      routing to links and lans, since doing it on a per host basis if not
      only hugely tedious, but plain impossible if the destination node has
      multiple links; the add-route syntax takes a node, but we need the IP
      of the relevant link in order to run the route add commands on the
      nodes. So, I've "extended" the syntax of add-route so that you can
      give it a Link or a Lan as the dest:
      
      	$nodeA add-route $link0 $nodeB
      	$nodeA add-route [$ns link $nodeB $nodeC] $nodeB
      
      In this case, the DESTTYPE=net, and the netmask is no longer ignored;
      it is used in the route add command. Currently, the mask is hardwired
      in the DB to 255.255.255.0, but by providing it in the tmcd command,
      we change it later if needed.
      
      I did not implement add-route-to-adj-node since that is not really
      useful in our context, and we definitely do not want the user to
      change the default routes on his nodes. But, its easy to add if we
      need to.
      
      The client side stuff is not done yet.
      d881770b
  12. 11 Apr, 2002 3 commits
  13. 10 Apr, 2002 3 commits
    • Leigh B. Stoller's avatar
      log (more informative) error when authentication fails for mysterious · d5aa3129
      Leigh B. Stoller authored
      reasons, as happens when Dave's autostatus daemon connects and closes
      right away.
      d5aa3129
    • Leigh B. Stoller's avatar
    • Leigh B. Stoller's avatar
      A fair amount of cleanup, both of the ssl stuff and of tmcd in general. · 40d072cf
      Leigh B. Stoller authored
      Deal with ssl/nossl clients; at Chad's suggestion add a small handshake
      tag to ssl enabled tmcc/tmcd which tells tmcd that it needs to enter
      full SSL mode. This allows old tmcc to connect to an ssl enabled tmcd,
      and still work okay.
      
      I've also ironed out the verification stuff. At the client, we make sure
      that the CommonName field of the peer cert maps to the same address that
      we connected to (bossnode).
      
      At the server, we check the OU field of the cert (we create the client
      certs with the OU field set to the node type; a convention I made up!).
      It must match the type of the node, as we get it from the nodes table.
      Also check the CommonName to make sure it matches our hostname. This is
      by no means bulletproof, but perfection is costly, and we don't have the
      money!
      
      Also cleaned up the REDIRECT testmode stuff. Instead of ifdef'ed under
      TESTMODE, leave it compiled in all the time, but only allow it from the
      local node (where tmcd is running). Mere users will not be able to
      access it, but testbed people can use it since they have accounts on the
      boss node.
      40d072cf
  14. 09 Apr, 2002 2 commits
  15. 04 Apr, 2002 1 commit
    • Leigh B. Stoller's avatar
      First round of ssl'ification of tmcd/tmcc. This needs to be looked at · ffe40d2e
      Leigh B. Stoller authored
      by smarter brains by me (I have asked Dave to look it over). Anyway ...
      
      I added a top level ssl directory which has a bunch of goo for
      creating certificates and keys.  I currently create a Certificate
      Authority, a server certificate, and a client certificate. The private
      keys for all three are unencrypted, so no password is required. All
      key/cert combos can be installed on boss. The client side needs the
      key/cert pair (in one file), and the CA cert (no key!). There are
      install targets to do this. NOTE, you do not want to create/install
      these without being careful, since you could instantly invalidate all
      the clients!
      
      I have added the necessary SSL routines to tmcd/tmcc. See the ssl.c
      and ssl.h file. I have set it up so that with all you need to do is
      uncomment three lines in the makefile, and accept,connect,read,write,
      and close are redirected to SSL'ified versions in ssl.c. The current
      security model is that the client and server both "demand" certificate
      verification from the other side (as opposed to just server side
      verification). tmcd reads in server.pem, while tmcc reads in
      client.pem. Both read in the emulab.pem (CA cert with no private
      key).
      
      Initial testing indicates I have done this at least partially
      correctly. Whoever invented this stuff has a really twisted mind
      though. There are some questions at the top of ssl.c that need to be
      answered.
      
      Oh, also redid all the syslog stuff throughout tmcd.
      ffe40d2e
  16. 03 Apr, 2002 4 commits
  17. 02 Apr, 2002 1 commit
  18. 01 Apr, 2002 4 commits
    • Robert Ricci's avatar
      Transition to tmcd and event-based node state reporting. · 44311142
      Robert Ricci authored
      Changed scripts that used the 'eventstatus' column to use the more
      descriptively-named 'eventstate' column.
      
      The FreeBSD and Linux starup scripts report a 'REBOOTED' state to tmcd
      when they start, and 'ISUP' when the starup script is done.
      
      node_reboot and power now send TBNODESTATE/REBOOTING events.
      44311142
    • Leigh B. Stoller's avatar
      Minor fixes and cleanups. · 9253e03b
      Leigh B. Stoller authored
      9253e03b
    • Leigh B. Stoller's avatar
    • 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.
      bd587829
  19. 29 Mar, 2002 3 commits