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).
#!/bin/sh
# file name where we set all variables to be used in install.sh later on
log_file=config
declare -A params
# pretty printing vars go here
table_length=102
table_first_col_length=28
table_second_col_length=67
table_char="-"
rm -f $log_file
# Two passes needed just in case there are input parameters specified more than
once
# Pass 1
for _p in $@; do
# slice ...
p=${_p:2}
[ -n "${p}" ] && {
# ... and dice
pn=${p%=*}
pv=${p#*=}
[ -n ${pn} ] && [ -n ${pv} ] && params[${pn}]="${pv}"
}
done
# some pretty printing to see what's what
printf -v line '%*s' "$table_length"
echo ${line// /$table_char}
printf "| %-${table_first_col_length}s | %-${table_second_col_length}s |\n"
"Parameter Name" "Parameter Value"
echo ${line// /$table_char}
# Pass 2
for _p in ${!params[@]}; do
printf "| %-${table_first_col_length}s | %-${table_second_col_length}s |\n"
${_p} ${params[${_p}]}
# set the appropriate parameter
case ${_p} in
build) # build triplet
echo "BUILD=${params[${_p}]}" >> $log_file
;;
host) # host triplet
echo "HOST=${params[${_p}]}" >> $log_file
;;
destdir) # destination directory
echo "DESTDIR=${params[${_p}]}" >> $log_file
;;
libexec) # libexec directory
echo "LIBEXEC=${params[${_p}]}" >> $log_file
;;
initdir) # init.d script directory
echo "INITDIR=${params[${_p}]}" >> $log_file
;;
perl-lib) # perllib directory
echo "PERLLIB=${params[${_p}]}" >> $log_file
;;
*) # anything else not specified above, not strictly necessary!
echo "${_p//-/_}=${params[${_p}]//-/_}" >> $log_file
;;
esac
done
echo ${line// /$table_char}
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
