Re: Is there going to be a release of network-manager-applet for GNOME 2.18?
Michael Biebl wrote: Dan Williams wrote: On Tue, 2007-03-06 at 00:39 +0100, Michael Biebl wrote: [..] I don't recommend to split the small nm-vpn-properties utility into a separate svn tree and tarball but simply move it from network-manager to network-manager-applet before 0.6.5 is released. That's a good point I guess. The main reason stuff like this didn't happen was because there wasn't a great need at the time, and there wasn't a lot of time to make it happen. But that's not really an excuse. What would your proposed directory structure look like after moving the properties app over? Hi Dan, sorry for the late reply. Please see the attached patches against NetworkManager-0.6 and network-manager-applet-0.6. The first one removes all traces of Gnome dependencies from NetworkManager, which is a good thing imho. The second patch moves the nm-vpn-properties files (together with the needed changes for configure.ac, po/POTFILES.in etc.) to network-manager-0.6/src/vpn-properties. Both packages still pass make distcheck and with a bit of luck also apply against the NetworkManager and network-manager-applet trunk. The only issue now is with nm-vpn-ui-interface.h, which is now in network-manager-applet. So if you want to build the vpn plugins with Gnome support, you have to install network-manager-gnome to get the header. But in a way, this also makes sense and is consistent. I really hope you consider this patches. Hmm, no response so far. Dan, Tambet, do you have any objections against these patches or just haven't had time yet to look at them? I can't stress that too much, but from a packaging POV it would really be beneficial if all gnome dependencies were moved into a single, separate package/tarball. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
I think something similar to this is planned for .7 so that users can publish settings system-wide and they are activated at boot On 3/15/07, Cindy [EMAIL PROTECTED] wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. --Cindy ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. Nope! As you say, that's a security issue. Instead you'll be able to publish a configuration to system settings so that it's available to everyone on the system (or just you if it's single-user) and therefore available for NetworkManager to use when the computer boots up, not just when you log in. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
I think something similar to this is planned for .7 so that users can publish settings system-wide and they are activated at boot Will there be also the possibility to deactivate wireless system-wide, so that it is not activated during boot? Just a curiosity. Is there a ReleaseSchedule for network manager? thank you. Nicolò ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
On Thu, 2007-03-15 at 08:11 -0400, Dan Williams wrote: On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. Nope! As you say, that's a security issue. Instead you'll be able to publish a configuration to system settings so that it's available to everyone on the system (or just you if it's single-user) and therefore available for NetworkManager to use when the computer boots up, not just when you log in. Random curiosity. Waht is the planned mechanism for storing the published WEP/WPA keys? I haven't found any documentation online, other than the preferences are getting published in the main gconf repo. Jon Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Clarification on SVN storage of NetworkManager versions
Am I to conclude that the NetwoprkManager source is now stored in a Subversion database rather than CVI. How does one download a binary version of NetworkManager from the SVN database? -- === Yow! Are we laid back yet? === 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: [RFC] nm-openswan
steve-210 wrote: Does anyone have need for this type of plugin, or is this software only useful for me? Yes, and no! I would absolutely love this. I am using Ubuntu Linux at the moment and I'm loving network-manager, now with VPN support. Unfortunately, I can't connect to my VPN at work using OpenVPN. OpenSwan only. If you could hack this into network-manager, I think it could be a huge time saver for a good amount of people. -- View this message in context: http://www.nabble.com/nm-openswan-tf3366858.html#a9483353 Sent from the Gnome - NetworkManager mailing list archive at Nabble.com. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
On Thu, 2007-03-15 at 08:46 -0400, Jon Nettleton wrote: On Thu, 2007-03-15 at 08:11 -0400, Dan Williams wrote: On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. Nope! As you say, that's a security issue. Instead you'll be able to publish a configuration to system settings so that it's available to everyone on the system (or just you if it's single-user) and therefore available for NetworkManager to use when the computer boots up, not just when you log in. Random curiosity. Waht is the planned mechanism for storing the published WEP/WPA keys? I haven't found any documentation online, other than the preferences are getting published in the main gconf repo. Well, given the fact that the keys have to be available to the system when there is no possibility of user-interaction for a password/passphrase, any necessary authentication information (keys, certificate passphrases, VPN passwords, etc) will be stored unencrypted in files owned by and r/w only by root, at least in the stock implementation. That's about as good as you can get, since if somebody has root on your box you're pretty much screwed anyway. That's the price you pay not sitting in front of the box when you want the network to come up. Technically the info-daemon for whatever desktop you're using will be able to store the keys as it sees fit. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Clarification on SVN storage of NetworkManager versions
On Thu, 2007-03-15 at 08:38 -0500, Aaron Konstam wrote: Am I to conclude that the NetwoprkManager source is now stored in a Subversion database rather than CVI. How does one download a binary version of NetworkManager from the SVN database? SVN is source control, there are no binaries in NM SVN. Try here: http://developer.gnome.org/tools/svn.html Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
That's excellent -- all I want is not to be futzing with entering a password in that keyring, however that is implemented. When is this planned to be released? --Cindy On 3/15/07, Dan Williams [EMAIL PROTECTED] wrote: On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. Nope! As you say, that's a security issue. Instead you'll be able to publish a configuration to system settings so that it's available to everyone on the system (or just you if it's single-user) and therefore available for NetworkManager to use when the computer boots up, not just when you log in. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
If you just want to avoid entering the password after logon, you could also look at pam_keyring which will silently give it the logon password.. Regards, Jon. - Original Message - That's excellent -- all I want is not to be futzing with entering a password in that keyring, however that is implemented. When is this planned to be released? --Cindy ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
On Thu, 2007-03-15 at 07:06 -0700, Cindy wrote: That's excellent -- all I want is not to be futzing with entering a password in that keyring, however that is implemented. When is this planned to be released? Cindy, Right now you can have your keyring unlocked at login using pam_keyring. Most the distributions have it packaged at this point. If you have questions about it you can contact me off the list ( I am the current maintainer ). Jon --Cindy On 3/15/07, Dan Williams [EMAIL PROTECTED] wrote: On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. Nope! As you say, that's a security issue. Instead you'll be able to publish a configuration to system settings so that it's available to everyone on the system (or just you if it's single-user) and therefore available for NetworkManager to use when the computer boots up, not just when you log in. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[no subject]
Hallo everybody. I found network manager which seems to be really interesting piece of software. I just want to understand several thinks about it, and especially about the dhcp, which I was not able to find discussion forum (as the search engine is probably broken). So, if I understand it, networkmanager talks to (controls) dhcdbd daemon through dbus, and dhcdbd controls ISP dhcp client (by the means of some dhcp client's protocol): dhcp-client ---client's protocol--- dhcdbd ---dbus--- networkmanager The manager then, by default when ethernet cable is plugged in, instructs the dhcp-client to obtain address from that interface (or assigns static address as I think is planned to 0.7 release). When the cable is unplugged and wireless connection is required by user, the namager instructs dhcp client to obtain address from wireless-related dhcp server (or optionally sets static address to wifi interface). Or the dhcp client is instructed to listen on another interface (e.g. wifi in addition to ethernet cable). - First question is - does the manager support more wired connections? Well, I know that not many laptops have several network cards, but I can imagine the case when users will use it on their desktops serving as interner routers at home (I did it some time ago). - Second question is, if the namager removes the address when ethernet cabel is unplugged, as 'ifplugd' daemon does? (http://0pointer.de/lennart/projects/ifplugd/). - Third question, does the manager provide means of starting/stopping dhcp daemons when there is no network connection required? E.g. when user disables it, or when no cable is plugged and no wireless is either in range or required by user? I ask because I guess users may not require to have unncessarry daemons running when theyr's laptops are running on bateries (even if dhcp probably does not consume much energy). I would like to know more about the way of dhcp contol. It is because I use 'dhcpcd' client, really small daemon default in gentoo distribution. I was thinking about the extension of this dhcp daemon to be controllable directly through dbus from the manager (build optionally). But I did not found any written specification, just the source codes. Is it possible to find something somewhere? I know that it is definitelly NOT the most important think to do in the network manager project, it also may not be neccessary when ISP dhcp client is working, but it would be nice to have a choice (which linux is about) ;-) - So, do you plan to establish (or is it established) a dbus 'protocol' how network manager will control dhcp? Either directly or through some inter-layer daemon? - And what about 'pppd' or other similar daemons? I have notice that modem connection through pppd is supported, but the pppd could also be controlled through dbus (which would be really great integration). They should also not be started before they are required. - And the last question - do you plan support other interfaces like bluetooth or irda in a future? Sorry for such a long mail, I have become very interested in the project, so I really wanted to ask. Thank you very much for your aswers, Dan -- Nenechte se nachytat! Internet nemusí být drahý. Připojte se s VOLNÝ od 349 Kč. Více informací na http://adsl.volny.cz nebo na telefonu 800 880 842. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
On Thu, 2007-03-15 at 10:42 -0400, Jon Nettleton wrote: On Thu, 2007-03-15 at 09:52 -0400, Dan Williams wrote: On Thu, 2007-03-15 at 08:46 -0400, Jon Nettleton wrote: On Thu, 2007-03-15 at 08:11 -0400, Dan Williams wrote: On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. Nope! As you say, that's a security issue. Instead you'll be able to publish a configuration to system settings so that it's available to everyone on the system (or just you if it's single-user) and therefore available for NetworkManager to use when the computer boots up, not just when you log in. Random curiosity. Waht is the planned mechanism for storing the published WEP/WPA keys? I haven't found any documentation online, other than the preferences are getting published in the main gconf repo. Well, given the fact that the keys have to be available to the system when there is no possibility of user-interaction for a password/passphrase, any necessary authentication information (keys, certificate passphrases, VPN passwords, etc) will be stored unencrypted in files owned by and r/w only by root, at least in the stock implementation. That's about as good as you can get, since if somebody has root on your box you're pretty much screwed anyway. That's the price you pay not sitting in front of the box when you want the network to come up. I find it somewhat amusing that with all the badmouthing of the ifup scripts storing the encryption keys unencrypted on the filesystem, we are right back to the same place. But like you said above, that is just how it has got to be. Will this mean that NetworkManager will be accepting patches to extend compatibility with existing network profile storage systems? I have had a Configuration daemon and patches I have been using for months now, that I didn't release because everyone seemed so down on the ideas. Perhaps. The problem is that distros have all sorts of configuration littered all over the system in different formats. The info-daemon needs to deliver the information to NetworkManager in a fairly specific format, but it doesn't really matter where it gets that information. I'll give you an example of the problem on Fedora. Fedora's network config lives in /etc/sysconfig/network-scripts, and each device gets an 'ifcfg-X' file that for wireless devices lists things like device type, MAC address, and wireless settings including encryption key, SSID, etc. That's totally unsuitable for NetworkManager, because it allows only one connection to be tied to the wireless device. It's just not flexible enough of a format to contain multiple connections for different wireless networks. So for Fedora, I don't think we'll use the /etc/sysconfig/network-scripts files at all, and we'll have to create a more flexible format. We may need to have 'backends' for each distro in the system-wide info daemon, sort of like we have now for the core NM daemon. Or runtime-loadable GModules or something. Or, each distro can write their own system info-daemon to parse their specific network config into the format that NM requires over D-Bus. Technically the info-daemon for whatever desktop you're using will be able to store the keys as it sees fit. I would hope that we could move to a point where a system smart card could be used to unlock an encrypted storage system. It isn't perfect, but you know that if you ditch a hard-drive or old computer your stuff your secrets will be a little more secure. Yeah, that would be nice. And if the distro supports that, I'd expect that the info-daemon could easily be extended to work with that. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
On Thu, 2007-03-15 at 11:08 -0400, Dan Williams wrote: On Thu, 2007-03-15 at 10:42 -0400, Jon Nettleton wrote: On Thu, 2007-03-15 at 09:52 -0400, Dan Williams wrote: On Thu, 2007-03-15 at 08:46 -0400, Jon Nettleton wrote: On Thu, 2007-03-15 at 08:11 -0400, Dan Williams wrote: On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. Nope! As you say, that's a security issue. Instead you'll be able to publish a configuration to system settings so that it's available to everyone on the system (or just you if it's single-user) and therefore available for NetworkManager to use when the computer boots up, not just when you log in. Random curiosity. Waht is the planned mechanism for storing the published WEP/WPA keys? I haven't found any documentation online, other than the preferences are getting published in the main gconf repo. Well, given the fact that the keys have to be available to the system when there is no possibility of user-interaction for a password/passphrase, any necessary authentication information (keys, certificate passphrases, VPN passwords, etc) will be stored unencrypted in files owned by and r/w only by root, at least in the stock implementation. That's about as good as you can get, since if somebody has root on your box you're pretty much screwed anyway. That's the price you pay not sitting in front of the box when you want the network to come up. I find it somewhat amusing that with all the badmouthing of the ifup scripts storing the encryption keys unencrypted on the filesystem, we are right back to the same place. But like you said above, that is just how it has got to be. Will this mean that NetworkManager will be accepting patches to extend compatibility with existing network profile storage systems? I have had a Configuration daemon and patches I have been using for months now, that I didn't release because everyone seemed so down on the ideas. Perhaps. The problem is that distros have all sorts of configuration littered all over the system in different formats. The info-daemon needs to deliver the information to NetworkManager in a fairly specific format, but it doesn't really matter where it gets that information. I'll give you an example of the problem on Fedora. Fedora's network config lives in /etc/sysconfig/network-scripts, and each device gets an 'ifcfg-X' file that for wireless devices lists things like device type, MAC address, and wireless settings including encryption key, SSID, etc. That's totally unsuitable for NetworkManager, because it allows only one connection to be tied to the wireless device. It's just not flexible enough of a format to contain multiple connections for different wireless networks. So for Fedora, I don't think we'll use the /etc/sysconfig/network-scripts files at all, and we'll have to create a more flexible format. This is an interesting misconception. You can name those scripts ifcfg-whateveryouwant and they will work fine. The device variable that is specified inside the file is really what is important. Way back when like 4 years ago, pre-NetworkManager I actually had patches to ifup that allowed wireless scanning and choosing the proper ifup-device_essid file as a config. All configurations were configured and managed through system-config-network. We may need to have 'backends' for each distro in the system-wide info daemon, sort of like we have now for the core NM daemon. Or runtime-loadable GModules or something. Or, each distro can write their own system info-daemon to parse their specific network config into the format that NM requires over D-Bus. So this is how I wrote my hack Configuration/Info daemon, whatever you want to call it. I don't actually read any of the scripts directly. I have tool similar to ip/ifconfig or iwconfig that that runs on the commandline and talks over dbus to the info daemon. This makes it really easy to adapt whatever backend you have without having to rewrite code all the time. As a system administrator it is also nice to be able to manipulate ip configurations without the need to have a gui. Technically the info-daemon for whatever desktop you're using will be able to store the keys as it sees fit. I would hope that we could move to a point where a system smart card could be used to unlock an encrypted storage system. It isn't perfect, but you know that if you ditch a hard-drive or old computer your stuff your secrets will be a little more secure. Yeah, that would be nice. And if the distro supports that, I'd expect
Re: keyring manager
On Thu, 2007-03-15 at 11:35 -0400, Jon Nettleton wrote: On Thu, 2007-03-15 at 11:08 -0400, Dan Williams wrote: On Thu, 2007-03-15 at 10:42 -0400, Jon Nettleton wrote: On Thu, 2007-03-15 at 09:52 -0400, Dan Williams wrote: On Thu, 2007-03-15 at 08:46 -0400, Jon Nettleton wrote: On Thu, 2007-03-15 at 08:11 -0400, Dan Williams wrote: On Wed, 2007-03-14 at 23:29 -0700, Cindy wrote: I'm sure this has been asked before. Are there any plans to make Network Manager's use of the keyring optional? I understand the security issues, and certainly NM should default to using the keyring. But an option to turn it off would, I'm sure, be appreciated by many. Nope! As you say, that's a security issue. Instead you'll be able to publish a configuration to system settings so that it's available to everyone on the system (or just you if it's single-user) and therefore available for NetworkManager to use when the computer boots up, not just when you log in. Random curiosity. Waht is the planned mechanism for storing the published WEP/WPA keys? I haven't found any documentation online, other than the preferences are getting published in the main gconf repo. Well, given the fact that the keys have to be available to the system when there is no possibility of user-interaction for a password/passphrase, any necessary authentication information (keys, certificate passphrases, VPN passwords, etc) will be stored unencrypted in files owned by and r/w only by root, at least in the stock implementation. That's about as good as you can get, since if somebody has root on your box you're pretty much screwed anyway. That's the price you pay not sitting in front of the box when you want the network to come up. I find it somewhat amusing that with all the badmouthing of the ifup scripts storing the encryption keys unencrypted on the filesystem, we are right back to the same place. But like you said above, that is just how it has got to be. Will this mean that NetworkManager will be accepting patches to extend compatibility with existing network profile storage systems? I have had a Configuration daemon and patches I have been using for months now, that I didn't release because everyone seemed so down on the ideas. Perhaps. The problem is that distros have all sorts of configuration littered all over the system in different formats. The info-daemon needs to deliver the information to NetworkManager in a fairly specific format, but it doesn't really matter where it gets that information. I'll give you an example of the problem on Fedora. Fedora's network config lives in /etc/sysconfig/network-scripts, and each device gets an 'ifcfg-X' file that for wireless devices lists things like device type, MAC address, and wireless settings including encryption key, SSID, etc. That's totally unsuitable for NetworkManager, because it allows only one connection to be tied to the wireless device. It's just not flexible enough of a format to contain multiple connections for different wireless networks. So for Fedora, I don't think we'll use the /etc/sysconfig/network-scripts files at all, and we'll have to create a more flexible format. This is an interesting misconception. You can name those scripts Huh. That certainly does make more sense :) So they might be able to fit in somewhere after all. I'm still unconvinced they could be used as a carrier for all the config info NM would put into them, plus we'd still need a place for VPN and whatnot. We'll see. ifcfg-whateveryouwant and they will work fine. The device variable that is specified inside the file is really what is important. Way back when like 4 years ago, pre-NetworkManager I actually had patches to ifup that allowed wireless scanning and choosing the proper ifup-device_essid file as a config. All configurations were configured and managed through system-config-network. We may need to have 'backends' for each distro in the system-wide info daemon, sort of like we have now for the core NM daemon. Or runtime-loadable GModules or something. Or, each distro can write their own system info-daemon to parse their specific network config into the format that NM requires over D-Bus. So this is how I wrote my hack Configuration/Info daemon, whatever you want to call it. I don't actually read any of the scripts directly. I have tool similar to ip/ifconfig or iwconfig that that runs on the commandline and talks over dbus to the info daemon. This makes it really easy to adapt whatever backend you have without having to rewrite code all the time. As a system administrator it is also nice to be able to manipulate ip configurations without the need to have a gui. I don't think I quite
Re: keyring manager
On Thu, 2007-03-15 at 14:50 -0400, Nathaniel McCallum wrote: On Thu, 2007-03-15 at 14:16 +, Jon Escombe wrote: If you just want to avoid entering the password after logon, you could also look at pam_keyring which will silently give it the logon password.. Which doesn't work if you are using a non-password based login technique (key, fingerprint, etc). Is this still the case? I know back in August the guys from pam_bioapi were working on embedding an encrypted password in the biometric signature file. This would enable the biometric scanner to then unencrypt it and pass that along in the pam stack as PAM_AUTHTOK for the other services that needed it. Jon Nathaniel ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
Nathaniel McCallum wrote: On Thu, 2007-03-15 at 14:16 +, Jon Escombe wrote: If you just want to avoid entering the password after logon, you could also look at pam_keyring which will silently give it the logon password.. Which doesn't work if you are using a non-password based login technique (key, fingerprint, etc). Nathaniel Indeed, I have that exact issue when using the fingerprint reader to logon. But as far as I know that's a gnome-keyring limitation.. Perhaps one day it will support real PAM authentication instead of expecting a password? Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
Jon Nettleton wrote: On Thu, 2007-03-15 at 14:50 -0400, Nathaniel McCallum wrote: On Thu, 2007-03-15 at 14:16 +, Jon Escombe wrote: If you just want to avoid entering the password after logon, you could also look at pam_keyring which will silently give it the logon password.. Which doesn't work if you are using a non-password based login technique (key, fingerprint, etc). Is this still the case? I know back in August the guys from pam_bioapi were working on embedding an encrypted password in the biometric signature file. This would enable the biometric scanner to then unencrypt it and pass that along in the pam stack as PAM_AUTHTOK for the other services that needed it. It's still the case when using pam_thinkfinger at least... Perhaps I'm just missing a better way to configure it all? Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Clarification on SVN storage of NetworkManager versions
Hello Aaron, Aaron Konstam wrote: Lets try again. CVI = CVS And the question is how does one download a src version of NM in order to compile it from a SVN database? From: http://developer.gnome.org/tools/svn.html Just type: svn co http://svn.gnome.org/svn/NetworkManager/trunk --Pat ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: keyring manager
On Thu, 2007-03-15 at 19:09 +, Jon Escombe wrote: Jon Nettleton wrote: On Thu, 2007-03-15 at 14:50 -0400, Nathaniel McCallum wrote: On Thu, 2007-03-15 at 14:16 +, Jon Escombe wrote: If you just want to avoid entering the password after logon, you could also look at pam_keyring which will silently give it the logon password.. Which doesn't work if you are using a non-password based login technique (key, fingerprint, etc). Is this still the case? I know back in August the guys from pam_bioapi were working on embedding an encrypted password in the biometric signature file. This would enable the biometric scanner to then unencrypt it and pass that along in the pam stack as PAM_AUTHTOK for the other services that needed it. It's still the case when using pam_thinkfinger at least... Perhaps I'm just missing a better way to configure it all? Quick follow up for the records. pam_bioapi does indeed allow for the storage of a password in the fingerprint. It is not secured yet, but I think they are working on that. This functionality does allow a person to authenticate with their finger and then the pam_bioapi module will pass the stored password down the pam stack. I hope this helps someone out. Jon Regards, Jon. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Interface Feedback requested please
On 3/15/07, steve [EMAIL PROTECTED] wrote: Hi all, I've attached a screenshot (57 KB) of my Plugin's connection properties interface. I know there's a lot going on , but IPsec connections have a lot of config details (hence the expanders). I'm only going to support the options I need to test for now. Others may follow. All feedback welcome. Thanks, steve. I think you did a pretty good job getting all the options into the space, for people with no experience it might be pretty intimidating though I can't think of a better layout ;-) How does it fit on lower resolution screens like 1024x768? ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Interface Feedback requested please
On 3/15/07, steve [EMAIL PROTECTED] wrote: Hi all, I've attached a screenshot (57 KB) of my Plugin's connection properties interface. I know there's a lot going on , but IPsec connections have a lot of config details (hence the expanders). I'm only going to support the options I need to test for now. Others may follow. All feedback welcome. Thanks, steve. I just saw some posts that indicate that OpenSwan might allow client connections with Nortel concentrators. If this is true then your plugin will be GREAT for people who have Contivity's at work. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Interface Feedback requested please
On Thu, 2007-03-15 at 20:46 -0400, steve wrote: Hi all, I've attached a screenshot (57 KB) of my Plugin's connection properties interface. I know there's a lot going on , but IPsec connections have a lot of config details (hence the expanders). I'm only going to support the options I need to test for now. Others may follow. All feedback welcome. I'm actually going to commit Jon's patch which moves 'advanced' VPN GUI options into a button and additional dialog rather than an expander. Works a lot better on smaller screens, and is a whole lot less intimidating. Any chance you could hide the less frequently used options underneath that button? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: New OpenVPN interface
On Sat, 2007-02-24 at 19:11 -0500, Jon Nettleton wrote: Attached are the patches to the openvpn gui I promised. I think they provide a simplistic default interface with the ability to expose the numerous configuration options needed by the vpn clients. Some Notes: The patch against trunk includes my fixes to make import-export work properly as well as the gui changes. I read up on the details of the Direction flag for TLS-Auth, and apparently it can be any of those options. Most the how-to's show Server as 0 and Client as 1 but really the client just has to be the opposite of the server, or both could be none. So for now I will leave those radio buttons in the config. The advanced dialog is modal and transient on the nm-vpn-properties window. I couldn't find a quick and easy way to figure out if it was launched from a druid or editor window. Committed to trunk and stable, thanks. If you want to take a stab at the other two, feel free :) Thanks! Dan Todo's If people are generally happy with this approach then give a nod and I will work on updating the other vpn clients to match. Add other options to the vpn clients. ( If people could bugzilla these I would appreciate it ). Questions/Comments? Jon ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
