4 ms·

That is partly true. But if there is nothing to hack into, there will also be nothing to log in to for an admin or an ops person. In the case of Erlang, for in

by alco 12y ago

That is partly true. But if there is nothing to hack into, there will also be nothing to log in to for an admin or an ops person. In the case of Erlang, for instance, it provides a built-in remote shell which allows one to connect to a running Erlang process, get multitude of information about the VM, loaded code, etc. As long as there is a convenient way to maintain a running system, that same way can be used for hacking.

andrewstuart 12y ago
Perhaps deployment and management practices will change to take into account this approach to management, rather than forcing the existing insecure approach onto dedicated applications/servers.
- edwintorok 12y ago
  I wouldn't mind to have an SSH shell to MirageOS though. Perhaps something like TinySSH could be translated to OCaml?
  - alco 12y ago
    You mean a pseudo-shell? Because when you're running OCaml on top of a hypervisor, there is no OS and shell in the traditional meaning of those words. So nothing to connect to.
    - edwintorok 12y ago
      Yeah, I don't mean a classic shell or even the OCaml toplevel. But it would be nice to provide a "standard" way for applications to define their own commands, and to provide some builtin commands for monitoring (memory usage, open connections, etc.).
      - alco 12y ago
        I'm afraid that going in the direction of using single-language platforms only draws us further for having a standard way of managing them.
        edwintorok 12y ago
        Hmm, but there could still be a libraries that take care of the common tasks: how to talk to an SSH client, how to get some basic info from the Mirage kernel, etc. Since these unikernels are so specialized maybe SSH would be overkill, but I wouldn't want each developer to invent their own potentially insecure way of communicating with the unikernels.
        avsm 12y ago
        We've got an SSHv2 client/server in pure OCaml already, but are waiting for the OCaml TLS effort to be integrated before putting the SSH layer in. It will be use the toplevel libraries and be optional...
  - andrewstuart 12y ago
    It's security advantage to not have a shell or anything that someone can log in to. Perhaps export instrumentation data or provide instrumentation via an interface or something.
amirmc 12y ago
You don't always require a shell if all you need is info about the system. Such a logging process can easily be compiled into the application and that data regularly pushed elsewhere. If you need to change what's being logged then adjust the code and recompile/deploy a new Unikernel. I have a version of my website being compiled as a Unikernel and the workflow is very simple [1]. My point is that the whole workflow of creating and deploying applications becomes much simpler as the final VM can be an (almost) disposable item, rebuilt at-will. This is pretty much what the configuration management tools are all striving for but Unikernels work this way by design. Therefore, our notions of managing such systems will also change. [1] http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/ http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-li...
- eric_bullington 12y ago
  Oh, great blog post. I've been looking for an excuse to re-do my website -- right now it's running on a semi-custom Python blog engine. I've been doing Project Euler in OCaml recently so this is a perfect excuse to expand my horizons.
  - amirmc 12y ago
    Thanks! If you're interested in deploying to EC2 then you should also look over Mindy Preston's posts [1]. There will also be more work done on improving cloud deployment over the summer [2]. I expect it won't be too long before we can have a heroku-like experience/system for easily building and deploying Unikernels to third-party clouds. [1] http://www.somerandomidiot.com/blog/categories/mirage/ http://www.somerandomidiot.com/blog/categories/mirage/ [2] http://openmirage.org/blog/welcome-to-our-summer-hackers http://openmirage.org/blog/welcome-to-our-summer-hackers

by alco 12y ago

andrewstuart 12y ago

Perhaps deployment and management practices will change to take into account this approach to management, rather than forcing the existing insecure approach onto dedicated applications/servers.

edwintorok 12y ago
I wouldn't mind to have an SSH shell to MirageOS though. Perhaps something like TinySSH could be translated to OCaml?
- alco 12y ago
  You mean a pseudo-shell? Because when you're running OCaml on top of a hypervisor, there is no OS and shell in the traditional meaning of those words. So nothing to connect to.
  - edwintorok 12y ago
    Yeah, I don't mean a classic shell or even the OCaml toplevel. But it would be nice to provide a "standard" way for applications to define their own commands, and to provide some builtin commands for monitoring (memory usage, open connections, etc.).
    - alco 12y ago
      I'm afraid that going in the direction of using single-language platforms only draws us further for having a standard way of managing them.
      - edwintorok 12y ago
        Hmm, but there could still be a libraries that take care of the common tasks: how to talk to an SSH client, how to get some basic info from the Mirage kernel, etc. Since these unikernels are so specialized maybe SSH would be overkill, but I wouldn't want each developer to invent their own potentially insecure way of communicating with the unikernels.
        avsm 12y ago
        We've got an SSHv2 client/server in pure OCaml already, but are waiting for the OCaml TLS effort to be integrated before putting the SSH layer in. It will be use the toplevel libraries and be optional...
- andrewstuart 12y ago
  It's security advantage to not have a shell or anything that someone can log in to. Perhaps export instrumentation data or provide instrumentation via an interface or something.

amirmc 12y ago

You don't always require a shell if all you need is info about the system. Such a logging process can easily be compiled into the application and that data regularly pushed elsewhere. If you need to change what's being logged then adjust the code and recompile/deploy a new Unikernel. I have a version of my website being compiled as a Unikernel and the workflow is very simple [1]. My point is that the whole workflow of creating and deploying applications becomes much simpler as the final VM can be an (almost) disposable item, rebuilt at-will. This is pretty much what the configuration management tools are all striving for but Unikernels work this way by design. Therefore, our notions of managing such systems will also change. [1] http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-lines/ http://amirchaudhry.com/from-jekyll-to-unikernel-in-fifty-li...

eric_bullington 12y ago
Oh, great blog post. I've been looking for an excuse to re-do my website -- right now it's running on a semi-custom Python blog engine. I've been doing Project Euler in OCaml recently so this is a perfect excuse to expand my horizons.
- amirmc 12y ago
  Thanks! If you're interested in deploying to EC2 then you should also look over Mindy Preston's posts [1]. There will also be more work done on improving cloud deployment over the summer [2]. I expect it won't be too long before we can have a heroku-like experience/system for easily building and deploying Unikernels to third-party clouds. [1] http://www.somerandomidiot.com/blog/categories/mirage/ http://www.somerandomidiot.com/blog/categories/mirage/ [2] http://openmirage.org/blog/welcome-to-our-summer-hackers http://openmirage.org/blog/welcome-to-our-summer-hackers