Hi Tom, Currently shorewall installs a number of files under /usr/share/shorewall which require executable permissions. As such, on SElinux enabled systems we''re having to add exceptions to allow shorewall to execute files under /usr/share. /usr/share is generally considered to be location of data needed by applications rather than executables. A better location for those files that need to be executable would be under /usr/libexec/shorewall. Executables I see under /usr/share/shorewall are: wait4ifup getparams compiler.pl Is this something you''d consider changing? I can work up a patch if you''d like. Cheers, Jonathan. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On 3/20/11 2:17 PM, Jonathan Underwood wrote:> Hi Tom, > > Currently shorewall installs a number of files under > /usr/share/shorewall which require executable permissions. As such, on > SElinux enabled systems we''re having to add exceptions to allow > shorewall to execute files under /usr/share. /usr/share is generally > considered to be location of data needed by applications rather than > executables. A better location for those files that need to be > executable would be under /usr/libexec/shorewall. Executables I see > under /usr/share/shorewall are: > > wait4ifup > getparams > compiler.pl > > Is this something you''d consider changing? I can work up a patch if you''d like.Hi Jonathan, You should be looking at 4.4.19 Beta 2 -- it allows complete flexibility as to where you install the shorewall components. So far, it covers shorewall, shorewall6, shorewall-lite and shorewall6-lite. Beta 3 will do the same for shorewall-init. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On 3/20/11 2:17 PM, Jonathan Underwood wrote:> > Is this something you''d consider changing? I can work up a patch if you''d like.I should add though that 4.4.19 Beta2 move the entire /usr/share/shorewall directory. So a patch is still needed. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On 20 March 2011 22:15, Tom Eastep <teastep@shorewall.net> wrote:> On 3/20/11 2:17 PM, Jonathan Underwood wrote: > >> >> Is this something you''d consider changing? I can work up a patch if you''d like. > > I should add though that 4.4.19 Beta2 move the entire > /usr/share/shorewall directory. So a patch is still needed.OK, looking into it. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On 20 March 2011 23:08, Jonathan Underwood <jonathan.underwood@gmail.com> wrote:> On 20 March 2011 22:15, Tom Eastep <teastep@shorewall.net> wrote: >> On 3/20/11 2:17 PM, Jonathan Underwood wrote: >> >>> >>> Is this something you''d consider changing? I can work up a patch if you''d like. >> >> I should add though that 4.4.19 Beta2 move the entire >> /usr/share/shorewall directory. So a patch is still needed. > > OK, looking into it. >OK, have posted a series of patches as a start towards this. However, my Perl skills are pretty much non-existant. Patch 05 is probably brain dead Also, moving the compiler.pl file to /usr/libexec means it won''t find the shorewall perl modules located under /usr/share/shorewall, and so a line needs adding to the top of it to be something like: use lib ''/usr/share/shorewall/Shorewall''; ... but I wasn''t sure how to achieve this without hardcoding "/usr/share/shorewall", whereas what we want to do is use $SHARE from install.sh ... Anyway, hope this is helpful. Cheers, jonathan. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On 3/20/11 5:51 PM, Jonathan Underwood wrote:> On 20 March 2011 23:08, Jonathan Underwood <jonathan.underwood@gmail.com> wrote: >> On 20 March 2011 22:15, Tom Eastep <teastep@shorewall.net> wrote: >>> On 3/20/11 2:17 PM, Jonathan Underwood wrote: >>> >>>> >>>> Is this something you''d consider changing? I can work up a patch if you''d like. >>> >>> I should add though that 4.4.19 Beta2 move the entire >>> /usr/share/shorewall directory. So a patch is still needed. >> >> OK, looking into it. >> > > OK, have posted a series of patches as a start towards this. > > However, my Perl skills are pretty much non-existant. > > Patch 05 is probably brain dead > > Also, moving the compiler.pl file to /usr/libexec means it won''t find > the shorewall perl modules located under /usr/share/shorewall, and so > a line needs adding to the top of it to be something like: > > use lib ''/usr/share/shorewall/Shorewall''; > > ... but I wasn''t sure how to achieve this without hardcoding > "/usr/share/shorewall", whereas what we want to do is use $SHARE from > install.sh ... > > Anyway, hope this is helpful.Thanks, Jonathan The Perl thing is troubling because my development process and the released code expects the modules to exist in the directory Shorewall located in the same directory as compiler.pl. I''ll work on that. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On 21 March 2011 01:29, Tom Eastep <teastep@shorewall.net> wrote:> Thanks, Jonathan > > The Perl thing is troubling because my development process and the > released code expects the modules to exist in the directory Shorewall > located in the same directory as compiler.pl. >A couple of options that occur to me: 1) Move the Shorewall perl modules such that they''re installed under a directory in the perl vendor lib location (i.e. location given by perl -V:installvendorlib which) - this would be /usr/share/perl5/Shorewall on my system. This would be placing the modules in a location already on the search path. 2) same as (1) but under perl -V:sitevendorlib (this is probably the recommended approach) 3) use the -I option when calling the compiler from the shell scripts 4) Use @INC in compile.pl to point to the directory containing the shorewall perl modules J. ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
On 3/21/11 4:49 AM, Jonathan Underwood wrote:> On 21 March 2011 01:29, Tom Eastep <teastep@shorewall.net> wrote: >> Thanks, Jonathan >> >> The Perl thing is troubling because my development process and the >> released code expects the modules to exist in the directory Shorewall >> located in the same directory as compiler.pl. >> > > A couple of options that occur to me: > 1) Move the Shorewall perl modules such that they''re installed under a > directory in the perl vendor lib location (i.e. location given by perl > -V:installvendorlib which) - this would be /usr/share/perl5/Shorewall > on my system. This would be placing the modules in a location already > on the search path. > > 2) same as (1) but under perl -V:sitevendorlib (this is probably the > recommended approach) > > 3) use the -I option when calling the compiler from the shell scripts > > 4) Use @INC in compile.pl to point to the directory containing the > shorewall perl modules > > J.Hi Jonathan, I was thinking along the lines of option 2 myself (although I think that it is ''perl -V:sitelib''). The problem with that, in my view, is that if Perl is upgraded to a new version, then the Shorewall libraries are in the wrong directory. That''s not an issue for you as you can use RPM dependencies insure that Shorewall and perl are upgraded together. But it seems like a sharp edge that users of the standalone install script can cut themselves on. The other bothersome detail about this whole thing is that Debian-based systems don''t even have a /usr/libexec/ directory. As long as I''m adding all of this installation flexibility into 4.4.19, I think I should just parameterize the location of these executable scripts so that individual distributions can put them where they want to. The defaults will remain as they are in the current installer. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d
Hi Tom, On 21 March 2011 14:26, Tom Eastep <teastep@shorewall.net> wrote:> I was thinking along the lines of option 2 myself (although I think that > it is 'perl -V:sitelib'). The problem with that, in my view, is that if > Perl is upgraded to a new version, then the Shorewall libraries are in > the wrong directory. That's not an issue for you as you can use RPM > dependencies insure that Shorewall and perl are upgraded together. But > it seems like a sharp edge that users of the standalone install script > can cut themselves on.True - though that would presumably only happen for a major Perl upgrade (i.e. moving from Perl 5 to Perl 6) where compatibility is probably not guaranteed. So in the case, I'd probably expect that the perl 5 compiler would still be available on the system.> > The other bothersome detail about this whole thing is that Debian-based > systems don't even have a /usr/libexec/ directory.Hm, right, yes I see. I think with the patches I sent, one could accommodate that by either setting LIBEXEC=SHARE (recovering the old behaviour), or, perhaps more correctly on Debian systems setting LIBEXEC=/usr/lib. Certainly, googling suggests that the stuff redhat-esque systems put in /usr/libexec, Debian-esque systems drop into /usr/lib rather than /usr/share.> > As long as I'm adding all of this installation flexibility into 4.4.19, > I think I should just parameterize the location of these executable > scripts so that individual distributions can put them where they want > to.Right - I think/hope that's what the LIBEXEC stuff did in the patches I sent.> The defaults will remain as they are in the current installer. >Right, so default to LIBEXEC=/usr/share (=SHARE) rather than /usr/libexec in the patches I sent. I am fine and happy with that, as I can still easily change it for the Fedora/EPEL packages. Cheers, Jonathan.> -Tom > -- > Tom Eastep \ When I die, I want to go like my Grandfather who > Shoreline, \ died peacefully in his sleep. Not screaming like > Washington, USA \ all of the passengers in his car > http://shorewall.net \________________________________________________ > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel > >------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
> On 3/21/11 4:49 AM, Jonathan Underwood wrote: >> On 21 March 2011 01:29, Tom Eastep <teastep@shorewall.net> wrote: >>> Thanks, Jonathan >>> >>> The Perl thing is troubling because my development process and the >>> released code expects the modules to exist in the directory Shorewall >>> located in the same directory as compiler.pl. >>> >> >> A couple of options that occur to me: >> 1) Move the Shorewall perl modules such that they''re installed under a >> directory in the perl vendor lib location (i.e. location given by perl >> -V:installvendorlib which) - this would be /usr/share/perl5/Shorewall >> on my system. This would be placing the modules in a location already >> on the search path. >> >> 2) same as (1) but under perl -V:sitevendorlib (this is probably the >> recommended approach) >> >> 3) use the -I option when calling the compiler from the shell scripts >> >> 4) Use @INC in compile.pl to point to the directory containing the >> shorewall perl modules >> >> J. > > Hi Jonathan, > > I was thinking along the lines of option 2 myself (although I think that > it is ''perl -V:sitelib''). The problem with that, in my view, is that if > Perl is upgraded to a new version, then the Shorewall libraries are in > the wrong directory. That''s not an issue for you as you can use RPM > dependencies insure that Shorewall and perl are upgraded together. But > it seems like a sharp edge that users of the standalone install script > can cut themselves on. > > The other bothersome detail about this whole thing is that Debian-based > systems don''t even have a /usr/libexec/ directory.According to Linux FHS /usr/libexec is not to be used anymore despite the fact that RedHat based distributions still use it widely. The 32/64bit mess, which led to /usr/lib64, has also helped to keep libexec around. Therefore I suggest to simply change /usr/libexec to /usr/lib, which is more in line with Debian and also accepted in this situation (no arch dependant libs) for RedHat based systems. Regards, Simon ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d