extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-27 18:13:13 +01:00
Code Issues Packages Projects Releases Wiki Activity

Add more documentation about 'generate'

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3251 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2006-01-07 19:22:58 +00:00
parent a71ee682bf
commit fa3e812f46
1 changed files with 57 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

87
Shorewall/releasenotes.txt
View File

@ -33,17 +33,17 @@ Problems corrected in 3.1.0
Migration Considerations: Migration Considerations:
1) The dynamic zone capability has been removed from Shorewall. Based on when 1) The dynamic zone capability has been removed from Shorewall. Based on when
ipsets are made a standard part of the Linux kernels from kernel.org, dynamic ipsets are made a standard part of the Linux kernels from kernel.org, dynamic
zones may be restored prior to the release of Shorewall 3.2. zones may be restored prior to the release of Shorewall 3.2.
New Features: New Features:
1) A new 'shorewall generate' command has been added. 1) A new 'shorewall generate' command has been added.
shorewall [ -q ] generate [ <config directory> ] <script file> shorewall [ -q ] generate [ <config directory> ] <script file>
where: where:
-q Suppresses many of the progress messages -q Suppresses many of the progress messages
<config directory> Is an optional directory to be searched for <config directory> Is an optional directory to be searched for
@ -53,39 +53,66 @@ New Features:
filename is given, the file will be created in filename is given, the file will be created in
/var/lib/shorewall. /var/lib/shorewall.
The 'generate' command processes the configuration and writes a script file The 'generate' command processes the configuration and writes a script file
which may then be executed (either directly or using the 'shorewall restore' which may then be executed (either directly or using the 'shorewall restore'
command) to configure the firewall. command) to configure the firewall.
WARNING: The generated script HAS ABSOLUTELY NO ERROR CHECKING so if there WARNING: The generated script HAS ABSOLUTELY NO ERROR CHECKING so if there
are errors in your configuration files that result in errors when are errors in your configuration files that result in errors when
the script is run then you may not be able to access your firewall the script is run then you may not be able to access your firewall
or your firewall may have security holes. or your firewall may have security holes.
Given the above warning, I recommend that you use 'generate' when making Given the above warning, I recommend that you use 'generate' when making
simple changes to your configuration but that you continue to use 'restart' simple changes to your configuration but that you continue to use 'restart'
for complex changes. for complex changes.
Some additional considerations: Some additional considerations:
a) All 'detect' operations are done at the time that the 'generate' command a) All 'detect' operations are done at the time that the 'generate' command
is run. So it is generally not possible to run 'generate' on one system is run. So it is generally not possible to run 'generate' on one system
then move the generated script to another system. then move the generated script to another system.
b) If you have extension scripts, they may need modification. The scripts b) If you have extension scripts, they may need modification. The scripts
will be run at generation time, rather than when the generated script will be run at generation time, rather than when the generated script
is executed. The standard functions like 'run_iptables' and is executed. The standard functions like 'run_iptables' and
'log_rule_limit' will write the iptables command to the script file 'log_rule_limit' will write the iptables command to the script file
rather than executing the command. As always, you can check $COMMAND rather than executing the command. As always, you can check $COMMAND
to determine which shorewall command is being executed. to determine which shorewall command is being executed.
In addition to 'generate', a 'shorewall reload' command has been added. In addition to 'generate', a 'shorewall reload' command has been added.
shorewall [ -q ] reload [ <config directory> shorewall [ -q ] reload [ <config directory>
where -q and <config directory> are as above. where -q and <config directory> are as above.
The 'reload' command creates a script using 'generate' and if there are The 'reload' command creates a script using 'generate' and if there are
no errors, it then restores that script. It is equivalent to: no errors, it then restores that script. It is equivalent to:
if shorewall generate <temp file>; then restore <tempfile>; fi if shorewall generate <temp file>; then restore <tempfile>; fi
The advantage of using reload over restart is that reload results in new
connections being dropped for a much shorter time. Here are the results of
tests that I conducted on my own firewall:
A) shorewall -q restart
real    0m17.540s
user    0m5.956s
sys     0m10.737s
B) shorewall -q restore foo # foo created using "shorewall generate"
real    0m3.505s
user    0m1.332s
sys     0m2.164s
C) shorewall -q restore # Restores from file generated by "shorewall save"
real    0m1.164s
user    0m0.556s
sys     0m0.608s
The time difference from B to C reflects the difference between
"iptables-restore" and multiple executions of "iptables". The system is a
1.4Ghz Celeron with 512MB RAM.