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