On 10/23/2010 12:15 PM, Rob Owens wrote:
On Sat, Oct 23, 2010 at 11:53:33AM -0400, Gilbert Sullivan wrote:Starting Network connection manager: wicd. startpar: service(s) returned failure: firestarter ... failed! Running scripts in rc2.d/ took xx seconds.Ah, you're using wicd. For each network connection, click on the "scripts" button. Tell it to run firestarter when the connection is activated. (Ideally you'd want it to run *before* the connection is activated, but it sounds like that isn't going to work based on your experiences).
Okay, this is interesting. I just opened wicd and tried configuring it to run firestarter. I clicked on the Scripts button and was presented with a password prompt. I entered the root password, and I saw the mouse cursor switch to its busy graphic, and then it went back to the normal cursor -- with no dialog coming up to specify a script. That's surely not a design intention. (Reminds me of the little black boxes with a tiny switch on the top. You moved the switch, the box started making odd noises, the lid would lift, a little hand would come out to shove the switch back to off, the hand would withdraw into the box, and the lid would snap shut.)
Should I try manually editing the wicd startup script? I'm concerned that my efforts in that area may have undesired consequences if they aren't performed properly. I'm not worried about screwing it up so that it won't run. That would be easy enough to fix by restoring the script to its initial state. What I'm worried about is the possibility of messing up the way the script works in respect to its behaviors for some or all of the various conditions that I see the firestarter scripts specifying. I wouldn't want to compromise the security of the configuration unawares.
On a related note, if I can get firestarter called successfully from the script that starts wicd, would it be a good idea to remove the init.d call to the firestarter script? Am I correct in assuming that would be accomplished merely by removing the /etc/rc2.d/S19firestarter file?
...
I tried editing /etc/rc2.d/S19kerneloops, which seems to be the next script to be executed after /etc.rc2.d/S19firestarter, but I couldn't see anything. I just added read at the beginning of that script. Is that what you were suggesting? The gdm screen came up and blocked my view of the scrolling text. When I switched to tty1 I just saw these linesThat is what I was suggesting. But I guess my suggestion didn't work... And yes, a "read" statement in bash is like a "pause" statement in DOS batch.
Thank you for that. This conversation is proving to me that I really should get off my figurative duff and start studying this new (to me) operating system. I've used computers every day since the early 60s, but they were always the systems WITH which I did my work rather than the system ON which I did my work -- if you get my meaning. Even given that, I had to learn a lot more about the earlier computing systems because I had to in order to make them do what I wanted. Oddly enough, coming to GNU/Linux has been like a vacation in comparison, despite the common sentiment that it's a tough operating system to use. These are just our personal systems, and everything we have used has "just worked". I've had to read a few man files from time-to-time, and I've even made a couple of bug reports, but it has been easy street compared to my travails on systems like Windows where getting precise information about how something works in the background isn't always very easy. (If it's hard in GNU/Linux, it's just because the system is complex or because there's some missing documentation, not because someone is trying to protect IP "rights".) This seems all very logical, if a little maze-like at times.
If your firewall script references an IP address (which you don't have when the network is down), I think it needs the network to be up in order to run. If the script only references the interface (eth0, for example) it might run even if the network is down, as long as the kernel is aware of eth0's existence. But I'm not sure how wicd affects this. I think your /etc/network/interfaces file will not have anything besides the loopback device listed. -Rob
It appears to me that the script is only referencing the interface, but that's only a guess from a cursory inspection. I haven't looked through all of the referenced files and environment settings to be certain.
It appears that you've determined essentially what my problem is. If I can find out how to cause wicd to make the firestarter script run without causing unwanted side effects I think I should have a solution for my problem.
I'll muddle this over and do some experiments to see what happens. Thank you very much, Gilbert