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