Today there are four Plasma NM versions:
1. Plasma NM for NM-0.8: this one have been in version 0.9 for several years now (even before NM-0.9 was announced), it is supported by us (Plasma NM developers) and is the Plasma NM version shipped by almost all distributions, usually with version 0.9 in its package version although it does *not* work with NM-0.9.
Plasma NM uses Solid's NetworkManager backend to talk to NetworkManager. The directory /usr/src/debug/kdebase-workspace-4.6.3/x86_64-redhat-linux-gnu/solid/networkmanager-0.7/ mentioned in the crash log in the bug entry is the Solid's backend, which is *not* part of Plasma NM source code. In despite of the 0.7 version number the Solid's backend works with both NM-0.7 and NM-0.8. I know, that is confusing already, but there is more...
2. Fedora's own solution to make Plasma NM (for *NM-0.8*) work with *NM-0.9*: this is an in house solution developed by Fedora to make #1 work with NM-0.9. This is the package the bug's reporter uses and it is not supported by us. Fedora guys created that solution because their release schedule did not allow them to wait for us (Plasma NM developers) to create an official solution and they had to ship NM-0.9 because gnome-shell's network management applet requires it. This version is a temporary solution and is going to be phased out when our official solution is ready.
So basicaly the bug's reporter's Plasma NM version 0.9, created to work with NetworkManager 0.8 and Solid's 0.7 backend, has been modified by Fedora guys to talk to NetworkManager 0.9 :-) That is confusing.
3. Plasma NM/branch nm09: this is our intermediate implementation for NM-0.9. Of course it is supported by us. As far as I know Fedora and Arch Linux are the only distributions that ship this version. Fedora 15 includes this one in kde-unstable repository and is the version they ship in Rawhide, the development branch of the next Fedora release.
Solid's 0.9 backend is included in Plasma NM/nm09 branch, so everything here is 0.9: Plasma NM version 0.9, created to work with NetworkManager 0.9 and Solid's 0.9 backend, talks to NetworkManager 0.9 :-) When everybody stops using NM-0.8 things are going to go back to normal, I hope.
4. Plasma NM/branch libnm-qt: this is going to be our official implemenation for NM-0.9. Of course this one is also supported by us, it is not ready yet, I have never tested it myself, and probably no distribution ships it. libnm-qt (version 0.9 I hope) is the replacement for Solid's NM backed 0.9 and simplifies the source code for us developers. There is no user visible differences between #3 and #4 since only the backend is different, the user interface is the same.
The last two are in development stage. I use #3 in my notebook with almost no problems. I just need to clean up the source code and fix one problem with system VPN connections (user VPN connections work). There is also some TODO's in #3 but most people probably do not need them yet and they can be implemented without disturbing users like we have been doing in master branch.
Some people asked me what version they should use. Well, #1 is the only one that works with NM-0.8 so there is no choice here. For NM-0.9 use #3, like me, since #4 is not ready yet. But there is a catch: #3 does not migrate NM-0.8 configuration to NM-0.9 format yet, so you will have to recreate all your connections, that is also the reason Fedora makes it available in kde-unstable instead of kde-testing repository. Since only Fedora ships #2, I think Fedora users should use #2 because there is no settings migration to be done like in #3 and #4. There is no migration between #3 to #4, they use the same configuration files.
I hope this explains the version number mess in Plasma NM. So basically NM-0.9 is our opportunity to make everything use the same version number.
Update: I have implemented in #3 the code to import the Plasma NM's configuration files used in #1 (NM-0.8), just do:
qdbus org.kde.networkmanagement /org/kde/networkmanagement org.kde.networkmanagement.ImportNm08Connections
The qdbus call above is one shot, you will have to restart kded4 to be able to trigger it again. The old configuration files are not deleted so that you can import the connections again, but if you delete the connection using Plasma NM's connection editor the secrets in kwallet will be deleted forever.
When the importer is well tested I am going to change the code to delete the old configuration files.
Update: importer is enabled by default now but old configuration files will not be deleted because of those two nasty bugs. NetworkManager calls our secret agent to save the wrong password, I do not know why that is happening. Last weekd I send an e-mail to NM mailing list asking for help but nobody has answered it yet.
Update: importer is enabled by default now but old configuration files will not be deleted because of those two nasty bugs. NetworkManager calls our secret agent to save the wrong password, I do not know why that is happening. Last weekd I send an e-mail to NM mailing list asking for help but nobody has answered it yet.
17 comments:
I just want to mention that the current version in Archlinux is taken from
http://quickgit.kde.org/?p=networkmanagement.git&a=snapshot&h=997e26d85cb76de9adb18f7ee8894556e3fa2653
with NM 0.8.99*. I don't pretend to understand what this means :)
Nice post though. It could help if you explain what you think people should use and how to check what version is being used...
Yes, Arch Linux uses #3 too. KDE NM solid backend is disabled and it's using networkmanagement from the nm09 branch
http://projects.archlinux.org/svntogit/packages.git/commit/kdebase-workspace/trunk?id=b1cda3ffcbeefb45ba6cfb82a6df5cf87ea7a17f
FYI, we have a snapshot of "3. Plasma NM/branch nm09" available for testing for Fedora 15 in the kde-redhat unstable repository. (It is also the version we ship in Fedora Rawhide, i.e. in the development branch for our next release(s).) But be warned that there is at this time no automatic migration of settings from 2. (what Fedora 15 is shipping) to 3., so anybody testing that option will have to reconfigure their networks (which is why the package sits in kde-unstable and not e.g. kde-testing). Making this migration work is the same problem as migrating user settings from 1. to 3. (our changes do not touch settings storage at all), so it should eventually get done, but it is not currently implemented.
I'm also going to clear up a few things:
* Solution 2. requires changes to both NetworkManager itself (compatibility API) and plasma-NM, which is why it is only a temporary solution.
* It's not that we didn't WANT to wait, it's that we COULDN'T wait. Your official solution only started getting usable a week after the Fedora 15 release, 3+ weeks after the final change deadline. We have a time-based release schedule. What we shipped was the only thing we could ship. (We had to ship NM 0.9 because gnome-shell's network management applet requires it.)
* We want to eventually phase out that custom solution even for Fedora 15 updates and migrate to the official one, but automatic migration of settings (both from the current Fedora 15 (2.) and from Fedora 14 (1.), but as I explained, that's really the same problem) is a major concern for us.
What will be the advantage of #4 over #3? Is #4 no longer using solid? If not, why not?
PS: Thanks a lot for your nm09 work! And sorry for the bug reports filed against the unsupported code, feel free to close those reports as DOWNSTREAM and point reporters to https://bugzilla.redhat.com/ . (You can also tell them about the kde-redhat unstable packages, but then please include a warning about the migration issue.)
@iazzi, 997e26d85cb76de9adb18f7ee8894556e3fa2653 is commit from nm09 branch from May 31. So Arch really uses #3 :-)
@bash, you can install Solid's 0.7 backend together with Plasma NM's 0.9 backend, they do not conflict with each other. Arch Linux did not need to disable Solid's backend. You just need to make sure the correct backend is going to be used with the correct Plasma NM or you could end up with unstable Plasma NM since the backend are not binary compatible.
@toddrme2178, libnm-qt simplifies the source code. There is no visible changes for users, just for us developers.
@Kevin Kofler, ok, I will also update my post to add yor comments.
the only thing that keeps me locked on wicd instead of networkmanager is the capability to run a script before and after connection, and before and after disconnection. Can be implemented in newtowkmanager too? It's necessary (for me) to change dns and mount samba shares in my home connection (and of course not do it in other connections). I think a lot of people will find useless this.
sorry useful not useless :-P
@Andrea You can do this by creating a script in /etc/NetworkManager/dispatcher.d/ directory.
correct me if i'm wrong, the script in that directory will be executed with EVERY connection nm established... right? and you can't control if to execute before OR after connection and disconnection... not exacly the same thing.
For doing what i was needing i was writing a huge script to check if the connection is really the one needed, and still i was without control on when executing it. Umounting of samba shares needs to be done just before disconnection, not after. And this was a problem.
Wicd have this feature built in and it's just easy to configure.
For every pecific connection ---> what to do before and after connection, before and after disconnection.
Yeah as far as I know you can't control if it happens before/after and it does run everytime.
that's why i propose to add this useful function :-)
@Andrea, you should suggest that in NetworkManager mailing list: http://mail.gnome.org/mailman/listinfo/networkmanager-list
Plasma NM and nm-applet are clients for the NM daemon, it is the NM daemon that (dis)connects the network interface, your request should be implemented there. Just to make it clear: we (Plasma NM developers) do not develop NM daemon, we just use it. I do not even have write access to NM source code.
thank you for the answer, i will try to see if there is already a similar request open
Hi!
Andrea,
I would like to say that this is NOT that hard to do this in NM.
See, I have that set UP for me, not actually mount/unmount connections, but to manipulate resolv.conf
If you need some really exotic stuff, well, you can script that easily :)
Here is a little bit of my script:
#!/bin/sh
INTERFACE=$1 # The interface which is brought up or down
STATUS=$2 # The new state of the interface
. /funny/path/to/my/function
case "$STATUS" in
"up") # $INTERFACE is up
exec /etc/rc.d/openntpd start
CUSTOMIZERESOLV start
;;
"down") # $INTERFACE is down
exec /etc/rc.d/openntpd stop
CUSTOMIZERESOLV stop
;;
esac
What I'm saying is not that NM implementation is better / weaker than WICD, but that things can be accomplished with NM as well...
You chould check address ranges to determine that you're at home or AP if that is WIFI network...
regards
Kirurgs
@Anonymous, you did not understand Andrea's problem. He needs to execute his script *before* NM disconnects the interface and NM executes it *after* the disconnection. After the disconnection you cannot unmount the exported directory. For instance, with NFS the "umount " command blocks forever by default when the server is gone. It is very likely wicd supports executing scripts before connect/disconnect events to accomodate that exactly kind of problem. I think NM should do the same.
AND there is another problem, i'm not so good in bash script to make so many conditions inside my script to detect which connections is established and what command(s) to execute.
And if i have 10 connections and maybe in 5-6 of them i need to execute different scripts? Sometimes in connection, sometimes in disconnection... sometimes before sometimes after.
This script would become big as linux kernel!
Post a Comment