Shorewall users - Aug 2002 - RPM update script for shorewall

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------9652C368D6E9348802C06E91
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have created a Shorewall RPM update script.

The main problem with Shorewall/RPM updates was that configuration
usually kept working but changes in comments, the one in the original
files, were lost. It''s of course not a problem of shorewall or RPM,
it''s
just the way how we update manually edited config files.
My solution was to create a script which updates shorewall via RPM but
patches the original config files.
I put the script shorewall-rpm-update.sh into the directory which
contains all the shorewall rpms and start it with
./shorewall-rpm-update.sh. Basically it performs the following steps:

- make some sanity checks (is ''patch'' installed, do we have
newer and
the currently installed rpm available...)

- save current /etc/shorewall to /root/shorewall-$rpmversion

- extract the rpm of the currently installed version to a temp directory

- create a diff of all changes to files in /etc/shorewall

- update shorewall to the newest version

- patch config files in /etc/shorewall

BIG FAT WARNING:
This script works for me. Don''t trust it blindly. I post it here
because
it may be useful for others but use at your own risk. Don''t cry if it
breaks your hole firewall.

BTW, the script doesn''t convert config file versions. If you upgrade
from 1.2 -> 1.3, you''ll have to modify by hand.

Simon
--------------9652C368D6E9348802C06E91
Content-Type: application/octet-stream;
 name="shorewall-rpm-update.sh"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="shorewall-rpm-update.sh"

IyEvYmluL3NoCgpCTj1gYmFzZW5hbWUgJDBgClBBQ0tBR0U9YGZpbmQgc2hvcmV3YWxsLT8u
Py4/Ki0/Lm5vYXJjaC5ycG0gMj4gL2Rldi9udWxsIHwgdGFpbCAtbjFgCkNVUlZFUj1gcnBt
IC1xIHNob3Jld2FsbGAKQ1VSUEFDSz0iJENVUlZFUi5ub2FyY2gucnBtIgoKd2hpY2ggZGlm
ZiA+IC9kZXYvbnVsbCAyPiYxCmlmIFsgJD8gLW5lIDAgXTsgdGhlbgogIGVjaG8gIiQwOiBD
YW4ndCBmaW5kIGRpZmYsIGV4aXRpbmcuLi4iCiAgZXhpdCAxCmZpCgp3aGljaCBwYXRjaCA+
IC9kZXYvbnVsbCAyPiYxCmlmIFsgJD8gLW5lIDAgXTsgdGhlbgogIGVjaG8gIiQwOiBDYW4n
dCBmaW5kIHBhdGNoLCBleGl0aW5nLi4uIgogIGV4aXQgMQpmaQoKaWYgWyAtZCAvcm9vdC8k
Q1VSVkVSIF07IHRoZW4KICBlY2hvICIkMDogL3Jvb3QvJENVUlZFUiBhbHJlYWR5IGV4aXN0
cywgZXhpdGluZy4uLiIKICBleGl0IDEKZmkKCmlmIFsgJD8gLW5lIDAgXTsgdGhlbgogIGVj
aG8gIiQwOiBDYW4ndCBjcmVhdGUgdGVtcCBmaWxlLCBleGl0aW5nLi4uIgogIGV4aXQgMQpm
aQoKaWYgWyAhIC1lICIkUEFDS0FHRSIgXTsgdGhlbgogIGVjaG8gIk5vIG5ld2VyIFNob3Jl
d2FsbCBwYWNrYWdlIGZvdW5kIGluIGN1cnJlbnQgZGlyZWN0b3J5ICEiCiAgZXhpdCAxCmZp
CgppZiBbICEgLWUgIiRDVVJQQUNLIiBdOyB0aGVuCiAgZWNobyAiQ3VycmVudGx5IGluc3Rh
bGxlZCBwYWNrYWdlIG5vdCBmb3VuZCBpbiBjdXJyZW50IGRpcmVjdG9yeSAhIgogIGV4aXQg
MQpmaQoKVE1QRklMRT1gbWt0ZW1wIC1xIC90bXAvJEJOLXBhdGNoLlhYWFhYWGAKVE1QRElS
PWBta3RlbXAgLWRxIC90bXAvJEJOLlhYWFhYWGAKCmVjaG8gIlNhdmluZyBjdXJyZW50IGNv
bmZpZyB0byAvcm9vdC8kQ1VSVkVSIgpjcCAtYXIgL2V0Yy9zaG9yZXdhbGwgL3Jvb3QvJENV
UlZFUgoKZWNobyAiRXh0cmFjdGluZyBjdXJyZW50bHkgaW5zdGFsbGVkIHBhY2thZ2UgdG8g
JFRNUERJUi8kQ1VSUEFDSyIKbWtkaXIgLXAgJFRNUERJUi8kQ1VSUEFDSwpycG0yY3BpbyAk
Q1VSUEFDSyB8IChjZCAkVE1QRElSLyRDVVJQQUNLIDsgY3BpbyAtaWRtKQoKZWNobyAiU2F2
aW5nIG5vbiBkaXN0cmlidXRpb24gY29uZmlnIGZpbGVzLi4uIgpwdXNoZCAvcm9vdC8kQ1VS
VkVSCmZpbmQgLiAtdHlwZSBmIHwgd2hpbGUgcmVhZCBpOyBkbwogIGliYXNlPWBiYXNlbmFt
ZSAkaWAKICBpZiBbICEgLWUgJFRNUERJUi8kQ1VSUEFDSy9ldGMvc2hvcmV3YWxsLyRpYmFz
ZSBdOyB0aGVuCiAgICBjcCAtdmEgJGliYXNlICRUTVBESVIvJENVUlBBQ0svZXRjL3Nob3Jl
d2FsbC8KICBmaQpkb25lCnBvcGQKCmVjaG8gIkNyZWF0aW5nIHBhdGNoZXMuLi4iCnB1c2hk
IC9ldGMvc2hvcmV3YWxsCnBvcGQKcHVzaGQgJFRNUERJUi8kQ1VSUEFDSy9ldGMKZGlmZiAt
TmF1ciBzaG9yZXdhbGwgL2V0Yy9zaG9yZXdhbGwgPiAkVE1QRklMRQpwb3BkCgplY2hvICJS
ZW1vdmluZyBjdXJyZW50IHBhY2thZ2UgJENVUlZFUiIKcnBtIC1lIHNob3Jld2FsbApybSAt
cmYgL2V0Yy9zaG9yZXdhbGwKCmVjaG8gIkluc3RhbGxpbmcgbmV3IHBhY2thZ2UgJFBBQ0tB
R0UiCnJwbSAtVXZoICRQQUNLQUdFCgplY2hvICJSZXN0b3Jpbmcgbm9uIGRpc3RyaWJ1dGlv
biBjb25maWcgZmlsZXMuLi4iCnB1c2hkIC9yb290LyRDVVJWRVIKZmluZCAuIC10eXBlIGYg
fCB3aGlsZSByZWFkIGk7IGRvCiAgaWJhc2U9YGJhc2VuYW1lICRpYAogIGlmIFsgISAtZSAv
ZXRjL3Nob3Jld2FsbC8kaWJhc2UgXTsgdGhlbgogICAgY3AgLXZhICRpYmFzZSAvZXRjL3No
b3Jld2FsbC8KICBmaQpkb25lCnBvcGQKCmVjaG8gIk1vZGlmeWluZyBjdXJyZW50IGNvbmZp
ZyBmaWxlcy4uLiIKcHVzaGQgL2V0Yy9zaG9yZXdhbGwKcGF0Y2ggLWIgLXAwIDwgJFRNUEZJ
TEUKcG9wZApybSAtZiAkVE1QRklMRQpybSAtcmYgJFRNUERJUgoKZWNobyAiZG9uZS4iCmVj
aG8KZWNobyAiTm93IGNoZWNrIHRoZSBjb25maWcgZmlsZXMsIHJ1biA8c2hvcmV3YWxsIGNo
ZWNrPiBhbmQgdGhlbiByZXN0YXJ0IHNob3Jld2FsbCAhIgo--------------9652C368D6E9348802C06E91--

I''ve seen several 6970 udp port blocked on my firewall.

In fact it''s a realvideo server which try to send out packet
on my firewall external interface.

I know it''s realvideo related, and looked on internet about it.

Several people have in their config, 

ACCEPT     net    net:external_interface    udp    6970

I understand that it will accept packets going to udp port 6970.

I don''t understand how it can work as they are related to an
outgoing connection (one local pc trying to see video on internet)
and the firewall seems to have no idea about this connection 
(I''m accepting related connection, but the firewall reject them).

How can i tell the firewal that they are related to an outgoing
connection ? Is there a module as in ipchains ?

Thnaks for any help

Jerome.