- 26 Aug, 2017 1 commit
-
-
Mike Hibler authored
-
- 12 Jul, 2017 2 commits
-
-
Mike Hibler authored
-
Mike Hibler authored
-
- 17 Jan, 2017 1 commit
-
-
Mike Hibler authored
-
- 21 Mar, 2016 1 commit
-
-
Kirk Webb authored
* Move common and client-side stuff to the clientside tree * Update autconf configure scripts: This commit bumps the version of the top-level auto-generated script from 2.68 to 2.69.
-
- 07 Oct, 2015 1 commit
-
-
Mike Hibler authored
-
- 02 Oct, 2014 1 commit
-
-
Mike Hibler authored
A clientside top-level "gmake freenas-tarball" will build everything and construct an appropriate tarball. You must either build on FreeBSD 8.3 or FreeBSD 9.2, depending on the version of FreeNAS you are targetting. This cannot be done native on the FreeNAS box! In part because there is no compiler there, but even if there was, the install target would wreak havoc on a full root filesystem; it assumes it is working on a skeleton FS with just the Emulab stuff in it. Mostly this commit is grotesque Makefile hacking due to our tragic client-side tmcc OS-specific directory structure. Hey, don't blame me! It was, um...okay DO blame me...
-
- 30 Sep, 2014 1 commit
-
-
Mike Hibler authored
Use the "freenas-tarball" makefile target to create a tarball for installation on FreeNAS 8.3 or 9.2. The tarball must be made on the corresponding FreeBSD system (since FreeNAS has no installed compiler). To install the tarball on FreeNAS you will need to login as root and: cd / mount -o rw -u / mount /cfg tar xzf freenas-tarball.tar.gz unmount /cfg mount -o ro -u /
-
- 20 Feb, 2014 1 commit
-
-
Mike Hibler authored
Not sure this is really useful, but Kevin Tew's test framework uses it.
-
- 29 Aug, 2013 1 commit
-
-
Gary Wong authored
-
- 30 Nov, 2012 1 commit
-
-
Mike Hibler authored
This officially drops the pretense that fs nodes can operate with minimal Emulab software. If you have a seperate fs node, it had better be dedicated to Emulab! However, it still doesn't do everything. In particular, accounts are not installed. This has never been needed for serving NFS, but is needed for the samba stuff to work correctly. Also, you cannot do an fs node software install from boss yet as we do not mount fs filesystems on boss. You really cannot do a full ops install from boss either since we don't mount ops' /usr/local/etc/emulab directory.
-
- 30 Oct, 2012 1 commit
-
-
Mike Hibler authored
-
- 11 Oct, 2012 1 commit
-
-
Leigh B Stoller authored
installing the clientside on an image.
-
- 24 Sep, 2012 1 commit
-
-
Eric Eide authored
This commit is intended to makes the license status of Emulab and ProtoGENI source files more clear. It replaces license symbols like "EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited blocks that contain actual license statements. This change was driven by the fact that today, most people acquire and track Emulab and ProtoGENI sources via git. Before the Emulab source code was kept in git, the Flux Research Group at the University of Utah would roll distributions by making tar files. As part of that process, the Flux Group would replace the license symbols in the source files with actual license statements. When the Flux Group moved to git, people outside of the group started to see the source files with the "unexpanded" symbols. This meant that people acquired source files without actual license statements in them. All the relevant files had Utah *copyright* statements in them, but without the expanded *license* statements, the licensing status of the source files was unclear. This commit is intended to clear up that confusion. Most Utah-copyrighted files in the Emulab source tree are distributed under the terms of the Affero GNU General Public License, version 3 (AGPLv3). Most Utah-copyrighted files related to ProtoGENI are distributed under the terms of the GENI Public License, which is a BSD-like open-source license. Some Utah-copyrighted files in the Emulab source tree are distributed under the terms of the GNU Lesser General Public License, version 2.1 (LGPL).
-
- 13 Sep, 2012 1 commit
-
-
Mike Hibler authored
Mostly added a taget for the newnode MFS.
-
- 13 Apr, 2012 1 commit
-
-
Mike Hibler authored
-
- 27 Jul, 2011 1 commit
-
-
Leigh B Stoller authored
clientside requres it to be there. As noted in previous revision, the full emulab build always includes the clientside subdir, but a clientside build will not necessarily include the rest of Emulab.
-
- 26 Jul, 2011 1 commit
-
-
Leigh B Stoller authored
-
- 21 Jul, 2011 1 commit
-
-
Leigh B Stoller authored
directory.
-
- 19 Jul, 2011 8 commits
-
-
Leigh B Stoller authored
avoid confusion and bad things happening when someome does the wrong kind of install. Its happened.
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
Leigh B Stoller authored
-
- 21 Dec, 2004 1 commit
-
-
Timothy Stack authored
Some cleanup of the robot vision system: * Makeconf.in: Add INSTALL_INCDIR for includes, EVENTSYS for whether or not the event system is available, HAVE_MEZZANINE for whether or not we'll be building mezzanine, and GTK_CONFIG which refers to the gtk-config binary, if there is one. * config.h.in: Add HAVE_LINUX_VIDEODEV_H and HAVE_MEZZANINE defines. * configure, configure.in: Check for the robot vision system dependencies. Add mezzanine template files. * robots/GNUmakefile.in: Add some conditionals for directories that depend on the event-system and mezzanine. * robots/mezzanine/GNUmakefile.in, robots/mezzanine/libfg/GNUmakefile.in, robots/mezzanine/libmezz/GNUmakefile.in, robots/mezzanine/mezzanine/GNUmakefile.in, robots/mezzanine/mezzcal/GNUmakefile.in, robots/mezzanine/rtk2/GNUmakefile.in: Fold mezzanine into the testbed's build system. * robots/vmcd/GNUmakefile.in: When building the vmc-client, use the mezzanine that we build locally instead of an installed version. * robots/vmcd/test_vmc-client.sh.in, robots/vmcd/test_vmcd.sh.in, robots/vmcd/test_vmcd2.sh, robots/vmcd/test_vmcd3.sh, robots/vmcd/test_vmcd4.sh: Bring the test cases up-to-date with respect to the actual code. * robots/vmcd/vmc-client.c: A bunch of cleanups and bug fixes: add comments, set TCP_NODELAY on the client sockets (doh), etc...
-
- 13 Dec, 2004 1 commit
-
-
Timothy Stack authored
Rmcd and garcia stuff: * configure, configure.in: Add robot related template files. * robots/GNUmakefile.in: Add primotion directory. * robots/emc/emcd.c: Debugging printfs, check the status for update-position messages from rmc, and add a basic handler for emulab clients. * robots/emc/test_emcd.sh.in: Update for changes in mtp. * robots/mtp/mtp.h, robots/mtp/mtp.c: Changes for the garcia. * robots/mtp/mtp_send.c: Fixes so that it will compile under linux. * robots/primotion/GNUmakefile.in: Makefile for building a fake gorobot in the testbed tree. * robots/primotion/Makefile: tweaks * robots/primotion/gorobot.cc: First draft with sort-of working networking code. * robots/primotion/test_gorobot.sh.in: Test case for the fake gorobot. * robots/primotion/dgrobot/GNUmakefile.in: Makefile for building a fake grobot class in the testbed tree. * robots/primotion/dgrobot/grobot.h: Add #if !defined(GROBOT_SIM) conditionals. * robots/primotion/dgrobot/grobot_sim.cc: Empty impl of grobot class used for testing. * robots/rmcd/GNUmakefile.in: Targets for building rmcd and running its test case. * robots/rmcd/rmcd.c: First draft with sort-of working networking code. * robots/rmcd/test_emcd.config: emcd configuration for the rmcd test case. * robots/rmcd/test_rmcd.sh.in: Test case for rmcd.
-
- 10 Dec, 2004 1 commit
-
-
Timothy Stack authored
Start on vmc: * configure, configure.in: Add vmcd related template files. * robots/GNUmakefile.in: Switch order of vmcd/rmcd. * robots/emc/GNUmakefile.in: cleanup * robots/mtp/GNUmakefile.in: Add mtp_dump tool. * robots/mtp/mtp.c: Change mtp_encode_packet to use a passed in buffer pointer or allocate a buffer if its NULL, probably gonna be a big source of errors... * robots/mtp/mtp_dump.c: Another command-line tool that connects to a server and dumps mtp packets that are received. Useful for seeing output from the vmc-client. * robots/vmcd/GNUmakefile.in: Add vmc-client and test case. * robots/vmcd/test_vmc-client.sh.in: Test case for the vmc-client. * robots/vmcd/vmc-client.c: First cut of the vmc-client, it reads mezzanine output and sends it to any connected clients.
-
- 08 Dec, 2004 1 commit
-
-
Timothy Stack authored
Elvinize emc and some bug fixes... * configure, configure.in: Add "robots/emc/test_emcd.sh" script to the list of template files. * robots/GNUmakefile.in: Add a target for install-subdir. * robots/emc/GNUmakefile.in: Compile emcd and install it on ops. Add test_emcd.sh test case. * robots/emc/emcd.h, robots/emc/emcd.c: Elvinize, add support for events, and some minor cleanup. * robots/emc/robot_list.c: Compilation fixes. * robots/emc/test_emcd.config: Robot config for the test case. * robots/emc/test_emcd.sh.in: Test case for emcd, just starts it up and uses mtp_send to send a few messages to it. * robots/mtp/GNUmakefile.in: Install mtp_send and mtp_recv on ops. * robots/mtp/mtp.h, robots/mtp/mtp.c: Marshall floats correctly, doh! Move the packet printing code from mtp_recv to the lib. * robots/mtp/mtp_recv.c: Move the packet printing code to the lib. * robots/mtp/mtp_send.c: Add a "-w" option to wait for a response from the peer and then dump the packet to stdout. Allow multiple packets to be sent from a single invocation, the arguments for each packet must be separated by a double dash (--), see test_emcd.sh.in for an example. * robots/mtp/mtp_test.c: Gah, test with actual floating point values dummy.
-
- 06 Dec, 2004 1 commit
-
-
Timothy Stack authored
Made a pass over the mtp directory: * GNUmakerules: Add a "check" target that runs the executables listed in the "TESTS" variable. * robots/GNUmakefile.in: Add "mtp" to the list of SUBDIRS. * robots/mtp/GNUmakefile.in: Testbed-friendly makefile. * robots/mtp/mtp.h, robots/mtp.c: Tweaks and bug fixes. * robots/mtp/mtp_test.c: Test case for mtp stuff.
-
- 01 Dec, 2004 1 commit
-
-
Leigh B. Stoller authored
-
- 26 Apr, 2004 1 commit
-
-
Mike Hibler authored
1. "make clean" will just remove stuff built in the process of a regular build 2. "make distclean" will also clean out configure generated files. This is how it was always supposed to be, there was just some bitrot.
-
- 13 May, 2003 1 commit
-
-
Robert Ricci authored
Generates dummy packets on all interfaces, so that the switch will learn their MAC addresses.
-
- 07 Jul, 2002 1 commit
-
-
Leigh B. Stoller authored
-
- 23 May, 2002 1 commit
-
-
Robert Ricci authored
First, gives us a handy way to build all the tools, if there is ever more than one. Second, it's a workaround for a really annoying problem with configure. Since there was nothing in the tools/ directory itself, it wasn't getting created, so configure could not make tools/pcapper (since the parent directory didn't exist.)
-