Fedora 17 x86_64 Cisco Webex Meeting Desktop Sharing

This is a complicated issue made even more complicated by the fact that although I got something "working" I don't yet fully understand all of the details. But assuming that having something working is better than not, then here goes with what I know, even if there are some holes in the understanding.

Given a Fedora 17 x86_64 system, the challenge is to get Cisco Webex Meeting with Desktop Sharing working.

The problem is actually quite easy if you ignore the Desktop Sharing requirement.

All you really need to do is to get Java working along with the Java web plugin, which is sometimes referred to as libjavaplugin.so and sometimes as libnpjp2.so.

I can recommend this page at the "if-not-true-then-false" website. My takes on Java are
  1. I prefer the Sun/Oracle implementation to the open source OpenJDK.
  2. On the above referenced page I prefer the JDK option to the JRE option.
  3. On the above referenced page I prefer the "absolute" version to the "latest" version.
  4. Since I'm running 64 bit Fedora, I obviously prefer the 64 bit version.
  5. If the alternatives install step acts funny I wrote a blog post about how to fix it.  (You basically remove a file in /var/lib/alternatives).
  6. The instructions in the above referenced page need to be followed very carefully and it's important to do one section and one section only - not multiple sections (For example do 64 bit/JDK/absolute only).
  7. You can test your work by going to any number of Java test sites but here's one way to test javaws in particular (previous blog post). 
  8. A better test is actually the Webex Join Test.
But this part is actually fairly easy. The problem is that you can follow all of these instructions to the letter but when it comes time to do Webex Desktop Sharing (either to share or to view another's share) things just won't work. You'll see the "Meeting Center" but you won't see your colleague's desktop.

The reason for this apparently is that Desktop Sharing is exclusively a 32 bit function and it just won't work in a (pure) 64 bit environment.

Some folks have suggested building a 32 bit Firefox/Java sandbox inside of a 64 bit computer and attacking the problem in that way. I actually tried that but couldn't quite make it work but also wasn't all that motivated to make it work for one simple reason.

Purely by happenstance/accident/serendipity I already had Desktop Sharing working on a Fedora 17 x86_64 computer (my desktop), and was really trying to find an answer for my other computer (my laptop).  I knew it could be done, the problem was to reverse engineer what had happened on the desktop that made it work and then transfer that knowledge to the laptop. I should also mention that so far my solution has worked for Firefox only and not for Google Chrome. The browser restriction is not a big deal to me however.

I think at this point it's just a question of cutting to the chase and giving what I think is really a fairly non-intuitive answer but - an answer that works!

The fix turned out to be to install the 32 bit Google Talk Plugin! In my case this had been done on the desktop machine (for reasons unknown but perhaps having to do with the fact that when I did it maybe there was no 64 bit option?).  Google has a page that allows you to grab your plugin of choice and it also configures a repository for you.  As soon as I did this on the laptop, desktop sharing immediately started working for me (Again, Firefox only).

I think that this turns out to be a hack - in the Ubuntu world a similar hack seems to be to install the "ia32-libs" package which pulls in a whole bunch of 32 bit libraries. I won't belabor this post with the RPM and yum commands that I used to convince myself that this was essentially what is also happening here (there is not Fedora ia32-lib package) but I believe this to be the case.

In a further twist once the 32 bit Google Talk Plugin is installed, Google Talk will no longer work inside of the 64 bit browser. No surprise there, actually. However, I was able to successfully uninstall the 32 bit plugin and reinstall the 64 bit one so I could have my Cisco Webex, Shared Desktops as well as the Google Talk Plugin. The uninstall/reinstall cycle had no adverse effect on what I had already achieved with Desktop Sharing.

Admittedly this whole thing is a hack/expedient/workaround (call it what you will) and perhaps having 32 bit and 64 bit libraries coexisting on a system is something to be avoided. All fair enough. But for now I've got a working 64 bit system where all the needed pieces are working as I need them to. That's good enough for me.

Also left unanswered is how exactly the 64 bit browser and its 64 bit Java plugin is able to talk to the 32 bit libraries that I pulled down in this manner. Since this is all happening inside of Java, there don't seem to be any easy ways to get at this question. Maybe if and when I learn more I'll either add to this post or create a new one.

Addendum: This functionality broke around the time I upgraded from Fedora 17 to Fedora 18 but now it's working fine on Fedora 18. The current setup is

  • Oracle Java configured via alternatives.
  • Use Firefox browser for webex.
  • Of course still need the requisite 32 bit libraries.
  • Installed the IcedTea plugin in ~/.mozilla/plugins directory
                      libjavaplugin.so -> /usr/lib64/IcedTeaPlugin.so

This seems like a sort of hybrid, cobbled together approach and indeed it is! Nevertheless it continues to work like a charm!

Addendum #2: This broke again (grrrr) and I think it happened around the time Fedora 18 upgraded icedtea-web to version 1.4-0 (from version 1.3.1-1).  The version change is more or less apparent to the user because with the new version the IcedTea Splash screen appears in your browser window when the plugin starts - this did not used to be the case. I suspected that the upgrade was the culprit but for reasons I still don't understand a downgrade did not fix the behavior. When things are busted icedtea won't even start (more grrrr) - instead you get an error with tracebacks that you can see here

https://bugzilla.redhat.com/show_bug.cgi?id=966401

In fact the problem did turn out to be the above referenced bug. I disabled selinux (edit /etc/selinux/config), rebooted, and all worked as before. Admittedly I'd rather have found a less invasive fix AND if I knew more about selinux I could probably configure selinux to ignore this one case but for the time being if I run the selinux "getenforce" it returns "Disabled" and my Webex app and Desktop Sharing all work as before!

The folloing exception has occured. For more information, try to launch the browser from the command line and examine the output.
For even more information you can visit http://icedtea.classpath.org/wiki/IcedTea-Web and follow the steps described there on how to obtain necessary information to file bug

These are the tracebacks from when IcedTea fails to run:
Another available info:
IcedTea-Web Plugin version: 1.4 (fedora-0.fc18-x86_64)
 6/5/13 10:11 AM 
Exception was: 
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:789)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:717)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:969)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Unknown Main-Class. Could not determine the main class for this application.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:708)
at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:249)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:382)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:444)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:420)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:755)
... 2 more
This is the list of exceptions that occurred launching your applet. Please note, those exceptions can originate from multiple applets. For a helpful bug report, be sure to run only one applet. 
1) at 6/5/13 10:11 AM
net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Unknown Main-Class. Could not determine the main class for this application.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:708)
at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:249)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:382)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:444)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:420)
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:755)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:717)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:969)
2) at 6/5/13 10:11 AM
net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize applet. For more information click "more information button".
at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:789)
at net.sourceforge.jnlp.Launcher.getApplet(Launcher.java:717)
at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:969)
Caused by: net.sourceforge.jnlp.LaunchException: Fatal: Application Error: Unknown Main-Class. Could not determine the main class for this application.
at net.sourceforge.jnlp.runtime.JNLPClassLoader.initializeResources(JNLPClassLoader.java:708)
at net.sourceforge.jnlp.runtime.JNLPClassLoader. (JNLPClassLoader.java:249)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.createInstance(JNLPClassLoader.java:382)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:444)
at net.sourceforge.jnlp.runtime.JNLPClassLoader.getInstance(JNLPClassLoader.java:420)

at net.sourceforge.jnlp.Launcher.createApplet(Launcher.java:755)



6 comments

Popular posts from this blog

Hit failing alternator with a hammer to confirm diagnosis of failing alternator due to bad brushes

alternatives --install gets stuck: failed to read link: No such file or directory

Using SSH, SOCKS, tsocks, and proxy settings to create a simultaneous "dual use" work/home computer