1. Step One – Gnome Shell PPA

   # echo 'deb http://ppa.launchpad.net/ricotz/testing/ubuntu lucid main # GnomeShell PPA' >> /etc/apt/sources.list
   # aptitude update
   

2. Step Two – Install the Beast

   # aptitude install gnome-shell
   

3. Step Three – Activate!

   $ echo 'export WINDOW_MANAGER=gnome-shell' >> ~/.gnomerc
   

4. Step Four – RELOGIN

Installing Gnome Shell under Ubuntu Linux ©, .

Let’s get to the business…

Nokia N900 part

Default Maemo5 bluetooth setup on Nokia N900 does not provide Dial-Up Networking BlueZ profile. You need to install “Bluetooth Dial-up Networking” package from extras-testing repository. Restart the phone after installing to activate DUN.

Ubuntu Karmic part

Ubuntu default gnome-bluetooth package does not provide means needed to setup Dial-Up connection. You need to replace it with a lot better Blueman. First add Blueman PPA to repositories.

Then install Blueman. It will replace gnome-bluetooth. Reboot workstation to get changes active.

Right click on bluetooth icon in notification area and “Setup a new device…” – pair your N900. Then left click on same icon and “Bluetooth devices” window opens.

Select your device and click “Settings…” button. Then connect “Dialup Networking (DUN)”. This will add your device to NetworkManager. Right click Network icon in notification area and select “Modify connections…”. Then on “Mobile” tab “Add” a connection for “Installed GSM device”. It’s good to check “Connect automatically”.

Now when you want to establish a connection just click the Bluetooth icon in notification area, right click your device and Connect “Dial-up Networking”. NetworkManager will kick in if you checked it to connect automatically and you’re online.

Have Fun.

GSM Dial-Up over Nokia N900 Bluetooth on Ubuntu Karmic ©, .

I needed to add one more – native to StarCraft – and let the graphics hardware scale it to full screen.
It’s pretty easy using XRandr extensions:

$ cat .xprofile
xrandr --newmode "640x480_120.00"  52.41  640 680 744 848  480 481 484 515  -HSync +Vsync
xrandr --addmode LVDS1 640x480_120.00

Fullscreen StarCraft on Linux WINE ©, .

The first line of the file in question some/file.php looks innocent:
<?php
A standard PHP code opening tag. So, where are the outputted characters?
Well… Welcome to Unicode world. With multibyte characters there is a need of distinguishing low-endian from high-endian encoded files. It’s a job of the BOM – byte-order mark – it is an invisible, no length space with a unique two bytes character code U+FEFF. It does not affect the rendered content of the document and it is easy to detect the endianness of the document.

But PHP is not a renderer – it takes the two bytes literally and sends them to browser. But before any content, it needs to send HTTP headers. The rest of the story is obvious – you cannot modify already sent headers and PHP warns you about the fact.

How to remove BOM?
It’s not that easy – in most editors it is not an editable character and they just leave it as-is. For me, the easiest way is to open the file in SciTE, change the File -> Encoding from UTF-8 with BOM to UTF-8 and save it.

PHP “Cannot modify header information” and the dreaded BOM ©, .

The best way to run monit is as the Init managed process. But there is no /etc/inittab on Ubuntu anymore. Instead we have Upstart. Adding Monit as an Upstart service is easy. Let me show you how…

Upstart is event based, and its event handling configuration is in /etc/event.d. The configuration is a bit similar to /etc/inittab, but a bit more verbose and placed in separate files. To add Monit as a managed process, just create a file similar to a getty spawner configuration in ttyX. I named my file: /etc/event.d/monit with content of:

# Run monit in standard run-levels
start on stopped rc2
start on stopped rc3
start on stopped rc4
start on stopped rc5
stop on runlevel 0
stop on runlevel 1
stop on runlevel 6
respawn
exec /usr/sbin/monit -Ic /etc/monit/monitrc

Next just start monit. Issue a command:
start monit

Good luck with service monitoring.

Using monit with Ubuntu Server ©, .

The latest nginx version does proxied request caching. It buffers the proxied server response and pushes it to the client as a whole. It does help in mitigating client-backend bandwidth differences, but breaks Comet requests like the BOSH one. There is an option added to nginx for this very purpose: proxy_buffering. You need to disable the buffering: proxy_buffering off;.

So, the complete BOSH proxy location should look like this:

location /http-bind/ {
proxy_buffering off;
tcp_nodelay on;
keepalive_timeout 55;
proxy_pass http://xmpp.server:5280/xmpp-httpbind/;
}

nginx and BOSH / Comet connections ©, .

Problems arise when the only thing you have (or are allowed to have) at hand locally is a Windows workstation. Put this problem has a good solution already – PuTTY.

But what if the application you need is an X client? You need to launch it remotely and display its windows on some X11 screen. Unfortunately Windows does not provide one.

You need to install a separate X11 server on your windows workstation. The best free one is Xming.
Get it, install and run “Xming” app. You should see the X icon in taskbar. You’re now half way there.

Next, launch PuTTY and enable X11 forwarding on your Connection -> SSH -> X11 pane. Check “Enable X11 forwarding” and enter 127.0.0.1:0 at “X display location”.

Login to the remote server account and check whether X11 forwarding is working. Issue command: echo $DISPLAY. You should get something like: localhost:10.0. You’re done.

But if you did get nothing, you’re not completely out of luck. Most probable reason is that X11 forwarding is disabled on your remote host. Check /etc/ssh/sshd_config “X11Forwarding” directive. If it is set to “no” or unset, just set it to “yes” (or ask the system administrator to set it). While you are there it’s worth setting “X11DisplayOffset 10″ too there, to avoid clashing local X servers on the machine.

Connecting remote X client to Windows workstation over SSH ©, .

Let me show you how to get it right…

PHP CGI binary is perfectly able running a FastCGI interface by itself. There is no need to run it with an external wrapper. No need to install anything more than the PHP itself.

Just install the php-cgi: aptitude install php5-cgi and run: php-cgi -b 127.0.0.1:9000. Done. You have PHP running FastCGI interface on localhost on port 9000. You can connect to it from nginx using fastcgi_pass 127.0.0.1:9000;.

php-cgi binary is configurable using environment variables. The most interesting ones are PHP_FCGI_CHILDREN telling how many child processes to launch and PHP_FCGI_MAX_REQUESTS telling how many requests each child need to process before termination (and launching another one).

I use this command (wrapped in a simple script) on my development machine. But server needs something to launch the PHP FastCGI processes on boot. Here is a simple init.d script to get the php-cgi running as a normal system service:

#!/bin/bash
BIND=127.0.0.1:9000
USER=www-data
PHP_FCGI_CHILDREN=15
PHP_FCGI_MAX_REQUESTS=1000

PHP_CGI=/usr/bin/php-cgi
PHP_CGI_NAME=`basename $PHP_CGI`
PHP_CGI_ARGS="- USER=$USER PATH=/usr/bin PHP_FCGI_CHILDREN=$PHP_FCGI_CHILDREN PHP_FCGI_MAX_REQUESTS=$PHP_FCGI_MAX_REQUESTS $PHP_CGI -b $BIND"
RETVAL=0

start() {
      echo -n "Starting PHP FastCGI: "
      start-stop-daemon --quiet --start --background --chuid "$USER" --exec /usr/bin/env -- $PHP_CGI_ARGS
      RETVAL=$?
      echo "$PHP_CGI_NAME."
}
stop() {
      echo -n "Stopping PHP FastCGI: "
      killall -q -w -u $USER $PHP_CGI
      RETVAL=$?
      echo "$PHP_CGI_NAME."
}

case "$1" in
    start)
      start
  ;;
    stop)
      stop
  ;;
    restart)
      stop
      start
  ;;
    *)
      echo "Usage: php-fastcgi {start|stop|restart}"
      exit 1
  ;;
esac
exit $RETVAL

Put it in /etc/init.d/php-fastcgi, make it executable chmod +x /etc/init.d/php-fastcgi, unleash the daemons /etc/init.d/php-fastcgi start and finally make it permanent update-rc.d php-fastcgi defaults.

May the nginx + php-cgi fastcgi serve you well.

P.S. Here’s a simple snippet of nginx configuration to make use of the described service:

server {
        listen          80;
        server_name     example.com;

        access_log      /var/log/nginx/example.com.access_log;
        error_log       /var/log/nginx/example.com.error_log warn;

        root            /var/www/example.com/public;

        index           index.php index.html;
        fastcgi_index   index.php;

        location ~ \.php {
                include /etc/nginx/fastcgi_params;
                keepalive_timeout 0;
                fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
                fastcgi_pass    127.0.0.1:9000;
        }
}

PHP FastCGI with nginx on Ubuntu ©, .

OpenVZ uses one “bare” venet0 device on the host side, connected to a multi-IP (or multi-aliased) venet0 device on the container side with a twisted PTP connection. The IP-level communication is done via 192.0.2.1 virtual gateway. It’s clever. It works well. But it’s not straightforward to get running – especially with sparse documentation OpenVZ has.

After a few hours of fighting and cursing I finally got it to work.

1. Create the container and migrate content as described in Physical to container doc.
2. Tune it according to the above doc and Gentoo template creation doc.
3. In the container remove all the network configuration scripts from runlevels: rc-update del net.eth0; rc-update del net.eth1 ...
4. Create a script for venet0 device: ln -s net.lo /etc/init.d/net.venet0 and add it to default runlevel: rc-update add net.venet0 default.
5. Set up the /etc/conf.d/net the following way:

   config_venet0=(
           "123.234.123.234/32" # the old eth0 address
           "10.0.0.1/24" # the old eth1 address
   )
   routes_venet0=(
           "192.0.2.1 dev venet0"
           "default via 192.0.2.1"
   )
   

P.S. For the curious ones – yes, the “old” Chrome Platform (seikken+amenite) is crammed in a new shiny Dell 1U rack server. ^_^

Gentoo physical machine to Ubuntu OpenVZ container migration ©, .

2009-03-25 09:40:24 failed to expand "${lookup pgsql{SELECT [...]}}" while checking a list: lookup of "SELECT [...]" gave DEFER: PGSQL: query failed: ERROR:  invalid byte sequence for encoding "UTF8": 0xc06e

No wonder… There is a local_user check in place in RCPT ACL and Exim checks username in DB table. The $local_part in the SQL query is taken directly from RCPT TO command without checking its encoding validity. You may expect anything on the wire though.

You need to add a check for UTF-8 validity of the $local_part. Exim does not have it built-in, but there is an easy way to code it manually.

Create an /usr/local/bin/isutf8 file:

#!/bin/bash
exec echo "$1" | /usr/bin/iconv -f UTF-8 -t UTF-8 >/dev/null 2>&1

Make it executable and add this rule to RCPT ACL just before the local_parts check:

deny
    message = address is invalid UTF-8
    condition = ${run{/usr/local/bin/isutf8 \"$local_part\"}{no}{yes}}

Restart Exim and you’re done.

Exim4, PostgreSQL and: invalid byte sequence for encoding UTF8 ©, .