Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://mort.io/blog/moving-onto-mirage/",
3 "title": "Moving Onto Mirage",
4 "link": "https://mort.io/blog/moving-onto-mirage/",
5 "updated": "2015-05-20T00:00:00",
6 "published": "2015-05-20T00:00:00",
7 "summary": "<p>For a little while I’ve had <a href=\"http://github.com/mor1/mor1.github.io\">this site</a> running as a <a href=\"http://openmirage.org/\">MirageOS</a>\nunikernel, shadowing the main site hosted on <a href=\"http://github.com/\">GitHub</a>. I’ve finally decided to\nmake the switch, as part of moving over to take advantage of Mirage’s DNS and\nTLS libraries.</p>\n<p>Following the usual pattern, as previously explained by <a href=\"http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/\">Amir</a>, <a href=\"http://www.somerandomidiot.com/blog/2014/08/19/i-am-unikernel/\">Mindy</a> and\nothers, the process is:</p>\n<ul>\n<li>Construct a static <a href=\"http://jekyllrb.com\">Jekyll</a> site.</li>\n<li>Write a <a href=\"http://travis-ci.com/\">Travis</a> YAML file to cause <a href=\"http://travis-ci.com/\">Travis</a> to build the unikernel image\nand commit it back to the deployment repository.</li>\n<li>Write a Git <code>post-merge</code> hook for the deployment repository, so that the\nlatest unikernel is automatically booted when a merge is detected, i.e., there\nis a new unikernel image.</li>\n<li>Write a <code>cron</code> job that periodically polls the deployment repository, pulling\nany changes.</li>\n</ul>\n<p>Building a <a href=\"http://jekyllrb.com\">Jekyll</a> site is well-documented – I did find that I had to tweak\nmy <a href=\"https://github.com/mor1/mor1.github.io/blob/master/_config.yml\"><code>_config.yml</code></a> so as to make sure my local toolchain matched the\none used by Github, ensuring consistency between versions of the site. For\nconvenience:</p>\n<pre><code><span><span><span>make</span></span><span> site</span>\n</span></code></pre>\n<h2><a href=\"https://mort.io/blog/moving-onto-mirage/#bringing-up-the-network\">Bringing up the network</a></h2>\n<p>The <a href=\"https://github.com/mor1/mor1.github.io/blob/master/.travis.yml\"><code>.travis.yml</code></a> file then specifies the three main targets for\nthe CI test build to carry out: Unix with a standard sockets backed\n(<code>MIRAGE_BACKEND=unix</code>, <code>MIRAGE_NET=socket</code>) and with the Mirage network stack\n(<code>MIRAGE_BACKEND=unix</code>, <code>MIRAGE_NET=direct</code>), and with the Xen backend\n(<code>MIRAGE_BACKEND=xen</code>). For the latter case, we must also specify the static IP\nconfiguration to be used (<code>MIRAGE_ADDR</code>, <code>..._GWS</code>, and <code>..._MASK</code>). The\n<a href=\"https://github.com/mor1/mor1.github.io/blob/master/.travis.sh\"><code>.travis.sh</code></a> script then calls the standard skeleton\n<a href=\"https://github.com/ocaml/ocaml-travisci-skeleton/blob/master/.travis-mirage.sh\"><code>.travis-mirage.sh</code></a> script after first building the site\ncontent using Jekyll.</p>\n<p>This tests the three basic combinations of network backend for a Mirage\nappliance:</p>\n<pre><code><span><span><span>$</span></span><span> make configure.socket build</span>\n</span></code></pre>\n<ul>\n<li><strong>UNIX/socket</strong> requires no configuration. The network device is configured\nwith the loopback address, <code>127.0.0.1</code>. Appliances can be run without\nrequiring <code>root</code> privileges, assuming they only bind to non-privileged ports.</li>\n</ul>\n<pre><code><span><span><span>$</span></span><span> make configure.direct build</span>\n</span></code></pre>\n<ul>\n<li><strong>UNIX/direct/dhcp</strong> requires no configuration if a DHCP server is running and\ncan respond. The appliance must be run with <code>root</code> privileges to use the new\nnetwork bridging capability of OSX 10.10, whereupon the DHCP client in the\nappliance follows the usual protocol.</li>\n</ul>\n<pre><code><span><span><span>$</span></span><span> make configure.xen build <span>\\\n</span></span></span><span><span> ADDR=<span><span>"</span>46.43.42.137<span>"</span></span> GWS=<span><span>"</span>46.43.42.129<span>"</span></span> MASK=<span><span>"</span>255.255.255.128<span>"</span></span></span>\n</span></code></pre>\n<ul>\n<li><strong>Xen</strong> uses the Mirage network stack and expects static configuration of the\nnetwork device.</li>\n</ul>\n<h2><a href=\"https://mort.io/blog/moving-onto-mirage/#using-travis-ci\">Using Travis CI</a></h2>\n<p>Of course, all that is for local development – for the live site, this is\nactually all wrapped up using <a href=\"http://travis-ci.com/\">Travis CI</a>. Due to a small pull request\nwaiting on the <a href=\"https://github.com/ocaml/ocaml-travisci-skeleton\">OCaml Travis CI skeleton scripts</a> and a few\nMirage releases currently being readied, this looks a little more complex than\nit needs to (the <code>FORK_USER</code> and <code>DEV_REMOTE</code> variables shouldn’t need to be\nspecified in the long run) but anyway:</p>\n<pre><code><span><span><span>language</span></span><span>:</span> <span>c</span>\n</span><span><span><span>script</span></span><span>:</span> <span>bash -ex .travis.sh</span>\n</span><span><span><span>env</span></span><span>:</span>\n</span><span> <span><span>matrix</span></span><span>:</span>\n</span><span> <span>-</span> <span>FORK_USER=mor1 DEV_REMOTE=git://github.com/mirage/mirage-dev</span>\n</span><span> <span>OCAML_VERSION=4.02 MIRAGE_BACKEND=unix MIRAGE_NET=socket</span>\n</span><span> <span>-</span> <span>FORK_USER=mor1 DEV_REMOTE=git://github.com/mirage/mirage-dev</span>\n</span><span> <span>OCAML_VERSION=4.02 MIRAGE_BACKEND=unix MIRAGE_NET=direct</span>\n</span><span> <span>-</span> <span>FORK_USER=mor1 DEV_REMOTE=git://github.com/mirage/mirage-dev</span>\n</span><span> <span>UPDATE_GCC_BINUTILS=1</span>\n</span><span> <span>OCAML_VERSION=4.02 MIRAGE_BACKEND=xen</span>\n</span><span> <span>MIRAGE_ADDR="46.43.42.137" MIRAGE_GWS="46.43.42.129" MIRAGE_MASK="255.255.255.128"</span>\n</span><span> <span>XENIMG=mortio MIRDIR=_mirage DEPLOY=1</span>\n</span></code></pre>\n<p>This uses the local <a href=\"https://github.com/mor1/mor1.github.io/blob/master/.travis.sh\"><code>.travis-sh</code></a> script to build the three versions\nof the site, using the <a href=\"https://github.com/mirage/mirage-dev\">Mirage development OPAM repository</a> so as to\npick up the latest versions of all the various packages, and updating the Travis\n<code>gcc</code> and <code>binutils</code> to ensure the stubs for a couple of packages (notably\n<code>mirage-entropy-xen</code>) build.</p>\n<p>Next stop: adding TLS and DNS support…</p>",
8 "content": "<p>For a little while I’ve had <a href=\"http://github.com/mor1/mor1.github.io\">this site</a> running as a <a href=\"http://openmirage.org/\">MirageOS</a>\nunikernel, shadowing the main site hosted on <a href=\"http://github.com/\">GitHub</a>. I’ve finally decided to\nmake the switch, as part of moving over to take advantage of Mirage’s DNS and\nTLS libraries.</p>\n<p>Following the usual pattern, as previously explained by <a href=\"http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/\">Amir</a>, <a href=\"http://www.somerandomidiot.com/blog/2014/08/19/i-am-unikernel/\">Mindy</a> and\nothers, the process is:</p>\n<ul>\n<li>Construct a static <a href=\"http://jekyllrb.com\">Jekyll</a> site.</li>\n<li>Write a <a href=\"http://travis-ci.com/\">Travis</a> YAML file to cause <a href=\"http://travis-ci.com/\">Travis</a> to build the unikernel image\nand commit it back to the deployment repository.</li>\n<li>Write a Git <code>post-merge</code> hook for the deployment repository, so that the\nlatest unikernel is automatically booted when a merge is detected, i.e., there\nis a new unikernel image.</li>\n<li>Write a <code>cron</code> job that periodically polls the deployment repository, pulling\nany changes.</li>\n</ul>\n<p>Building a <a href=\"http://jekyllrb.com\">Jekyll</a> site is well-documented – I did find that I had to tweak\nmy <a href=\"https://github.com/mor1/mor1.github.io/blob/master/_config.yml\"><code>_config.yml</code></a> so as to make sure my local toolchain matched the\none used by Github, ensuring consistency between versions of the site. For\nconvenience:</p>\n<pre><code><span><span><span>make</span></span><span> site</span>\n</span></code></pre>\n<h2><a href=\"https://mort.io/blog/moving-onto-mirage/#bringing-up-the-network\">Bringing up the network</a></h2>\n<p>The <a href=\"https://github.com/mor1/mor1.github.io/blob/master/.travis.yml\"><code>.travis.yml</code></a> file then specifies the three main targets for\nthe CI test build to carry out: Unix with a standard sockets backed\n(<code>MIRAGE_BACKEND=unix</code>, <code>MIRAGE_NET=socket</code>) and with the Mirage network stack\n(<code>MIRAGE_BACKEND=unix</code>, <code>MIRAGE_NET=direct</code>), and with the Xen backend\n(<code>MIRAGE_BACKEND=xen</code>). For the latter case, we must also specify the static IP\nconfiguration to be used (<code>MIRAGE_ADDR</code>, <code>..._GWS</code>, and <code>..._MASK</code>). The\n<a href=\"https://github.com/mor1/mor1.github.io/blob/master/.travis.sh\"><code>.travis.sh</code></a> script then calls the standard skeleton\n<a href=\"https://github.com/ocaml/ocaml-travisci-skeleton/blob/master/.travis-mirage.sh\"><code>.travis-mirage.sh</code></a> script after first building the site\ncontent using Jekyll.</p>\n<p>This tests the three basic combinations of network backend for a Mirage\nappliance:</p>\n<pre><code><span><span><span>$</span></span><span> make configure.socket build</span>\n</span></code></pre>\n<ul>\n<li><strong>UNIX/socket</strong> requires no configuration. The network device is configured\nwith the loopback address, <code>127.0.0.1</code>. Appliances can be run without\nrequiring <code>root</code> privileges, assuming they only bind to non-privileged ports.</li>\n</ul>\n<pre><code><span><span><span>$</span></span><span> make configure.direct build</span>\n</span></code></pre>\n<ul>\n<li><strong>UNIX/direct/dhcp</strong> requires no configuration if a DHCP server is running and\ncan respond. The appliance must be run with <code>root</code> privileges to use the new\nnetwork bridging capability of OSX 10.10, whereupon the DHCP client in the\nappliance follows the usual protocol.</li>\n</ul>\n<pre><code><span><span><span>$</span></span><span> make configure.xen build <span>\\\n</span></span></span><span><span> ADDR=<span><span>"</span>46.43.42.137<span>"</span></span> GWS=<span><span>"</span>46.43.42.129<span>"</span></span> MASK=<span><span>"</span>255.255.255.128<span>"</span></span></span>\n</span></code></pre>\n<ul>\n<li><strong>Xen</strong> uses the Mirage network stack and expects static configuration of the\nnetwork device.</li>\n</ul>\n<h2><a href=\"https://mort.io/blog/moving-onto-mirage/#using-travis-ci\">Using Travis CI</a></h2>\n<p>Of course, all that is for local development – for the live site, this is\nactually all wrapped up using <a href=\"http://travis-ci.com/\">Travis CI</a>. Due to a small pull request\nwaiting on the <a href=\"https://github.com/ocaml/ocaml-travisci-skeleton\">OCaml Travis CI skeleton scripts</a> and a few\nMirage releases currently being readied, this looks a little more complex than\nit needs to (the <code>FORK_USER</code> and <code>DEV_REMOTE</code> variables shouldn’t need to be\nspecified in the long run) but anyway:</p>\n<pre><code><span><span><span>language</span></span><span>:</span> <span>c</span>\n</span><span><span><span>script</span></span><span>:</span> <span>bash -ex .travis.sh</span>\n</span><span><span><span>env</span></span><span>:</span>\n</span><span> <span><span>matrix</span></span><span>:</span>\n</span><span> <span>-</span> <span>FORK_USER=mor1 DEV_REMOTE=git://github.com/mirage/mirage-dev</span>\n</span><span> <span>OCAML_VERSION=4.02 MIRAGE_BACKEND=unix MIRAGE_NET=socket</span>\n</span><span> <span>-</span> <span>FORK_USER=mor1 DEV_REMOTE=git://github.com/mirage/mirage-dev</span>\n</span><span> <span>OCAML_VERSION=4.02 MIRAGE_BACKEND=unix MIRAGE_NET=direct</span>\n</span><span> <span>-</span> <span>FORK_USER=mor1 DEV_REMOTE=git://github.com/mirage/mirage-dev</span>\n</span><span> <span>UPDATE_GCC_BINUTILS=1</span>\n</span><span> <span>OCAML_VERSION=4.02 MIRAGE_BACKEND=xen</span>\n</span><span> <span>MIRAGE_ADDR="46.43.42.137" MIRAGE_GWS="46.43.42.129" MIRAGE_MASK="255.255.255.128"</span>\n</span><span> <span>XENIMG=mortio MIRDIR=_mirage DEPLOY=1</span>\n</span></code></pre>\n<p>This uses the local <a href=\"https://github.com/mor1/mor1.github.io/blob/master/.travis.sh\"><code>.travis-sh</code></a> script to build the three versions\nof the site, using the <a href=\"https://github.com/mirage/mirage-dev\">Mirage development OPAM repository</a> so as to\npick up the latest versions of all the various packages, and updating the Travis\n<code>gcc</code> and <code>binutils</code> to ensure the stubs for a couple of packages (notably\n<code>mirage-entropy-xen</code>) build.</p>\n<p>Next stop: adding TLS and DNS support…</p>",
9 "content_type": "html",
10 "author": {
11 "name": "Unknown",
12 "email": null,
13 "uri": null
14 },
15 "categories": [],
16 "source": "https://mort.io/atom.xml"
17}