> I assume that by "build shorewall from source", you mean running > install.sh rather than running the build45 script from the > shorewall/tools Git repository. > > When running install.sh, you can use either relative or absolute path > names. If either of the settings is a relative pathname, then /usr/ is > prepended to form an absolute pathname; otherwise the value is used as is. > Generally speaking, I use one method of compiling Shorewall and that is to build it using a .spec file. When I got the init.d problem (incidentally, that was the first time I tried to compile all shorewall packages instead of just the main ones - shorewall & shorewall-core), I used to unpack all package sources and run install.sh, mimicking what was done in the %build section of the .spec file.
As far as the above goes - I find it confusing. Either use $PREFIX/$LIBEXEC (my preferred option - see below) or just $LIBEXEC irrespective of $PREFIX. If you have to use LIBEXEC as a name of the libexec directory, you might consider renaming this to LIBEXECNAME instead - it would be more clear that way. The reason I prefer $PREFIX/$LIBEXEC (and that is also valid for its perl counterpart) is because it would be more consistent and I won't be looking in thousand different places to see where shorewall was installed. The $PREFIX also has one other important function - it would allow me to install shorewall in a "non-trivial" location (not just /usr) - it comes handy when you wish to deploy it on embedded systems or systems which do not follow FHS. I am assuming that for the shorewall to function properly, you do not rely on the FHS. If you do, then you probable won't need $PREFIX at all and you may use "standard" location installation for shorewall, irrespective of what was specified. I am still not clear why do you need libexec though - why not use $PREFIX/sbin or $PREFIX/bin for example? > Given that the scripts are changing so much for 4.5.1, it would probably > be a good time to drop that compatibility, alright. > The ideal time for introducing major changes (and drop backward-compatibilities dragging you down) was with 4.5.0, but I guess, better late than never, eh? You may also wish to drop the "blacklist" as well in favour of the blrules file. On an unrelated note - I keep getting the following 3 types of warnings: 1. WARNING: Option EXPORTPARAMS=Yes is deprecated (what is the equivalent of this?) 2. WARNING: Shorewall no longer uses broadcast addresses in rule generation when Address Type Match is available I have this in my interfaces file: local usb0 192.168.0.255 tcpflags,logmartians,nosmurfs,optional the usb0 is used to connect/debug my android device. 3. ipset WARNINGS: shorewall[1439]: Compiling /etc/shorewall/blrules... shorewall[1439]: WARNING: Ipset AAA does not exist [...ad nauseum...] shorewall[1439]: WARNING: Ipset XXX does not exist shorewall[1439]: Compiling /etc/shorewall/rules... shorewall[1439]: WARNING: Ipset YYY does not exist [...ad nauseum...] shorewall[1439]: WARNING: Ipset ZZZ does not exist Now, I remember asking you to put these warnings a few mohts back, but what I did not account for was that shorewall will be screaming at me with these before executing "init" where these sets are loaded. Is there any way to rectify this? ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
