Joe Blogs

Enabling lxdm in Fedora 19

Dec
09

Quick tip.

Long story short, I decided to swap out gdm for a lighter display manager on an underpowered machine.

I found the lxdm is packaged, but when I ran the system-switch-displaymanager helper script it told me that:

“The graphical display manager lxdm is not supported yet.”

I had a poke around in the system-switch-displaymanager code and found that it is very simple, and does this:

rm -f /etc/systemd/system/display-manager.service

systemctl enable $DM.service

Where $DM is what you pass it (one of GDM, KDM, XDM, WDM or LIGHTDM, currently).

So I checked if lxdm had a systemd service script (it does) and did that myself:

rm -f /etc/systemd/system/display-manager.service

systemctl enable lxdm.service

and it worked.

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.

Installing the flock browser on Fedora 12 64-bit

Apr
20

I just finished installing Flock on my desktop, but ran into a few issues. Nothing obvious that I could find that explained the dependency problems, so now that I’ve sorted them:

Flock only provides 32-bit (i686) binaries so if you’re running 64-bit (x86_64) Fedora Linux, you probably don’t have the right dependencies.

First step, download the archive file from flock.com

Then, uncompress it. I choose to do this straight to /usr/local

sudo tar -C /usr/local -xf /path/to/flock-*.linux-i686.tar.bz2

Create a symlink in /usr/local/bin so it is in your path:

sudo ln -s /usr/local/flock/flock-browser /usr/local/bin

If you run flock-browser now, you’ll get an error:

error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

If you satisfy this, you’ll get some more, so here are the packages you need to install with yum (which will pull down lots more). Don’t try to satisfy them yourself, it will only cause you pain. Just use yum.

sudo yum install gtk2.i686 libXt.i686 PackageKit-gtk-module.i686 libcanberra-gtk2.i686

You might still get some errors about a gtk theme, but I ignored them as they appear to be fairly harmless (at least I don’t care about them):

(flock-bin:19147): Gtk-WARNING **: Unable to locate theme engine in module_path: "clearlooks",