Beta 3 is now available for testing.
Problems Corrected:
1) The generated firewall script generates code to automatically
create ipsets that a referenced but that don''t exist. That code was
broken in releases 4.4.22 and later. That defect has been
corrected. As part of this fix, the generated script will now
issue a warning message when it creates an ipset.
2) Nested TC classes could result in Perl diagnostics like this one:
Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in
numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042,
<$currentfile> line 13.
These harmless messages have been eliminated.
3) It is once again possible to omit the minimum length in the LENGTH
column of the tcrules file.
4) Under the following conditions, a compiler internal error was
raised:
- Extended conntrack match support is available.
- Repeat Match is not available.
- A DNAT rule specifies a destination port, a server port and
an original destination.
New Features:
5) The evolution of the Shorewall installation process
continues. Testers are invited to provide comments and suggestions
about the following.
Note: This feature has only been tested lightly but I need your help. I
plan several Betas to insure that this works when released to the
user population.
Beginning with this release, the installers accept a configuration
file as a parameter. Options set in the configuration file are as
follows:
BUILD (optional) -- Platform on which the installation is being
performed. Possible values are:
apple - OS X
archlinux - ArchLinux
cygwin - Cygwin running under Windows
debian - Debian and derivatives
linux - Generic Linux system
redhat - Fedora, RHEL and derivatives
suse - SLES and OpenSuSE
If no value is assigned, then the installer
will detect the platform.
HOST (Optional) -- Allowed values are same as for BUILD. If not
specified, the BUILD setting is used.
CONFDIR (Req''d) -- Directory where product configuration
directory is installed. Normally /etc.
SHAREDIR (Req''d) -- Directory where architecture-independent
product files are installed. Normally
/usr/share.
LIBEXECDIR (Req''d) -- Directory where product executables are
installed. Normally /usr/share or
/usr/libexec.
PERLLIBDIR (Req''d) -- Directory where Shorewall Perl modules are
to be installed. Traditionally
/usr/share/shorewall.
SBINDIR (Req''d) -- Directory where product CLI programs are
installed. Normally /sbin
MANDIR (Req.d) -- Directory where manpages are
installed. Mornally /usr/share/man.
INITFILE (Optional)
-- Optional. If given, specifies the installed
filename of the initscript. Normally
set to $PRODUCT which the installers expand
to the name of the product being installed.
If not specified, no init script will be
installed.
INITSOURCE (Optional)
-- Must be specified if INITFILE is specified.
Gives the name of the file to be installed
as the INITFILE.
INITDIR (Optional) -- Directory where SysV init scripts are
installed. Must be specified if INITFILE is
specified.
ANNOTATED (Optional)
-- If non-empty, indicates that the
configuration files are to be annotated with
manpage information. Normally empty.
SYSTEMD (Optional) -- Name of the directory where .service files
are to be installed. Should only be specified
on systems running systemd.
SYSCONFDIR (Optional)
-- Name of the directory where subsystem
init configuration information is stored.
On Debian and derivates, this is
/etc/default. On other systems, it is
/etc/sysconfig.
SYSCONFFILE (Optional)
-- Name of the file to be installed in the
SYSCONFIGDIR. The installed name of the file
will always be the product name (shorewall,
shorewall-lite, etc.)
SPARSE (Optional) -- If non-empty, causes only the .conf file to
be installed in
${CONFDIR}/${PRODUCT}/. Otherwise, all of
the product''s skeleton configuration files
will be installed.
VARDIR (Required) -- Directory where product state information
is stored. Normally /var/lib.
This setting was previously stored in the
optional vardir file in the product''s
configuration directory.
Each of the product tarballs contains a set of configuration files
for the various HOSTS:
shorewallrc.apple
shorewallrc.archlinux
shorewallrc.cygwin
shorewallrc.debian
shorewallrc.default (for HOST ''linux'')
shorewallrc.redhat
shorewallrc.suse
The .spec files have been modified to use shorewallrc.%{_vendor}
as the configuration file for installation. To create a totally
custom installation, you can pick the file that comes closest to
what you want and modify it.
When Shorewall-core is installed on a system (with no PREFIX or
DESTDIR), it copies the specified configuration file into
root''s ~/.shorewallrc. The ~/.shorewallrc file is then used, by
default, when installing the other packages. It is also used by the
CLI programs and the rules compiler to locate the installed files.
Note: For Shorewall-lite and Shorewall6-lite, the ~/.shorewallrc
file on the Firewall system determines where the components are
installed.
The configuration file is also installed in
${SHAREDIR}/shorewall/shorewallrc, thus allowing users other than
root to copy this file to $HOME/.shorewallrc.
Thank you for testing.
-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 \________________________________________________
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
Trying Shorewall 4.5.2 Beta 3 on centos and i got this installing the RPM cp: cannot stat `shorewallrc.suse'': No such file or directory Non-fatal POSTIN scriptlet failure in rpm package shorewall-core-4.5.2-0Beta3.noarch error: %post(shorewall-core-4.5.2-0Beta3.noarch) scriptlet failed, exit status 1 I got an error message then trying to stop shorewall - /etc/rc.d/init.d/shorewall: line 57: syntax error near unexpected token `&'' /etc/rc.d/init.d/shorewall: line 57: ` echo "Usage: $0 start|stop|reload|restart|status" > &2'' Which may be related to the install not being completed. neal On Sun, Mar 25, 2012 at 8:12 PM, Tom Eastep <teastep@shorewall.net> wrote:> Beta 3 is now available for testing. > > Problems Corrected: > > 1) The generated firewall script generates code to automatically > create ipsets that a referenced but that don''t exist. That code was > broken in releases 4.4.22 and later. That defect has been > corrected. As part of this fix, the generated script will now > issue a warning message when it creates an ipset. > > 2) Nested TC classes could result in Perl diagnostics like this one: > > Mar 24 22:42:14 dmz1 shorewall[839]: Use of uninitialized value in > numeric eq (==) at /usr/share/perl5/Shorewall/Tc.pm line 1042, > <$currentfile> line 13. > > These harmless messages have been eliminated. > > 3) It is once again possible to omit the minimum length in the LENGTH > column of the tcrules file. > > 4) Under the following conditions, a compiler internal error was > raised: > > - Extended conntrack match support is available. > - Repeat Match is not available. > - A DNAT rule specifies a destination port, a server port and > an original destination. > > New Features: > > 5) The evolution of the Shorewall installation process > continues. Testers are invited to provide comments and suggestions > about the following. > > Note: This feature has only been tested lightly but I need your help. I > plan several Betas to insure that this works when released to the > user population. > > Beginning with this release, the installers accept a configuration > file as a parameter. Options set in the configuration file are as > follows: > > BUILD (optional) -- Platform on which the installation is being > performed. Possible values are: > > apple - OS X > archlinux - ArchLinux > cygwin - Cygwin running under Windows > debian - Debian and derivatives > linux - Generic Linux system > redhat - Fedora, RHEL and derivatives > suse - SLES and OpenSuSE > > If no value is assigned, then the installer > will detect the platform. > > HOST (Optional) -- Allowed values are same as for BUILD. If not > specified, the BUILD setting is used. > > CONFDIR (Req''d) -- Directory where product configuration > directory is installed. Normally /etc. > > SHAREDIR (Req''d) -- Directory where architecture-independent > product files are installed. Normally > /usr/share. > > LIBEXECDIR (Req''d) -- Directory where product executables are > installed. Normally /usr/share or > /usr/libexec. > > PERLLIBDIR (Req''d) -- Directory where Shorewall Perl modules are > to be installed. Traditionally > /usr/share/shorewall. > > SBINDIR (Req''d) -- Directory where product CLI programs are > installed. Normally /sbin > > MANDIR (Req.d) -- Directory where manpages are > installed. Mornally /usr/share/man. > > INITFILE (Optional) > -- Optional. If given, specifies the installed > filename of the initscript. Normally > set to $PRODUCT which the installers expand > to the name of the product being installed. > If not specified, no init script will be > installed. > > INITSOURCE (Optional) > -- Must be specified if INITFILE is specified. > Gives the name of the file to be installed > as the INITFILE. > > INITDIR (Optional) -- Directory where SysV init scripts are > installed. Must be specified if INITFILE is > specified. > > ANNOTATED (Optional) > -- If non-empty, indicates that the > configuration files are to be annotated with > manpage information. Normally empty. > > SYSTEMD (Optional) -- Name of the directory where .service files > are to be installed. Should only be specified > on systems running systemd. > > SYSCONFDIR (Optional) > -- Name of the directory where subsystem > init configuration information is stored. > On Debian and derivates, this is > /etc/default. On other systems, it is > /etc/sysconfig. > > SYSCONFFILE (Optional) > -- Name of the file to be installed in the > SYSCONFIGDIR. The installed name of the file > will always be the product name (shorewall, > shorewall-lite, etc.) > > SPARSE (Optional) -- If non-empty, causes only the .conf file to > be installed in > ${CONFDIR}/${PRODUCT}/. Otherwise, all of > the product''s skeleton configuration files > will be installed. > > VARDIR (Required) -- Directory where product state information > is stored. Normally /var/lib. > > This setting was previously stored in the > optional vardir file in the product''s > configuration directory. > > Each of the product tarballs contains a set of configuration files > for the various HOSTS: > > shorewallrc.apple > shorewallrc.archlinux > shorewallrc.cygwin > shorewallrc.debian > shorewallrc.default (for HOST ''linux'') > shorewallrc.redhat > shorewallrc.suse > > The .spec files have been modified to use shorewallrc.%{_vendor} > as the configuration file for installation. To create a totally > custom installation, you can pick the file that comes closest to > what you want and modify it. > > When Shorewall-core is installed on a system (with no PREFIX or > DESTDIR), it copies the specified configuration file into > root''s ~/.shorewallrc. The ~/.shorewallrc file is then used, by > default, when installing the other packages. It is also used by the > CLI programs and the rules compiler to locate the installed files. > > Note: For Shorewall-lite and Shorewall6-lite, the ~/.shorewallrc > file on the Firewall system determines where the components are > installed. > > The configuration file is also installed in > ${SHAREDIR}/shorewall/shorewallrc, thus allowing users other than > root to copy this file to $HOME/.shorewallrc. > > Thank you for testing. > > -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 \________________________________________________ > > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel >-- (\(\ That''s odd. That''s very odd. (^.^) Wouldn''t you say that''s very odd? (")") -------- When the going gets weird, the weird turn pro. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/26/2012 04:48 AM, Neal Thomsen wrote:> Trying Shorewall 4.5.2 Beta 3 on centos and i got this installing the RPM > > cp: cannot stat `shorewallrc.suse'': No such file or directory > Non-fatal POSTIN scriptlet failure in rpm package > shorewall-core-4.5.2-0Beta3.noarch > error: %post(shorewall-core-4.5.2-0Beta3.noarch) scriptlet failed, exit > status 1 > > I got an error message then trying to stop shorewall - > > /etc/rc.d/init.d/shorewall: line 57: syntax error near unexpected token `&'' > /etc/rc.d/init.d/shorewall: line 57: ` echo "Usage: $0 > start|stop|reload|restart|status" > &2'' > > Which may be related to the install not being completed. >Please do two things: 1) Replace /etc/rc.d/init.d/shorewall with the attached file (retain the filename ''shorewall''). 2) cp /usr/share/shorewall/shorewallrc ~/.shorewallrc -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> > Please do two things: > > 1) Replace /etc/rc.d/init.d/shorewall with the attached file (retain the > filename ''shorewall''). > > 2) cp /usr/share/shorewall/shorewallrc ~/.shorewallrc > > -Tom >Okay, I did those two things and when I try to stop/start/restart i get this: [root@cahpwww ~]# /etc/rc.d/init.d/shorewall stop /etc/rc.d/init.d/shorewall: line 93: /shorewall: No such file or directory /etc/rc.d/init.d/shorewall: line 93: exec: /shorewall: cannot execute: No such file or directory or line 87,90 depending... neal ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/26/2012 07:20 AM, Neal Thomsen wrote:> Please do two things: > > 1) Replace /etc/rc.d/init.d/shorewall with the attached file (retain the > filename ''shorewall''). > > 2) cp /usr/share/shorewall/shorewallrc ~/.shorewallrc > > -Tom > > > Okay, I did those two things and when I try to stop/start/restart i get > this: > > [root@cahpwww ~]# /etc/rc.d/init.d/shorewall stop > /etc/rc.d/init.d/shorewall: line 93: /shorewall: No such file or directory > /etc/rc.d/init.d/shorewall: line 93: exec: /shorewall: cannot execute: > No such file or directory > > or line 87,90 depending...This should fix you up. -Tom PS -- All of my testing so far has been on Debian so the other distros are likely to encounter these sorts of issues. -- 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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
Well that''s better! But this happens now: [root@cahpwww temp]# /etc/rc.d/init.d/shorewall stop ERROR: Shorewall has never been started [root@cahpwww temp]# /etc/rc.d/init.d/shorewall restart Compiling... Shorewall configuration compiled to /var/lib/.restart Restarting Shorewall.... done. [root@cahpwww temp]# /etc/rc.d/init.d/shorewall stop ERROR: Shorewall has never been started [root@cahpwww temp]# /etc/rc.d/init.d/shorewall start Shorewall is already running [root@cahpwww temp]# /sbin/shorewall status Shorewall-4.5.2-Beta3 Status at cahpwww.vet.upenn.edu - Mon Mar 26 10:35:30 EDT 2012 Shorewall is running State:Unknown neal On Mon, Mar 26, 2012 at 10:28 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 03/26/2012 07:20 AM, Neal Thomsen wrote: > > Please do two things: > > > > 1) Replace /etc/rc.d/init.d/shorewall with the attached file (retain > the > > filename ''shorewall''). > > > > 2) cp /usr/share/shorewall/shorewallrc ~/.shorewallrc > > > > -Tom > > > > > > Okay, I did those two things and when I try to stop/start/restart i get > > this: > > > > [root@cahpwww ~]# /etc/rc.d/init.d/shorewall stop > > /etc/rc.d/init.d/shorewall: line 93: /shorewall: No such file or > directory > > /etc/rc.d/init.d/shorewall: line 93: exec: /shorewall: cannot execute: > > No such file or directory > > > > or line 87,90 depending... > > This should fix you up. > > -Tom > > PS -- All of my testing so far has been on Debian so the other distros > are likely to encounter these sorts of issues. > > -- > 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 \________________________________________________ > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel > >-- (\(\ That''s odd. That''s very odd. (^.^) Wouldn''t you say that''s very odd? (")") -------- When the going gets weird, the weird turn pro. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> 1) The generated firewall script generates code to automatically > create ipsets that a referenced but that don''t exist. That code was > broken in releases 4.4.22 and later. That defect has been > corrected. As part of this fix, the generated script will now > issue a warning message when it creates an ipset. >Would that always be the case (getting ipset warnings, that is)?> 5) The evolution of the Shorewall installation process > continues. Testers are invited to provide comments and suggestions > about the following. > > [...] > > > Each of the product tarballs contains a set of configuration files > for the various HOSTS: > > shorewallrc.apple > shorewallrc.archlinux > shorewallrc.cygwin > shorewallrc.debian > shorewallrc.default (for HOST ''linux'') > shorewallrc.redhat > shorewallrc.suse >This is quite impressive, I have to say! A couple of questions/suggestions though: 1. Is this the complete list of all directories shorewall installation/use/removal is dependent on? If so, I''d suggest that you add another one - TMPDIR. This may look a bit odd, but on read-only root systems where /tmp or /var/tmp is usually read-only, if I have shorewall lite (and derivatives), the firewall script refuses to run, simply because the shell needs a temporary directory, which is read-write and not read-only. I can dig up the exact error message I was getting if you wish. By (re)defining TMPDIR, this issue is resolved (this is what I do on my side when producing firewall and firewall.conf - I execute a "sed -i" replacement to add/readjust TMPDIR to a read-write path, which can then be used).> The .spec files have been modified to use shorewallrc.%{_vendor} > as the configuration file for installation. To create a totally > custom installation, you can pick the file that comes closest to > what you want and modify it. >2. Provided the directory list you included in your announcement is complete, then for distro-specific builds, who use packaging system (rpm etc) I would make the same suggestion as I did a while ago: use a "configure". Why? Because by inserting "%configure" in the .spec file (note the percentage sign - this is quite different from just "configure" or "./configure"!), you are triggering a distro-specific macro, which executes "configure" in the BUILD directory (where the shorewall product is to be build) *and* passes all (or the majority) of the above-listed directories to that script as standard, so that these may be omitted. That "configure" script can then use these parameters and build the shorewallrc.<distro> file and proceed with the installation/build up. In that way, shorewall will be getting the latest directories used by a given distro (your shorewallrc.<distro> may be outdated!) and these can be used to build shorewall. The actual "configure" script file is quite basic and its only function is to pick up all command-line parameters passed to it, strip the leading "--" passed by the distro-specific macro, and then create the shorewallrc.<distro> file and that is it. In other words, at least in case of Fedora''s RPM, by just adding "%configure" (no parameters!) in the .spec file this is *automatically* translated by the Fedora''s RPM system to: "configure --build=YY --host-=YY --disable-dependency-tracking --sbindir=XX --sysconfdir=XX --bindir=XX --includedir=XX --program-prefix=XX --perl-lib=XX --mandir=XX --libdir=XX --infodir=XX --localstatedir =XX--datadir=XX --exec-prefix=XX --destdir=XX --initdir=XX --libexecdir=XX --prefix=XX --sharedstatedir=XX" Where XX is the appropriate distro-specific path used when %configure is executed, YY is the build/host tuple (again, determined by the distro used). So, by creating a simple "configure" shell script, similar to the one I am attaching, you can pick up all those distro-specific directories without much hassle! Nothing is stopping you from adding additional command line parameters to that "%configure" macro, like BUILD, TARGET (even "%{_vendor}" if you wish ;-) ) etc. Once the configure shell script has done its job and you have a definite list of all directories (saved in a separate file for example) then install.sh can be invoked in the usual way. The configure shell script I am attaching has more than you need (it has "pretty-printing" for example, which isn''t strictly required), but I could help you refine it if you are willing to go this way - just let me know.> When Shorewall-core is installed on a system (with no PREFIX or > DESTDIR), it copies the specified configuration file into > root''s ~/.shorewallrc. The ~/.shorewallrc file is then used, by > default, when installing the other packages. It is also used by the > CLI programs and the rules compiler to locate the installed files. > > Note: For Shorewall-lite and Shorewall6-lite, the ~/.shorewallrc > file on the Firewall system determines where the components are > installed. >So, to be clear: shorewall-lite (and derivatives) *always* use "~/.shorewallrc" to find out what was installed where, is that right? Is this also valid for all shorewall products? Regardless, I think that''s wrong - what if I do not have a home directory defined, what happens then? Also, what if the root (/) is read-only (which means /root could also be read-only)? I think you should not assume any pre-defined directory in advance at all. What I think you should do (in order of preference!) is look for .shorewallrc in: 1. Current directory 2. Root home (/root) 3. Root (/) 4. Current user home (*if* HOME is defined) 5. Environment variable called SHOREWALLRC_HOME I am also assuming that shorewallrc (I think it is better if you call this file .shorewallrc, don''t you think?) is going to be used when I want to uninstall shorewall, is that right? It would be a complete waste otherwise.> Thank you for testing. >One last thing: Am I right in thinking that all programs used by shorewall (no matter what shorewall product is used/installed) are listed/defined in shorewall.conf? If so, I have a suggestion for you to add one more - ID (for the id program). ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/26/12 7:36 AM, "Neal Thomsen" <skip1952@gmail.com> wrote:> Well that''s better! But this happens now: > > [root@cahpwww temp]# /etc/rc.d/init.d/shorewall stop > ERROR: Shorewall has never been started > [root@cahpwww temp]# /etc/rc.d/init.d/shorewall restart > Compiling... > Shorewall configuration compiled to /var/lib/.restart > Restarting Shorewall.... > done. > [root@cahpwww temp]# /etc/rc.d/init.d/shorewall stop > ERROR: Shorewall has never been started > [root@cahpwww temp]# /etc/rc.d/init.d/shorewall start > Shorewall is already running > > [root@cahpwww temp]# /sbin/shorewall status > Shorewall-4.5.2-Beta3 Status at cahpwww.vet.upenn.edu > <http://cahpwww.vet.upenn.edu> - Mon Mar 26 10:35:30 EDT 2012 > > Shorewall is running > State:UnknownI suggest that you wait for Beta 4 then. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On Mon, Mar 26, 2012 at 11:11 AM, Tom Eastep <teastep@shorewall.net> wrote:> On 3/26/12 7:36 AM, "Neal Thomsen" <skip1952@gmail.com> wrote: > > Well that''s better! But this happens now: > > [root@cahpwww temp]# /etc/rc.d/init.d/shorewall stop > ERROR: Shorewall has never been started > [root@cahpwww temp]# /etc/rc.d/init.d/shorewall restart > Compiling... > Shorewall configuration compiled to /var/lib/.restart > Restarting Shorewall.... > done. > [root@cahpwww temp]# /etc/rc.d/init.d/shorewall stop > ERROR: Shorewall has never been started > [root@cahpwww temp]# /etc/rc.d/init.d/shorewall start > Shorewall is already running > > [root@cahpwww temp]# /sbin/shorewall status > Shorewall-4.5.2-Beta3 Status at cahpwww.vet.upenn.edu - Mon Mar 26 > 10:35:30 EDT 2012 > > Shorewall is running > State:Unknown > > > I suggest that you wait for Beta 4 then. > > -Tom > You do not need a parachute to skydive. You only need a parachute to > skydive twice. > >Ok! thanks neal ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/26/12 7:48 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> 1) The generated firewall script generates code to automatically >> create ipsets that a referenced but that don''t exist. That code was >> broken in releases 4.4.22 and later. That defect has been >> corrected. As part of this fix, the generated script will now >> issue a warning message when it creates an ipset. >> >Would that always be the case (getting ipset warnings, that is)?Yes.> >> 5) The evolution of the Shorewall installation process >> continues. Testers are invited to provide comments and suggestions >> about the following. >> >> [...] >> >> >> Each of the product tarballs contains a set of configuration files >> for the various HOSTS: >> >> shorewallrc.apple >> shorewallrc.archlinux >> shorewallrc.cygwin >> shorewallrc.debian >> shorewallrc.default (for HOST ''linux'') >> shorewallrc.redhat >> shorewallrc.suse >> >This is quite impressive, I have to say! A couple of >questions/suggestions though: > >1. Is this the complete list of all directories shorewall >installation/use/removal is dependent on? If so, I''d suggest that you >add another one - TMPDIR. > >This may look a bit odd, but on read-only root systems where /tmp or >/var/tmp is usually read-only, if I have shorewall lite (and >derivatives), the firewall script refuses to run, simply because the >shell needs a temporary directory, which is read-write and not >read-only. I can dig up the exact error message I was getting if you >wish. By (re)defining TMPDIR, this issue is resolved (this is what I do >on my side when producing firewall and firewall.conf - I execute a "sed >-i" replacement to add/readjust TMPDIR to a read-write path, which can >then be used).I''m not finding TMPDIR in the Shorewall source tree.> >> The .spec files have been modified to use shorewallrc.%{_vendor} >> as the configuration file for installation. To create a totally >> custom installation, you can pick the file that comes closest to >> what you want and modify it. >> >2. Provided the directory list you included in your announcement is >complete, then for distro-specific builds, who use packaging system (rpm >etc) I would make the same suggestion as I did a while ago: use a >"configure". Why?...> >So, by creating a simple "configure" shell script, similar to the one I >am attaching, you can pick up all those distro-specific directories >without much hassle! Nothing is stopping you from adding additional >command line parameters to that "%configure" macro, like BUILD, TARGET >(even "%{_vendor}" if you wish ;-) ) etc. Once the configure shell >script has done its job and you have a definite list of all directories >(saved in a separate file for example) then install.sh can be invoked in >the usual way. > >The configure shell script I am attaching has more than you need (it has >"pretty-printing" for example, which isn''t strictly required), but I >could help you refine it if you are willing to go this way - just let me >know.Thanks. It looks straight forward, although requires bash (declare -A is a bash-ism).> >> When Shorewall-core is installed on a system (with no PREFIX or >> DESTDIR), it copies the specified configuration file into >> root''s ~/.shorewallrc. The ~/.shorewallrc file is then used, by >> default, when installing the other packages. It is also used by the >> CLI programs and the rules compiler to locate the installed files. >> >> Note: For Shorewall-lite and Shorewall6-lite, the ~/.shorewallrc >> file on the Firewall system determines where the components are >> installed. >> >So, to be clear: shorewall-lite (and derivatives) *always* use >"~/.shorewallrc" to find out what was installed where, is that right?Yes.>Is >this also valid for all shorewall products?Yes.>Regardless, I think that''s >wrong - what if I do not have a home directory defined, what happens >then? Also, what if the root (/) is read-only (which means /root could >also be read-only)? > >I think you should not assume any pre-defined directory in advance at >all. What I think you should do (in order of preference!) is look for >.shorewallrc in: > >1. Current directory >2. Root home (/root) >3. Root (/) >4. Current user home (*if* HOME is defined) >5. Environment variable called SHOREWALLRC_HOMEOkay.> >I am also assuming that shorewallrc (I think it is better if you call >this file .shorewallrc, don''t you think?)It is called .shorewallrc> is going to be used when I >want to uninstall shorewall, is that right? It would be a complete waste >otherwise.Yes> >> Thank you for testing. >> >One last thing: Am I right in thinking that all programs used by >shorewall (no matter what shorewall product is used/installed) are >listed/defined in shorewall.conf? If so, I have a suggestion for you to >add one more - ID (for the id program).Okay -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/26/12 7:48 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >In other words, at least in case of Fedora''s RPM, by just adding >"%configure" (no parameters!) in the .spec file this is *automatically* >translated by the Fedora''s RPM system to: > >"configure --build=YY --host-=YY --disable-dependency-tracking >--sbindir=XX --sysconfdir=XX --bindir=XX --includedir=XX >--program-prefix=XX --perl-lib=XX --mandir=XX --libdir=XX --infodir=XX >--localstatedir =XX--datadir=XX --exec-prefix=XX --destdir=XX >--initdir=XX --libexecdir=XX --prefix=XX --sharedstatedir=XX" > >Where XX is the appropriate distro-specific path used when %configure is >executed, YY is the build/host tuple (again, determined by the distro >used).Unfortunately, the build/host tuples aren''t useful to the Shorewall installer. That''s why the current .spec files are using %{_vendor} which doesn''t seem to be passed to configure. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
>> Would that always be the case (getting ipset warnings, that is)? >> > > Yes. >So the choice is either fill in my syslog with meaningless warnings or not have warnings at all (provided there is an option to shut it up)?> I''m not finding TMPDIR in the Shorewall source tree. >There isn''t any and that is the problem. (b)ash assumes it is /tmp and then looks in /var/tmp. If both are read-only it bails out. If TMPDIR is set (as environment variable) and provided this directory is read-write (b)ash is quite happy to continue and execute the firewall script. That is why I am currently patching the resultant "firewall" file to include "export TMPDIR=<whatever>"> Thanks. It looks straight forward, although requires bash (declare -A is a > bash-ism). >I wouldn''t know about that :-P The array''s purpose is to weed out variables/parameters specified more than once. Fedora''s RPM implementation in particular has a very nasty bug, which assumes that my tuple is "<arch>-unknown-linux-gnu", which is a complete shambles of course, so in all my .spec files, I am using an additional --host/--target parameters, which I pass to configure so that I have the right tuple in them (<arch>-redhat-linux-gnu). As a result of that, when I execute "%configure --host=<my_host_arch>-redhat-linux-gnu" for example, Fedora''s RPM translates this into: configure build=<build_arch>-unknown-linux-gnu --host=<host_arch>-unknown-linux-gnu --all-the-other-guff-goes-here --host=<my_host_arch>-redhat-linux-gnu If the above is passed on to the configure script I already attached (with the 2 repeated "--host" arguments) and my array "fix" is not used, then this would result in: BUILD=<build_arch>-unknown-linux-gnu HOST=<host_arch>-unknown-linux-gnu [...all the other guff] HOST=<my_host_arch>-redhat-linux-gnu Notice the x2 HOST. With using the array in the way I created it, if two (or more!) parameters with the same name are specified, only the last one makes it in the resultant file - all values prior to this are - quite rightly - lost. This is the whole purpose of "pass 2" in the configure script I attached. Of course shorewall is unlikely to use either --build or --host (%{_vendor} is used instead, which was a good decision), but the above serves as an example why repeated parameters are weeded out. If you don''t really care having multiple variables with the same name appearing in the resulting file, the configure script would be much more simple - let me know if that is the case.>> I think you should not assume any pre-defined directory in advance at >> all. What I think you should do (in order of preference!) is look for >> .shorewallrc in: >> >> 1. Current directory >> 2. Root home (/root) >> 3. Root (/) >> 4. Current user home (*if* HOME is defined) >> 5. Environment variable called SHOREWALLRC_HOME >> > > Okay. >You may be even more flexible and adopt a similar approach as openssh does: 1. Current directory 2. $HOME (if it exist) 3. /etc 4. /root 5. / 6. Environment variable>> is going to be used when I >> want to uninstall shorewall, is that right? It would be a complete waste >> otherwise. >> > > Yes >Than I presume uninstall.sh was adapted accordingly to take full advantage of this, right? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> Unfortunately, the build/host tuples aren''t useful to the Shorewall > installer. That''s why the current .spec files are using %{_vendor} which > doesn''t seem to be passed to configure. >All true, but as I already pointed out, you could just ignore these - this could be implemented with a slight tweak of the configure script. As I just pointed in my previous post - if having repeated variable names is not much of an eyesore for you, then the configure script would have much more simplistic look, particularly given that some of the parameters passed by the RPM system could safely be ignored. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/26/2012 02:47 PM, Mr Dash Four wrote:> > >>> Would that always be the case (getting ipset warnings, that is)? >>> >> >> Yes. >> > So the choice is either fill in my syslog with meaningless warnings or > not have warnings at all (provided there is an option to shut it up)?This is AFTER init has been processed; why would your log fill up with meaningless warnings?> >> I''m not finding TMPDIR in the Shorewall source tree. >> > There isn''t any and that is the problem. (b)ash assumes it is /tmp and > then looks in /var/tmp. If both are read-only it bails out. If TMPDIR is > set (as environment variable) and provided this directory is read-write > (b)ash is quite happy to continue and execute the firewall script. That > is why I am currently patching the resultant "firewall" file to include > "export TMPDIR=<whatever>"> >>> I think you should not assume any pre-defined directory in advance at >>> all. What I think you should do (in order of preference!) is look for >>> .shorewallrc in: >>> >>> 1. Current directory >>> 2. Root home (/root) >>> 3. Root (/) >>> 4. Current user home (*if* HOME is defined) >>> 5. Environment variable called SHOREWALLRC_HOME >>> >> >> Okay. >> > You may be even more flexible and adopt a similar approach as openssh does: > > 1. Current directory > 2. $HOME (if it exist) > 3. /etc > 4. /root > 5. / > 6. Environment variableI prefer this order with $HOME before /root since it allows my user id to have a private Shorewall configuration unrelated to root''s. I have, in fact, already implemented that order :-)> >>> is going to be used when I >>> want to uninstall shorewall, is that right? It would be a complete waste >>> otherwise. >>> >> >> Yes >> > Than I presume uninstall.sh was adapted accordingly to take full > advantage of this, right?It has been. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> This is AFTER init has been processed; why would your log fill up with > meaningless warnings? >My bad - I thought ipset warnings will always be shown. If warnings are not shown in case a given ipset exists *after* init has been processed, than I have no qualms with that approach at all - in fact, I like it. It should have been like that from the beginning. I am guessing, though, that the ''src'' and ''dst'' warnings aren''t fixed yet, right?>> You may be even more flexible and adopt a similar approach as openssh does: >> >> 1. Current directory >> 2. $HOME (if it exist) >> 3. /etc >> 4. /root >> 5. / >> 6. Environment variable >> > > I prefer this order with $HOME before /root since it allows my user id > to have a private Shorewall configuration unrelated to root''s. I have, > in fact, already implemented that order :-) >I like that as well - it feels more "natural" that way somehow.>> Than I presume uninstall.sh was adapted accordingly to take full >> advantage of this, right? >> > > It has been. >Marvellous work! What do you want me to do with configure (if anything)? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
OK, I''ve picked up on this file as it is easier for me to query/make suggestions. What do you install in the "USR" directory (you don''t have this in your announcement)? From what I can see (and I am looking at the Fedora-centric rc file as I am not that familiar with other distros), you don''t have anything installed in this directory, but use it as a base to others, in which case you don''t actually need this at all. Using directories only makes sense if you use them to install files in it, not employ them as pointers to some other directory - it is much more complicated that way, keep it simple.> LIBEXECDIR (Req''d) -- Directory where product executables are > installed. Normally /usr/share or > /usr/libexec.Do you actually need this? System executables normally go to /sbin or /usr/sbin.> SYSCONFFILE (Optional) > -- Name of the file to be installed in the > SYSCONFIGDIR. The installed name of the file > will always be the product name (shorewall, > shorewall-lite, etc.)This is defined as "SYSCONFFILE=sysconfig" in the Fedora rc. I agree with the above though - this should be the name of the product. I haven''t looked much in install.sh/deinstall.sh - just skimmed over the main shorewall install.sh file and picked up on this: # # Load packager''s settings if any # [ -f ../shorewall-pkg.config ] && . ../shorewall-pkg.config #![...] if [ -n "${DESTDIR}" -a -f ../shorewall-pkg.config ]; then . ../shorewall-pkg.config || exit 1 #! #! So, shorewall-pkg.config is sourced twice, if it exists. Why? #! file = ../shorewall-pkg.config elif [ -f ~/.shorewallrc ]; then #! Why do you reference ~/.shorewallrc and sourcing it if it exists? For what purpose? . ~/.shorewallrc || exit 1 file=~/.shorewallrc else fatal_error "No configuration file specified and ~/.shorewallrc not found" fi It is good that you thought of removing (older) shorewall installations by using absolute paths. On a separate note - I just realised that for some reason I have "/var/lib/shorewallundo_rfc1918_routing" as well as "/var/lib/shorewall/undo_rfc1918_routing" - I am still on 4.5.1. I''''l have a more thorough look tomorrow! ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/26/12 6:05 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >OK, I''ve picked up on this file as it is easier for me to query/make >suggestions. > >What do you install in the "USR" directory (you don''t have this in your >announcement)? From what I can see (and I am looking at the >Fedora-centric rc file as I am not that familiar with other distros), you >don''t have anything installed in this directory, but use it as a base to >others, in which case you don''t actually need this at all. > >Using directories only makes sense if you use them to install files in >it, not employ them as pointers to some other directory - it is much more >complicated that way, keep it simple.I had it the other way initially; then I tried to modify the rc file to install Shorewall in /opt. That''s when I added the additional variable because it made that process much easier.> >> LIBEXECDIR (Req''d) -- Directory where product executables are >> installed. Normally /usr/share or >> /usr/libexec. >Do you actually need this? System executables normally go to /sbin or >/usr/sbin.There has been a lot of discussion about this on the development list. Yes, it is needed for executables that Shorewall products run internally.> >> SYSCONFFILE (Optional) >> -- Name of the file to be installed in the >> SYSCONFIGDIR. The installed name of the file >> will always be the product name (shorewall, >> shorewall-lite, etc.) >This is defined as "SYSCONFFILE=sysconfig" in the Fedora rc. I agree with >the above though - this should be the name of the product. I haven''t >looked much in install.sh/deinstall.sh - just skimmed over the main >shorewall install.sh file and picked up on this:Some packages have a file called sysconfig that must be installed in the SYSCONFIG directory as ${SYSCONFIG}/$PRODUCT. That is why this variable is needed.> ># ># Load packager''s settings if any ># >[ -f ../shorewall-pkg.config ] && . ../shorewall-pkg.config > >#![...] > > if [ -n "${DESTDIR}" -a -f ../shorewall-pkg.config ]; then > . ../shorewall-pkg.config || exit 1 >#! >#! So, shorewall-pkg.config is sourced twice, if it exists. Why? >#! > file = ../shorewall-pkg.config > elif [ -f ~/.shorewallrc ]; then >#!>Why do you reference ~/.shorewallrc and sourcing it if it exists? For >what purpose?Think about people like me that only install from tarballs and install.sh (not all of us use packaging systems; especially those of use who develop and test Shorewall). Once the first >= 4.5.2 Shorewall-core is installed, We don''t have to worry about where we have decided to install all of the components; we just run the install.sh scripts without any argument.> . ~/.shorewallrc || exit 1 > file=~/.shorewallrc > else > fatal_error "No configuration file specified and ~/.shorewallrc not >found" > fi > >It is good that you thought of removing (older) shorewall installations >by using absolute paths. On a separate note - I just realised that for >some reason I have "/var/lib/shorewallundo_rfc1918_routing" as well as >"/var/lib/shorewall/undo_rfc1918_routing" - I am still on 4.5.1.Those are used by ''restart'' and ''stop'' processing. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
>> [USR] >> > > I had it the other way initially; then I tried to modify the rc file to > install Shorewall in /opt. That''s when I added the additional variable > because it made that process much easier. >OK, but give it a meaningful name, like "PREFIX", "EXEC_PREFIX" or "PROGRAM_PREFIX" (similar to what RPM uses for example). I still can''t understand why do you need it though - it is not directly used anywhere - it is just a part of another variable, which could be modified as well. As for "/opt" - this is what my intention is also - to see whether I could install all shorewall packages in it. That is what I intend to test next after reviewing the install/uninstall scripts.>>> LIBEXECDIR (Req''d) -- Directory where product executables are >>> installed. Normally /usr/share or >>> /usr/libexec. >>> >> Do you actually need this? System executables normally go to /sbin or >> /usr/sbin. >> > > There has been a lot of discussion about this on the development list. > Yes, it is needed for executables that Shorewall products run internally. >Well, I am subscribed to the shorewall development list and don''t remember such discussion ever taking place. Unless you mean another development list. In LIBEXECDIR, from what I could gather, you have just 2 files - compiler.pl, and, I think, getparams. Does this warrant a separate directory? Why not put this together with the other perl stuff?> Some packages have a file called sysconfig that must be installed in the > SYSCONFIG directory as ${SYSCONFIG}/$PRODUCT. That is why this variable is > needed. >I have no problems with SYSCONFIG as such - the name of the file you choose to put in that rc file (sysconfig) is different from the actual name advertised ($PRODUCT). I think it should be $PRODUCT, not "sysconfig".>> # >> # Load packager''s settings if any >> # >> [ -f ../shorewall-pkg.config ] && . ../shorewall-pkg.config >> >> #![...] >> >> if [ -n "${DESTDIR}" -a -f ../shorewall-pkg.config ]; then >> . ../shorewall-pkg.config || exit 1 >> #! >> #! So, shorewall-pkg.config is sourced twice, if it exists. Why? >> #! >>Why do you need this?>> file = ../shorewall-pkg.config >> elif [ -f ~/.shorewallrc ]; then >> #! >> > > >> Why do you reference ~/.shorewallrc and sourcing it if it exists? For >> what purpose? >> > > Think about people like me that only install from tarballs and install.sh > (not all of us use packaging systems; especially those of use who develop > and test Shorewall). Once the first >= 4.5.2 Shorewall-core is installed, > We don''t have to worry about where we have decided to install all of the > components; we just run the install.sh scripts without any argument. >Ah, I see. So, previous settings are used, if available, to install shorewall products. That needs to change though to reflect the order of priority, starting from current directory, /etc and so on - as discussed yesterday. Also, am I right in thinking that *all* shorewall products need/are dependent on shorewall-core? Another query - in all of your install.sh/uninstall.sh you use $PRODUCT. What are the possible variations on this - so far I know of "Shorewall" and "Shorewall-lite", along with their "6" counter parts, so that makes it 4 different "products". Are there any more of those? Another thing I spotted yesterday was that you have a lot of inconsistent use of "$PRODUCT" and "shorewall" hard-coded as part of directory setup in your scripts - I''ll look into this further today.>> It is good that you thought of removing (older) shorewall installations >> by using absolute paths. On a separate note - I just realised that for >> some reason I have "/var/lib/shorewallundo_rfc1918_routing" as well as >> "/var/lib/shorewall/undo_rfc1918_routing" - I am still on 4.5.1. >> > > Those are used by ''restart'' and ''stop'' processing. >This can''t be right! I have "/var/lib/shorewallundo_rfc1918_routing" (note tha absence of "/" between "shorewall" and "undo_rfc1918_routing"). This file is zero sized. I have no qualms with "/var/lib/shorewall/undo_rfc1918_routing" - that is perfectly legitimate and I know what it could be used for, but the existence of the former is a mistake, I think. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/26/2012 02:12 AM, Tom Eastep wrote:> Beta 3 is now available for testing. > > shorewallrc.apple > shorewallrc.archlinux > shorewallrc.cygwin > shorewallrc.debian > shorewallrc.default (for HOST ''linux'') > shorewallrc.redhat > shorewallrc.suseFirst great job in working to ease the installation workload. Couple of things related to shorewallrc.suse since I am the maintainer of shorewall packages in openSUSE and some thoughts in general as I am sure other packagers do have their opinion as well. shorewallrc.suse: LIBEXECDIR=${USR}/libexec is wrong there is no directory as libexec it is lib hence it should be as follows LIBEXECDIR=${USR}/lib Here are some warnings I am getting shorewall-core: install.sh: line 138: local: can only be used in a function shorewall6-lite: install.sh: line 147: local: can only be used in a function shorewall-init: install.sh: line 132: local: can only be used in a function Now apart from these changes as a whole I am not so happy about this shorewallrc.vendor approach you have made hard coded destinations and this does not fit to the previously discussed rpmmacros approach. I do not like the idea of installing the following under /usr/share/shorewall they belong to %perl_vendorlib as they are modules Shorewall/Accounting.pm Shorewall/Chains.pm Shorewall/Compiler.pm Shorewall/Config.pm Shorewall/IPAddrs.pm Shorewall/Misc.pm Shorewall/Nat.pm Shorewall/Proc.pm Shorewall/Providers.pm Shorewall/Proxyarp.pm Shorewall/Raw.pm Shorewall/Rules.pm Shorewall/Tc.pm Shorewall/Tunnels.pm Shorewall/Zones.pm I would rather go back to the 4.5.1 install and packaging routine which used the rpmmacros Togan ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 03:42 AM, Mr Dash Four wrote:> >>> [USR] >>> >> >> I had it the other way initially; then I tried to modify the rc file to >> install Shorewall in /opt. That''s when I added the additional variable >> because it made that process much easier. >> > OK, but give it a meaningful name, like "PREFIX", "EXEC_PREFIX" or > "PROGRAM_PREFIX" (similar to what RPM uses for example). I still can''t > understand why do you need it though - it is not directly used anywhere > - it is just a part of another variable, which could be modified as well.I''ve renamed it PREFIX.> > As for "/opt" - this is what my intention is also - to see whether I > could install all shorewall packages in it. That is what I intend to > test next after reviewing the install/uninstall scripts. > >>>> LIBEXECDIR (Req''d) -- Directory where product executables are >>>> installed. Normally /usr/share or >>>> /usr/libexec. >>>> >>> Do you actually need this? System executables normally go to /sbin or >>> /usr/sbin. >>> >> >> There has been a lot of discussion about this on the development list. >> Yes, it is needed for executables that Shorewall products run internally. >> > Well, I am subscribed to the shorewall development list and don''t > remember such discussion ever taking place. Unless you mean another > development list. In LIBEXECDIR, from what I could gather, you have just > 2 files - compiler.pl, and, I think, getparams. Does this warrant a > separate directory? Why not put this together with the other perl stuff?This was at the insistence of the Fedora maintainer. The Fedora release police dislike executables in /usr/share and prefer for them to go into /usr/libexec.> >> Some packages have a file called sysconfig that must be installed in the >> SYSCONFIG directory as ${SYSCONFIG}/$PRODUCT. That is why this variable is >> needed. >> > I have no problems with SYSCONFIG as such - the name of the file you > choose to put in that rc file (sysconfig) is different from the actual > name advertised ($PRODUCT). I think it should be $PRODUCT, not "sysconfig".That would create a name collision since most packages already have a file called $PRODUCT which gets installed in $SBINDIR.> >>> # >>> # Load packager''s settings if any >>> # >>> [ -f ../shorewall-pkg.config ] && . ../shorewall-pkg.config >>> >>> #![...] >>> >>> if [ -n "${DESTDIR}" -a -f ../shorewall-pkg.config ]; then >>> . ../shorewall-pkg.config || exit 1 >>> #! >>> #! So, shorewall-pkg.config is sourced twice, if it exists. Why? >>> #! >>> > Why do you need this?I don''t it''s been eliminated in Beta 4.> >>> file = ../shorewall-pkg.config >>> elif [ -f ~/.shorewallrc ]; then >>> #! >>> >> >> >>> Why do you reference ~/.shorewallrc and sourcing it if it exists? For >>> what purpose? >>> >> >> Think about people like me that only install from tarballs and install.sh >> (not all of us use packaging systems; especially those of use who develop >> and test Shorewall). Once the first >= 4.5.2 Shorewall-core is installed, >> We don''t have to worry about where we have decided to install all of the >> components; we just run the install.sh scripts without any argument. >> > Ah, I see. So, previous settings are used, if available, to install > shorewall products. That needs to change though to reflect the order of > priority, starting from current directory, /etc and so on - as discussed > yesterday.Already done.> > Also, am I right in thinking that *all* shorewall products need/are > dependent on shorewall-core?Yes. That''s been true since 4.5.0.> > Another query - in all of your install.sh/uninstall.sh you use $PRODUCT. > What are the possible variations on this - so far I know of "Shorewall" > and "Shorewall-lite", along with their "6" counter parts, so that makes > it 4 different "products". Are there any more of those?Shorewall-core and Shorewall-init.> > Another thing I spotted yesterday was that you have a lot of > inconsistent use of "$PRODUCT" and "shorewall" hard-coded as part of > directory setup in your scripts - I''ll look into this further today.Both Shorewall-core and Shorewall install files into $SHAREDIR/shorewall.> >>> It is good that you thought of removing (older) shorewall installations >>> by using absolute paths. On a separate note - I just realised that for >>> some reason I have "/var/lib/shorewallundo_rfc1918_routing" as well as >>> "/var/lib/shorewall/undo_rfc1918_routing" - I am still on 4.5.1. >>> >> >> Those are used by ''restart'' and ''stop'' processing. >> > This can''t be right! I have "/var/lib/shorewallundo_rfc1918_routing" > (note tha absence of "/" between "shorewall" and > "undo_rfc1918_routing"). This file is zero sized. I have no qualms with > "/var/lib/shorewall/undo_rfc1918_routing" - that is perfectly legitimate > and I know what it could be used for, but the existence of the former is > a mistake, I think.Indeed. Will be corrected in Beta 4. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> Now apart from these changes as a whole I am not so happy about this > shorewallrc.vendor approach you have made hard coded destinations and > this does not fit to the previously discussed rpmmacros approach. >I doubt the shorewallrc.vendor would be needed if my suggestion of adopting "%configure" (which lists most, if not all of the distro-specific directories) is adopted - shorewallrc.%{_vendor} won''t be needed then at all.> I do not like the idea of installing the following under > /usr/share/shorewall they belong to %perl_vendorlib as they are modules > > > Shorewall/Accounting.pm > Shorewall/Chains.pm > Shorewall/Compiler.pm > Shorewall/Config.pm > Shorewall/IPAddrs.pm > Shorewall/Misc.pm > Shorewall/Nat.pm > Shorewall/Proc.pm > Shorewall/Providers.pm > Shorewall/Proxyarp.pm > Shorewall/Raw.pm > Shorewall/Rules.pm > Shorewall/Tc.pm > Shorewall/Tunnels.pm > Shorewall/Zones.pm >I agree with that too.> I would rather go back to the 4.5.1 install and packaging routine which > used the rpmmacros >The "old" (busted) installation method is fraud as it has many of the directories used hard-coded, making it impossible to install any shorewall products in places where there is no package management system available (routers, smartphones, embedded devices in general comes to mind). By having the whole product packaged in a tar archive and using a simple install script to install and then uninstall/upgrade is the way to go, but then I would need to be able to specify/redefine the directories used for that installation, hence the need of an additional file (whether this is shorewall-pkg.config or .shorewallrc is a matter of debate) to store these. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 06:37 AM, Togan Muftuoglu wrote:> On 03/26/2012 02:12 AM, Tom Eastep wrote: >> Beta 3 is now available for testing. >> >> shorewallrc.apple >> shorewallrc.archlinux >> shorewallrc.cygwin >> shorewallrc.debian >> shorewallrc.default (for HOST ''linux'') >> shorewallrc.redhat >> shorewallrc.suse > > First great job in working to ease the installation workload. > Couple of things related to shorewallrc.suse since I am the maintainer > of shorewall packages in openSUSE and some thoughts in general as I am > sure other packagers do have their opinion as well. > > shorewallrc.suse: > LIBEXECDIR=${USR}/libexec is wrong there is no directory as libexec it > is lib hence it should be as follows > LIBEXECDIR=${USR}/lib > > Here are some warnings I am getting > shorewall-core: > > install.sh: line 138: local: can only be used in a function > > shorewall6-lite: > > install.sh: line 147: local: can only be used in a function > > shorewall-init: > install.sh: line 132: local: can only be used in a functionAll have been corrected in Beta 4.> > Now apart from these changes as a whole I am not so happy about this > shorewallrc.vendor approach you have made hard coded destinations and > this does not fit to the previously discussed rpmmacros approach. > > I do not like the idea of installing the following under > /usr/share/shorewall they belong to %perl_vendorlib as they are modules > > > Shorewall/Accounting.pm > Shorewall/Chains.pm > Shorewall/Compiler.pm > Shorewall/Config.pm > Shorewall/IPAddrs.pm > Shorewall/Misc.pm > Shorewall/Nat.pm > Shorewall/Proc.pm > Shorewall/Providers.pm > Shorewall/Proxyarp.pm > Shorewall/Raw.pm > Shorewall/Rules.pm > Shorewall/Tc.pm > Shorewall/Tunnels.pm > Shorewall/Zones.pm > > I would rather go back to the 4.5.1 install and packaging routine which > used the rpmmacrosAnd I''m trying to get out of the business of creating custom installers for each distribution. What I''m considering is: 1. Retain the shorewallrc.* files. They will provide default values. 2. Use a variation of Mr Dash Four''s configure script. The config file it builds will use the settings in shorewallrc.%{_vendor} as defaults and override directory settings from rpmmacros. That is necessary because the installers need information that isn''t known to rpm. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> I''ve renamed it PREFIX. >Thanks!>>>>> LIBEXECDIR (Req''d) -- Directory where product executables are >>>>> installed. Normally /usr/share or >>>>> /usr/libexec. >>>>> > This was at the insistence of the Fedora maintainer.I am sure he can read what has been posted and answer/take part in the discussion as appropriate.> The Fedora release > police dislike executables in /usr/share and prefer for them to go into > /usr/libexec. >I may be mistaken, but from what I remember in the early versions of shorewall I think those files used to be in the perl directory, wasn''t that the case?> >>> Some packages have a file called sysconfig that must be installed in the >>> SYSCONFIG directory as ${SYSCONFIG}/$PRODUCT. That is why this variable is >>> needed. >>> >>> >> I have no problems with SYSCONFIG as such - the name of the file you >> choose to put in that rc file (sysconfig) is different from the actual >> name advertised ($PRODUCT). I think it should be $PRODUCT, not "sysconfig". >> > > That would create a name collision since most packages already have a > file called $PRODUCT which gets installed in $SBINDIR. >You''ve lost me! In that Fedora rc file, you have "SYSCONFFILE=sysconfig", which gets installed in $SYSCONFDIR, so the whole file name, including the path is /etc/sysconfig/sysconfig (made of $SYSCONFDIR/$SYSCONFFILE), which I think is wrong - it should be /etc/sysconfig/shorewall, hence my suggestion "SYSCONFFILE=$PRODUCT".>> Another thing I spotted yesterday was that you have a lot of >> inconsistent use of "$PRODUCT" and "shorewall" hard-coded as part of >> directory setup in your scripts - I''ll look into this further today. >> > > Both Shorewall-core and Shorewall install files into $SHAREDIR/shorewall. >Any reason for that?>> This can''t be right! I have "/var/lib/shorewallundo_rfc1918_routing" >> (note tha absence of "/" between "shorewall" and >> "undo_rfc1918_routing"). This file is zero sized. I have no qualms with >> "/var/lib/shorewall/undo_rfc1918_routing" - that is perfectly legitimate >> and I know what it could be used for, but the existence of the former is >> a mistake, I think. >> > > Indeed. Will be corrected in Beta 4. >Are you going ahead with Beta4 or do you need additional feedback from me? To be honest, I haven''t properly looked at the install/uninstall files of all packages yet, so I am not able to judge these one way or another... ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> 1. Retain the shorewallrc.* files. They will provide default values. > > 2. Use a variation of Mr Dash Four''s configure script. The config file > it builds will use the settings in shorewallrc.%{_vendor} as > defaults and override directory settings from rpmmacros. That is > necessary because the installers need information > that isn''t known to rpm. >Am I right in thinking that the order in which various directories get pulled/set is as follows: 1. shorewallrc.%{_vendor} file in the source directory 2. .shorewallrc (installed in one of the 5 possible places on the BUILD system) 3. "%configure" + various additional parameters specified when this file is executed (this gets set in shorewall-pkg.config) So, that would mean whatever is set via "%configure"/shorewall-pkg.config takes presedence. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 08:10 AM, Mr Dash Four wrote:> >> I''ve renamed it PREFIX. >> > Thanks! > >>>>>> LIBEXECDIR (Req''d) -- Directory where product executables are >>>>>> installed. Normally /usr/share or >>>>>> /usr/libexec. >>>>>> >> This was at the insistence of the Fedora maintainer. > I am sure he can read what has been posted and answer/take part in the > discussion as appropriate. > >> The Fedora release >> police dislike executables in /usr/share and prefer for them to go into >> /usr/libexec. >> > I may be mistaken, but from what I remember in the early versions of > shorewall I think those files used to be in the perl directory, wasn''t > that the case?They are in that directory in all distributions except Fedora/RedHat.> >> >>>> Some packages have a file called sysconfig that must be installed in the >>>> SYSCONFIG directory as ${SYSCONFIG}/$PRODUCT. That is why this variable is >>>> needed. >>>> >>>> >>> I have no problems with SYSCONFIG as such - the name of the file you >>> choose to put in that rc file (sysconfig) is different from the actual >>> name advertised ($PRODUCT). I think it should be $PRODUCT, not "sysconfig". >>> >> >> That would create a name collision since most packages already have a >> file called $PRODUCT which gets installed in $SBINDIR. >> > You''ve lost me! In that Fedora rc file, you have > "SYSCONFFILE=sysconfig", which gets installed in $SYSCONFDIR, so the > whole file name, including the path is /etc/sysconfig/sysconfig (made of > $SYSCONFDIR/$SYSCONFFILE), which I think is wrong - it should be > /etc/sysconfig/shorewall, hence my suggestion "SYSCONFFILE=$PRODUCT".The installed filename is ALWAYS $PRODUCT; the installers don''t need a setting for that.> >>> Another thing I spotted yesterday was that you have a lot of >>> inconsistent use of "$PRODUCT" and "shorewall" hard-coded as part of >>> directory setup in your scripts - I''ll look into this further today. >>> >> >> Both Shorewall-core and Shorewall install files into $SHAREDIR/shorewall. >> > Any reason for that?It was done that way to retain the historical content of /usr/share/shorewall as opposed to having some files in /usr/share/shorewall and others in /usr/share/shorewall-core.> >>> This can''t be right! I have "/var/lib/shorewallundo_rfc1918_routing" >>> (note tha absence of "/" between "shorewall" and >>> "undo_rfc1918_routing"). This file is zero sized. I have no qualms with >>> "/var/lib/shorewall/undo_rfc1918_routing" - that is perfectly legitimate >>> and I know what it could be used for, but the existence of the former is >>> a mistake, I think. >>> >> >> Indeed. Will be corrected in Beta 4. >> > Are you going ahead with Beta4 or do you need additional feedback from > me? To be honest, I haven''t properly looked at the install/uninstall > files of all packages yet, so I am not able to judge these one way or > another...I''ll be releasing Beta 4 once I have the configure script doing the right thing. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 08:16 AM, Mr Dash Four wrote:> >> 1. Retain the shorewallrc.* files. They will provide default values. >> >> 2. Use a variation of Mr Dash Four''s configure script. The config file >> it builds will use the settings in shorewallrc.%{_vendor} as >> defaults and override directory settings from rpmmacros. That is >> necessary because the installers need information >> that isn''t known to rpm. >> > Am I right in thinking that the order in which various directories get > pulled/set is as follows: > > 1. shorewallrc.%{_vendor} file in the source directory > 2. .shorewallrc (installed in one of the 5 possible places on the BUILD > system) > 3. "%configure" + various additional parameters specified when this file > is executed (this gets set in shorewall-pkg.config)When building an RPM, I propose a simple two-tier scheme. - Default settings are established via shorewallrc.%{_vendor} - %configure overrides the following settings from that file: SBINDIR - from %{_sbindir} SHAREDIR - from %{_datadir} MANDIR - from %{_mandir} CONFDIR - from %{_sysconfdir} LIBEXECDIR - from %{_libexecdir} PERLLIBDIR - from %{perl_privlib} -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
>> You''ve lost me! In that Fedora rc file, you have >> "SYSCONFFILE=sysconfig", which gets installed in $SYSCONFDIR, so the >> whole file name, including the path is /etc/sysconfig/sysconfig (made of >> $SYSCONFDIR/$SYSCONFFILE), which I think is wrong - it should be >> /etc/sysconfig/shorewall, hence my suggestion "SYSCONFFILE=$PRODUCT". >> > > The installed filename is ALWAYS $PRODUCT; the installers don''t need a > setting for that. >OK, lets start again - what is the purpose of $SYSCONFFILE then? I always thought that it is the name of the file which gets installed in $SYSCONFDIR, isn''t that so? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> When building an RPM, I propose a simple two-tier scheme. > > - Default settings are established via shorewallrc.%{_vendor} > > - %configure overrides the following settings from that file: > > SBINDIR - from %{_sbindir} > SHAREDIR - from %{_datadir} > MANDIR - from %{_mandir} > CONFDIR - from %{_sysconfdir} > LIBEXECDIR - from %{_libexecdir} > PERLLIBDIR - from %{perl_privlib} >How do you know the rest of the directories won''t change? Also, how do you know I am not using, for example, a different VARDIR (specified in a separate rpm macro so that %configure picks it up), which points to a permanent storage/read-write partition, let alone the case when I might be using different PREFIX? I think you should get as much as possible from %configure and leave it at that. Fair enough, you discard .shorewallrc - makes sense since I am going to build a package, but I think "configure" (the script) should squeeze as much as possible from "%configure". I am also assuming that when %configure is executed the %{_vendor} parameter would be passed as well, is that so? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 05:57 PM, Tom Eastep wrote:> > When building an RPM, I propose a simple two-tier scheme. > > - Default settings are established via shorewallrc.%{_vendor} > > - %configure overrides the following settings from that file: > > SBINDIR - from %{_sbindir} > SHAREDIR - from %{_datadir} > MANDIR - from %{_mandir} > CONFDIR - from %{_sysconfdir} > LIBEXECDIR - from %{_libexecdir}These I have no problem> PERLLIBDIR - from %{perl_privlib}openSUSE uses %{perl_vendorlib} but as long as I can change the default that comes with your configure script I am fine with this one. Togan ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 08:57 AM, Mr Dash Four wrote:> >>> You''ve lost me! In that Fedora rc file, you have >>> "SYSCONFFILE=sysconfig", which gets installed in $SYSCONFDIR, so the >>> whole file name, including the path is /etc/sysconfig/sysconfig (made of >>> $SYSCONFDIR/$SYSCONFFILE), which I think is wrong - it should be >>> /etc/sysconfig/shorewall, hence my suggestion "SYSCONFFILE=$PRODUCT". >>> >> >> The installed filename is ALWAYS $PRODUCT; the installers don''t need a >> setting for that. >> > OK, lets start again - what is the purpose of $SYSCONFFILE then? I > always thought that it is the name of the file which gets installed in > $SYSCONFDIR, isn''t that so? >Yes. Debian ALWAYS requires such a file and all products except Shorewall-core include a default.debian file. In Shorewall-init, Redhat also requires such a file which is different from the Debian one. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 09:11 AM, Mr Dash Four wrote:> >> When building an RPM, I propose a simple two-tier scheme. >> >> - Default settings are established via shorewallrc.%{_vendor} >> >> - %configure overrides the following settings from that file: >> >> SBINDIR - from %{_sbindir} >> SHAREDIR - from %{_datadir} >> MANDIR - from %{_mandir} >> CONFDIR - from %{_sysconfdir} >> LIBEXECDIR - from %{_libexecdir} >> PERLLIBDIR - from %{perl_privlib} >> > How do you know the rest of the directories won''t change? Also, how do > you know I am not using, for example, a different VARDIR (specified in a > separate rpm macro so that %configure picks it up), which points to a > permanent storage/read-write partition, let alone the case when I might > be using different PREFIX?So let me see if I understand the big picture. - I have a %configure macro defined in my .rpmmacros that does what I want it to. - If you don''t like what mine does, you put a %configure in your .rpmmacros file that does things the way that you want. If this is what you are proposing, then do you believe that I should publish my own %configure in some form so you and other RPM builders can hack it to suit your needs? -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
>>>> You''ve lost me! In that Fedora rc file, you have >>>> "SYSCONFFILE=sysconfig", which gets installed in $SYSCONFDIR, so the >>>> whole file name, including the path is /etc/sysconfig/sysconfig (made of >>>> $SYSCONFDIR/$SYSCONFFILE), which I think is wrong - it should be >>>> /etc/sysconfig/shorewall, hence my suggestion "SYSCONFFILE=$PRODUCT". >>>> >>>> >>> The installed filename is ALWAYS $PRODUCT; the installers don''t need a >>> setting for that. >>> >>> >> OK, lets start again - what is the purpose of $SYSCONFFILE then? I >> always thought that it is the name of the file which gets installed in >> $SYSCONFDIR, isn''t that so? >> >> > > Yes. Debian ALWAYS requires such a file and all products except > Shorewall-core include a default.debian file. In Shorewall-init, Redhat > also requires such a file which is different from the Debian one. >I have no objections to exclude the use of that file (well, I do, but hear me out), I have objections to its name - according to the Fedora rc, this file would be called "sysconfig" and will be installed in /etc/sysconfig, so the whole path would be /etc/sysconfig/sysconfig, which is, quite frankly ridiculous! The default value of SYSCONFFILE should be either plain old "shorewall" or "$PRODUCT", but definitely not "sysconfig", so that, when installed the whole path would be /etc/sysconfig/shorewall or /etc/sysconfig/$PRODUCT. Do you understand now? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> So let me see if I understand the big picture. > > - I have a %configure macro defined in my .rpmmacros that does what I > want it to. >No, no, no! You don''t define any %configure macros at all - they are already installed by the distro on your machine - that is the beauty of it all, the "%configure" is already there, you don''t have to do a thing! It has all the "default" directories there as determined by that distro - being Fedora SUSE etc. As soon as you trigger "%configure" the whole lot is completed for you and control is passed to an executable file (script) in the BUILD directory. You read the various parameters there, weed out what you don''t need etc and write this to shorewall-pkg.config or whatever name you decide to use, so that install.sh can pick it up later and do its magic.> - If you don''t like what mine does, you put a %configure in your > .rpmmacros file that does things the way that you want. >Nope! If I would like to change a directory (OK, for the sake of argument let''s just say it is VARDIR), which is different from the "defaults" offered by the "standard" version of "%configure", I define my own macro and put these variations there - "%configure" is smart enough to pick it up and, again, you don''t have to do a thing as the whole lot is passed on to BUILD/configure and you take it from there. You don''t care what the directory name is, as long as it is specified. My point with the example I have given you in the previous post is that if you write your own shorewallrc.%{_vendor} file and include what you *think* is the right/standard values of the various directories provided by a certain distro, and then proceed to *not* pick up that value from "%configure" later on (as is the case with VARDIR - it is missing from your original list of directories, right?), then you are not going to have the correct value of that directory if: 1. The distro decided to change that directory recently (say, as a matter of policy or other such guff!); or 2. I have redefined that directory to what I choose to use on my own machine (it is my PC, right?); or 3. You''ve just got it plain wrong as the list of directories you included in that shorewallrc.%{_vendor} is your own interpretation of these values at the time you created that file and distributed it So, all I am suggesting to you is this: Just get everything you possibly can from %configure" and do *not* introduce any restrictions like you did with the list you included in the previous post. By all means, honour your original shorewallrc.%{_vendor} values, but let these get overwritten by %configure (*without* restrictions!) - that is simply what I have tried to illustrate with my previous post. it is really that simple! Do you understand it now?> If this is what you are proposing, then do you believe that I should > publish my own %configure in some form so you and other RPM builders can > hack it to suit your needs? >Nope, see above! Again, Tom, you do NOT have to do a thing - just fine-tune that configure file and that is it, really! ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 02:40 PM, Mr Dash Four wrote:> >>>>> You''ve lost me! In that Fedora rc file, you have >>>>> "SYSCONFFILE=sysconfig", which gets installed in $SYSCONFDIR, so the >>>>> whole file name, including the path is /etc/sysconfig/sysconfig (made of >>>>> $SYSCONFDIR/$SYSCONFFILE), which I think is wrong - it should be >>>>> /etc/sysconfig/shorewall, hence my suggestion "SYSCONFFILE=$PRODUCT". >>>>> >>>>> >>>> The installed filename is ALWAYS $PRODUCT; the installers don''t need a >>>> setting for that. >>>> >>>> >>> OK, lets start again - what is the purpose of $SYSCONFFILE then? I >>> always thought that it is the name of the file which gets installed in >>> $SYSCONFDIR, isn''t that so? >>> >>> >> >> Yes. Debian ALWAYS requires such a file and all products except >> Shorewall-core include a default.debian file. In Shorewall-init, Redhat >> also requires such a file which is different from the Debian one. >> > I have no objections to exclude the use of that file (well, I do, but > hear me out), I have objections to its name - according to the Fedora > rc, this file would be called "sysconfig" and will be installed in > /etc/sysconfig, so the whole path would be /etc/sysconfig/sysconfig, > which is, quite frankly ridiculous! The default value of SYSCONFFILE > should be either plain old "shorewall" or "$PRODUCT", but definitely not > "sysconfig", so that, when installed the whole path would be > /etc/sysconfig/shorewall or /etc/sysconfig/$PRODUCT. Do you understand now?I understand -- you don''t. On Fedora, the file ./sysconfig will be installed as /etc/sysconfig/$PRODUCT. On Debian, the file default.debian will be installed as /etc/default/$PRODUCT (SYSCONFDIR = /etc/default on Debian). -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 03/27/2012 02:43 PM, Mr Dash Four wrote:> >> So let me see if I understand the big picture. >> >> - I have a %configure macro defined in my .rpmmacros that does what I >> want it to. >> > No, no, no! > > You don''t define any %configure macros at all - they are already > installed by the distro on your machine - that is the beauty of it all, > the "%configure" is already there, you don''t have to do a thing! > > It has all the "default" directories there as determined by that distro > - being Fedora SUSE etc. As soon as you trigger "%configure" the whole > lot is completed for you and control is passed to an executable file > (script) in the BUILD directory. > > You read the various parameters there, weed out what you don''t need etc > and write this to shorewall-pkg.config or whatever name you decide to > use, so that install.sh can pick it up later and do its magic. > >> - If you don''t like what mine does, you put a %configure in your >> .rpmmacros file that does things the way that you want. >> > Nope! If I would like to change a directory (OK, for the sake of > argument let''s just say it is VARDIR), which is different from the > "defaults" offered by the "standard" version of "%configure", I define > my own macro and put these variations there - "%configure" is smart > enough to pick it up and, again, you don''t have to do a thing as the > whole lot is passed on to BUILD/configure and you take it from there. > You don''t care what the directory name is, as long as it is specified. > > My point with the example I have given you in the previous post is that > if you write your own shorewallrc.%{_vendor} file and include what you > *think* is the right/standard values of the various directories provided > by a certain distro, and then proceed to *not* pick up that value from > "%configure" later on (as is the case with VARDIR - it is missing from > your original list of directories, right?), then you are not going to > have the correct value of that directory if: > > 1. The distro decided to change that directory recently (say, as a > matter of policy or other such guff!); or > 2. I have redefined that directory to what I choose to use on my own > machine (it is my PC, right?); or > 3. You''ve just got it plain wrong as the list of directories you > included in that shorewallrc.%{_vendor} is your own interpretation of > these values at the time you created that file and distributed it > > So, all I am suggesting to you is this: Just get everything you possibly > can from %configure" and do *not* introduce any restrictions like you > did with the list you included in the previous post.My current configure script has no restrictions.> > By all means, honour your original shorewallrc.%{_vendor} values, but > let these get overwritten by %configure (*without* restrictions!) - that > is simply what I have tried to illustrate with my previous post. it is > really that simple! Do you understand it now?Sorry -- I''m a virtual rpm illiterate. If you want to override something (say VARDIR for which there appears to be no standard RPM macro), how are you going to do that? I''m obviously missing something. -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 \________________________________________________ ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> I understand -- you don''t. > > On Fedora, the file ./sysconfig will be installed as > /etc/sysconfig/$PRODUCT. On Debian, the file default.debian will be > installed as /etc/default/$PRODUCT (SYSCONFDIR = /etc/default on Debian). >I was under the impression that all variables in shorewallrc.%{_vendor}, as well as your BUILD/configure refer to files/directories for the HOST platform (i.e. what is going to be installed and where is that going to be installed), not what you have on the BUILD, isn''t that the case? If so, then - at least in Fedora''s example - the sysconfig file is called $PRODUCT and it is going to be in /etc/sysconfig, so, naturally, I assumed that SYSCONFDIR=/etc/sysconfig and SYSCONFFILE=$PRODUCT. Since in your shorewallrc.fedora you have "SYSCONFFILE=sysconfig" that is a mistake and should be corrected. Am I missing something? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> My current configure script has no restrictions. >Good, though I thought you are only going to honour a subset of the variables that could be defined in those shorewallrc.%{_vendor} files, in which case if I use %configure to pass something extra (via my own rpm macro or just adding an extra parameter to the %configure line in my .spec file) this will not be honoured. If that is not the case and your configure script file does not have any restrictions, then all this is a storm in a teacup!> >> By all means, honour your original shorewallrc.%{_vendor} values, but >> let these get overwritten by %configure (*without* restrictions!) - that >> is simply what I have tried to illustrate with my previous post. it is >> really that simple! Do you understand it now? >> > > Sorry -- I''m a virtual rpm illiterate. If you want to override something > (say VARDIR for which there appears to be no standard RPM macro), how > are you going to do that? I''m obviously missing something. >I have the precise statement on one of the dev machines at home and could post later it if you are interested - let me know. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
On 3/27/12 4:09 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> I understand -- you don''t. >> >> On Fedora, the file ./sysconfig will be installed as >> /etc/sysconfig/$PRODUCT. On Debian, the file default.debian will be >> installed as /etc/default/$PRODUCT (SYSCONFDIR = /etc/default on >>Debian). >> >I was under the impression that all variables in shorewallrc.%{_vendor}, >as well as your BUILD/configure refer to files/directories for the HOST >platform (i.e. what is going to be installed and where is that going to >be installed), not what you have on the BUILD, isn''t that the case?No. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure
> No. >Well, you should have clarified that when you''ve made your announcement as it was logically to assume that whatever you refer to in that file concerns the HOST, not the BUILD. Apart from SYSCONFFILE, do you have anything else which refers to file/directories on the BUILD, not the HOST, needed for the installation? ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure