Re: Libvirt on IPFire

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4059 bytes --]

Hi,

thanks for getting in touch.

On Sat, 2016-03-19 at 09:42 +0100, Jonatan Schlag wrote:
> Hi list,
> in October 2014 I began to build libvirt for IPFire. This failed the first
> time and second but now I tried it the third time with a lot more knowledge
> and it works well.

This is indeed something I would personally like to see in IPFire. Although I
have many reasons why this is a bad idea...

> So I have a running libvirt daemon on my IPFire (Arch is x86_64 works very
> well by the way) and want to ask if the project is interested that the libvirt
> package becomes an official addon. 

It must be an add-on so that users do not have to install it if they don't wish
to do so and to reduce attack surface.

> It could save a lot of work because everybody have the chance to install what
> he want in a virtual machine.  Also, I think it is safer to put my owncloud
> into a virtual machine than to put is directly on my IPFire. Also, it could
> save energy because a home user has to run only one real computer.  

It is probably not more secure to run a KVM machine. Breaking out of that is
easy enough. However, I would also like to see some things installed on a
different system instead of on IPFire itself. Just because I think that there
are better distributions out there to host owncloud and similar things. It will
also allow to migrate this functionality from a physical machine to IPFire or
from IPFire to a physcial machine later.

> Otherwise, libvirt is one more security risk and it is possible to break out
> of a virtual machine and attack the host. 
> So these are some security aspects, but in the moment, I think there are more
>  benefits than disadvantages. 
> But  I would like to hear your opinions on this topic. 
> 
> So what are the dependencies for libvirt and what have to be done on existing
> packages.
> 
> Hard dependencies
> 
> util-macros
> libpciaccess
> libyajl
> 
> nice to have ( increase the usability)
> 
> opus
> python-six
> python-pyparsing
> spice-protocol
> spice
> 
> These packages provide a protocol similar to vnc (http://www.spice-space.org/)

These look okay. Basically anything that is free software and actively
maintained upstream should be okay. Please consider to reduce size as best as
you can. It does not have to fit into a megabyte all together, but avoid adding
things that are not useful.

> optional ( create errors on start up but nothing more)
> 
> pm-utils
> dmidecode

Add these too.

> what have to be done on existing addons
> 
> nmap: update to the latest version 
> (to have a ncat version which supports the -U options, this is required to
> communicate over a normal ssh session)

Please send updates as individual patches up front.

> ebtables: create some links
> (libvirt search in the wrong directory  for the binaries)

Where?

> dnsmasq
> enable 
> HAVE_DHCP
> HAVE_SCRIPT
> HAVE_TFTP 
> but I have to check this again on i686 HAVE_SCRIPT is enough,  in the moment I
> have not the time to test where the problem is, but  I will do this in the
> next weeks.

This will probably be a bigger issue. We are using dnsmasq just as a DNS proxy
and do not use the DHCP component. If that should be used we either have to
disable this in our other configuration or ship a second copy. I would like to
avoid the latter.

> So that is it.
> Now I am waiting for your opinion and what you think about this :-).

Do you have code for this already? Do you have a git repository or do you need
one? We could host things if needed.

> Regards Jonatan
> 
> Ps. I would maintain these packages if they become official packages. 

That is a huge requirement. We just don't have the man power to do this
ourselves. Although we are keen to support you when ever needed.

> PSS. I use a new e-mail address because my old one is currently blocked by
> this server.

Which one is that? Could you maybe email me details about that in private?

Best,
-Michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]