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.

Disabling comments for individual posts in WordPress

Dec
14

This had me stumped for a while, so I’m posting this for other, and to jog my memory if I forget.

I’m not sure when it happened, but in more recent versions of WordPress the page/post editing screen has been cleaned up by default to not include some of the (presumably lesser-used) options.

The way to re-enable them is via the “Screen Options” menu in the top right-hand corner:

Screen Options drop-down

Once clicked, it opens a menu where you can toggle various aspects; Categories, Tags, Excerpt, Send Trackbacks, Custom Fields, Discussion, Comments, Slug and Author.

Discussion is the option you need to turn on to disable comments, as “Comments” only shows the existing comments. ¬†Somewhat disconcertingly, I found that the Discussion section, when it appeared, was empty:

Screenshot from 2012-12-14 09:49:02

However, if you click on the Discussion bar, it will expand and show you the check boxes for “Allow comments” and “Allow trackbacks and pingbacks on this page”.

Screenshot from 2012-12-14 09:49:09

Not all that intuitive, I guess. But you may find similar features hidden in the “Screen Options” on other parts of the admin dashboard. Check it out.

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)

Google Chrome, Chromium and proxy settings

Jan
21

This is really for my benefit, in case I forget, but might also help somebody else who finds this annoyance.

I use google chrome to get at bits of the web that certain corporate proxies don’t allow. I use an ssh tunnel to a tinyproxy instance running on my home machine and then connect to the forwarded port on my local machine.

Something that has annoyed me for some time is that if you change google’s proxy settings, it affects the system proxy settings. It’s like Internet Explorer all over again, and it doesn’t tell you it’s doing it.

There are bugs:

http://code.google.com/p/chromium/issues/detail?id=43990

but the windows equivalent was closed “WONTFIX” for spurious reasons (IMHO, of course).

There is a way around it, though:

google-chrome --proxy-server:localhost:8888

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",

WordPress Upgrade

Feb
24

I’ve upgraded WordPress to 1.5. It was straightforward for me, although I had to hack one of the scripts a bit to deal with my dynamic php/css stuff. I managed to stuff up Hannah’s at first but a bit of hacking on the posts database fixed things.

The templates seem pretty good, much better than the old way. That is all

Ubuntu Netinstall without CDROM

Jan
09

I’m writing this up for my own benefit as it will be faster to find next time I forget.

I have problems installing Ubuntu on my laptop as it does not provide debian style floppy-based installation media. My CDROM drive is totally shot, so all I have is a floppy drive or network card as my installation options.

I found my way around this with a combination of a post on a forum (which I was unable to find second time around) and some figuring out of my own. Nothing particularly ground-breaking about anything I’ve done, but it might be of use…

The method I aimed to use was to get hold of appropriate kernel image and initrd from the netinstall CDROM and then get GRUB to load them.

Tracking down the images wasn’t too bad, and working out the appropriate appends came down to mounting the iso loopback and having a ferret around.

Download vmlinuz
and initrd.gz.

The way I did this method was to do this from an existing installation of Linux. I think it would be possible to do it with only Windows (or other OS) installed and a GRUB boot disk. I may explore that possibility later and write that up, too.

I copied the vmlinuz and initrd.gz to my /boot partition, adding a “-warty-netinstall” suffix for clarity, and then added the following to my menu.lst for grub.


==# For installing Ubuntu Linux==
title Install Ubuntu
root (hd0,0) # partition that the vmlinuz and initrd.gz are on
kernel /vmlinuz-warty-netinstall vga=normal ramdisk_size=11057 root=/dev/rd/0 devfs=mount,dall rw --
initrd /initrd-warty-netinstall.gz

The equivalent Lilo entry is:

label "Install Ubuntu"
kernel vmlinuz-warty-netinstall
append vga=normal initrd=initrd-warty-netinstall.gz ramdisk_size=11057 root=/dev/rd/0 devfs=mount,dall rw --

Then, just reboot (first running `lilo’, if using it) and select “Install Ubuntu” from the menu. That’s all there was to it for me.

Hope it helps someone, even if that’s only me in a few months time.

Hacked

Dec
21

Bah. I got hacked. I think it was probably due to a couple of files being world writeable (i.e. index.php and a style file) mainly due to my laziness in editing them in the wordpress editor. I won’t be doing that again. Of course, I may get hacked again, in which case it must be something else.

Fortunately, I’d backed up stuff so I could restore it fairly trivially.