09:21 <bramford> hannes: Is there a documented/known way to use cohttp-mirage with ocaml-tls to make https client requests in a mirage unikernel? 'example' (in ocaml-tls) is the only non-unix TLS web client example I've found so far but doesn't use cohttp.

09:50 <hannes> bramford: not sure whether any cohttp-mirage documentation is around, sorry about that. on the positive side, I did successfully do https client connections with cohttp and tls :)

09:52 <hannes> let me try to condense an example (the last time i used cohttp + tls + unikernel was part of https://github.com/hannesm/ocaml-letsencrypt/tree/nsupdate/mirage which is not straightforward)

09:56 <Drup> isn't there is a unikernel in mirage skeleton who serves a static website on https ?

09:58 <bramford> hannes: Ok cool, I'll check it out. In the meantime, I think I found a way - Use Cohttp_mirage.Client.ctx (with a TLS conduit and a DNS resolver)

10:00 <hannes> bramford: https://gist.github.com/hannesm/2d2bd883d929bb15ba1f5f82a230b9f0

10:00 <hannes> Drup: bramford asked about a https _client_

10:06 <hannes> bramford: important to remember that (iirc) conduit/cohttp doesn't provide any interface to do certificate verification in such a setting, and just accept any certificate

10:09 <bramford> hannes: Yeah that's an issue. So I can't construct a new Tls.Config.client and provide it somehow?

10:10 <hannes> bramford: you've to ask conduit / cohttp people about that, I don't understand their interfaces too well

10:10 <bramford> hannes: Ok, it seems like a rather common requirement.

10:11 <hannes> bramford: I do agree, and at least on the TLS interface it is easily doable!

10:12 <hannes> there are several similar issues at conduit https://github.com/mirage/ocaml-conduit/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+tls -- some even opened by myself

10:15 <bramford> Ah yep, seems like a rather well-highlighted issue

10:18 <bramford> hannes: Thanks for the gist example. A question - How does the conduit become TLS-capable? Is it due to `let ctx = Cohttp_mirage.Client.ctx resolver ctx in`?

10:19 <Ulrar> Okay so now my unikernel works fine with unix backend. I'm trying to compile it with virtio, but I get "ocamlfind: Package `mirage-bootvar-solo5' not found" and a after that "ocamlfind: Package `nocrypto.mirage' not found"

10:19 <Ulrar> make depend doesn't show any errors, but make fails with that

10:20 <hannes> bramford: again I don't know much about the conduit design choices here, but "Conduit_mirage.with_tls ctx >>= fun ctx ->" does the trick (this requires conduit compiled with tls)

10:21 <hannes> Ulrar: you have mirage-solo5, mirage-entropy, and zarith-freestanding installed? if not, install them. if yes, reinstall nocrypto.

10:21 <Ulrar> Yeah looks like I have mirage-no-solo5 conflicting

10:21 <Ulrar> shouldn't make depend tell me this ?

10:21 <Ulrar> opam install mirage-bootvar-solo5 seems to have a plan to fix it, so let's try that

10:24 <bramford> hannes: Right, yeah, thanks.

10:50 <mort___> bramford: https://github.com/mor1/tlstunnel/blob/unikernelise/mirage/tlstunnel.ml may be of interest. (sorry dropping into a conversation halfway through…)

10:54 <bramford> mort___: Interesting, but definitely complex. More so than the mirage https client example found in ocaml-tls.git

10:56 <hannes> mort___: that again is a TLS server which forwards as a TCP client... ;)

11:12 <mort___> true, i did say might :)

13:09 <Ulrar> Mh, it's not booting. qemu stays stuck on "booting from ROM..." and nothing happens after that

13:11 <Ulrar> The exact same config works fine with rumprun, so it must be something to do with solo5

13:19 <Ulrar> Okay got it, solo5 just ignores vga, you have to use serial. Fair enough

13:22 <hannes> Ulrar: sounds like that isn't very visibly documented anywhere? if so, and you feel like it, open a issue or PR at the solo5 (or mirage) repository!?

13:28 <Ulrar> Well it is written on the solo5 github, but as far as I can tell it isn't on mirageos

13:28 <Ulrar> But reading the solo5 github I can see that it supports one serial on com1, one virtio block and one virtio net

13:28 <Ulrar> hence it doesn't support any vga

13:29 <Ulrar> Similarly, --ipv4 is documented everywhere, but I couldn't find anything about how to provide the gateway. Looks like it's --ipv4-gateway

13:30 <Ulrar> Guess most people aren't using regular kvm

13:34 <Ulrar> Now it seems to be assigning it's public v4 properly, it pings, but port 80 stays closed for some reason

13:35 <Ulrar> Maybe because it's 8080 in my code .. nevermind

13:35 <Ulrar> Sorry for the noise

13:37 <Ulrar> Yeah it works fine. Problems solved, thanks :)

13:43 <hannes> \o/

13:43 <hannes> I use --ipv4 and --ipv4-gateway quite a lot

20:12 <Ulrar> Yeah, I wish there was a way to configure ipv4 programatically though, at runtime

20:12 <Ulrar> would allow for some interesting stuff

20:13 <Ulrar> although if solo5 only supports one net device, maybe not

22:49 <bramford> Ulrar: When you run `mirage configure -t virtio` it will spit out a file `_libvirt.xml`. It includes examples of the devices solo5 supports - A single instance of each - serial console, clock, block device, network interface. The names of these devices apperars to be irrelevant.