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)

Comments

Anonymous said…
Hi, could you please elaborate a little about which specific 32-libraries were missing and prevented webex desktop sharing from working? A friend of mine is dealing with the same issue at work....

Nick
January 24, 2013 at 3:13 AM
John Glotzer said…
I actually don't know - I think I'd have to do some digging through my yum logs and maybe I could figure it out - maybe not. I may get to that one of these days. Sorry I couldn't be more helpful.
January 24, 2013 at 6:13 AM
John Glotzer said…
Here's some info from my yum logs - AFAICT these are the dependencies that got pulled in ...

Packages Altered:
Dep-Install atk-2.4.0-1.fc17.i686 @fedora/17
Dep-Install audit-libs-2.2.1-1.fc17.i686 @fedora/17
Dep-Install avahi-libs-0.6.31-5.fc17.i686 @updates/17
Dep-Install cups-libs-1:1.5.4-2.fc17.i686 @updates/17
Dep-Install gdk-pixbuf2-2.26.1-1.fc17.i686 @fedora/17
Install google-talkplugin-3.6.1.0-1.i386 @/google-talkplugin_current_i386/17
Dep-Install gtk2-2.24.11-1.fc17.i686 @updates/17
Dep-Install jasper-libs-1.900.1-19.fc17.i686 @fedora/17
Dep-Install libXcomposite-0.4.3-3.fc17.i686 @fedora/17
Dep-Install libpng-compat-2:1.5.10-1.fc17.i686 @fedora/17
Dep-Install libv4l-0.8.8-2.fc17.i686 @updates/17
January 28, 2013 at 6:25 PM
Anonymous said…
Just do this:
yum install libXmu.i686
April 11, 2013 at 8:37 AM
himanshu jani said…
can you please tell me what are requisite 32 bit librarires needed for desktop sharing. I am badly in need to get this working as my final project review is going to happen on webex.
June 13, 2013 at 7:23 PM
John Glotzer said…
A colleague did a variation of this:

ldd `find /home/someuser/.webex/ -name \*.so`

and then unique-afied this list.

He got this. Your mileage may definitely vary - this stuff is more black magic then
it is an exact science.

atascli2.so:
atascli.so:
atgzip.so:
atjpeg.so:
atpng.so:
ld-linux.so.2
libasound.so.2
libatdv.so:
libatk-1.0.so.0
libcairo.so.2
libcmcrypto_jni.so:
libc.so.6
libdbr.so:
libdl.so.2
libexpat.so.1
libffi.so.6
libfontconfig.so.1
libfreetype.so.6
libgcc_s.so.1
libgdiplus.so:
libgdk_pixbuf-2.0.so.0
libgdk-x11-2.0.so.0
libgio-2.0.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
libgtk-x11-2.0.so.0
libICE.so.6
libjawt.so
libmmaud.so:
libmmsvid.so:
libmsess.so:
libm.so.6
libnsl.so.1
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpangox-1.0.so.0
libpangoxft-1.0.so.0
libpcre.so.3
libpixman-1.so.0
libpng12.so.0
libpthread.so.0
libresolv.so.2
librt.so.1
libselinux.so.1
libSM.so.6
libstdc++.so.6
libtpwrap.so:
libuuid.so.1
libwbxtrace.so:
libX11.so.6
libXau.so.6
libxcb-render.so.0
libxcb-shm.so.0
libxcb.so.1
libXcomposite.so.1
libXcursor.so.1
libXdamage.so.1
libXdmcp.so.6
libXext.so.6
libXfixes.so.3
libXft.so.2
libXinerama.so.1
libXi.so.6
libXmu.so.6
libXrandr.so.2
libXrender.so.1
libXt.so.6
libXtst.so.6
libXv.so.1
libz.so.1
linux-gate.so.1
welsdec.so:
June 13, 2013 at 7:33 PM
Post a Comment

Popular posts from this blog

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

Hitting something with a hammer often feels good but does nothing useful. Here's one case where it actually helps. On my 2004 Ford Explorer the alternator light came on. I brought it to the auto parts store and they put a volt meter on it. The alternator needs to put out a voltage that is higher than the battery's full charged voltage in order to properly function - somewhere in the 14 volt range. Mine came in low - probably below 13.5 volts. So the guy at the auto parts store took a rubber mallet to the alternator and just briefly, for a period of 10 seconds or maybe less the voltage jumped up into the normal range before falling back to where it was before. This confirmed the diagnosis of a bad alternator in general and worn brushes in particular. The brushes are spring loaded, are located in the are a wearable item and must make contact with the fixed part of the alternator. Tapping the alternator with the hammer temporarily changes spatial relationships between the brushes ...
Read more

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

Alternatives utility gets stuck doing install. Fedora 17 x86_64. Removing the /var/lib/alternatives/javaws file resolved the issue (for me). # alternatives --install /usr/bin/javaws javaws /usr/java/jdk1.7.0_07/jre/bin/javaws  20000 failed to read link /usr/bin/javaws: No such file or directory # ls /usr/bin/javaws ls: cannot access /usr/bin/javaws: No such file or directory # ls -al /var/lib/alternatives/javaws -rw-r--r--. 1 root root 105 Sep 22 11:39 /var/lib/alternatives/javaws # rm /var/lib/alternatives/javaws rm /var/lib/alternatives/javaws rm: remove regular file `/var/lib/alternatives/javaws'? y # alternatives --install /usr/bin/javaws javaws /usr/java/jdk1.7.0_07/jre/bin/javaws  20000 # which javaws /bin/javaws # ls /usr/bin/javaws /usr/bin/javaws # ls -al /var/lib/alternatives/javaws -rw-r--r--. 1 root root 65 Sep 22 11:50 /var/lib/alternatives/javaws # cat /var/lib/alternatives/javaws auto /usr/bin/javaws /usr/java/jdk1.7.0_0...
Read more

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

The Problem: Allow one linux workstation to be simultaneously used for both work and non-work purposes so that work and non-work traffic are segregated. The Requirements: I would like to be able to use the following applications in the corporate environment VNC Web (typically Google Chrome but potentially other browsers as well) Email - IMAP, SMTP, LDAP using Thunderbird IM - pidgin As already mentioned here the corporate network has an SSH server that you authenticate and connect to and from there you can reach the other corporate network resources. I would like non-work related traffic to bypass the corporate network - this is mostly web traffic but might also include things like Spotify, yum updates, and other assorted tasks. Finally it would be nice (but not essential) to wrap all this up in a handy GUI operation or series of operations. The Environment:  Fedora Core 16 (x86_64) and Gnome 3. The Solution:  Use SSH, SOCK...
Read more