>> 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
_______________________________________________
Shorewall-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-devel
