Server Technical Specification: Agenda and First Draft

Fri Feb 28 20:37:11 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/28/2014 08:56 AM, drago01 wrote:
> On Fri, Feb 28, 2014 at 2:43 PM, Stephen Gallagher <sgallagh at redhat.com>
> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> 
>> For the sake of keeping people in the loop, here's a first pass at the 
>> Fedora Server technical specification that we will be discussing in a 
>> meeting in #fedora-meeting-1 in about 75 minutes.
>> 
>> If you can't attend, please make comments on the 
>> server at lists.fedoraproject.org mailing list, so they're all in one
>> place.
>> 
>> - -------- Original Message -------- Subject: Server Technical
>> Specification: Agenda and First Draft Date: Fri, 28 Feb 2014 08:40:02
>> -0500 From: Stephen Gallagher <sgallagh at redhat.com> Reply-To:
>> server at lists.fedoraproject.org To: server at lists.fedoraproject.org
>> 
>> I've created a wiki page[1] for the Technical Specification that we are
>> working on. I've copied much of the structure from the Workstation tech
>> spec, as it was well organized.
>> 
>> There are quite a few sections in it that I have tagged as UNAPPROVED. I
>> believe we need to make these the agenda for the Tech Spec Working 
>> Session today. What we will do is quickly go through each of them. We'll
>> mark any that are uncontested as "Approved" and then go back and discuss
>> any that need discussion.
>> 
>> 
>> [1] https://fedoraproject.org/wiki/Server/Technical_Specification
> 
> Just copying IRC snipped from #fedora-devel:
> 
> <drago01> sgallagh: "systemd-nspawn will be used to manage containerization
> capabilities. " did I miss something or doesn't upstream say that it should
> not be used for anything that needs secruity? <sgallagh> drago01: Last I
> heard, the Dans (Walsh and Berrange) had SELinux working with it now. 
> <mclasen> dargo01: I think that statement may be evolving ? <sgallagh> And
> Docker is moving to systemd-nspawn and away from lxc <mclasen> but
> certainly valuable to raise the question on the list, and see if lennart,
> dan or dan want to chime in <drago01> sgallagh: "Note that even though
> these security precautions are taken systemd-nspawn is not suitable for
> secure container setups. Many of the security features may be circumvented
> and are hence primarily useful to avoid accidental changes to the host
> system from the container. The intended use of this program is debugging
> and testing as well as building of packages, distributions and software 
> involved with boot and systems mana <drago01> gement." [1] <sgallagh> So
> it's definitely the way forward. <drago01> sgallagh, mclasen : ok makes
> sense
> 
> So I am not sure if that has changed yet or not but if it has we should at
> least get the man page updated.
> 
> 1: http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html (man
> page)
> 
Well this has changed again.   Docker is now going native.  It will support
containers directly and not require a different set of tooling like lxc,
systemd-nspawn or libvirt-lxc.

This will be the default, and I guess people could experiment with others.