Re: change in behavior of iptables with respect to firestarter
On 10/23/2010 04:57 AM, Greg Madden wrote:
Runlevel 2 is the default runlevel.
Look for a link: '/etc/rc2.d/Sxxfirestarter -> ../init.d/firestarter'
Hi, Greg.
Thanks to you and Rob I'm getting a bit of an education.
I found /etc/rc2.d/S19firestarter. It does not contain any apparent (to
me) direct reference to the /etc/init.d/firestarter file. This is an
excerpt from /etc/rc2.d/S19firestarter.
---------------------8<------------------------
. /lib/lsb/init-functions
FS_CONTROL="/etc/firestarter/firestarter.sh"
[ -x /usr/sbin/firestarter ] || exit 0
[ -x $FS_CONTROL ] || exit 0
[ -s /etc/firestarter/configuration ] || exit 0
---------------------8<------------------------
It looks it's starting a script called firestarter.sh, and that's
running a bunch of tests, the outcome of which determine what
firestarter is supposed to do? (I'm asking here, but it seems that's
what's going on.)
What has perplexed me about all of this is the lack of any kind of
warning being issued in the Firestarter GUI -- and no apparent (to me)
warnings to be found in dmesg or syslog.
I had brought the systems to the other network and tried to connect by
SSH from notebook to desktop. I couldn't do it because I had forgot to
tell Wicd about the change in networks. (I use fixed IP addresses both
at home and at the alternative network.)
I told Wicd to change the network settings to the profile I use on the
alternate network. Then I corrected from notebook to desktop right away.
But I realized that this should not have been possible because I had not
changed the firewall rules in the desktop firewall's incoming policy. I
cranked up firestarter on the desktop and lost my connection. After a
little bit of head scratching, here I am.
Now that I'm home I suddenly hit upon a cunning plan. I played around
with two other Debian testing systems (my wife's), and I learned that
irestarter is working perfectly on her systems. There's no sign of the
problem on them, and firestarter works on them exactly the way I
remember it working on my systems. As far as I know, all four systems
(her two, and the two of mine that are malfunctioning) have been
configured almost identically.
So I went to her systems and hit <Ctrl>+<Alt>+<F1> to get tty1, and I
can definitely see a difference on that screen. On her two systems with
firestarter running properly there are no hints of trouble. On both of
mine I see the following:
Starting MTA: exim4.
Starting the Firestarter firewall... failed!
Starting kerneloops:
...and, a little later...
Starting Network connection manager: wicd.
startpar: service(s) returned failure: firestarter ... failed!
Running scripts in rc2.d/ took xx seconds.
On both of her systems I see the same thing -- except, of course, for
the two "failed!" warnings.
So, at least I know how I can tell whether or not my firewall has
started. Just look at tty1. (Where would those failures be logged?)
I did try issuing the command on both of my computers after booting, and
that succeeded with no warnings.
# /etc/init.d/firestarter start
Firewall started
When I check with "iptables -L" I can see that the rules are now in
place. So I guess from all of this evidence that firestarter is being
called properly, but that some condition for its startup is not being
met and is causing the failure.
And then I rebooted (showing the same failures in tty1) and tried
starting the firewall this way.
# /etc/firestarter/firestarter.sh start
Firewall started
and that worked, too. So whatever wasn't allowing the script to work
before gdm pops up is no longer defeating it after I've logged on to the
systems.
I'm sorry to be writing a book. This is interesting. I guess it's going
to take some more digging to find out why the firewalls on these two
systems are failing. Could it be simply that they both have two network
configurations and my wife's systems only have one? That's the only
significant configuration difference that I can think of.
I appreciate your help,
Gilbert
Reply to: