Peter Littmann <[email protected]> wrote:
> 1. Please inform the user who wants to install the firewall and takes the
> description from here: http://shorewall.net/standalone.htm that the macros
> does not provide any magic.
> So when he takes "macro.Webmin" by example this macro will not take care
> about the user by inspecting /etc/webmin/miniserv.conf which port to listen.
> Instead it sets the standard port of 10000 which is wrong after the user has
> changed the port (in my case :1023).
Like every other macro, it'll break if you do something non-standard. There's a
hint in the name - macro - which to me at least implies a shortcut to a set of
operations, not some magic. Did you not at least have any curiosity and look at
the contents of the macro file ?
> 2. On the same webpage it is described: "appropriate macro in
> /etc/shorewall/macro.*, the general format of a rule" where in fact, at
> least on Fedora 20, which provides version 4.5.21.5, the macros are in
> "/usr/share/shorewall" and need not to be copyed to be under /etc.
That's your distro. If you install from source I assume you'll get what the
project pages suggest, but when installing from distro packages then these
things tend to change. That's the case with Debian - but IIRC they tend to put
a notes file in the /usr/share/[doc/]${package} directory noting differences
like this. It's not by any stretch limited to Shorewall.
Also, under Debian, you do not need to move the macros from
/usr/share/shorewall to /etc/shorewall. The Debian package looks in
/usr/share/shorewall and will find the standard ones there. If your Fedora
package doesn't then I'd consider this a bug and you should raise it with the
Fedora (or Red Hat) package maintainer.
> 3. There is also mentioned to change "/etc/shorewall/routestopped" on this
> page, but there is no file with this name on Fedora 20 and it seems not to be
> important?
Ditto, that's a distro packaging issue.
> 4. Under "/usr/share/shorewall" there is a file actions.std. This extension
> is also a well known extension for StarOffice 6 and OpenOffice.org formatted
> files. So when you are on a TUI with midnight commander, it will not use the
> file command to detect that this file is ASCII text. No, it will consult
> mc.ext where it takes the information that this file should be viewed with
> odt2txt. This will not work. So a user might become a problem or at least
> gets a false idea about the format of this file.
At the risk of starting a "my editor is better than yours" argument, that's a
problem with using a tool that makes assumptions about file types. None of the
'regular' text tools (vi, nvi, vim, nano, more, less, cat, etc, etc, etc) have
a problem.
What most of this comes down to is that you cannot expect the authors of
individual packages to know what the downstream distro package maintainers are
doing regarding file locations. You also can't expect them to think of every
possible other bit of software that users may choose to be using. This is
particularly the case with something like midnight commander which (from vague
memory) is a pseudo shell which I can't help thinking isn't all that common
when working with a relatively technical tool like Shorewall.
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users
