1. 19 Aug, 2002 2 commits
  2. 18 Aug, 2002 1 commit
  3. 15 Aug, 2002 1 commit
  4. 14 Aug, 2002 1 commit
  5. 13 Aug, 2002 2 commits
  6. 29 Jul, 2002 1 commit
  7. 26 Jul, 2002 1 commit
    • Leigh B. Stoller's avatar
      Hack in temporary permission stuff for remote nodes. Accounts are now · 5b297f80
      Leigh B. Stoller authored
      driven by new field in the project table called pcremote_ok, which is
      the set of remote node types that a project is allowed to have
      accounts on. When a node of that type checks in, match its type
      against the project table, and return accounts for everyone in all of
      the projects with that type listed in pcremote_ok.
      Kill the NOSHAREDEXPTS ifdefs in doaccounts since that stuff is dead
      for now.
  8. 16 Jul, 2002 1 commit
  9. 12 Jul, 2002 1 commit
    • Leigh B. Stoller's avatar
      Fix for the problem Eric reported for this topology: · d04e2b59
      Leigh B. Stoller authored
      	uav <---> distrib <---> display
               ^           ^             ^
               +-----------+-------------+---> namer
      where tmcd was returning multiple aliases since there were multiple links
      between nodes. Thats been a bug for long time, but its very rare to have
      two links between the same two nodes, and so I never bothered to deal with
      it. I have "fixed" it, but the fix is very unsatisfying since the choice it
      makes is not consistent. For example, on distrib the ideal choice is to
      create aliases for the lan links, but instead I get a mix; one alias is for
      the duplex link to uav, another to the lan link to display. To make it
      select a consistent set, it will take even more hackery in tmcd, and I am
      not in the mood for it right now, given how rarely this happens. At least
      the host file is now "correct."
  10. 07 Jul, 2002 1 commit
  11. 05 Jul, 2002 1 commit
    • Robert Ricci's avatar
      Bug fix. exports_setup specifically excludes home directories of · f9530c20
      Robert Ricci authored
      users that aren't approved into the project (actually, the group.)
      But, tmcdd was looking at whether or not the user was active. Thus,
      in the unlikely case that you have a user who is active (probably
      from being in another project,) but has not yet been approved into
      this group, tmcd decided that their home directory should be
      mounted, but exports_setup hadn't exported it.
  12. 21 Jun, 2002 1 commit
  13. 19 Jun, 2002 1 commit
    • Leigh B. Stoller's avatar
      Make isalive a real command (usable from tcp as well as UDP). · efaa3cda
      Leigh B. Stoller authored
      Return the update_accounts flag so that the client knows to
      update accounts. This flag is set in node_update for remote nodes.
      Once the client picks up accounts, decrement the update_accounts flag.
      This functions a simple barrier (up/down counter so that clients
      do not miss).
  14. 13 Jun, 2002 1 commit
  15. 12 Jun, 2002 1 commit
    • Leigh B. Stoller's avatar
      A minor ("30" minute) hack to support widearea keepalive. If a remote · 1bfee4eb
      Leigh B. Stoller authored
      node connects with UDP, update the nodes table status with 'up' and the
      current time. This is the only thing that can happen when a remote
      node connects with UDP (since there is no ssl). The idea is that a
      daemon on the remote nodes will wake up periodically and send in a UDP
      packet that says its alive. Since the idea is to be low overhead, I'm
      using a UDP packet for now, which means I can run it fairly often on
      all the clients, without it being too much of a drain. By its nature,
      if the remote node can start up tmcc and get a udp packet out, its
      probably in good shape. Maybe we will find out this does not work, but
      if so I will have lost only "30 minutes". See related changes in
      Also, add the code that kicks out remote nodes that connect with tcp
      but no ssl (it was commented out while I originally updated the ron
      nodes with the new tmcc stuff).
  16. 06 Jun, 2002 1 commit
  17. 30 May, 2002 1 commit
  18. 28 May, 2002 1 commit
  19. 23 May, 2002 1 commit
  20. 14 May, 2002 1 commit
  21. 07 May, 2002 2 commits
  22. 01 May, 2002 1 commit
  23. 30 Apr, 2002 2 commits
  24. 29 Apr, 2002 1 commit
  25. 24 Apr, 2002 1 commit
    • 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.
  26. 16 Apr, 2002 1 commit
  27. 15 Apr, 2002 1 commit
    • 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
      		NEXTHOP= 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, 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.
  28. 11 Apr, 2002 1 commit
  29. 10 Apr, 2002 2 commits
    • 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
      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.
  30. 09 Apr, 2002 1 commit
  31. 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
      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
      Oh, also redid all the syslog stuff throughout tmcd.
  32. 03 Apr, 2002 2 commits
  33. 02 Apr, 2002 1 commit
  34. 29 Mar, 2002 1 commit