On Monday 01 March 2010 11:18:49, Ritesh Raj Sarraf wrote: > [..] > > You should be able to fix this problem by putting a full path to a script > > -- those fields are not meant to contain any "command", just something > > like /home/ritesh/my-wicd-preconnect.sh (it could also be something > > different from Bash, if you wish -- it's run by python's > > subprocess.Popen()). > > > > If this fixes the problem for you, I'll proceed in fixing the manpage > > about it. > > This does not seem to be fixing the problem. > > [..] > 2010/03/01 15:37:07 :: Executing post-connection script > 2010/03/01 15:37:07 :: Expanded '/home/rrs/bin/vpnc-wicd.sh post-connect' > to '/home/rrs/bin/vpnc-wicd.sh post-connect' > 2010/03/01 15:37:07 :: Executing '/home/rrs/bin/vpnc-wicd.sh post-connect' > with params > 2010/03/01 15:37:07 :: '/home/rrs/bin/vpnc-wicd.sh post-connect' returned > 127
Ok, maybe I didn't explain myself clearly enough :).
Don't put any whitespace in those fields; they're supposed to executed ONE
command, with no arguments.
Try making a vpnc-wicd-postconnect.sh and vpnc-wicd-postdisconnect.sh, and see
if those work. Yes, I agree we should make it safer, and document the whole
thing better. And maybe find a better solution for you ;)
> I also discovered some more problems. I populated the an ESSID with
> pre/post script details. Later, I removed the Pre-XX setting. But on
> re-looking at the window I could see the same value back. The setting
> wasn't being removed at all. I had to go and edit the setting in the
> /etc/wicd/wireless-settings.conf file ultimately.
This is a separate bug, please file a new one, and we'll investigate that too.
> Haven't tried it again as wicd is a "critical" package for me that provides
> me the network service. Just want to get my network working. :-(
> Perhaps we should have a more conservative policy for such core packages.
I don't consider wicd a "core package" -- I consider it rather young to be
"core", but I'm sure you're not the only one considering it so :)
Unfortunately, the scripting mechanism is barely documented, and I agree this
is an important bug to be solved ASAP. I'm sorry it doesn't just work out-of-
the-box for you; but maybe it's just a misunderstanding of you, plus a heavy
lack of documentation.
See:
$ cat foo.py
from wicd.misc import ExecuteScript
ExecuteScript("/bin/echo foo", True)
ExecuteScript("whoami", True)
$ python foo.py
Executing '/bin/echo foo' with params
'/bin/echo foo' returned 127
Executing whoami with params
whoami returned 0
$
This explains the "bug" you're facing. You're passing arguments inside the
connection script field -- the text you enter there is passed to
ExecuteScript(). This could also be the reason why it worked with 1.6.2.2 -- I
don't remember any ExecuteScript() there, just a misc.Run() function which
worked differently. But I haven't really checked this, just ideas.
Ok, let's solve your problem now.
If you need some arguments, the {pre,post}-{dis,}connect scripts you specify
get some passed:
a) if it's a wired interface, the script you give is passed with "wired
wired wired" (it's just really for compatibility with the wireless one)
b) if it's a wireless, the script is passed "wireless essid bssid"
And yes, this is totally undocumented ;/.
Regarding your original bug: I forgot to say that all this could be avoided,
just by dropping "sudo".. scripts are executed by the user running the daemon,
i.e. root. However, it's been useful to investigate how scripts work a bit
better :)
If you still have problems, after dropping "sudo" from your original command,
or after passing just ONE script, with no arguments, in the given fields, then
this really is a weird serious bug. But I hope/think this will not be the case
:)
Kindly,
David
--
. ''`. Debian developer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 ----|----
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
signature.asc
Description: This is a digitally signed message part.
