Custom Query (98 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (76 - 78 of 98)

Ticket Resolution Summary Owner Reporter
#26 fixed incorrect MAC addresses are reported for dataplane interfaces on OpenVZ containers somebody chaos@bbn.com
Description

I am comparing three sources of information about MAC addresses assigned to dataplane interfaces on experimental nodes:

These three data sources agree given a physical node. However, given an OpenVZ container, the second data source is incorrect, and the third is missing.

I've only tried to verify this once, using the sliver pgeni-gpolab-bbn-com/ecgtest, which contains the mapping:

Physical Node Mapping:
ID              Type         OS              Physical
--------------- ------------ --------------- ------------
phys1           dl360        FEDORA15-STD    pc3
virt1           pcvm         OPENVZ-STD      pcvm5-1 (pc5)

For this experiment, i see:

  • For the physical node interface, everything is correct:
    MAC addrs reported for phys1:0 == 10.10.1.1
      E8:39:35:B1:4E:8A: from /sbin/ifconfig eth1 run on phys1 (authoritative)
      e83935b14e8a:      from sliverstatus as experimenter (correct)
      e8:39:35:b1:4e:8a: from: https://boss.utah.geniracks.net/showexp.php3?experiment=363#details (correct)
    
  • For the virtual node interface, sliverstatus reports an incorrect MAC, and showexp.php3 reports no MAC at all:
    MAC addrs reported for virt1:0 == 10.10.1.2
      82:01:0A:0A:01:02: from /sbin/ifconfig mv1.1 run on virt1 (authoritative)
      00000a0a0102:      from sliverstatus as experimenter (incorrect: first four digits are wrong)
      -                : from https://boss.utah.geniracks.net/showexp.php3?experiment=363#details (not reported)
    
#25 fixed how can site admins find the Emulab source version installed on an image somebody chaos@bbn.com
Description

In testing IG-MON-1 step 6, i wanted to identify the source of the following files from the FEDORA15-OPENVZ-STD image, which are part of Emulab:

/usr/local/etc/emulab/emulab-syncd
/usr/local/libexec/pubsubd

As a site administrator at a rack that contains an image like:

/usr/testbed/images/FEDORA15-OPENVZ-STD.ndz

how can i determine what version of Emulab was installed on this image?

#24 fixed how can site admins find the Emulab, FreeBSD base, and package source code used to install their system? somebody chaos@bbn.com
Description

There is a rack requirement that site admins be able to figure out where the software installed on their rack came from. In looking at boss.utah.geniracks.net (performing IG-MON-1 step 1), i was able to track down most things, but have the following three caveats in terms of tracking system binaries back to source code:

  1. Since Emulab system binaries are installed by a make install type process, the easiest way to verify where they came from (that i can think of) is to md5 the binary and compare it to a binary in an .../obj tree whose corresponding .../src tree is known. On boss right now, that tree seems to be /users/stoller/testbed/{src,obj}. So that works well, but i had to make a guess about where the tree was likely to be. Are you planning a standard location for the {src,obj} from which each rack's Emulab software will be installed, or will it vary?
  2. If the OS base install had been upgraded, i could do the same thing for verifying FreeBSD base system software by looking in /usr/{src,obj}. However, right now, boss has a FreeBSD base install, so there is no base software in /usr/obj. Does FreeBSD provide a standard solution for this, or do they assume that anyone who cares what version they're running has recompiled their base and thus has something in /usr/obj? Any thoughts?
  3. Some software on the system comes from FreeBSD packages, which i believe are created by Utah. Is the source/patches/etc used to create those packages available somewhere?
Note: See TracQuery for help on using queries.