Hi I have enable the firewall in FEDORA CORE 4.
Now I want to make some rule changes... where is the iptables
file that is called
that I can make changes in?
Thanks.
You're not really supposed to edit the file manually, but its /etc/sysconfig/iptables
I think the proper way to edit the file is to use system-config-securitylevel or to run iptables commands manually and save them with service iptables save.
-Mike
I never use the GUIs. I don't feel that, in general, they give you the functions and control you need. Nor is using a GUI good for learning what is really going on in the system, and how to properly and effectively admin a system.
I suggest that you look at the iptables command. This will modify the rules directly.
In fedora, once you get the rules the way you want them, run '/etc/init.d/iptables save' to update the /etc/sysconfig/iptables file. I never edit the sysconfig file by hand, although I will make copies of the file as backup.
Bob
Mike McGrath wrote:
Hi I have enable the firewall in FEDORA CORE 4.
Now I want to make some rule changes... where is the iptables
file that is called
that I can make changes in?
Thanks.
You're not really supposed to edit the file manually, but its /etc/sysconfig/iptables
I think the proper way to edit the file is to use system-config-securitylevel or to run iptables commands manually and save them with service iptables save.
-Mike
On Thu, Dec 01, 2005 at 11:51:30AM -0500, Bob Kryger wrote:
I never use the GUIs. I don't feel that, in general, they give you the functions and control you need. Nor is using a GUI good for learning what is really going on in the system, and how to properly and effectively admin a system.
I am aghast that we have gone backwards from AIX "smit" and Linuxconf in earlier (Red Hat!) distros. A GUI configuration tool should:
1. Have a command line interface.
2. Generate a script log that shows the exact commands required to reproduce the changes, and can be massaged through light editing to abstract it. [By "exact" I mean, restore your system to the snapshot taken before running the tool, run the script through the command-line interface, and it should reproduce the exact same result.]
3. Provide an optional list of every configuration file that has been touched by an operation.
4. Integrate with a revision control system, so that the history of configuration changes is recorded somewhere.
...
This is not rocket science at all(*), but unfortunately people who are "good" GUI developers never grokked Unix (or Plan 9!), and think that the whole world is a single !@#$% desktop machine. So we get Windows 95 running over a POSIX core. Lovely. :-(
Please, someone prove me wrong! Point me to an active project that aims to satisfy any of the above criteria; I'm not out there actively looking, so perhaps such a beast exists.
-Bill
(*) The "rocket science" is in having applications respond to dynamic updates, using, e.g., Gconf. I grant that this is an order-of-magnitude more difficult.
In general a nice idea and I agree. Especially w/ the GUI builders and the single user/desktop centered interfaces of many GUIs.
I did get a kick out of the smit 'running man' especially when he fell on his face. Frankly I only used smit for the first time i needed to do something or for infrequent tasks that i could not remember the command for.
bob
Bill Rugolsky Jr. wrote:
On Thu, Dec 01, 2005 at 11:51:30AM -0500, Bob Kryger wrote:
I never use the GUIs. I don't feel that, in general, they give you the functions and control you need. Nor is using a GUI good for learning what is really going on in the system, and how to properly and effectively admin a system.
I am aghast that we have gone backwards from AIX "smit" and Linuxconf in earlier (Red Hat!) distros. A GUI configuration tool should:
Have a command line interface.
Generate a script log that shows the exact commands required to reproduce the changes, and can be massaged through light editing to abstract it. [By "exact" I mean, restore your system to the snapshot taken before running the tool, run the script through the command-line interface, and it should reproduce the exact same result.]
Provide an optional list of every configuration file that has been touched by an operation.
Integrate with a revision control system, so that the history of configuration changes is recorded somewhere.
...
This is not rocket science at all(*), but unfortunately people who are "good" GUI developers never grokked Unix (or Plan 9!), and think that the whole world is a single !@#$% desktop machine. So we get Windows 95 running over a POSIX core. Lovely. :-(
Please, someone prove me wrong! Point me to an active project that aims to satisfy any of the above criteria; I'm not out there actively looking, so perhaps such a beast exists.
-Bill
(*) The "rocket science" is in having applications respond to dynamic updates, using, e.g., Gconf. I grant that this is an order-of-magnitude more difficult.
On Thu, 2005-12-01 at 11:56, Bob Kryger wrote:
In general a nice idea and I agree. Especially w/ the GUI builders and the single user/desktop centered interfaces of many GUIs.
Are there any other choices in this respect? For example something that would let you take advantage of X's network transparency by automatically finding applications added to remote application servers and including them in your menus?
Thanks I did what you suggested... I just flushed all the rules and then I inputed the ones I wanted and then did iptables save... did not know you could do it that way...awsome... thanks!
On 12/1/05, Bob Kryger bobk@panix.com wrote:
I never use the GUIs. I don't feel that, in general, they give you the functions and control you need. Nor is using a GUI good for learning what is really going on in the system, and how to properly and effectively admin a system.
I suggest that you look at the iptables command. This will modify the rules directly.
In fedora, once you get the rules the way you want them, run '/etc/init.d/iptables save' to update the /etc/sysconfig/iptables file. I never edit the sysconfig file by hand, although I will make copies of the file as backup.
Bob
Mike McGrath wrote:
Hi I have enable the firewall in FEDORA CORE 4. Now I want to make some rule changes... where is the iptablesfile that is called
that I can make changes in?
Thanks.You're not really supposed to edit the file manually, but its /etc/sysconfig/iptables
I think the proper way to edit the file is to use system-config-securitylevel or to run iptables commands manually and save them with service iptables save.
-Mike-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Phil wrote:
Thanks I did what you suggested... I just flushed all the rules and then I inputed the ones I wanted and then did iptables save... did not know you could do it that way...awsome... thanks!
You can also directly invoke the 'iptables-save' and 'iptables-restore' commands to save and restore to/from an arbitrary file, not just /etc/sysconfig/iptables. That can be very handy when you're working with alternative or experimental rulesets.
--On Thursday, December 01, 2005 11:51 AM -0500 Bob Kryger bobk@panix.com wrote:
In fedora, once you get the rules the way you want them, run '/etc/init.d/iptables save' to update the /etc/sysconfig/iptables file. I never edit the sysconfig file by hand, although I will make copies of the file as backup.
Instead of using the path to the init script, you can use "service iptables save". The "service" command figures out where the initscript is.
I do backup my sysconfig file before messing with the firewall, but I often edit it once I've backed it up. The format isn't too tough to decipher. Each line has the stuff after "iptables -t majortable -A minortablename". The major and minor tables are in groups. The counters for each rule can optionally appear at the beginning of the line in brackets.
The big win in using the save file over individual rule invocations is that it gets loaded into the kernel in one gulp, with only one locking of the kernel structure. This makes it much faster when you have a lot of rules. Some iptables helper programs can generate 100's of rules, so this makes your firewall loading much less painful.
On Thu, 2005-12-01 at 14:27 -0800, Kenneth Porter wrote:
I do backup my sysconfig file before messing with the firewall, but I often edit it once I've backed it up. The format isn't too tough to decipher. Each line has the stuff after "iptables -t majortable -A minortablename". The major and minor tables are in groups. The counters for each rule can optionally appear at the beginning of the line in brackets.
The big win in using the save file over individual rule invocations is that it gets loaded into the kernel in one gulp, with only one locking of the kernel structure. This makes it much faster when you have a lot of rules. Some iptables helper programs can generate 100's of rules, so this makes your firewall loading much less painful.
When I first messed with iptables, there wasn't an interface. So I ended up writing a script file with my rules in it (as you'd type them into the CLI). Giving me an easy way to modify things (keeping some things the same, changing others), and an easy way to re-implement the same set of rules later on. The last line of the script saved the rules to the standard place, so they were implemented at bootup, just the same as you've described above. It worked well for me.
-
Bill Rugolsky Jr. -
Bob Kryger -
Kenneth Porter -
Les Mikesell -
Mike McGrath -
Phil -
Robert Nichols -
Tim