6 ms·
LXC 1.0 Released
- SEJeff 13y agoGreat news for docker and the greater container loving communities!
- ucarion 13y agoHopefully a Docker 1.0 will follow soon too!
- magnusgraviti 13y agoThe same thoughts here. Docker 0.8 added a lot of new features and fixed a lot of bugs but it is still work in progress. I.e. you can't rename containers and have to recreate (remove and create) them. and thank you guys for the release!
- jvermillard 13y agoand added some bugs ;) like I'm having hard time "rm" a stopped container since 0.8
- shykes 13y agoHi, Docker 0.8.1 was released last week, it fixes several old bugs as well as all known regressions spotted in 0.8. Would you mind trying it out, and letting us know in an issue if we missed your bug? Thanks!
- jvermillard 13y agoThanks will try next week. I just need the time to patch the docker code for bigger /dev/shm
- jacksoncage 13y agoAt last! This release is a significant milestone for us as it is the first release we consider to be production ready.
- magnusgraviti 13y agoIs flynn.io using LXC or something Docker-like?
- xnxn 13y agoFlynn uses Docker.
- nl 13y agoCan someone talk about LXC security in practice? I've read[1], and it is excellent to have options, but there I'd like guidance for what is actually usable and useful, especially via Docker. Background: I want to be able to execute arbitrary code submitted from the web. At the moment I'm sandboxing it inside a ZeroVM[2] container, inside a Docker (LXC) container. I'd like to lock down the Docker container more than the default (eg, disable outgoing network connections), but I don't really know where to start. (And yes, I do find it strange that it was easier to get an entirely new, experimental and undocumented container running inside LXC than it was to work out how to configure LXC. But layers are good, right?) [1] https://www.stgraber.org/2014/01/01/lxc-1-0-security-features/ https://www.stgraber.org/2014/01/01/lxc-1-0-security-feature... [2] http://zerovm.org/ http://zerovm.org/
- zobzu 13y agolayers of containers wont give you much. the main issue is the shared kernel, any bug there, any shared resource from there, and all containers have the same risk, no matter how many levels of nesting you have. layers of vm's, lxc containers, zerovms, etc, will probably make the attacks harder, but also the management, and speed, will suffer, and the security/useability trade off will probably not be adequate (given how fast vm's start anyway, if you want more isolation, you could just use a VM then) Zerovm is nice, but it requires porting, and of course, is not a silver bullet either.
- falconfunction 13y agoLibvirt and virtsandbox might help?
- nl 13y agoCould you be more specific? There is plenty of general advice around, but a complete lack of actionable steps to take.
- groks 13y agohttp://sandbox.libvirt.org/quickstart/ http://sandbox.libvirt.org/quickstart/ Or even just: http://danwalsh.livejournal.com/28545.html http://danwalsh.livejournal.com/28545.html ...an selinux sandbox without the containers stuff.
- nkvoll 13y agoAnyone know if it will make it into Ubuntu 14.04 LTS?
- jevinskie 13y agoCan anybody give me pointers on setting up this scenario? I would like to run my IRC bouncer inside a container. I want to make sure that this bouncer only makes outbound connections using an OpenVPN instance running outside the container. I think I need to wire up a tun/tap device to the container. The container also needs to somehow accept connections from my IRC client (directly, not through the VPN) while still concealing the connecting IP. Basically, I don't want my ZNC container or the IRC servers that it connects to to have access to sensitive Ip addresses.