Re: Potential problem in getting WPA key from KDE Wallet
On Sunday 01 July 2007, Larry Finger said: I would be happy to do any further testing and/or provide the contents of logs, providing you tell me where to find them. I'm using 0.6.4-51 of NetworkManager from the x86_64 openSUSE 10.2 distribution. The kicker applet is version 0.1r606753-17.1. Did you open a bug report at bugzilla.novell.com for this? I can't see a bug there which looks like this problem. regards Will Stephenson ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Networkmanager not connecting to known network
I have been reading the list and snooping around in the files trying to figure this out, but I'm not sure what I'm looking for. I know it is supposed to connect to a known network automatically. It does try but times out. Any help is appreciated. Thanks, Alex -- Ourwoods.org Dell Inspiron 1501, Ubuntu 7.04 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FR: NetworkManagerDispatcher should fireup scripts owned by any user.
On Sun, 2007-07-08 at 21:02 -0400, Hans Deragon wrote: Greetings. [ Resending with a less annoying title and non signed email; Please reply to this email instead to start a thread. My apologies ] I would like to propose a new feature. The NetworkManagerDispatcher should call any scripts found under NM_SCRIPT_DIR (currently hardcoded to '/etc/NetworkManager/dispatcher.d' directory), regardless of the owner. Currently, it only executes scripts owned by root. Scripts would be executed with the EUID set to the user owning the script. This would prevent a user to gain root privileges. But with this feature, users without any admin privileges could add their own scripts. For instance, they could set ssh tunnels when getting connected to a particular network. NM_SCRIPT_DIR would have the sticky bit set, like /tmp. From chmod man page: When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by the directory owner as well as by root or the file owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable. Comments are welcomed. If my proposal is welcomed, I could give a try coding it and submit a patch. Instead of calling system() directly, a fork would be executed, and the child would perform a setuid() call prior calling system(). One advantage of forking is that the daemon would never freeze since only the children would call shell commands. Thus if a shell command loops indefinitely, the main daemon isn't affected. Best regards, Hans Deragon -- === Quidquid latine dictum sit, altum viditur. [Whatever is said in Latin sounds profound.] === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Networkmanager not connecting to known network
On Mon, 2007-07-09 at 10:23 -0400, Alex Janssen wrote: I have been reading the list and snooping around in the files trying to figure this out, but I'm not sure what I'm looking for. I know it is supposed to connect to a known network automatically. It does try but times out. Any help is appreciated. Thanks, Alex Is it a wired or wireless network it is timing out on? -- === Lazlo's Chinese Relativity Axiom: No matter how great your triumphs or how tragic your defeats -- approximately one billion Chinese couldn't care less. === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Temporary solution to NM LEAP glitch.
This is only for people who believe in kludgey solutions to annoying problems. As was decided, LEAP does not work in the current NM in the sense you can configure it and it will connect but never connect on further logins. A solution has been suggested Jon Escombe and eventually it will be included in the distribution. What can you do in the meantime? What I have done is the following. Created a script which removes the directory TrinityAP which represents the LEAP access point in my .gconf directory tree. The next time you can configure the LEAP connection from the beginning and connect; and go on your merry way. Before you log off you must remember to run the script, which completes the kludge solution to the problem. It works but be free to ignore it if you hate kludges. -- === Who goeth a-borrowing goeth a-sorrowing. -- Thomas Tusser === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FR: NetworkManagerDispatcher should fireup scripts owned by any user.
On Sun, 2007-07-08 at 21:02 -0400, Hans Deragon wrote: Greetings. [ Resending with a less annoying title and non signed email; Please reply to this email instead to start a thread. My apologies ] I would like to propose a new feature. The NetworkManagerDispatcher should call any scripts found under NM_SCRIPT_DIR (currently hardcoded to '/etc/NetworkManager/dispatcher.d' directory), regardless of the owner. Currently, it only executes scripts owned by root. There is no such directory on my Fedora 7 machine. What version of Linux is being used? Scripts would be executed with the EUID set to the user owning the script. This would prevent a user to gain root privileges. But with this feature, users without any admin privileges could add their own scripts. For instance, they could set ssh tunnels when getting connected to a particular network. NM_SCRIPT_DIR would have the sticky bit set, like /tmp. From chmod man page: When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by the directory owner as well as by root or the file owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable. Comments are welcomed. If my proposal is welcomed, I could give a try coding it and submit a patch. Instead of calling system() directly, a fork would be executed, and the child would perform a setuid() call prior calling system(). One advantage of forking is that the daemon would never freeze since only the children would call shell commands. Thus if a shell command loops indefinitely, the main daemon isn't affected. Best regards, Hans Deragon -- === First there was Dial-A-Prayer, then Dial-A-Recipe, and even Dial-A-Footballer. But the south-east Victorian town of Sale has produced one to top them all. Dial-A-Wombat. It all began early yesterday when Sale police received a telephone call: You won't believe this, and I'm not drunk, but there's a wombat in the phone booth outside the town hall, the caller said. Not firmly convinced about the caller's claim to sobriety, members of the constabulary drove to the scene, expecting to pick up a drunk. But there it was, an annoyed wombat, trapped in a telephone booth. The wombat, determined not to be had the better of again, threw its bulk into the fray. It was eventually lassoed and released in a nearby scrub. Then the officers received another message ... another wombat in another phone booth. There it was: *Another* angry wombat trapped in a telephone booth. The constables took the miffed marsupial into temporary custody and released it, too, in the scrub. But on their way back to the station they happened to pass another telephone booth, and -- you guessed it -- another imprisoned wombat. After some serious detective work, the lads in blue found a suspect, and after questioning, released him to be charged on summons. Their problem ... they cannot find a law against placing wombats in telephone booths. -- Newcastle Morning Herald, NSW Australia, Aug 1980. === Aaron Konstam telephone: (210) 656-0355 e-mail: [EMAIL PROTECTED] ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FR: NetworkManagerDispatcher should fireup scripts owned by any user.
Aaron Konstam a écrit : On Sun, 2007-07-08 at 21:02 -0400, Hans Deragon wrote: Greetings. [ Resending with a less annoying title and non signed email; Please reply to this email instead to start a thread. My apologies ] I would like to propose a new feature. The NetworkManagerDispatcher should call any scripts found under NM_SCRIPT_DIR (currently hardcoded to '/etc/NetworkManager/dispatcher.d' directory), regardless of the owner. Currently, it only executes scripts owned by root. As usual, I am confused. In Fedora 7 there is no such directory. Are you on another Linux version. Looks like a standard directory. Ubuntu 7.04 and SuSE Linux Enterprise Desktop 10 have it. It is hard coded in: NetworkManager-0.6.5/dispatcher-daemon/NetworkManagerDispatcher.c #define NM_SCRIPT_DIR SYSCONFDIR/NetworkManager/dispatcher.d Scripts would be executed with the EUID set to the user owning the script. This would prevent a user to gain root privileges. But with this feature, users without any admin privileges could add their own scripts. For instance, they could set ssh tunnels when getting connected to a particular network. NM_SCRIPT_DIR would have the sticky bit set, like /tmp. From chmod man page: When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by the directory owner as well as by root or the file owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable. Comments are welcomed. If my proposal is welcomed, I could give a try coding it and submit a patch. Instead of calling system() directly, a fork would be executed, and the child would perform a setuid() call prior calling system(). One advantage of forking is that the daemon would never freeze since only the children would call shell commands. Thus if a shell command loops indefinitely, the main daemon isn't affected. Br, Hans Deragon http://www.deragon.bizOpen source (contribution): mailto://[EMAIL PROTECTED] http://autopoweroff.deragon.biz ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gnome network manager doesn't check dial-up status -- no vpn possible
Roberto Scelzo [EMAIL PROTECTED] writes: On Sat, 2007-07-07 at 17:07 +0530, Ritesh Khadgaray wrote: On Fri, 2007-07-06 at 22:26 +0200, Florian Pressler wrote: Hi there, I'm trying the gnome network manager for the first time these days, and so far I can say that things work quite easily and without much config-hassling. [cut] You could use vpnc from commandline as a workaround. Yes, it's just what I'm doing now...but the very ugly thing is that since nm stays in disconnected mode, many apps switch to offline mode... so I have to use a package built from the svn which has the ability to tell dbus that a connection is available but it isn't stable enough... Is there some dbus command that I can send to manually tell NM or nm-applet that the connection is up? I'd rather not futz around trying to get vpnc to work manually. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FR: NetworkManagerDispatcher should fireup scripts owned by any user.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There was nothing wrong with the original request -- I just personally have nothing to say about it. Sounds like an alright idea, but then again, there may be a reason for things being the way they are -- don't know. Hans Deragon wrote: Greetings. [ Resending with a less annoying title and non signed email; Please reply to this email instead to start a thread. My apologies ] I would like to propose a new feature. The NetworkManagerDispatcher should call any scripts found under NM_SCRIPT_DIR (currently hardcoded to '/etc/NetworkManager/dispatcher.d' directory), regardless of the owner. Currently, it only executes scripts owned by root. Scripts would be executed with the EUID set to the user owning the script. This would prevent a user to gain root privileges. But with this feature, users without any admin privileges could add their own scripts. For instance, they could set ssh tunnels when getting connected to a particular network. NM_SCRIPT_DIR would have the sticky bit set, like /tmp. From chmod man page: When the sticky bit is set on a directory, files in that directory may be unlinked or renamed only by the directory owner as well as by root or the file owner. Without the sticky bit, anyone able to write to the directory can delete or rename files. The sticky bit is commonly found on directories, such as /tmp, that are world-writable. Comments are welcomed. If my proposal is welcomed, I could give a try coding it and submit a patch. Instead of calling system() directly, a fork would be executed, and the child would perform a setuid() call prior calling system(). One advantage of forking is that the daemon would never freeze since only the children would call shell commands. Thus if a shell command loops indefinitely, the main daemon isn't affected. Best regards, Hans Deragon - -- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer III |$| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGksOmmb+gadEcsb4RAkb+AKCBLUP76nr9luM2ubAoMSdKDWDz6wCfakCO wpMC5ajUkOKjhJ7ktCHRZ0I= =99Qa -END PGP SIGNATURE- begin:vcard fn:Ryan Novosielski n:Novosielski;Ryan org:UMDNJ;IST/AST adr;dom:MSB C630;;185 South Orange Avenue;Newark;NJ;07103 email;internet:[EMAIL PROTECTED] title:Systems Programmer III tel;work:(973) 972-0922 tel;fax:(973) 972-7412 tel;pager:(866) 20-UMDNJ x-mozilla-html:FALSE version:2.1 end:vcard ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
