<talex5>
- Access control: instead of a single public service, you can now host services that are only available to clients that have the appropriate secret, which is embedded in an offline capability URL (sturdy ref).
<talex5>
- TLS: connections are now encrypted and authenticated by default.
<talex5>
- Persistence: you can get a URL for a service and reconnect to that later, and there is server-side support for restoring services from disk dynamically.
<avsm>
I've not had much time to hack on the build CI in the last few weeks, but I have scheduled some time next week to bring up the 0.2 version with persistent capabilities. I think it's a couple of days hacking away from doing real builds. The tutorial is awesome :)
<talex5>
Thanks :-)
<hannes>
I'd still be interested in a minimal capnp-enabled MirageOS unikernel...
<talex5>
That will require some minor changes to the capnp Runtime module, to remove the dependency on Core_kernel and to move Unix-specific parts to a separate capnp.unix library. Might make a good pioneer project.
<yomimono>
very cool, thanks for the update talex5 :)
<avsm>
the stub cross-compilation is making steady progress; the latest thing that happened on that front is the jbuilder meeting at icfp where the maintainers agreed to work on it as a high priority
<yomimono>
avsm: can you give a little bit more context?
<talex5>
We should remove Core_kernel anyway though. I don't think it's using much of it.
<avsm>
As part of that, once it has builtin spport for cross compilation, we are almost ready for the "real" stub support in all the mirage backends
<avsm>
which basically involves separating the C compilation into a separate jbuilder workspace and applying CFLAGS in a consistent fashion
<avsm>
the big advantage is that mirage will just use the "blessed" ocaml cross compilation support
<avsm>
since we just need to define a set of CFLAGS per platform
<avsm>
we tried this a few years ago via opam switches, but it really needed better support in the build system
<avsm>
almost all the mirage libraries are jbuildered up now, with the notable exception of mirage-xen
<avsm>
mirage-xen needs to be replaced with a ocaml-freestanding port, which is in progress
<avsm>
and then we can focus our cross compilation efforts on ocaml-freestanding
<avsm>
in order to port mirage-xen, there has been a new "unicore" project proposed in xen (now approved) that makes it far simpler to vendor minios
<yomimono>
cool. I had an agenda item to ask you about mirage-xen (well, 4.05.0, but IIRC mirage-xen is gating that)
<avsm>
i am hoping we can switch to unicore soon, retire mirage-xen, and then get back to cross compilation
<yomimono>
so mirage-xen is then gated on unicore, which is outside of our control?
<avsm>
there has been method behind all the build system porting madness :P apologies it's taking so long
<yomimono>
I have to admit that I don't like that, because I easily imagine 4.06 being released before we can build on 4.05
<avsm>
unicore is a little out of our control, but has the advantage of a dedicated team working on incubating it as a fresh project. i.e. they are motivated and designing it explicitly for use with mirage-style unikernels
<mato>
I don't think it's gated on unicore; were someone to do the work to port -freestanding to current Mini-OS then that should work as well
<avsm>
we *could* rebase minios with 4.05, but upstream minios seems problematic. need to rewind a few revisions. minios master doesnt even build on stock linux for me!
<avsm>
mato: yes indeed; i just got stuck and tired of trying to get stock upstream minios to compile
<hannes>
yomimono: it's part of mirage-platform with some ad-hoc shell and Makefile build system, which can clearly be ported to 4.05+ (ignoring waiting for jbuilder or unicore)
<avsm>
i am really reluctant to continue expanding that codebase in mirage-platform. It has vastly outlived its time and really needs to be retired. I'd prefer to deploy 4.05 unikernels on solo5 in the short term, and get xen back on track "properly" via unicore
<talex5>
Is unicore a base for Mirage-type systems? It looks more like an all-in-one C build system to me.
<mato>
avsm: yes, making it work is mostly wrangling with build systems and fighting mini-os assuming it can pollute the symbol namespace with $KITCHEN_SINK
<avsm>
talex5: we just need the stripped down minios
<avsm>
talex5: which unicore will apparently give us :) i.e. no xenstore C libraries
<mato>
talex5: my impression is that unicore aims to be a "better mini-os" mostly.
<talex5>
"The Unicore build tool is in charge of compiling the application and the
<talex5>
selected libraries together to create a binary for a specific platform and
<talex5>
architecture (e.g., Xen on x86_64). The tool is currently inspired by
<talex5>
Linux’s kconfig system and consists of a set of Makefiles. It allows users
<talex5>
to select libraries, to configure them, and to warn them when library
<talex5>
dependencies are not met. In addition, the tool can also simultaneously
<talex5>
generate binaries for multiple platforms."
<avsm>
mato: yeah, I am most happy if someone else wants to do it. In my tree, I also got rid of the OS module. I can upstream that quite soon actually -- it needs a minor mirage rev
<avsm>
talex5: i understand that it can generate libraries too, just like the linux build does (for internal use) before the binary is linked
<avsm>
how desperate are people for a 4.05 xen backend? :-)
<talex5>
New users hit this pretty quickly, since they typically start with the current version of the compiler...
<yomimono>
I build unikernels for xen and run them there a lot, and I don't want to lose libraries as they move forward
<avsm>
personally i am fine with holding that backend to a 4.04.2 ceiling until we get a well-engineered basis for it
<avsm>
right, but i dont think any libraries actually depend on 4.05 just yet
<avsm>
they will of course, but we have a few months grace i think
<yomimono>
in the short term then, we need to express the incompatibility in opam (I think we don't currently do this)
<avsm>
excellent plan :)
<hannes>
depends on what your goal is, I've to admit that 4.05 already has several fixes for integer overflows in the standard library... (by jeremy yallog, string.concat et al)
<avsm>
hannes: yeah, very true
<yomimono>
I'd much prefer not to wait for unicore for 4.05.0 support in mirage-xen, fwiw
<avsm>
ok, if anyone can get minios vaguely compiling out of master, i can resurrect my trees
<hannes>
yomimono: please don't mark conflicts in mirage et al for OCaml versions, 4.05 is working fine with ukvm + virtio FWIW
<yomimono>
I'd intended to mark a compiler version dependency for just mirage-xen
<talex5>
What's the problem with the current minios version?
<avsm>
i dont quite have the time to wade through the minios namespace disaster though :-/
<avsm>
it doesnt compile
<hannes>
yomimono: this is a good idea!
<avsm>
some missing symbols, need to find the right combination of CONFIG options for us. just like you did in your original fork talex5 :)
<talex5>
I wonder what changed?
<talex5>
I assume it's something new in the OCaml headers?
<avsm>
nope, i mean just stock minios
<avsm>
just try cloning minios master and building it (i tried on alpine)
<talex5>
Why use master? Our fork is working isn't it?
<talex5>
Seems dangerous to let things bit-rot until unicore is ready.
<yomimono>
+1
<avsm>
there was some reason -- i think new headers pulled in functionality, but we could patch minios
<avsm>
i'd much rather have minios and ocaml-freestanding working -- even by using our fork
<avsm>
it really was the point of the ocaml-freestanding work in the first place, to have a single point of cross compilation
<avsm>
as it is, we've been maintaining two separate cross compilation codebases for over a year
Bluerise has quit [Ping timeout: 276 seconds]
<avsm>
this is very bad :)
<avsm>
duplicated C stubs, that sort of thing
<avsm>
hence my reluctance to work on mirage-platform beyond breaking up the ocaml code and retiring the repo. ocaml-freestanding is much higher quality engineering
<hannes>
AFAICS, there are 3 things: (a) move mirage-platform as-is onto 4.05+ (should involve minor shell/Makefile stuff), (b) move mirage-platform to freestanding (more effort, since more integration work); (c) wait for unicore
<avsm>
yep thats right, except i dont think (a) was quite as minor as expected, but I unfortunately can't remember the blocker (sorry!)
<yomimono>
is a guess at the workneeded to move mirage-platform to freestanding documented somewhere?
<hannes>
where (a) should be a viable short-term solution, and if someone is committed, (b) should be attempted as soon as possible
<avsm>
i think (b) with our minios fork is do-able, as talex5 suggested too. i went down the rabbithole of rebasing minios which was probably not wise
Bluerise has joined #mirage
<mato>
yomimono: I believe i may have explained the work roughly in various chats, but I don't remember where
<mato>
... and when... and to whom :)
<yomimono>
mato: yeah, this conversation feels familiar, which is usually a sign that it should be in an issue or a mailing list thread somewhere
<mato>
tho probably to avsm at some point
<avsm>
on the bright side, i finally have a xenserver cluster running :)
<yomimono>
hannes's summary seems reasonable to me
<avsm>
and so can run xen unikernels relatively easily in the CUCL now
<mato>
yomimono / avsm: can you raise an issue, ping me in it and i'll try and remember the proposed workflow for b)
<yomimono>
mato: will do, thanks :)
<mato>
ta
<avsm>
awesome :) i'll look at my trees on friday afternoon and document the ocaml end
<avsm>
it was uniformly good news. almost nothing outside of mirage-xen used the OS module
<avsm>
so we can just patch libraries trivially to replace OS with the direct Xen module instead
<hannes>
in other news, I attempted 4.06 + ocaml-freestanding last week, but this needs some work... some of the OCaml build system changed, and make otherlibs.a isn't happy anymore
<avsm>
(no point abstracting OS for xen-only libraries -- there was some interest in doing this a few years ago to run in userspace using /dev/xen, but this is now largely superseded by solo5)
<avsm>
hannes: nice! first beta being cut this week, so fixes can still be done if you find build system bugs that can be more cleanly handled upstream
<yomimono>
I hesitate to even ask whether anyone has more on this issue :)
<hannes>
avsm: yes, I wanted to wait for the beta as next step (also already invested half a day in that) -- the motivation for this was zarith.1.6 release - which no longer marks the stack executable (done by some inline assembly there) -- thus I upgraded gmp (which now needs some more symbols, strstr, and some SHRT_MAX/MIN/..., PR at freestanding pending) + zarith
<yomimono>
er, sorry, currently at yomimono/mirage-nat, I hope to put it at mirage/mirage-nat
<talex5>
This is great! I can remove the last pin in qubes-firewall...
<avsm>
ooh, Qi Li would also benefit
<yomimono>
oh, I didn't realize Qi was still doing stuff based on this library
<avsm>
not entirely sure, but worth checking.
<hannes>
yomimono: I encountered a strange thing in there... so you've a nat-hashtable package... but this is actually using a LRU, not a hashtable..
<avsm>
he is certainly routing stuff
<yomimono>
I test against qubes-mirage-firewall already, I'll get in touch and make sure I don't break anything for Qi
<yomimono>
hannes: yes, very true
<hannes>
yomimono: you may consider renaming before releasing..
<yomimono>
this would be a sensible time to rename that
<hannes>
maybe nat-state or sth to be independent of the data structure in which the state is stored
<yomimono>
yeah, that's much more sensible; I'll throw that in before 1.0 (sorry talex5)
<talex5>
Does hashtable need to be a separate opam package? lru seems like a small build dependency.
<yomimono>
another good point; I picked that structure when the optional thing was irmin, which was a way bigger deal
<hannes>
talex5: that is a good question as well, how useful is the nat without the store?
<yomimono>
I think lru has opam install -t problems because of the test dependency that's not available
<avsm>
(as an aside, I'm not mad. mini-os master fails with this command: docker run alpine sh -c "apk add --update alpine-sdk perl && git clone git://xenbits.xen.org/mini-os.git && cd mini-os && make"
<yomimono>
but as hannes says, the nat isn't useful without the store, so you might as well fail for everything
<yomimono>
that's probably enough about that, thanks folks :)
<yomimono>
next up, hannes wanted to know about the status of the nameserver for mirage.io ?
<avsm>
not going to do this until the new cluster is up and running (which it physically is now)
<avsm>
doing too much infrastructure migration at the moment -- need to spend time on making sure that we can update them and so on
<avsm>
I'm migrating some of the shakier ocaml.org services first, and the xenserver cluster is looking quite healthy, so it can run a dns server soon too
thomasga has quit [Quit: Leaving.]
thomasga has joined #mirage
<avsm>
sorry -- I know it's taking time, but once the ocaml cluster is done we have a much more robust system
<hannes>
avsm: aha, so I can actually switch them off anyways, since you want to run your own dns servers?
<avsm>
no, we can all run DNS servers! i just want a core set running at the CUCL
<avsm>
so if all the others disappear, we still have the "permanent" ones here
<avsm>
and before we move a service like DNS, the website has to move first...
<hannes>
I don't understand "core set" and "permanent", neither the DNS <-> webserver dependency
<avsm>
well, what tends to happen to infrastructure is that it tends to last for a year or two, and then rapidly atrophy as people forget keys or whatever
<hannes>
but anyways, doesn't matter too much.. I'm heavily working on a DNSSec + nsupdate (via dns-over-tls) solution for NS (+let's encrypt)
<avsm>
so for a service such as DNS, I want to have at least one node I run
<avsm>
the infrastructure itself can be distributed
<avsm>
but if there's one node, then in an emergency I can always swap the root NS to the one good one
<avsm>
(i insisted on doing for this for ocaml.org, and voila -- all the other servers crashed when i was hopping on a flight to Nara for last years ICFP)
<avsm>
so apologies for the delay, but we will have self hosted DNS this year. the servers are all finally in place :)
<avsm>
hannes: letsencrypt you say? :-)
<hannes>
avsm: yes, I'm frustrated by various points there: I don't want to run a http stack on my mail server, I don't want to update private keys, I want to use mirageos, ...
<avsm>
understood...
<hannes>
so there's a simple design using dns auth, which requires the http client to push nameserver updates (txt records). all done by some mirageos unikernels. 85% ready
<avsm>
nice!
<avsm>
i'm hoping that one of the xen hosts can use your VM signing method too
<hannes>
it would be interesting to have that up and running, either kvm or xen and linux... let me know if you end up in issues / need features...
<avsm>
will do!
<avsm>
provisioning a few opam build workers for it first to make sure the hardware is solid, then will expand out
<hannes>
there's some pending work to get statistics from the host about the vms into prometheus
<hannes>
is your cluster + setup (or planned setup) documented somewhere? would be interesting to take a look how this should in the end look like
<avsm>
it is, but stuck internally in a cambridge wiki and a google doc. i'm pulling it out into a public website now that all the money/machines are sorted
<avsm>
om the list for next week. Malcolm Scott at the CUCL has been installing the machines the last couple of days
<avsm>
gw.ocamlabs.io is pingable and routing all the traffic via openbsd
<avsm>
gw.ocamllabs.io, sorry
<reynir>
Did you use ocaml-letsencrypt?
<avsm>
not yet, but i want to!
<hannes>
reynir: i do, yes... as said, 85% ready
<hannes>
avsm: doesn't reply to icmp echo requests from me
<mato>
avsm: As I suggested, perhaps we could have a private repository documenting the project infrastructure? I.e. accessible to members of the mirage org?
<avsm>
mato: yes
<avsm>
that's the plan once the new machines are in place. we have to tear down the bytemark and rackspace VMs over the next few months as they are 1) expensive and 2) going away
<avsm>
so all the new stuff will be documented
<mato>
avsm: I guess that implies paying for private Github repos on the org level but that should be doable via OCL?
<avsm>
i'll find a place to host and pay for them, not thought about it yet :)
<avsm>
is the job opening for someone to work on ocaml build infrastructure (including these machines, the capnp opam build infra, and hopefully unikernel infra :)
<avsm>
spread the word!
<avsm>
thanks yomimono for reminding me that this is in fact the ideal channel to advertise it
<avsm>
ciao everyone! have a good week
<mato>
ciao!
talex5 has quit [Quit: Leaving]
avsm has quit [Quit: Page closed]
thomasga has quit [Quit: Leaving.]
mort___ has joined #mirage
mort___ has left #mirage [#mirage]
mort___1 has joined #mirage
mort___1 has left #mirage [#mirage]
<hannes>
yomimono: FWIW mirage-xen-ocaml already has the available ocaml <4.05.0...
<yomimono>
huh, that's interesting; you definitely get pretty far into trying to build unikernels for xen on 4.05.0 switches
<yomimono>
or at least you used to, maybe someone else fixed it already
<yomimono>
it's <= 4.05.0 for mirage-xen-ocaml 3.0.4, which seems wrong