My thoughts on Slackware, life and everything

Integrating NetworkManager into KDE while keeping the Gnome out

I think that I am not wrong when I say that Networkmanager is the de-facto way of network configuration management in Linux. Most Linux distributions have implemented it. Slackware on the other hand, traditionally encourages the use of “vi” for network configuration management (by editing “/etc/rc.d/rc.inet1.conf“)… but in recent times, the WICD daemon has been added to the “/extra” directory of Slackware, and that includes a graphical network configuration utility. A lot of (particularly mobile) users like WICD, and so do I.

WICD is for the most part a one-man exercise and the main developer has stated that he is not able to work on the program as much as it deserves. That is not too good news, but I still have hopes for the project.

In the meantime, switching to NetworkManager is not a decision that should be taken lightly. Not because NetworkManager itself will give us issues, but because NM is only the service framework and it does not come with configuration utilities (either GUI or cli oriented – I do not consider the nmcli program adequate) that allow you, the computer’s user, to configure your network connections.

Traditionally, distros will add the “nm-applet” aka “network-manager-applet” to that purpose. The nm-applet is a graphical configuration utility that lives in your desktop’s system tray area. It is being developed by the NetworkManager team. However it is is a Gnome applet, and as such it is riddled with Gnome dependencies. Precisely for that reason it is not trivial to add nm-applet  to Slackware, one of the few Linux distros that does not contain Gnome.

I think that if you are a Slackware GUI lover, you should consider yourself very lucky that the WICD developer team has one passionate Slackware user (NaCl) as member!

Having said all that, I do not have any issues with Networkmanager itself. It’s just the default configuration tool which sucks because of its Gnome allegiance. Hmm, that is not completely true… in the well-known take-a-blunt-knife-and-kill-your-software style of Redhat they managed to break API as well as ABI compatibility with the release of the 0.9 series of NM last august… where did I hear this story before? Like with PolicyKit, HAL and systemd, Redhat managed to cause a lot of fuss when developers decided to throw away their code and start over with fresh insights…

Applications which have been written to interact with the old  0.8 interface of NM have to be re-written and that takes time. At this moment, many NM-aware programs still do not support NM 0.9.

While all of that passed, I have been keeping an eye on what happens in the KDE camp. The KDE software compilation has never had a good network configurator for the 4.x series and the team which was developing KNetworkManager seems to have dissolved. But there is good news: a new networkmanagement plasmoid (KDE widget) plus accompanying KControl is available, it supports NM 0.8.x and is stable enough that I have come to prefer it over WICD.

I have built a set of supporting packages (many thanks to Robby Workman for some of these SlackBuild scripts):

  • NetworkManager (the actual network service framework)
  • cnetworkmanager (a commandline interface to NM if you don’t like the GUI)
  • mobile-broadband-provider-info (world-wide database of mobile access providers)
  • ModemManager (accompanying bradband modem management)

These packages allowed me to recompile the kde-workspace package and make it pick up support for NM in KDE’s solid device management. And finally I added the package for the required configuration GUI, networkmanagement

You can get these packages from my ktown repository or any of its mirrors, I built them for KDE 4.7.2 and you will find them inside the directory called “test“.

You can install these packages (kde-workspace needs to be upgraded of course, not installed a second time) with a single command after downloading the packages appropriate for your hardware architecture (32bit or 64bit). Run the following command in the directory which contains the six packages:

# upgradepkg –install-new *.t?z

And please read the README file which specifies in great detail how to enable NetworkManagement while at the same time disabling WICD!

How does it look in KDE after you rebooted? Well, here is a screenshot:

My goal for the next releases of KDE (in case I will still be building the packages for it) is to compile kde-workspace in the presence of NetworkManager and thus add support for NM to the kde-workspace package. Then it will be up to you if you want to actually switch to NM or keep using WICD. The kde-workspace package will work fine even if you did not install NetworkManager.

Give me feedback! Eric

 

41 Comments

  1. amigib

    Thanks Eric, i wasn’t able to get it work earlier, now works great.
    Integrating Pulseaudio was kinda easy, and now left me only systemd.

  2. Alex

    Sounds good, but let me add that there’s also a WICD client for KDE available from SlackBuilds.org, which provides a KDE frontend. Looks good and works just fine even in KDE 4.5.5: http://slackbuilds.org/repository/13.37/network/wicd-client-kde/.

    Best regards

    Alex

  3. a.key

    One may actually need to preserve wicd as well as network manager.
    In this case to not have the annoying applet pop up with authorization to start up wicd daemon every time user logs on to kde It is required to delete the startup files for wicd applet from /etc/xdg/autostart and /usr/share/autostart.

    This will preserve wicd so that it can be used if required and use network manager as primary network manager.

  4. Arvent

    Nice, Nice and Nice! Very nice indeed. So small thing, but give so much pleasure. Now I do have the feeling that one more ting is set right. Great add-on to KDE and then from you to our beloved Slackware. Thank You very much, Eric!

  5. alienbob

    @a.key

    You can prevent the wicd client from starting when you logon, if you add this line to the .desktop files in /etc/xdg/autostart and /usr/share/autostart :

    NotShowIn=KDE;

    Eric

  6. escaflown

    Works fine here, Eric. Another suggestion: as we have now a testing directory in your kde slackbuilds, could you also add kde-telepathy to the testing directory if dependency allows? I was able to compile it myself using your modular kde script. I juts tought it would be nice to have it all in one place. Thanks!

  7. ArTourter

    Hi Eric

    thank you very much for this, it work beautifully, and with robby’s networkmanager-pptp package from SBO I am now able to access my work’s VPN without hassle.

    Although I do prefer the vi/vim option for desktop and servers, on mobile devices, wicd was a great help, but the extra options of NM makes it a very nice addition to slack.

    Greg

  8. y0g1

    Hi Eric,
    is it possible to run NetworkManager without hal? I saw in ArchLinux, that it could use dbus or hal. In Your packages I get: HAL must be running to start NetworkManager. Is it hard to use networkmanager with dbus support?

  9. alienbob

    @ y0g1

    I have not used HAL in KDE for a long time. So, yes, my NM package can be used without HAL.

  10. Niki Kovacs

    Hi Eric,

    Last summer I experimented quite a bit with laptops and wireless, and after some trial and error, I found a solution that JustWorks(tm). Here’s what it looks like:

    http://www.microlinux.fr/images/networkmanager.png

    Basically it’s just the three packages NetworkManager, network-manager-applet and ModemManager from SBo, with nothing altered. Graphically it integrates nice thanks to oxygen-gtk. On the technical side, it’s rock-solid. I’ve tried Wicd before, but it didn’t work well, since it disconnected every few minutes.

    Now it’s good to know that KDE has a native applet for NetworkManager.

  11. Georgios Vasilakis

    Hi eric,
    excellent post but one question… got any idea of a lightweight(suitable for xfce or windowmaker docker in my xase) non kde client for Nm?

    Thanx

  12. Dray

    hi eric, have you seen my new blog and links to new slab stuff? hope all is well
    steve

  13. alienbob

    Hi Steve !

    I am sorry man, I regularly check your site http://themosesman.blogspot.com/ but I have neglected you… months of silence made me anxious.

    Now I see http://slab-descension.blogspot.com/ has been created. and I know that I have something to read tonight!

    Thanks for visiting, and all you other guys read http://alien.slackbook.org/blog/slab/ for more background.

    Cheers, Eric

  14. Rodrigo L. Fernandez

    Hi, Eric. Thank you for those packages and updated, I’m a big fan of NetworkManager (don’t know why, I just am) and was wating for that a long time.

    Sorry to bother you, though, but I have one question: I have disabled acpi_handler.sh (chmod -x /etc/acpi/acpi_handler.sh) so that I could adjust the KDE power resource actions. With this, I’ve noticed one that, since KDE-4.6, it takes too long to shutdown the laptop via poweroff button (~15s). Is this normal? I’m not complaining, just asking. 🙂

    Thank you again for these great deeds.

  15. dpantaleo

    Thanks Eric, it works perfectly ^_^

  16. dpantaleo

    moreover, WICD caused kernel panics while trying to reconnect a wifi network (even on plain slackware) O_o

  17. Walter

    You start this article with this:

    Slackware on the other hand, traditionally encourages the use of vi
    for network configuration management (by editing
    /etc/rc.d/rc.inet1.conf

    I remember to disable the execution bit in rc.wireless and just add the essid
    and key data to rc.inet1.conf to got my wireless working. Indeed I don’t need
    and dislike the roaming feature. Now rc.inet1 seems to depend of rc.wireless
    to successfully connect the wireless.

    I can see modifications made by you in wireless scripts and, taking in care
    that your big goal seems to be get KDE working I will beg you take in care the
    following:

    The KISS philosophy is what make Slackware the “only” option for people that
    want to “use” the machine. I mean, everybody can do with its time its own; do
    you like to “play” with eye candy desktops? Do it. But, please, let to people
    like me that “only one” option that Slackware give to us. Add what you want to
    get KDE working but don’t touch the basic config files just for this. Please.

    For eye candy desktops and graphical network managers you have Mac OS X that do
    it right (and force you to do it in this way). But with Slackware I prefer,
    for example, just adding this hook to /usr/lib/pm-utils/sleep.d to resume my
    wireless even from console:

    #!/bin/sh
    # sleep and resume rc.inet1

    . “${PM_FUNCTIONS}”

    suspend_nm()
    {
    printf “Stoping rc.inet1…”
    /etc/rc.d/rc.inet1 stop >/dev/null 2>&1 && \
    echo Done. || echo Failed.
    }

    resume_nm()
    {
    printf “Starting rc.inet1…”
    /etc/rc.d/rc.inet1 start >/dev/null 2>&1 && \
    echo Done. || echo Failed.
    }

    case “$1” in
    hibernate|suspend)
    suspend_nm
    ;;
    thaw|resume)
    resume_nm
    ;;
    *) exit $NA
    ;;
    esac
    # End

    Keep It Simple Slackware 😉

  18. tomtomjkw

    Thank you, Eric. Does the NM have any place where it stores its log files? My vpn does not work and I’d like to know why exactly before asking further questions. Messages and syslog do not help much.

  19. alienbob

    Hi Walter

    Long ago, in Slackware 10.0, I added wireless support to rc.inet1:

    Mon Jun 7 00:56:25 PDT 2004

    n/tcpip-0.17-i486-27.tgz: Merged in changes to rc.inet1 to add wireless support and per-interface start/stop/restart (thanks to Eric Hameleers)

    And I do not intend to see this traditional method of (wireless and wired) network configuration disappear or change. In fact I would very much like to expand the functionality of rc.inet1 with bridge support, but that is always vetoed.
    Nevertheless, rc.inet1 will keep working like it has done since Slackware 10.0. By the way, disabling wireless by removing the x bit from rc.wireless was possible only in the very beginning when that file got added. Very quickly I added the code that lets the two scripts (rc.inet1 and rc.wireless) decide for themselves if they are dealing with a wireless interfacee and take appropriate action.

    Enabling support for WICD or NM has always been optional. If you are using a laptop and move a lot, and if you like a GUI configurator, then WICD or NM are nice. On my servers, I only use rc.inet1.

    Eric

  20. notzed

    oh god – just say no. notworkmanager and pulseaudio are the two first things i remove from any new install.

    they both have caused me more headaches than any single aspect of ‘modern’ linux and are a giant step backwards in stability and usability even compared to vi.

  21. alienbob

    @ notzed

    There is no reason to complain – adding NM is still optional for my KDE package set, and you can stick with WICD or the good old rc.inet1 network configuration if you want.

    Making solid pick up NM support does not mean that KDE will suddenly start barfing on you. Also, are your issues related to the Gnome applet, or to NM itself?

    Eric

    Eric

  22. escaflown

    rc.inet1 + NM + wicd = linux freedom

  23. amigib

    I’m using pulseaudio (about month) and now networkmanager, didn’t find any problem so far.
    Networkmanager can be replaced with wicd but pulseaudio (not perfect, high latency) has no reasonable alternative for now.
    Both are just so easy to use

  24. Walter

    Eric

    The traditional method will not disappear while ifconfig and iwconfig exist. I
    can write my own bash scripts to connect the wireless in Slackware, Ubuntu, or
    whatever distro, and remove the software that pretending simplify the task make
    it difficult or impossible. I changed from Debian to Slackware because I got
    tired of Debian init scripts. But I live with the hope of, one day, not be
    forced to rewrite the whole OS each time I reinstall :-).

    By other hand, I must say that in the near past I must to do the same that
    notzed; each time I installed a gnome based distribution I must remove NM to
    get the wireless connected. But the last days I’ve tried some linux liveCDs
    and surprisingly network manager daemon do its job right.

    In my laptop I use IceWM and a simple bash script that call wireless tools to
    scan and connect to available routers. Honestly, I may suffer some Mr Spock
    syndrome or alike that doesn’t let me associate the KISS Unix philosophy with
    KDE or Gnome.

    But, Eric, I am talking in general, don’t take this personally. If you was who
    added the wireless feature to rc.inet1 I appreciate that. Furthermore, if you
    was who made the thing work you even have the right to screw it up :-).
    Please, accept my apologies.

    Walter

  25. alienbob

    @Walter –

    I was not offended at all by your post. In fact, one of my own driving forces is to keep Slackware SIMPLE and ENJOYABLE. You will notice that I try do do this taking two approaches: first by providing a set of additional packages on top of Slackware, like LibreOffice, VLC or an integrated graphical desktop based on KDE. Basically that boils down to finding program source code and compiling that into a useable bunch of packages. Anyone could do that if they took the time.

    But at the same time I spend a lot of time on actual Slackware content – the core scripts – i.e. the things that you cannot find in 3rd party sources.
    This is what I enjoy more than putting together packages like KDE, or LibreOffice, or VLC, … making Slackware actually better than it was.
    The wireless network support in rc.inet1, many many enhancements to the Slackware installer, creating a better mkinitrd package, adding full disk encryption, writing documentation, that is the stuff which I am really passionate about. Slackware is more than the sum of all those nice packaged programs, and I am grateful that I was allowed to contribute to that magical “more than the sum of its parts”.

    Eric

  26. Walter

    Reading your last response now I know you’ll understand my point of view. I
    will explain it by an example. The last year I had a web server running with
    Slackware. It was not too difficult for me to get it working nicely, in part
    because I ENJOY doing it. But besides the enjoyable aspect of the task I had
    clients and a responsibility. And, of course, I had questions and doubts
    about security concerns. The point is I could not found any forum, mailing
    list, or whatever web page where to find people discussing about this. Be sure
    I would find a lot of threads discussing about how to get transparencies at
    some terminal.

    The same I can say about FreeBSD. Search about why in “The power of serve” OS
    the default kernel has not disk quotas compiled. Then search about playing
    games or stupid flame wars about if its better than linux.

    You know what I mean.

    That’s why some times I am a bit rude in the few times I post something. In
    the name of freedom some say “It is just about taste”. No, it is about
    priorities too. You can live in a yellow house in the same way that in a green
    one; but not in a house without a roof.

    Sorry for the off topic and thanks for your response.

    Walter

  27. p431i7o

    Hi Eric!

    I almost never use wicd or NM, because just using vim with /etc/rc.d/rc.inet1.conf was always what I need, and in fact, as I start my slack on init 3 level, the rc.d related to network just work fine, I don’t need any G.U.I. to configure wireless or wired networks, but that doesn’t want to.
    I think that just a little improve of the netconfig command will be enough for us, or just me in this case, I don’t know what the community will say, but that is what I want to say.
    It took a long time to know how, but now, I don’t change for anything that knowledge.
    In my mind, just think that we need a whole Desktop enviroment just to use network connections doesn’t look the right way to do things, and if we can do with ncurses, then why not?

    Cheers, and thanks again, your work make more ease to me make my job.
    thanks again.

  28. djemos

    the link in kde-runtime 64 bit package in all editions of kde since 4.7.0 to 4.7.2 points to no nonsexist path
    look at doinst.sh of the kde-runtime-4.7.2-x86_64 package.
    there is this line ( cd usr/bin ; ln -sf /usr/lib6464/kde4/libexec/kdesu kdesu )

  29. alienbob

    @djemos –

    That is an obvous bug in the SlackBuild script, thanks for catching!
    I will have repaired it in the next release of the package.

    Eric

  30. alienbob

    Hi p431i7o

    I must say, there is an exhanced version of “netconfig” which was written by PiterPUNK three yeats ago (!) but which never became part of Slackware. It adds a lot of functionality which would be good to have inside the installer but also afterwards (support for any interface, not just eth0, and a wireless configurator as well).
    Perhaps PiterPUNK should just make it available for download somewhere.
    Perhaps I should attempt a rewrite.

    Eric

  31. Troy

    Works for me! Thanks a bunch Eric. 😀

  32. jason

    awesome …. for some reason wicd wouldn’t connect to my home wireless Network manager connects first try and stays connected …..

    thank you for everything you do Eric!!!

  33. Cwizardone

    I was finally able to hook up to a broadband connection and download KDE 4.7.2 and the NetworkManager files and it worked as advertised the first time.
    Thank you very much!

  34. Walter

    Eric,

    A very subjective observation: It is difficult to get a stable wireless
    connection with Slackware and I think dhcpcd is the first responsible. I don’t
    remember a good experience with dhcpcd. I remember the knoppix cds that came
    dhcpcd and get a connection was even imposible. Surely I ignore how to use it,
    or I miss some trick; but with my same ignorance I never had problems with
    dhclient.

    So I bother you with just one more question (perhaps more important). Do you
    know why Slackware use dhcpcd instead of dhclient by default? I know it is
    installed too but I ignore the goal of have both dhcp clients installed. Is
    there a Slackware way (I mean changing some option in rc scripts) to change to
    dhclient?

    Thanks in advance

  35. alienbob

    Walter,

    Slackware has always only supported only dhcpcd in its startup script rc.inet1 . It is not trivial to re-wite it to support dhclient instead but you could do it.
    I never had any issues with dhcpcd, but on the other hand I have had nothing but trouble with dhclient…

    There are very few stories like yours, so it would require more detail in your troubleshooting information to make any useful remark about it.

    Eric

  36. greg

    Walter isn’t the only one who ran against trouble with dhcpcd. I recall having some problems with dhcpcd provided in slackware64-13.0. I couldn’t make it working with my modem (BELL WIMAX RSU-2510-RV ). I had to downgrade with the one’s provided in slackware-12.2. After a while I grabbed the release 5.1.2 from Marples’s ftp server and learnt the basics of shell scripting in order to understand the SlackBuilds scripts. Afterwards I sent an email to R.Marples to thank him for his work and to inform that the release 5.1.2 was working fine with slackware64-13.0 but not the 3.2.3 release.

  37. squirrl

    It’s about time 🙂
    WICD is annoying. K3B and NetworkManager make a computer usable. Well that and a good wordprocessor.

    Danka

  38. alienbob

    @squirrl :

    With my upcoming KDE 4.7.3 package set I am also going to ship the “wicd-kde” applet, so that there is even more choice for KDE users.

    🙂 Eric

  39. escaflown

    Hi Eric!
    Cantor can’t find the R backend. I can use the maxima and the octave backends but no luck wit R. Could you confirm that cantor was built with R backend enabled? Thanks!

  40. alienbob

    Hi escaflown.

    The “R” backend will only be built if “R” has been installed first. SInce Slackware does not include “R” this backend will not be built by default.
    This is what the build log for cantor states:

    —————————————————————————–
    — The following OPTIONAL packages could NOT be located on your system.
    — Consider installing them to enable more features from this software.
    —————————————————————————–
    * R <http://www.r-project.org/>
    A free software environment for statistical computing and graphics
    Backend to use R with Cantor.

    —————————————————————————–

    You can easily rebuild cantor of course, after you installed “R”.
    A previous post on my blog contains a thorough description of the KDE build process, it will show you how to rebuild this single package (cantor was splitoff from kdeedu).

    Eric

  41. escaflown

    Thanks Eric!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2024 Alien Pastures

Theme by Anders NorenUp ↑