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 lines
That 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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cc32486.9000...@comcast.net
