On 02/21/2012 07:13 AM, Mr Dash Four wrote: > 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?
The sole purpose of PREFIX (a.k.a DESTDIR) is for building packages. $PREFIX specifies the root of the filesystem in which the installer will install the product (rpm/BUILDROOT/product-... for rpms). There was never any intention that a Shorewall product installed into a directory could actually run in that environment. LIBEXEC exists because some distributions don't want to put executable shell scripts in /usr/share and prefer to put them in /usr/libexec/ instead. Similarly, some distributions object to Perl modules living in /usr/share, which is why PERLLIB was invented. Both of these specify an absolute pathname to be used at run-time. > >> 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? Yep. > You may also wish to drop the "blacklist" as > well in favour of the blrules file. I considered that but may users have scripts that load the existing blacklist file so I've maintained support for it. > > 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?) EXPORTPARAMS=Yes causes the entire params file script to be executed by the generated firewall script. That's usually not what is wanted. When EXPORTPARAMS=No, the variables that the params file creates are automatically set in the generated script, allowing them to be used in the other user exits like init, started, etc. > > 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. Simply use '-' in the BROADCAST column. I should create a new format interfaces file that simply omits that column; I've done similar things with other configuration files that support a FORMAT directive. I'll add that before the first 4.5.1 RC. > > 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? I suppose that we could control generation of this message by a command option. Today, it is simply predicated on whether the user is root or not. e.g, 'shorewall check -i' would issue the warnings if executed by root. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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
