Re: Libvirt on IPFire

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

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