Joe Blogs

Webex on 64-bit Fedora 19

Sep
23

It’s hard to believe that 32/64-bit compatibility is still an issue in this day an age. I’d hoped it would be plain sailing by now.

But no.

I use Webex at work, and at some point it and/or java stopped working. I kind of lost track of what I’d done before, but decided I wanted the “pure” solution or none at all (64-bit OS, therefore 64-bit firefox and 64-bit java). I failed to get it working, so resorted to running it in a Windows 7 VM in VirtualBox (works perfectly, of course).

I decided to spend a little more time on it, and with the latest java and firefox (jre-1.7.0_40 and firefox-24.0-1), the applet side of things “Just Worked”, i.e.:

http://java.com/en/download/installed.jsp?detect=jre&try=1 reports “Congratulations! You have the recommended Java installed (Version 7 Update 40).”

To get this far, install the latest jre RPM (http://www.java.com/en/download/linux_manual.jsp?locale=en)

# rpm -Uvh jre-7u40-linux-x64.rpm
# /usr/sbin/alternatives --install /usr/bin/java java /usr/java/default/bin/java 20000
# /usr/sbin/alternatives --config java

There is 2 program that provides 'java'.

  Selection    Command
-----------------------------------------------
*+ 1 /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.2.0.fc19.x86_64/jre/bin/java
   2           /usr/java/default/bin/java

Enter to keep the current selection[+], or type selection number: 2 

Symlink the java plugin to somewhere appropriate (I chose my home directory):

$ ln -s /usr/java/default/lib/amd64/libnpjp2.so ~/.mozilla/plugins/

And restart firefox.

However, starting a Webex would work to a point, but I couldn’t see anything I entered into the chat box, or any response (although both show up on a working client at the other “end”).

I’d got the java console running and googled around on some of the errors I was seeing.

This got me this page:

http://www.emsperformance.net/2013/03/25/making-webex-work-on-64bit-fedora-core-18/

This implied that installing the 64-bit version of the pangox-compat RPM would help. I already had that. In desperation, I tried installing the i686 version, too. No improvement in symptoms.

After poking around some more, using this error:

Loading native DBR...
java.lang.UnsatisfiedLinkError: /home/jwrigley/.webex/1224/libdbr.so: /home/jwrigley/.webex/1224/libdbr.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch

I found that there are a bunch of files pulled down by the applet (I presume?) into ~/.webex/1224/, which are 32-bit (I don’t know if the number, here 1224, differs on other systems).

$ file .webex/1224/*.so
.webex/1224/atascli2.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
.webex/1224/atascli.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
.webex/1224/atgzip.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
...

More googling brought little hope. The consensus appeared to be that the only solution is to run 32-bit firefox and java. *spit*

Tenacity, or pigheadedness, forced me to have one more try.

As described in the link above, I straced the java process once I’d started a conference. This opened a lot of threads.

I noticed that the strace process would report, when I clicked “Share My Desktop”, something like this:

Process 1004 attached
[ Process PID=1004 runs in 32 bit mode. ]

That saved me some time in grepping, as I opened the strace log for that process and right at the bottom:

15:16:16 writev(2, [{"/home/jwrigley/.webex/1224/atasj"..., 34}, {": ", 2}, {"error while loading shared libra"..., 36}, {": ", 2}, {"libXmu.so.6", 11}, {": ", 2}, {"cannot open shared object file", 30}, {": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10) = 145

I had libXmu.so.6 in /usr/lib64, so I figured it couldn’t hurt to try installing the 32-bit version:

# yum install libXmu.i686

Tried again, and still not working, but the new thread had a different error, this time libXt.

I followed this cycle a couple of times, installing 32-bit versions of libXt, libXmu and gtk2 (for libgtk-x11-2.0.so.0), and lo! I got a popup telling me I was sharing my desktop. Unfortunately, I couldn’t see my desktop on the other client, but when I shared that desktop, I could see it on my local machine.

The packages I installed, as a one-liner:

# yum install pangox-compat.i686 libXt.i686 libXmu.i686 gtk2.i686

(the last one pulls down quite a few dependencies.

The problem with the chat appears to have come along with the newer java, as there are claims that it’s fixed by rolling back. The associated error/traceback is:

chat component version = 2011.01.29.1101
Resource: atlchat
Resource: atlchat_en
Resource: atlchat_en_US
Exception in thread "AWT-EventQueue-3" java.lang.IllegalStateException: This function should be called while holding treeLock
at java.awt.Component.checkTreeLock(Unknown Source)
at java.awt.Container.validateTree(Unknown Source)
at ChatControlPane.access$100(ChatControlPane.java:61)
at ChatControlPane$1$1.run(ChatControlPane.java:120)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$200(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)

So, only a partial fix, but at least I can view somebody else’s shared desktop from the comfort of my own browser, which is about 90% of my use-case.

Automounting USB disk on boot with systemd in Fedora

Dec
03

I had a requirement to boot a USB disk (a Hitachi SimpleDrive) on a machine I rarely log into via the GUI. In the good old days, I’d hack up a udev script to do it.

In Fedora, with the advent of systemd, I googled and quickly became horribly confused about how it should work.

I found some stuff about systemd and automount, but the idea of a system.automount unit file scared me and I *really* didn’t want to have to learn too much more about systemd, just in order to mount a disk (I guess I’m putting off the inevitable since, professionally, I support Oracle Linux and I imagine it will eventually start to use systemd).

I found the man page for systemd.mount(5) and read:

Mount units may either be configured via unit files, or via /etc/fstab
(see fstab(5) for details).

When reading /etc/fstab a few special mount options are understood by
systemd which influence how dependencies are created for mount points
from /etc/fstab. If comment=systemd.mount is specified as mount option,
then systemd will create a dependency of type Wants from either
local-fs.target or remote-fs.target, depending whether the file system
is local or remote. If comment=systemd.automount is set, an automount
unit will be created for the file system. See systemd.automount(5) for
details.

I obviously hadn’t drunk enough coffee, so I couldn’t seem to grok this, and had to read http://0pointer.de/blog/projects/blame-game.html:

Well, systemd possesses magic powers, in form of the comment=systemd.automount mount option in /etc/fstab. If you specify it, systemd will create an automount point at /home and when at the time of the first access to the file system it still isn’t backed by a proper file system systemd will wait for the device, fsck and mount it.

I added:

UUID=d0e1f72d-c56e-4239-ae79-277af99ada7a /simpledrive ext4 defaults,comment=systemd.automount 1 2

On reboot, I got dumped to a systemd console, and I thought maybe it was because the volume was being mounted before it was ready, so I added noauto, to let systemd pick it up later:

UUID=d0e1f72d-c56e-4239-ae79-277af99ada7a /simpledrive ext4 noauto,defaults,comment=systemd.automount 1 2

Still failed, but this time I got to see an error, and ran:

# systemctl status automount.simpledrive

and it told me something about a resource. I figured out I’d misunderstood this line by Lennart:

If you specify it, systemd will create an automount point

and that I needed to manually create /simpledrive:

# mkdir /simpledrive

After that,

# systemctl status simpledrive.automount
simpledrive.automount
Loaded: loaded
Active: active (running) since Mon, 03 Dec 2012 10:25:00 +0000; 1h 51min ago
Where: /simpledrive

and on reboot, the drive is mounted:

systemd-1 on /simpledrive type autofs (rw,relatime,fd=44,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
/dev/sdd1 on /simpledrive type ext4 (rw,relatime,data=ordered)