GitLab

EtherChannel and try another trunk port before giving up altogether.

in the basic style.

Jay has "comments"), but I do not want it hanging around in my source
tree. Here is my mail message:

* The "My Mailing Lists" is context sensitive (copied from Tim's
  changes to the My Bug Databases). It takes you to the *archives* for
  the current project (or subgroup) list. Or it takes you to your
  first joined project.

* The showproject and showgroup pages have direct links to the project
  and group specific archives. If you are in reddot mode, you also
  get a link to the admin page for the list. Note that project and
  group leaders are just plain members of these lists.

* The interface to create a new "user" list is:

	https://www.emulab.net/dev/stoller/newmmlist.php3

  We do not store the password, but just fire it over in the list
  creation process.

  Anyone can create their own mailing lists. They are not associated
  with projects, but just the person creating the list. That person
  is the list administrator and is given permission to access the
  configuration page.

  This page is not hooked in yet; not sure where.

* Once you have your own lists, you user profile page includes a link
  in the sub menu: Show Mailman Lists. From this page you can delete
  lists, zap to the admin page, or change the admin password (which is
  really just a subpage of the admin page).

* As usual, in reddot mode you can mess with anyone else's mailman lists,
  (via the magic of mailman cookies).

* Note on cross machine login. The mailman stuff has a really easy way
  to generate the right kind of cookie to give users access. You can
  generate a cookie to give user access, or to the admin interface for
  a list (a different cookie). Behind the scenes, I ssh over and get
  the cookie, and set it in the user's browser from boss. When the
  browser is redirected over to ops, that cookie goes along and gives
  the user the requested access. No passwords need be sent around,
  since we do the authentication ourselves.

read matches the prompt, i.e., don't wait to get a newline.  With the
new power controller on the rocketport muxes on a pc1500 tipserver,
even though we send two newlines, we just get back a single prompt
with no newline.  This would cause us to hang forever waiting for the
newline.

Note that it did not do this on the same RPCs with the same muxes on
our ops node (a pc3000).  This could be a bad sign for things to come...

Added new script "linesofcode2.pl" which is like ""linesofcode.sh"
but uses a ".loc-ignore" file instead of lots of egreps.  Also added
a ".loc-ignore" file in the root directory so that the results from
the two scripts are basically the same.  The only difference is that
the new script also ignores files starting with "." which I assume
is a desirable behavior.

(and subgroup) mailman lists.

rerun assign on an empty testbed if the initial assign pass failed.
If assign failed on an empty testbed than It will fail with the error
message:
  Experiment can not be run on an empty testbed.  Please fix the experiment.

and other privs.

fails.

"reload" since that part does not work right. I need to spend some
time rethinking the existing (original) code for doing plain monitor.

password for each project/group list, and another to the users
table to hold each users password.

These passwords are stored in cleartext. This is okay since the
mailman password is deemed to be throw away since the mailman
system is happy to mail them out to people in cleartext.

We initially set them to a random value, and will provide a web
interface on the Emulab side to change them. This is done in the
mailman setup script though.

option to mtp_dispatch.

avoidance to work correctly.

starting pilot seemed to cause problems.

checks on the log files that were retrieved.  Also update the event
scheduler to run the validation after a sync.

exists in the experiment log directory.

when assigning vnode (control net) IP addresses.  Once we hit 255, we
increment the low bit of the network address ala:

	on pc254: 172.16.254.N
	on pc255: 172.17.1.N

Note that the Utah case is different than the default in that we wrap at
200 rather than 254.  This is so that we "wrap" at the boundary of the
new cluster (which starts at pc201); i.e., pc201 has addresses 172.18.1.N.

ElabInElab experiment loads the current elabinelab.ns file from the
lib directory.

Otherwise:

	tb-elab-in-elab-topology withrouter

will load elabinelab-withrouter.ns from the lib directory.

setup-network.txt file.

project.

begin recording packets, instead, begin recording immediately and take
a snapshot if a TIME STARTED is received.  Need to do this since a
rebooted node will sit for forever waiting for the event.

Fix the race between loading a mote and rebooting its host stargate.

	* db/libdb.pm.in: Add TBNodeSubNodes function which returns the
	list of subnodes for a given node.

	* mote/tbuisp.in: Don't reboot the stargate anymore after loading
	the attached mote.  The problem with the radio not working after
	the upload should be fixed now.

	* tbsetup/libreboot.pm.in: Check if a node's subnodes are being
	reloaded.  If so, try to wait until they reach ISUP before
	actually doing the reboot.

	* tbsetup/os_setup.in: Do not skip the ISUP wait for subnodes that
	are imageable (like motes), otherwise their allocstates are not
	updated correctly.  Remove the robot-specific hack that	assumed
	tbuisp would do the reboot if the attached mote was being reloaded.