On 24/02/16 21:31, David Halls wrote:
I'd much rather distribute a config than rumprun - asking users to execute
an arbitrary program is much less safe than giving a unikernel + config to
qemu.
If someone is willing to execute several million lines of qemu against
an untrusted binary, and not willing to execute a few hundred line shell
script, they really should sit down, have a cigar, and think about life.
Now, granted, qemu+more is not better, but put into mathematical
terms, qemu+epsilon approaches qemu.
The "dtuf pull-target" spell sort of hints that it doesn't, at least
unless you distribute a tarball and pipe to tar -zxf.
I can think of some options:
- tarball (as you suggested)
- Have a convention which says the first blob is always the Rumprun binary
and then second one is the default config
- Publish the default config separately, appending '.cfg' (or whatever) -
e.g. 0.7.8-x86_64-rumprun-netbsd-hw_generic.cfg
- Invent a manifest format and publish that in the repo (e.g. with the
target name 'MANIFEST'). The manifest would describe the image and how to
run it. Docker takes this approach for containers. However when I asked on
https://github.com/docker/distribution/pull/1068 whether it would be better
to do something more opaque, there was some support. I don't really want to
go down the route they took.
In general, I don't really fancy building a manifest spec into dtuf - at
the moment it knows nothing about Unikernels and I'd prefer it to stay that
way.
Ok let's keep an open mind and see how the landscape develops.
Thinking ahead, I guess in the future one could distribute an example
config, and then the qemu spell would be: qemu ... -initrd rumprun.cfg
That would be super cool. We should definitely keep the tooling (and
config) separate from distribution.
Assuming you meant sort of what I understood you meant, one should be
able to set up the config once, and then keep re-running with the same
config through binary upgrades. At least that should be a goal.
Did you happen to market this Ghost distribution to people who would
normally use Ghost? They might be able to provide feedback beyond the
capabilities of this list.
