<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Thank you very much for such a detailed answer.<div><br></div><div>This is exactly what we were looking for.</div><div><br></div><div>More replies inter lines:</div><div><br><div><div>On Sep 3, 2013, at 8:34 PM, Stephen Soltesz <<a href="mailto:soltesz@opentechinstitute.org">soltesz@opentechinstitute.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Also requested was a description of typical package deployment and<br>experiment management on M-Lab.<br><br>Typical package management follows these basic steps:<br><br>1) build rpm package from source repos in <a href="http://github.com/m-lab-tools/">http://github.com/m-lab-tools/</a><br>2) copy and sign rpm package to M-Lab yum repository<br><br>Now per-machine, the slice (i.e. experiment VM) is instantiated:<br><br>3) upon slice vm creation on an M-lab server, the first-phase of<br>initialization includes bootstrapping the yum configuration of the vm's<br>filesystem (i.e. /etc/yum.conf and /etc/yum.slice.d/slice.repo list).<br>These import the public signing key, and point to CentOS mirrors and the<br>M-Lab slice package repository.<br>4) the second phase of slice initialization then tries to install the<br>slice package:<br>   i.e. yum install mlab_ooni<br>5) on success, the service starts.  on failure, stop.<br>6) M-Lab uses external monitoring to identify failed services and inform<br>a directory service like mlab-ns of available servers.<br><br></blockquote><div><br></div><div>Can we extend this to inform a different service that is not mlab-ns? We have concluded that it's probably ideal to not rely to heavily on m-lab for the discovery and of collectors and helpers.</div><div><br></div><div>We would ideally want to be able to do a HTTP POST request over Tor to a certain service to update the list of collectors and helpers that are currently running as is detailed in this ticket.</div><div><br></div><div>In light of this data we have devised this possible strategy for learning about new collector and test helpers: <a href="https://github.com/TheTorProject/ooni-probe/issues/183">https://github.com/TheTorProject/ooni-probe/issues/183</a>.</div><div><br></div><div>Would it be a problem to install tor, torsocks and curl on these machines and add a script to push to such a service?</div><div><br></div><div>Does this monitoring service also routinely check to monitor the health of the nodes?</div><br><blockquote type="cite">Since the rpm packages are effectively public, they do not include any<br>private information.  Some experiments have conditional deployment. i.e.<br>if site==nuq01, then run an additional service.  As well, the initialize<br>scripts for a package could generate per-machine key pairs.<br><br></blockquote><div><br></div><div>The reason why this is the case is now clear to me. If we can add some extra commands to the monitoring scripts that would be sufficient for us.</div><div><br></div><div>Would it be possible to service the monitoring infrastructure with private key material?</div></div></div><div><br></div><div>Thanks again for your thorough reply.</div><div><br></div><div>~ Art.</div><div><br></div></body></html>