Re: Libvirt on IPFire

Re: Libvirt on IPFire

[Michael Tremer]

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

Hi,

On Sat, 2016-03-19 at 15:44 +0100, Jonatan Schlag wrote:
> Hi,
> thank you for your response.
> 
> Am Sa, 19. Mär, 2016 um 2:16 schrieb Michael Tremer <michael.tremer(a)ipfire.org
> >:
> > 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.
> I absolutely agree everybody should have the possibility to decide if he wants
> libvirt or not. Although this should be only interesting for home users. I
> would never recommend a libvirt addon to a company. So if libvirt is an addon
> like qemu or something similar it should be ok or did i miss understand you?

No, please send patches. +1 from me.

> 
> > 
> > 
> >  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.
> That is true. There are better distributions for owncloud and so on, that was
> also my motivation to build libvirt for IPFire. IPFire is a very good firewall
> distribution, but it is not a good distribution for web hosting. But that is
> not a fault because IPFire is not developed for that, and this perfect. My
> thought was to use a virtual machine on my IPfire to server all other things I
> need because why should I compile 20 libraries when I have to compile 10 and
> then I could install everything in a virtual machine that I want.
> 
> > 
> > 
> >  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.or
> > g/)
> > 
> > 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.
>  
> Thanks. I will have a look at spice and if we really need it otherwise this is
> the technology which is actively developed and is comparison tho vnc very
> fast. I try it with vnc but it is horrible to install a server when your
> monitor show only 5 pictures per second. So I will have a look on that, but i
> do not see a real change to reduce the amount of packages.

I think spice should be included. I assume that most people will run something
like Windows in this to have a machine on a remote network to connect to and do
debugging. In that case, a good remote screen protocol like spice is necessary.

> >  optional ( create errors on start up but nothing more)
> >  
> >  pm-utils
> >  dmidecode
> > 
> > Add these too.
> I will drop this. 

I was rather saying that you should build these packages.

I would like to add dmidecode to the core system any way.

> >  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.
> Ok, I will send patches for everything that I listed in these part.
> 
> > 
> > 
> >  ebtables: create some links
> >  (libvirt search in the wrong directory  for the binaries)
> > 
> > Where?
> Libvirt looks in the /sbin directory for the binaries
> These are the 3 symlinks
> 
>  ln -s /usr/local/sbin/ebtables-save /sbin/ebtables-save
>  ln -s /usr/local/sbin/ebtables /sbin/ebtables
>  ln -s /usr/local/sbin/ebtables-restore /sbin/ebtables-restore

We should probably move it to /usr/sbin then and libvirt should be able to find
it there.

Would you be up to send a patch for that, too?

> >  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.
> I guessed that this would be a big problem. Libvirt start it own dnsmasq
> daemons so the second copy is maybe an alternative, but you are right this not
> a good solution. 
> The problem is that libvirt require the DHCP option otherwise, the whole
> network configuration does not work. That is a big problem and make the whole
> thing around dnmasq more complicated. 
> I sad to say this but in the moment, I have no real idea what we could do. 

We will figure this out. Start building the rest and we will have a look at this
when we arrive at this point.

> >  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.
> I have a local git repository with all changes. But I have no online git
> repository. I would be very cool and helpfull if you could host one for me. :-
> ).
> A big thanks for the offer that you could host the things.

No worries :) I will send you another email about this.

> 
> > 
> > 
> >  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.
> Thanks for the help. I will maintain this packages if libvirt become an
> official addon
> 
> qemu and it dependencies. (When I maintain libvirt I think I make sense to
> maintain qemu, because libvirt is nothing without qemu. )
> 
> libvirt
> util-macros
> libpciaccess
> libyajl
> 
> spice
> spice-protocol
> python-pyparsing
> python-six
> opus
> 
> I know that the project has not he power to maintain all these packages, so
>  for me it is logical to say if I want libvirt in IPFire, I have to maintain
> libvirt. 
> Nevertheless, a big thanks that you want to support me if there are problems. 

We have a development Jabber channel in case you need help with the build
system. Someone should usually be around.

> 
> > 
> > 
> >  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
> I will write you a second E-Mail on this topic.
> 
> Thanks to all  for the opinions on that topic.
> 
> Regards Jonatan
> 

-Michael

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

Re: Libvirt on IPFire

[Michael Tremer]

[-- 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 --]