ebuilds for Shorewall 3.2 series
Created attachment 91468 [details] shorewall 3.2.0 ebuild
Created attachment 91469 [details] shorewall initscript
Created attachment 91470 [details] shorewall-lite ebuild
Created attachment 91471 [details] shorewall-lite initscript
Shorewall 3.2 implements major changes. Shorewall 3.0 is treated in http://bugs.gentoo.org/show_bug.cgi?id=112942
Created attachment 91487 [details] Shorewall initscript Cleaned header
Created attachment 91488 [details] Shorewall-lite iniscript Cleaned header.
Please version bump to 3.2.1 as important bugs have been fixed upstream.
*** Bug 141667 has been marked as a duplicate of this bug. ***
netmon, ping?
Version bump to 3.2.2. Bypass Sandbox access violation I am unfamiliar with (pointer appreciated): * emerge -C shorewall shorewall-lite * emerge shorewall shorewall-lite If noone has time for this then maybe this ebuild could be put up in CVS and marked M~ testing / hard masked ?
Created attachment 93934 [details, diff] shorewall-3.2.1-install.sh.patch The sandbox violation comes from the install script trying to change current CONFIG_PATH to "/usr/share/shorewall/configfiles:/usr/share/shorewall" in any existing /usr/share/shorewall/configfiles/shorewall.conf. (thats why it helps to unmerge it first) There should be some info telling that this change is needed to be done manually. Attatched patch just removes the sandbox violating line.
Created attachment 93935 [details] shorewall-3.2.2.ebuild ebuild for 3.2.2 with sandbox violation fix.
I would prefer having the install script do everything :-). Changing these lines in install.sh by adding ${PREFIX} seems to satisfy sandbox: qt mywhich perl && perl -p -w -i -e 's|^CONFIG_PATH=.*|CONFIG_PATH=/usr/share/shorewall/configfiles:/usr/share/shorewall|;' ${PREFIX}/usr/share/shorewall/configfiles/shorewall.conf qt mywhich perl && perl -p -w -i -e 's/^STARTUP_ENABLED=No/STARTUP_ENABLED=Yes/;s/^IP_FORWARDING=On/IP_FORWARDING=Keep/;s/^SUBSYSLOCK=.*/SUBSYSLOCK=/;' ${PREFIX}/etc/shorewall/shorewall.conf Help/suggestions are being requested upstream.
As I understand the script, it changes your current config, in case you already have shorewall installed. ebuilds are not supposed to change your config. etc-update is supposed to take care of that. You will *never* have the file installed in your sandbox (unless you copy it from live filesystem first and then do the replace). so adding a ${PREFIX} is doing the same as removing it. ...if I understand the script correctly.
yes but the install script has always been that way as you can see for example under "# Check for /etc/shorewall". Previous shorewall ebuilds don't handle that either. etc-update or dispatch-conf take care of the config files in etc/shorewall so the second line might as well be ignored: qt mywhich perl && perl -p -w -i -e 's/^STARTUP_ENABLED=No/STARTUP_ENABLED=Yes/;s/^IP_FORWARDING=On/IP_FORWARDING=Keep/;s/^SUBSYSLOCK=.*/SUBSYSLOCK=/;' ${PREFIX}/etc/shorewall/shorewall.conf However, the first line refers to a "non-dispatchconf-standard" config file location: ${PREFIX}/usr/share/shorewall/configfiles/ and the ebuild specifies that keepdir is only for /var/lib/shorewall. So when one emerges to a newer shorewall, /usr/share/shorewall/configfiles/ content will be lost and replaced with the new files. This is ok just as long as the user keeps using the default config dir, i.e. /etc/shorewall. In other words, install.sh does "too much" but it's "enough" for the build as a whole. However, I may be wrong.
fixed in Shorewall svn ;-)
Maybe setting up an overlay for shorewall (or net-firewall as a whole) could be interesting? http://overlays.gentoo.org
(In reply to comment #18) > Maybe setting up an overlay for shorewall (or net-firewall as a whole) could be > interesting? > http://overlays.gentoo.org How would that be better than commit it to official gentoo tree?
(In reply to comment #19) > How would that be better than commit it to official gentoo tree? Shorewall-lite is a new package and there's no ebuild for that in the official tree. Putting it up on an overlay would make users have the chance to cleanly get it, test it and eventually someone will put it in the main portage tree. Or at least that's how I think it can be useful. Maybe the "sunrise overlay" could be fine for this. However, shorewall-lite won't work if the user didn't install shorewall 3.2 on one of his/her systems. Of course, committing it to the official tree directly would be nice but since the Gentoo Shorewall maintainers are busy I really think the "overlays" idea is constructive and should make users participate more actively.
Created attachment 94767 [details, diff] Updated install.sh patch install.sh script updated upstream and can be used with Natanael's ebuild (practically speaking, it has the same effect as Natanael's patch but it comes from Shorewall's svn). However, I think we can wait for 3.2.3.
(In reply to comment #21) > > However, I think we can wait for 3.2.3. > Sounds like a good idea. :)
Created attachment 95223 [details] net-firewall/shorewall-3.2.3 ebuild Shorewall 3.2.3 has a fix for the sandbox violation error. Installs and upgrades cleanly.
Created attachment 95224 [details] net-firewall/shorewall-lite-3.2.3 ebuild Shorewall-lite 3.2.3: new package.
in cvs, thanks for the work.
(In reply to comment #25) > in cvs, thanks for the work. Thanks for putting shorewall 3.2 in portage. I am reopening this bug because shorewall-lite has been forgotten ;-( (I know this is a new package and may require more dev work to allow it into portage)
Please version bump for shorewall 3.2.4 and shorewall-lite 3.2.4
Can you provide a gentoo-style init script for it?
(In reply to comment #28) > Can you provide a gentoo-style init script for it? > won't the already attatched init scripts work? https://bugs.gentoo.org/attachment.cgi?id=91488
All in CVS now, thanks for reporting :)
Created attachment 100763 [details] net-firewall/shorewall-3.2.5 ebuild version bump 3.2.5. New proposed ebuild just adds one einfo line which states that the user should read the Release Notes (especially useful for migration issues). Otherwise, please just rename 3.2.4.
net-firewall/shorewall 3.2.5 net-firewall/shorewall-lite 3.2.5 version bump Also requesting 3.0.9 to go stable on x86 and amd64 as that is the last version of the 3.0 series and 3.2 has been around for a while now.
Hi there, shorewall3-series fail to operate properly if iproute2 is build with the minimal useflag USE="minimal" emerge iproute2 is missing the /sbin/ip utility needed by shorewall to do anything (start stop etc.) after a "blind" update of iproute2 with globally set USE="minimal" and a reboot i got locked out of my system... patch should fix it, please apply it :-) --- with patch: gateway All # emerge =iproute2-2.6.16.20060323 shorewall -av -k These are the packages that would be merged, in order: Calculating dependencies... done! [binary UD] sys-apps/iproute2-2.6.16.20060323 [2.6.18.20061002] USE="berkdb minimal* -atm" [ebuild R ] net-firewall/shorewall-3.2.4 USE="doc" 0 kB --- will deny to merge a broken shorewall... greets martin
Created attachment 100975 [details, diff] shorwall-iproute2-minimal-useflag.patch
Created attachment 101126 [details] net-firewall/shorewall-3.2.5 ebuild This proposed ebuild includes Martin's patch and the latest official Shorewall 3.2.5 patches. If you're not using 3.2.4 yet I suggest going directly for the patched 3.2.5.
Created attachment 101127 [details, diff] patch-3.2.5-1.diff
Created attachment 101128 [details, diff] patch-3.2.5-2.diff
>=3.2.3 multi-ISP users should visit: http://www1.shorewall.net/pub/shorewall/CURRENT_STABLE_VERSION_IS_3.2/shorewall-3.2.5/known_problems.txt The attached 3.2.5 ebuild includes these patches.
Created attachment 102333 [details] net-firewall/shorewall-3.2.6.ebuild shorewall and shorewall-lite 3.2.6 version bump. Reattached shorewall ebuild for clarity with latest considerations.
OK, can we stop recycling this bug perpetually? Fixed, closed. New version -> new bug. Thanks.
