Use of lokkit in livecd-builder

[Bryan Kearney]

The F9 version of livecd-tools usese /usr/sbin/lokkit to enable and 
disable the firewall. There is a FIXME near it to suport the rest of the 
options which lokkit takes. The current implementation executes this in 
the chroot environment, so forces several packages to be deployed into 
the image when it is built. Since I would be curious in reducing the 
package set for the images which are built, I am curious if there are 
plans around any of the following:

1) Remove the use of lokkit and instead directly manipulate the files 
(or perhaps use augeas).
2) Look to break up system-config-firewall-tui so that lokkit is a 
separate package with less dependencies.

Thanks!

-- bk

[Jeremy Katz]

On Thu, 2008-08-28 at 08:44 -0400, Bryan Kearney wrote:
>  The F9 version of livecd-tools usese /usr/sbin/lokkit to enable and 
>  disable the firewall. There is a FIXME near it to suport the rest of the 
>  options which lokkit takes. The current implementation executes this in 
>  the chroot environment, so forces several packages to be deployed into 
>  the image when it is built. Since I would be curious in reducing the 
>  package set for the images which are built, I am curious if there are 
>  plans around any of the following:
>  
>  1) Remove the use of lokkit and instead directly manipulate the files 
>  (or perhaps use augeas). 
Not really.  We use lokkit so that when things change, there's only one
implementation that needs changing.  And this is a *good* thing.  And
augeas would be seen as a far more "one-off" dep than lokkit at this
point to most of the world.

>  2) Look to break up system-config-firewall-tui so that lokkit is a 
>  separate package with less dependencies. 
The big dep that looks trimmable is rhpl as it's just used for
translation stuff (... and I want to get things off of using
rhpl.translate and just using the gettext module directly anyway).
There's not really anything else which is even feasible to remove

Jeremy

[Bryan Kearney]

Jeremy Katz wrote:
>  On Thu, 2008-08-28 at 08:44 -0400, Bryan Kearney wrote:
> > The F9 version of livecd-tools usese /usr/sbin/lokkit to enable and 
> > disable the firewall. There is a FIXME near it to suport the rest of the 
> > options which lokkit takes. The current implementation executes this in 
> > the chroot environment, so forces several packages to be deployed into 
> > the image when it is built. Since I would be curious in reducing the 
> > package set for the images which are built, I am curious if there are 
> > plans around any of the following:
> >
> > 1) Remove the use of lokkit and instead directly manipulate the files 
> > (or perhaps use augeas).
>  
>  Not really.  We use lokkit so that when things change, there's only one
>  implementation that needs changing.  And this is a *good* thing.  And
>  augeas would be seen as a far more "one-off" dep than lokkit at this
>  point to most of the world. 
I can understand that... and I expected that was the reason. And I 
assume since the whole hting is done in the chroot, it would be 
difficult to move this part out of the chroot?

>  
> > 2) Look to break up system-config-firewall-tui so that lokkit is a 
> > separate package with less dependencies.
>  
>  The big dep that looks trimmable is rhpl as it's just used for
>  translation stuff (... and I want to get things off of using
>  rhpl.translate and just using the gettext module directly anyway).
>  There's not really anything else which is even feasible to remove 
I scanend it, and if all you need is lokkit then the following seem 
"unnecessary"

system-config-network-tui
newt
rhpl

I agree they are needed if you want the tui, but if there ware other 
config paths.. then these are not necessary.

-- bk

[Jeremy Katz]

On Thu, 2008-08-28 at 09:25 -0400, Bryan Kearney wrote:
>  Jeremy Katz wrote:
>  > On Thu, 2008-08-28 at 08:44 -0400, Bryan Kearney wrote:
>  >> The F9 version of livecd-tools usese /usr/sbin/lokkit to enable and 
>  >> disable the firewall. There is a FIXME near it to suport the rest of the 
>  >> options which lokkit takes. The current implementation executes this in 
>  >> the chroot environment, so forces several packages to be deployed into 
>  >> the image when it is built. Since I would be curious in reducing the 
>  >> package set for the images which are built, I am curious if there are 
>  >> plans around any of the following:
>  >>
>  >> 1) Remove the use of lokkit and instead directly manipulate the files 
>  >> (or perhaps use augeas).
>  > 
>  > Not really.  We use lokkit so that when things change, there's only one
>  > implementation that needs changing.  And this is a *good* thing.  And
>  > augeas would be seen as a far more "one-off" dep than lokkit at this
>  > point to most of the world.
>  
>  I can understand that... and I expected that was the reason. And I 
>  assume since the whole hting is done in the chroot, it would be 
>  difficult to move this part out of the chroot? 
Absolutely impossible.  It would require that something outside the
chroot know the details (past, present, and future) of how to configure
something inside the chroot.

>  >> 2) Look to break up system-config-firewall-tui so that
> lokkit is a 
>  >> separate package with less dependencies.
>  > 
>  > The big dep that looks trimmable is rhpl as it's just used for
>  > translation stuff (... and I want to get things off of using
>  > rhpl.translate and just using the gettext module directly anyway).
>  > There's not really anything else which is even feasible to remove
>  
>  I scanend it, and if all you need is lokkit then the following seem 
>  "unnecessary" 
[snip]
>  I agree they are needed if you want the tui, but if there ware other
>
>  config paths.. then these are not necessary. 
lokkit *IS* the tui.  Removing that would be like saying "well, let's
take out bash's interactive mode because that's not strictly necessary"
as you also use it just to run scripts

Jeremy

[Bryan Kearney]

Jeremy Katz wrote:
>  On Thu, 2008-08-28 at 09:25 -0400, Bryan Kearney wrote:
> > Jeremy Katz wrote:
> >> On Thu, 2008-08-28 at 08:44 -0400, Bryan Kearney wrote:
> >>> The F9 version of livecd-tools usese /usr/sbin/lokkit to enable and 
> >>> disable the firewall. There is a FIXME near it to suport the rest of the 
> >>> options which lokkit takes. The current implementation executes this in 
> >>> the chroot environment, so forces several packages to be deployed into 
> >>> the image when it is built. Since I would be curious in reducing the 
> >>> package set for the images which are built, I am curious if there are 
> >>> plans around any of the following:
> >>>
> >>> 1) Remove the use of lokkit and instead directly manipulate the files 
> >>> (or perhaps use augeas).
> >> Not really.  We use lokkit so that when things change, there's only one
> >> implementation that needs changing.  And this is a *good* thing.  And
> >> augeas would be seen as a far more "one-off" dep than lokkit at this
> >> point to most of the world.
> > I can understand that... and I expected that was the reason. And I 
> > assume since the whole hting is done in the chroot, it would be 
> > difficult to move this part out of the chroot?
>  
>  Absolutely impossible.  It would require that something outside the
>  chroot know the details (past, present, and future) of how to configure
>  something inside the chroot.
>  
> >>> 2) Look to break up system-config-firewall-tui so that lokkit is a 
> >>> separate package with less dependencies.
> >> The big dep that looks trimmable is rhpl as it's just used for
> >> translation stuff (... and I want to get things off of using
> >> rhpl.translate and just using the gettext module directly anyway).
> >> There's not really anything else which is even feasible to remove
> > I scanend it, and if all you need is lokkit then the following seem 
> > "unnecessary"
>  [snip]
> > I agree they are needed if you want the tui, but if there ware other 
> > config paths.. then these are not necessary.
>  
>  lokkit *IS* the tui.  Removing that would be like saying "well, let's
>  take out bash's interactive mode because that's not strictly necessary"
>  as you also use it just to run scripts 
It looks like the tui is /usr/bin/system-config-firewall-tui which 
loads /usr/share/system-config-firewall/fw_tui.py that then makes calls 
to lokkit.

So.. it seems possible to seperate out the acutal presentaiton from the 
command line (tui, gui, etc) from the execution (lokkit)

-- bk

[Daniel P. Berrange]

On Thu, Aug 28, 2008 at 09:22:13AM -0400, Jeremy Katz wrote:
>  On Thu, 2008-08-28 at 08:44 -0400, Bryan Kearney wrote:
>  > The F9 version of livecd-tools usese /usr/sbin/lokkit to enable and 
>  > disable the firewall. There is a FIXME near it to suport the rest of the 
>  > options which lokkit takes. The current implementation executes this in 
>  > the chroot environment, so forces several packages to be deployed into 
>  > the image when it is built. Since I would be curious in reducing the 
>  > package set for the images which are built, I am curious if there are 
>  > plans around any of the following:
>  > 
>  > 1) Remove the use of lokkit and instead directly manipulate the files 
>  > (or perhaps use augeas).
>  
>  Not really.  We use lokkit so that when things change, there's only one
>  implementation that needs changing.  And this is a *good* thing.  And
>  augeas would be seen as a far more "one-off" dep than lokkit at this
>  point to most of the world. 
If augeas were to be used I'd expect lokkit itself to use it directly,
rather than livecd-creator using it.

>  > 2) Look to break up system-config-firewall-tui so that lokkit is
> a 
>  > separate package with less dependencies.
>  
>  The big dep that looks trimmable is rhpl as it's just used for
>  translation stuff (... and I want to get things off of using
>  rhpl.translate and just using the gettext module directly anyway).
>  There's not really anything else which is even feasible to remove 
It is not worth worrying about rhpl. The killer piece that causes pain
for oVirt in this scenario is the presense of python. Unless that's
killable, the rest is just a rounding error.

The way we currently do it is include lokkit packages at first, and then
use a %post script to uninstall python and everything using it. Unless
someone wants to re-implement entire of lokkit in C, I don't see any 
other viable approach other than this uninstall in %post.

Daniel.
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

[Jeremy Katz]

On Thu, 2008-08-28 at 15:07 +0100, Daniel P. Berrange wrote:
>  > > 2) Look to break up system-config-firewall-tui so that
> lokkit is a 
>  > > separate package with less dependencies.
>  > 
>  > The big dep that looks trimmable is rhpl as it's just used for
>  > translation stuff (... and I want to get things off of using
>  > rhpl.translate and just using the gettext module directly anyway).
>  > There's not really anything else which is even feasible to remove
>  
>  It is not worth worrying about rhpl. The killer piece that causes pain
>  for oVirt in this scenario is the presense of python. Unless that's
>  killable, the rest is just a rounding error. 
python is going to continue to creep its way into oVirt because it's a
basic part of Fedora (and RHEL) systems.  And thus, basic parts of the
infrastructure of the system get written (and will continue to get
written) with it

>  The way we currently do it is include lokkit packages at first, and
> then
>  use a %post script to uninstall python and everything using it. Unless
>  someone wants to re-implement entire of lokkit in C, I don't see any 
>  other viable approach other than this uninstall in %post. 
The irony is that lokkit was originally written in C.  But to add all of
the functionality that people continued to want, it was rewritten in
python years ago :)

And really, the advantages that you get of being able to do things in
python far far far outweighs the amount of disk space it occupies, even
in a minimal environment like oVirt.

Jeremy

[Daniel P. Berrange]

On Thu, Aug 28, 2008 at 10:21:44AM -0400, Jeremy Katz wrote:
>  On Thu, 2008-08-28 at 15:07 +0100, Daniel P. Berrange wrote:
>  > The way we currently do it is include lokkit packages at first, and then
>  > use a %post script to uninstall python and everything using it. Unless
>  > someone wants to re-implement entire of lokkit in C, I don't see any 
>  > other viable approach other than this uninstall in %post.
>  
>  The irony is that lokkit was originally written in C.  But to add all of
>  the functionality that people continued to want, it was rewritten in
>  python years ago :) 
The ever increasing functionality of lokkit is incredibly a poor design
choice :-(  For libvirt to register iptables rules, SELinux policy had
to be changed to allow libvirtd to run lokkit. This has the dubious
side-effect of now giving libvirtd permission to turn off SELinux.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|