Making Popcorn: Adding a Disk to a Rust Rumprun Unikernel | Hacker News Reader

Making Popcorn: Adding a Disk to a Rust Rumprun Unikernel

polyfractal.com

75 pointsingve9 comments

For those interested in unikernels. We just launched a community website — http://unikernel.org

Interesting to me that the author is seeking to add this into the unikernel. I was playing with the PHP Rumprun unikernel before trying to make it immutable such that the unikernel is based on one file structure only (surprise: most PHP applications assume they can write to a FS).

I like the idea that my deployment is closer to being idempotent for a number of reasons, one of which is security.

Can you expand on that idea? For Rumprun, it's not very many minutes of work to set things up so that you have a lower readonly file system layer (immutable across restarts) and then a memory file system on top of that (for purposes of applications insisting to modify "readonly" files). But, of course, it's not very many minutes only if you know the ins and outs of the backend system, and that's not the level of usability what we're aiming for. So, if writing "readonly" files is a widely desired feature, we should probably somehow support it as part of the general infrastructure in Rumprun so that it just works even if you don't know the ins and out of the underlying system.

Hey, a few months ago you might recall I was working on https://twitter.com/rumpkernel/status/623320639097712640 (I go by a different user name on hackernews).

The core issue with PHP is that most applications think they can just drop files in all sorts of places depending on what page was requested and to what user is logged in and what the state of the database was... and it always depends on what the application is. Some of these files are user uploads, logs, or cache for performance sake (more conflicting here is that PHP will cache op codes into memory based on the filesystem structure).

It's also pretty common to see exploits where an attacker injects code into a PHP file, so making a subset of this immutable would be a big win IMO when talking to business and IT about the list of reasons I would use this in production.

Ah, yes, I definitely remember you and your work, just didn't realize it was the same person.

Hop on to irc again some day or start a thread on the mailing list, and we can brainstorm about the best solution.

Author here. My goal is to (eventually) host a toy key:value store on top of a unikernel. So the KV store would need to persist data to a writable file system. It's great when you don't need to alter state and the unikernel can be immutable (baking config into code ala Mirage, etc)...but something like a KV store can't get away with that.

But, the KV store + unikernel is mostly for fun, so may not be the most practical of real-world ideas anyway :)

We have at least redis in rumprun-packages -- https://github.com/rumpkernel/rumprun-packages/tree/master/r... -- which AFAIK was packaged based on a non-toy need.

Yes, the need for persistent storage for persistent values is quite solid ;-)

Have you been able to also run it with KVM - I wonder why -no-kvm is passed to qemu. As you tried ext4 I think it failed as netbsd is not having drivers for it.

Wouldn't something like Irmin work well with this (assuming you can fit the working set into memory, which I think might be a requirement of Irmin's design)?

Reply on news.ycombinator.com