On 10/23/2010 02:38 PM, Gilbert Sullivan wrote:
...
I'm guessing I should try to run firestarter in the Pre-connection
Script field first, and then fall back to using the Post-connection
Script field if Pre-connection fails.
Now I just have to decide which of the firestarter scripts it makes the
most sense to use in this case. I'm guessing from the order in which
things appear in the output seen in tty1 that the firestarter script
will most likely have to run post-connection?
I've manually started firestarter successfully after login with both of
the following:
# /etc/init.d/firestarter start
# /etc/firestarter/firestarter.sh start
...
I'll add this note. I spent a fair amount of time trying one alternative
after another.
First of all, for some reason, trying to get wicd to run firestarter
didn't work with either command or in either the pre-connection or
post-connection settings.
I tried editing /etc/firestarter/firestarter.sh. I was able to get
firestarter to start by commenting out some of the checks that script
was performing. I'm thinking that the checks wouldn't be there if the
developers hadn't thought they were needed for one reason or another. If
I'm unwittingly defeating a check that affects the security of the
system, I'd rather not do that.
I'm also concerned that editing the regular startup scripts could run
afoul of other issues. Obviously any update to firestarter might (and
probably would) overwrite my customized scripts. That wouldn't be so bad
if the danged thing didn't fail without putting a warning in a log or
flagging my attention in some other way.
This is a pretty sophisticated firewall front end, allowing for
connection sharing and allowing you to limit service connections to
specific IP addresses or IP address ranges, but it's not working
reliably for me. And the moderator of their list hasn't bothered to
respond to either my request to join the list or to allow an outsider
post to the list.
I decided that, rather than have a sophisticated application that I
can't rely upon, I'd rather just do without or find a substitute. I was
surprised to find gufw in the Debian repositories. (I think it was
originally written for use in Ubuntu.) It's not anywhere near as
sophisticated as firestarter, but it works, and it appears to have
pretty active bugtracker and user list activity.
I left firestarter on my wife's systems (where it works) and removed it
from mine (where it doesn't). My wife's systems aren't used anywhere but
at home on our own network behind a decent router. I'm just going to use
gufw on my own systems for now, even though it won't allow me to limit
inbound IP addresses.
The choice with gufw is to all connections from anywhere or not to allow
connections, but at least it's configured per service. I can tighten up
ssh configuration on the host to help keep this from being a problem.
I kind of feel like a schmuck for dropping firestarter this easily
(especially after your attempt to help me with it), but I remember
having a similar problem with it in another distro when I was testing a
couple of years ago. If you look at the archives for their sourceforge
list you can see that this non-starting issue has been around for a
long, long time. The fact that I couldn't get a response from them (at
least not yet) and the fact that the firewall rules can fail to be
applied without any apparent warning to the end user has kind of killed
my appetite for trying to work with the application.
Many thanks again for your help, Rob Owens and Greg Madden!
Regards,
Gilbert
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
