how can site admins find the Emulab source version installed on an image

[chaos@bbn.com]

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?

[chaos@bbn.com]

Note that, unlike in ticket:24, i am not necessarily hoping to verify those files against the compiled objects for MD5 modifications. The weaker restriction is partly because i don't think it's realistic (these images have likely been customized from a central image at a different rack location to which the site admin won't have access), and partly because i think it is less necessary (if a site admin is worried that a file in an image has been tampered with, it is easy enough for them to setup a new node running the same image for comparison purposes).

[chaos@bbn.com]

Sorry i've been so slow to get back to this. Leigh said via e-mail:

Date: Thu, 17 May 2012 13:04:36 -0700
...

Try running each of the programs with the -V option to get the version
info.

Trying that on pc3 (running as a shared OpenVZ node), i get:

vhost2,[~],05:03(1)$ /usr/local/etc/emulab/emulab-syncd -V
Built 30-Apr-2012 by stoller@n1:/users/stoller/testbed/obj-fc15/os/syncd

vhost2,[~],05:03(0)$ /usr/local/libexec/pubsubd -V
Built 30-Apr-2012 by stoller@n1:/users/stoller/pubsub (ELVIN_COMPAT)

Trying it on pc1 (running a custom Ubuntu image which Luisa updated from UBUNTU11-64-STD (i believe)):

root@hostx:~# /usr/local/etc/emulab/emulab-syncd -V
Built 15-Aug-2011 by root@node0:/root/emulab-devel-obj/clientside/os/syncd

root@hostx:~# /usr/local/libexec/pubsubd -V
Built 15-Aug-2011 by root@node0:/root/pubsub

So, that may be enough information that one can kinda/sorta guess at a code tag, but it's not a code tag... given that code tags are intended to be used as the definitive identifier for what version of the code is running on boss and ops and even what versions of system packages are running there (as i believe Rob said in a call a few weeks ago), i think it would make sense for the image install process to actually place the code tag somewhere on the image, so a site admin who wanted to find out what version of emulab software was running in an image could track that down directly.

Addressing a likely counterargument in advance: if an image is built by Emulab admins who are likely to be running from an up-to-date code tree, a build date is pretty close to a code tag even though it isn't a code tag (though i'd still prefer the code tag, since some admins work from stable instead of devel, upgrade dates vary, etc). However, an experimenter who creates a custom image which is doing something weird, may or may not have been working from an up-to-date tree. So the build date alone isn't as informative in that case.

[chaos@bbn.com]

Rob intends to work on this soon.

[ricci@cs.utah.edu]

Will do, but after GEC14

[chaos@bbn.com]

I think the goal here is still to embed the code tag of the emulab client code inside each image somewhere, so this ticket is still open.

[chaos@bbn.com]

Per today's call: Rob thinks it should be doable to write the git code tag to a file whenever a new image is created. This would not be backported to older images, so any images created before this proposed change would not have such a file. This solution sounds fine to Rob, Leigh, and GPO.

[stoller@flux.utah.edu]

These changes have been made and pushed up to emulab-devel. The file written will be /etc/emulab/version and will contain the SHA1 git hash. The commit message for these changes:

commit 749c8170b44618d503219eb6e82bf30e25264360 Author: Leigh B Stoller <​stoller@flux.utah.edu> Date: Thu Oct 11 16:07:13 2012 -0600

For the GPO: Write the current git hash to /etc/emulab/version when installing the clientside on an image.

[chaos@bbn.com]

Great! I'll keep an eye out for a newly-rolled image i can use to check this out, or feel free to suggest it if you remember the next time one is created.

[chaos@bbn.com]

The image which is currently loaded on the shared nodes at Utah does not yet have /etc/emulab/version. However, it appears that there is a newish copy of the F15 shared image:

boss,[~],11:47(126)$ ls -l /usr/testbed/images/FEDORA15-OPENVZ-STD.ndz
-rw-r--r--  1 stoller  wheel  1216348160 Nov  5 15:01 /usr/testbed/images/FEDORA15-OPENVZ-STD.ndz

which is newer than Leigh's last update to this ticket. I'll go ahead and reserve an exclusive VM, and see what happens.

Here's my rspec:

$ cat ~/instaticket-25-exclusive.rspec 
<?xml version="1.0" encoding="UTF-8"?>
<!-- This rspec will reserve one openvz node, specifying exclusive=true.
     This should yield a physical node running FEDORA15-OPENVZ-STD.  -->
<rspec xmlns="http://www.geni.net/resources/rspec/3"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xsi:schemaLocation="http://www.geni.net/resources/rspec/3
                           http://www.geni.net/resources/rspec/3/request.xsd" 
       type="request">

  <node client_id="virt1" exclusive="true">
    <sliver_type name="emulab-openvz" />
    <interface client_id="virt1:if0" />
  </node>
</rspec>

Hmm. It looks like this file doesn't exist on the new FEDORA15-OPENVZ-STD either:

[chaos@pc2 ~]$ ls -l /etc/emulab/version
ls: cannot access /etc/emulab/version: No such file or directory

[chaos@pc2 ~]$ hostname
pc2.ecgtest.pgeni-gpolab-bbn-com.utah.geniracks.net

Leigh, do you think the FEDORA15-OPENVZ-STD that you installed at Utah IG on Nov 5th should contain this file, or not yet?

[chaos@bbn.com]

On BBN's instageni rack, i logged into pc1, one of our shared nodes. It has:

vhost1,[~],15:37(0)$ cat /etc/emulab/version 
4f885af160a1d036c5b95749cfcfb0444eee0fda

about which git log says:

commit 4f885af160a1d036c5b95749cfcfb0444eee0fda
Author: Leigh B Stoller <stoller@flux.utah.edu>
Date:   Thu Dec 6 10:25:14 2012 -0700

That looks exactly right to me. Closing this.