On 3/26/12 7:48 AM, "Mr Dash Four" <[email protected]> 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_HOME
Okay.
>
>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
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
