1. 25 May, 2007 1 commit
  2. 08 May, 2007 1 commit
  3. 23 Apr, 2007 1 commit
  4. 03 Jan, 2005 1 commit
  5. 24 Jun, 2004 1 commit
    • Mike Hibler's avatar
      Improve the client-side install. With these changes, it should now be · 976133e4
      Mike Hibler authored
      possible to:
      
      	gmake client
      	sudo gmake client-install
      
      on a FBSD4, FBSD5, RHL7.3, and RHL9.0 client node.
      
      There are still some dependencies that are not explicit and which would
      prevent a build/install from working on a "clean" OS.  Two that I know of are:
      you must install our version of the elvin libraries and you must install boost.
      976133e4
  6. 20 Apr, 2004 1 commit
    • Mike Hibler's avatar
      Improve the client-install. You can now do a "make client-install" from · 361ee691
      Mike Hibler authored
      the top level.  This will build all the necessary binaries and then install
      them.  This works on FBSD4 and RHL7.3.  It still doesn't work on FBSD5
      (newer compiler that no longer supports a style of use of _FUNCTION_ in the
      event lib) or RHL9 (event lib needs SSL lib which has a bad dependency
      on Kerberos).  Notes:
      
      - requires that elvin libraries be installed on nodes (they are) to build
        event agents, requires linuxthreads be installed on FBSD (it is now) to
        build imagezip (which is installed, but is not strictly necessary)
      
      - installed event-agents and other binaries are stripped
      
      - added a few missing files to the source tree for bsd (healthd.conf)
        and linux (healthd.conf, rc.local)
      
      - the only thing that doesn't get rebuilt in /usr/local/etc/emulab is
        healthd, I couldn't quickly find how it gets built
      
      - uses a scaled down version of libtb with no DB functions (since mysql
        isn't installed on nodes).  N.B. DO NOT DO A CLIENT INSTALL FROM YOUR
        REGULAR OBJ TREE OR ELSE YOU MAY WIND UP WITH A NEUTERED VERSION OF
        libtb.a!
      
      The build-as-well-as-install semantics are counter to the regular install
      targets, but this is what we gotta do for now.  Once the TB source builds
      under Linux and newer BSDs, we could undo this and just require that people
      do a regular "make" followed by "make client-install"  OTOH, there should
      be no reason to require installation of mysql and other server-side packages
      just to build clients (or make them sit through the compilation of assign),
      so maybe we will keep the client build special.
      361ee691
  7. 05 Nov, 2003 1 commit
    • Leigh Stoller's avatar
      Middle part of the event system changes. The main part of this change · 54bc15c4
      Leigh Stoller authored
      is to add HMACs to events to ensure they that events cannot be
      injected into an experiment by an unauthorized client.
      
      * The frontend now generates a secret key for each experiment and
        stores that into a file and in the DB.
      
      * Each of the event clients, as well as the event producers
        (scheduler, tevc) have a new -k option to specify the name of the
        file. Two new event library functions were added for clients to give
        the key:
      
          event_handle_t
          event_register_withkeyfile(char *name, int threaded, char *keyfile);
      
          event_handle_t
          event_register_withkeydata(char *name, int threaded,
      	   		       unsigned char *keydata, int keylen);
      
      * When the library is in possesion of a key, it will generate an HMAC
        and attach it to outgoing notifications. A client receiving a
        notification will compute an HMAC and compare it against the HMAC in
        the notification. If they do not compare, the notification is
        dropped with a warning message printed (the client callback never
        gets the notification). If the client has not provided a key, then
        the HMAC in the incoming notification is ignored.
      
      * The scheduler also takes a -k option, and will compute HMACs for all
        of the static events ahead of time. That keeps it off the critical
        path.
      
      * The tevc client also takes a -k option. However, tevc will always
        try to find the keyfile (default path) so that it can attach the
        HMAC to dynamic events before sending them to the scheduler (which
        will check to make sure it matches). The scheduler will not accept
        dynamic events without unless the HMAC is present and matches.
      
      * I have rebuilt the elvin librarys, removing all of the X goop and
        the SSL goop. Smaller binaries. So, I had to add -lcrypto to all of
        the client makefiles to that programs link.
      
      * The program-agent got a few more changes. The command string is no
        longer passed inside the event; it comes in when the program agent
        is started, via a config file generated from tmcd data. This gets
        rid of our mostly insecure remote execution facility.
      54bc15c4
  8. 18 Dec, 2002 1 commit
  9. 10 Jul, 2002 1 commit
  10. 22 Mar, 2002 1 commit
  11. 07 Mar, 2002 1 commit
    • Leigh Stoller's avatar
      Isolate the pain of building threaded (and statically linked) event · 4dad8ebe
      Leigh Stoller authored
      system programs. Build two versions of the event library, one for non
      threaded programs and another (libevent_r.a) for threaded versions.
      Remove all that -pthread goo from all of the makefiles, except for the
      scheduler (which is threaded); it gets linked as before, but with
      -levent_r instead. If you try and use the threaded API without the
      proper link, the library will print an error message and quit.
      4dad8ebe
  12. 05 Mar, 2002 1 commit
  13. 04 Mar, 2002 1 commit
  14. 26 Feb, 2002 2 commits
  15. 25 Feb, 2002 1 commit
  16. 24 Feb, 2002 1 commit
  17. 21 Feb, 2002 1 commit
    • Leigh Stoller's avatar
      Some whacking of the event system. I have implemented the addressing · 8305021f
      Leigh Stoller authored
      scheme that we discussed in email. Notifications and subscriptions now
      take an "address_tuple" argument (I know, crappy name) that is a
      structure that looks like this:
      
      	char		*site;		/* Which Emulab site. God only */
      	char		*expt;		/* Project and experiment IDs */
      	char		*group;		/* User defined group of nodes */
      	char		*host;		/* A specific host */
      	char		*objtype;	/* LINK, TRAFGEN, etc ... */
              char		*objname;	/* link0, cbr0, cbr1, etc ... */
              char		*eventtype;	/* START, STOP, UP, DOWN, etc ... */
      
      These can be a specific value, ADDRESSTUPLE_ANY if you are a
      subscriber, or ADDRESSTUPLE_ALL if you are a producer. The reason for
      the distinction is that you can optimize the match expression with the
      extra bit of information, and the above structure can make for a
      fairly lengthy match expression, which takes more time of course.
      You should use address_tuple_alloc() and address_tuple_free() rather
      than allocating them yourself. Note that host above is actually the
      ipaddr of control interface. This turns out to be more convenient
      since free nodes do not have virtual names.
      
      Also added a new tbgen directly. This directory includes 3 programs in
      the making:
      
      tbmevd: Is the Testbed Master Event Daemon, to be run on boss and will
      handle TBCONTROL events (reboot, reload, etc). It is just a shell of a
      program right now, that takes the events but does not do anything
      useful with them. Have not defined what the events are, and what DB
      state will be modified.
      
      tbmevc: Is the Testbed Master Event Client (akin to tmcc). It
      generates TBCONTROL events which the tbmevd will pick up and do
      something useful with. This program is intended to be wrapped by a
      perl script that will ask the tmcd for the name of the boss (running
      the event daemon).
      
      sample-client: This is a little client to demonstrate how to connect
      to the event system and use the address tuple to subscribe to events,
      and then how to get information out of notifications.
      
      Note that I have not created a proper build environment yet, so new
      programs should probably go in the event dir for now, and link using
      the same approach as in tbgen/GNUmakefile.in.
      8305021f
  18. 19 Feb, 2002 1 commit