GridFTP on Archlinux

After having globus-gridftp-server and myproxy-server work on Gentoo linux, it was easy to convert the scripts to work on Arch linux. Following their guide, I tried myproxy-server at first and it worked nicely. Actually in their guide they should mention about ensuring that the executable is in PATH.

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

GLOBUS_LOCATION=/home/phoenix/gt
DAEMON=myproxy-server
ARGS=

[ -r /etc/conf.d/$DAEMON ] && . /etc/conf.d/$DAEMON

PID=$(pidof -o %PPID $DAEMON)

case "$1" in
 start)
   stat_busy "Starting $DAEMON"
   [ -z "$PID" ] && $GLOBUS_LOCATION/sbin/$DAEMON $ARGS &>/dev/null
   if [ $? = 0 ]; then
     add_daemon $DAEMON
     stat_done
   else
     stat_fail
     exit 1
   fi
   ;;
 stop)
   stat_busy "Stopping $DAEMON"
   [ -n "$PID" ] && kill $PID &>/dev/null
   if [ $? = 0 ]; then
     rm_daemon $DAEMON
     stat_done
   else
     stat_fail
     exit 1
   fi
   ;;
 restart)
   $0 stop
   sleep 1
   $0 start
   ;;
 *)
   echo "usage: $0 {start|stop|restart}" 
esac

Now, getting the script for the gridftp-server working was a bit tricky as I had to pass the parameter for the port number and also to get it work as a daemon. I tried to provide the parameters from /etc/conf.d/gridftp-server; but somehow it was not reading the parameters from that file so I had to provide it in the rc script itself.

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

export GLOBUS_LOCATION=/homephoenix/gt
export LD_LIBRARY_PATH=$GLOBUS_LOCATION/lib
source $GLOBUS_LOCATION/etc/globus-user-env.sh
DAEMON=globus-gridftp-server
ARGS="-S -f -p 2811"

[ -r /etc/conf.d/$DAEMON ] && . /etc/conf.d/$DAEMON

PID=$(pidof -o %PPID $DAEMON)

case "$1" in
 start)
   stat_busy "Starting $DAEMON"
   [ -z "$PID" ] && $GLOBUS_LOCATION/sbin/$DAEMON $ARGS &>/dev/null
   if [ $? = 0 ]; then
     add_daemon $DAEMON
     stat_done
   else
     stat_fail
     exit 1
   fi
   ;;
 stop)
   stat_busy "Stopping $DAEMON"
   [ -n "$PID" ] && kill $PID &>/dev/null
   if [ $? = 0 ]; then
     rm_daemon $DAEMON
     stat_done
   else
     stat_fail
     exit 1
   fi
   ;;
 restart)
   $0 stop
   sleep 1
   $0 start
   ;;
 *)
   echo "usage: $0 {start|stop|restart}" 
esac

GridFTP on Gentoo

The Globus Project provides gridftp as one of the modules of its toolkit. I got the source and followed the quickstart guide to start the installation. However, the guide tells you how to run myproxy-server and globus-gridftp-server as xinet daemons. Although Gentoo provides xinetd package, that is not their preferred way of handling daemons. They use their own init scripts. So, I have tried to do it their way. My first script was for myproxy-server.

#!/sbin/runscript

start() {
    ebegin "Starting myproxy-server"
    start-stop-daemon --start --exec /home/titu/soc/gt/sbin/myproxy-server    eend $?
}

stop() {
    ebegin "Stopping myproxy-server"
    start-stop-daemon --stop --exec /home/titu/soc/gt/sbin/myproxy-server
    eend $?
}

My next script was for starting globus-gridftp-server as a daemon; however this process has having problems when I tried it the way I did for myproxy-server. Sometimes start-stop-daemon was not returning and sometimes start-stop-daemon was unable to stop. I tried to store PID values in a pid file by asking start-stop-daemon to create the pidfile by using -m option. However, it turned out that the PID in the pidfile was always slightly less than the actual PID. It was most likely because of forking. So, I modified the script using killall.

#!/sbin/runscript

start() {
    ebegin "Starting globus-gridftp-server"
    start-stop-daemon --start -b -e GLOBUS_LOCATION=/home/titu/soc/gt -e LD_LIBRARY_PATH=/home/titu/soc/gt/lib --exec /home/titu/soc/gt/sbin/globus-gridftp-server -- -S -f -p 2811
    eend $?
}

stop() {
    ebegin "Stopping globus-gridftp-server"
    killall globus-gridftp-server
    eend $?
}

It is essential to set environment variables for the gridftp server.

Automounting NTFS flash drives in Gentoo

Recently, I noticed flash drives with ntfs file systems on them were nicely automounted on my KDE on Archlinux. However, when I tried it in GNOME on Gentoo, it showed me an error message. Initially I thought if it is a desktop environment issue; but automounting is usually done by udev. So I decided to check for udev and ntfs-3g driver.

emerge -pv udev ntfs3g

I found that the ntfs3g package had "udev" USE flag disabled. I douted this might be the reason. To verify I ran a quick check using the following command.

equery u ntfs3g

I found "udev" USE flag installs udev rule to make udisks use ntfs-3g instead of the kernel NTFS driver. So, I
enabled it by adding the following line to /etc/portage/package.use

sys-fs/ntfs3g udev

Re-emerging the package solved the issue and I can nicely automount flash drives with ntfs filesystems.

What happened to Thunderbird 4?

I have been using Mozilla Thunderbird since version 2.0. Recently I saw a version bump directly from 3.x to 5.0. This is because Mozilla wanted to keep the version numbering same as Firefox. From the release notes, the main reason for such a bump seems to be the new Gecko 5 engine.

Recently Firefox versions have come up very fast. By the time add-ons became compatible with Firefox 4.x, Firefox 5.0 was out and some add-ons are incompatible with it. Mozilla should slow down the release cycle, decide what it wants to implement as part of its next release cycle and provide a feature rich and stable browser.

Removing slotted libpng in Gentoo

While upgrading my Gentoo system, I upgraded gentoolkit package and I got a message saying asking me to run the following command.

glsa-check -p affected

Running it told me that there are no upgrades available for libpng-1.2.44. I found out that there were multiple versions of libpng installed on my system:

• libpng-1.4.5 and;
• a slotted version, i.e. libpng-1.2.44.

The solution was to remove all versions of libpng and freshly install it. This can be achieved using the following command.

emerge -C libpng && emerge -1 libpng:0

Mouse vs keyboard

Over the years, we have had a conflict between two groups of users: GUI-friendly and CLI-friendly. Mostly the CLI-friendly people think that the keyboard is faster than mouse while the GUI-friendly people think that the mouse is faster. A research by Apple shows that actually it is the mouse that is faster in most cases although people think the keyboard to be. However, it is not the metrics that matter; but the mentality that is developed.

A programmer typing in full flow is very unlikely to break his flow and hold the mouse. He probably would prefer the whole window to be controllable from the keyboard. That way the interface is letting the programmer do his job without being distracted towards using a mouse. Emacs is a classic example of this.

However, people who work primarily with the mouse like desktop users who are copying files or playing music can use the mouse with ease letting the other hand rest.

Apple and Microsoft provide a nice GUI interface and are doing good business because most of their users are GUI-friendly. However, linux allows choice. There are great GUI windows managers like Enlightenment and there are also tiling window managers like awesome.

Commandos II: Men of Courage multiplayer mode glitch

Recently I have been playing Commandos II: Men of Courage, with my brother, in multiplayer mode. We have played the game in single player mode numerous times; but this was out first multiplayer experience. We found synchronizing glitches in the game.

In the following image you can see two views: one on my screen and one on my brother’s. The same enemy soldier has different positions on the two screens.

Moreover, when I killed the enemy soldier using the Green Beret my brother’s system would show that a fellow Commando has died and mission failed. The same was shown to me if he took the soldier down with the Sapper. We tried to let the game recover by continuing the game trying to get the Green Beret meet with the Sapper. Interestingly as the Green Beret was alive on my system, he showed up with the Sapper and Lupin while on my brother’s system it was only the Sapper and Lupin.

When we had encountered a similar error within a closed room, I thought it was a glitch in coordinate calculation. However, I was wrong as proved by this incident. Clearly there is a concurrency issue here.

In the mission "Is Paris Burning?", there was another glitch where an enemy soldier picks up a cigarette from a distance. Look for the 14th second and the 57th second in the video.

Installing Google Talk plugin in Gentoo linux

Google provides Google Talk plugin as rpm or deb packages for 32-bit and 64-bit architectures. To get it on Gentoo when you try

emerge -pv google-talkplugin

you can see that it is masked by license. It means you have to accept the license before installing. You can find all licenses at /usr/portage/licenses. To get a specific license try

ls /usr/portage/licenses | grep google

You can read the license and if you accept it then add a line to /etc/portage/package.license to reflect it. In this case, the line would be

www-plugins/google-talkplugin google-talkplugin

and in general it is:

<full package name> <license name>

Now when you try emerging it you get a message saying that the license does not allow mirroring. This is why the fetch restriction is in place. The message also tells you to download the .deb package suitable to your architecture and put it in /usr/portage/distfiles. The problem is Google provides you current version and not the version considered stable by Gentoo. Moreover, the version 1.8 which is considered stable by Gentoo is not available according a Gentoo bug [I wish I had found that out earlier].

So the 1.8 version ebuild is for those who have a copy of the older Google Talk plugin. All others have to unmask the newer version according to their architectures. I had to add the following line to /etc/portage/package.keywords.

=www-plugins/google-talkplugin-2.1.6.0 ~amd64

Now portage can fetch it for you. However, if you have already downloaded latest version of the plugin then you can use the command as root to copy it to you distfiles folder and portage will not have any checksum error either if the versions have not changed.

cp -v Downloads/google-talkplugin_current_amd64.deb /usr/portage/distfiles/google-talkplugin_2.1.6.0-1_amd64.deb

Now portage will not have to redownload the package.

Bootcharting Gentoo baselayout 2

In this post I shall share my experience of yet another Gentoo installation. I keep coming back to this distribution for its stability, wonderful package management and the experiencing fine grained control.

I have been using KDE for over six years now. I wanted to try GNOME 3. However, as I found out GNOME 3 is not yet stabilized in Gentoo so I had to be content with GNOME 2. They are stabilization by the next release. I believe that it for good reason. Well GNOME 3 does not support Compiz. There are no multiple timezone clocks.

Having prior experience in installing Gentoo linux, I knew that following the handbook strictly you have to wait for downloads while there is compilation going on and vice versa. So this time I chrooted not from a single terminal but from multiple terminals. I could run package downloads separately using

emerge -f <package name>

and compile concurrently on a different terminal using

emerge <different package>

After installation, when I booted the system hung up.

Hung up Gentoo bootscreen

I read a line saying

Ext3-fs: couldn't mount because of unsupported optional features(240)

Adding the following to the kernel line solved the issue.

rootfstype=ext4

However, I was still getting a hung up system. If I inserted or removed USB drives, I was getting appropriate messages printed on screen; but the system was not responding to any keystrokes or mouse, neither was it loading X. Only the error line was gone. So, I understood that it was not the filesystem issue that was causing it. Asking on #gentoo I found that it was a common issue caused by the switch to baselayout 2. Instead of old init scripts Gentoo had started using openRC. Last time  heard about it was about a couple of years ago. It was a nice project started by Roy Marples. However, now it was stable and I was happy to be using it. My issue was solved following Alex's suggestions for the issue.

I wanted to see the boot time with baselayout 2 and openRC so after I had other installations I did a boot chart to find much faster boot than my previous installation on the same machine.

Also noteworthy was the fact that X worked out of the box and I was surprised to see Firefox 3.6.17 in stable tree. I was expecting Firefox 4.0. Well I hope it is stabilized soon.