Most developers work on their startups far away from the daylight – they keep it in complete secret till the end. I’ve decided to do something new – I have started a project which is available to preview during the whole development. It is available at urevs.com. I also share all the project info on dedicated blog: blog.urevs.com.

This project consists currently of authentication framework and a lot of backend solutions. Site allows users to login using OpenID’s, Google, Twitter, Facebook or Yahoo Accounts. Full details are available here – social bootstrap engine for Django.

I’d be very glad to hear from You, about every suggestion You have.

Some of us dont know this command, so:

nme@werewolf ~ $ dpkg -S /usr/bin/ffmpeg
ffmpeg: /usr/bin/ffmpeg
nme@werewolf ~ $

or

nme@werewolf ~ $ dpkg -S `which gcc`
gcc: /usr/bin/gcc
nme@werewolf ~ $

or

nme@werewolf ~ $ dpkg -S *bash
xz-utils: /usr/share/doc/xz-utils/extra/7z2lzma/7z2lzma.bash
bash: /usr/share/menu/bash
util-linux: /usr/share/doc/util-linux/examples/getopt-test.bash
util-linux: /usr/share/doc/util-linux/examples/getopt-parse.bash
bash: /bin/bash
apparmor: /etc/apparmor.d/abstractions/bash
bash: /bin/rbash
bash-completion, bash: /usr/share/doc/bash
global: /usr/bin/globash
nme@werewolf ~ $

You know smarter way? Add Your comment!

I needed small function to validate IPv4 netmasks, havent found one, so I wrote my own. I’ve decided to use IPv4 CIDR notation to get corresponding netmasks. Here is the code:

def ipv4_cidr_to_netmask(bits):

    """ Convert CIDR bits to netmask """

    netmask = ''
    for i in range(4):
        if i:
            netmask += '.'
        if bits >= 8:
            netmask += '%d' % (2**8-1)
            bits -= 8
        else:
            netmask += '%d' % (256-2**(8-bits))
            bits = 0
    return netmask

Example usage is presented below. They also show how lambda mappings are useful in regular, daily use.

List all possible netmasks:

for netmask in map(lambda x: ipv4_cidr_to_netmask(x), range(0,33)):
    print netmask

0.0.0.0
128.0.0.0
192.0.0.0
224.0.0.0
240.0.0.0
248.0.0.0
252.0.0.0
254.0.0.0
255.0.0.0
255.128.0.0
255.192.0.0
255.224.0.0
255.240.0.0
255.248.0.0
255.252.0.0
255.254.0.0
255.255.0.0
255.255.128.0
255.255.192.0
255.255.224.0
255.255.240.0
255.255.248.0
255.255.252.0
255.255.254.0
255.255.255.0
255.255.255.128
255.255.255.192
255.255.255.224
255.255.255.240
255.255.255.248
255.255.255.252
255.255.255.254
255.255.255.255

Get netmask for /24:

print ipv4_cidr_to_netmask(24)

255.255.255.0

Is 255.255.254.0 valid IPv4 netmask?

print "255.255.254.0" in map(lambda x: ipv4_cidr_to_netmask(x), range(0,33))

True

Reverse search – get CIDR for 255.255.192.0 netmask

print map(lambda x: ipv4_cidr_to_netmask(x), range(0,33)).index('255.255.254.0')

23

As usual – enjoy

I’d like to present simplest way I know to debug WordPress plugins. It is a method I was using developing plugin to cloak URL‘s described earlier.

Below You can find the most minimalistic example plugin code possible – all it does is log REQUEST_URI to our debug file located at wp-content/plugins/debug. Row by row. Dirty and simple – and the most important – it does not require us to switch our WordPress to debug mode.

Plugin consists of three parts – plugin description header, debugging function and hook to main function which is executed right before page is rendered.

/*
Plugin Name: test
Plugin URI:
Description:
Version:
Author:
Author URI:
*/

function debug($msg)
{
        $fp = fopen('wp-content/plugins/debug', 'a');
        fwrite($fp, $msg."\n");
        fclose($fp);
}

function main()
{
        debug($_SERVER['REQUEST_URI']);
}

add_action('init', 'main');

Of course the most important part of the code is debug function which stores results we need to verify to our debug file.

I’ve recently published jQuery-UI themeselect widget allowing users to add friendly looking, themable dropdown to instant theme switch.

In oppose to standard jQuery-UI themeswitcher, this one looks exacly like the rest of the theme.

My ui-themeselect has been published on New BSD License making it freely available and the code is hosted at Google Code. If You are familiar with Mercurial, you can clone the repository using command below:

hg clone https://ui-themeselect.googlecode.com/hg/ ui-themeselect

I have ripped the code out from my own Django / Google App Engine applications development Javascript bootstrap, because I think that someone else might consider it useful.

As an example how can it look inside jQuery-UI themed interface, take a look at this screenshot taken from one of my apps:

Enjoy!

After few unsuccessful searches for free WordPress plugin that would allow me to cloak URL’s on my blog – I decided to write my own. It was not really hard. I’m publishing it on GPLv3 license.

Plugin is really simple – full code consists of 75 lines of code. It does not contain database support, hits counting nor wp-admin interface. If some of You will like to extend it including those features – please do it and inform me – I will be first betatester

Plugin assumes that You already accomplished redirecting URL’s to WordPress subsystem that You would like to be handled by WordPress in a different way.

There are three possible kinds of URL threating:

• Permanent redirect – typical HTTP 301 redirect
• Temporary redirect – typical HTTP 302 redirect
• Local cloak – it works only on Your blog web page (thats why it is called local) – it will hide real destination URL leaving it cloaked

How does it work?

The core of the plugin source is pasted below. Maybe some of You will consider it as interesting The most unfortunate part of the plugin is need to use /wp-admin/plugins.php Edit plugin feature to manually change URL’s. Those are listed inside $redirect variable.

define('PERMANENT_REDIRECT',301);
define('TEMPORARY_REDIRECT',302);
define('LOCAL_CLOAK',1);

$redirects = array(
  # source match         TYPE                           destination url
  # /u
  "^/u$" =>              array(TEMPORARY_REDIRECT,      "/u/"),
  "^/u/(.*)$" =>         array(LOCAL_CLOAK,             "/category/u/$1"),
}

function url_cloaker()
{
    global $redirects;
    $src_url = $_SERVER['REQUEST_URI'];
    foreach ($redirects as $src => $dst) {
        $src = str_replace('/','\/',$src);
        if (preg_match('/'.$src.'/',$src_url)) {
            #__d('Matched: '.$src);
            $dst_url = preg_replace('/'.$src.'/', $dst[1], $src_url);
            switch ($dst[0]) {
                case PERMANENT_REDIRECT:
                    wp_redirect($dst_url, PERMANENT_REDIRECT);
                    exit;
                case TEMPORARY_REDIRECT:
                    wp_redirect($dst_url, TEMPORARY_REDIRECT);
                    exit;
                case LOCAL_CLOAK:
                    $_SERVER['REQUEST_URI'] = $dst_url;
                    break;
            }
        }
    }
}

add_action('init', 'url_cloaker');

Plugin use actions hooking framework inside WordPress to make sure it is fired before page is shown.

The code above seems to be unreadable for You? Get this PHP book, because PHP is very simple language to learn and it offers a lot of new possibilities for those who know how to use it.

Those of you, who are having problems adding IMQ support to recent Ubuntu/Debian release, might consider this blog entry useful

I will not discuss what IMQ is and wheater is it good or bad – I will describe how to prepare kernel, iptables packages and how to deploy them to our Debian/Ubuntu system including taking care of making them immune to accidential system upgrade packages replacement.

Kernel package with IMQ support

Before we start – we need few packages that will might be required:

sudo aptitude install fakeroot build-essential kernel-package ncurses-dev

Now we are ready to start: first, we need our current kernel with distro patches. For desktop instance I would use -generic instead of -server:

apt-get source linux-image-2.6.32-22-server

Now, we download imq patch, apply it and compile kernel:

wget http://linuximq.net/patchs/linux-2.6.32-imq-test2.diff

cd linux-2.6.32/

patch -p1 < ../linux-2.6.32-imq-test2.diff

fakeroot time make-kpkg --initrd --append_to_version=imq linux-image

During the compilation process, make-kpkg script will discover unanswered features that we need to check as modules:

  "IMQ" target support (NETFILTER_XT_TARGET_IMQ) [N/m/?] (NEW) m

  IMQ (intermediate queueing device) support (IMQ) [M/y/?] (NEW) M

    IMQ behavior (PRE/POSTROUTING)

      1. IMQ AA (IMQ_BEHAVIOR_AA) (NEW)

    > 2. IMQ AB (IMQ_BEHAVIOR_AB) (NEW)

      3. IMQ BA (IMQ_BEHAVIOR_BA) (NEW)

      4. IMQ BB (IMQ_BEHAVIOR_BB) (NEW)

    choice[1-4?]: 2

    Number of IMQ devices (IMQ_NUM_DEVS) [16] (NEW)

Finally... in parent directory we will find:

linux-image-2.6.32.11+drm33.2imq_2.6.32.11+drm33.2imq-10.00.Custom_i386.deb

If everything went fine and our package is present - we can clean up compiled object files that will not be required anymore, recovering few GB of hard disk space:

./debian/rules clean

in case You forget to generate initrd file, it always might be generated by hand:

sudo -i

cd /boot/

mkinitramfs-kpkg -o initrd.img-2.6.32.11+drm33.2imq 2.6.32.11+drm33.2imq

update-grub

Iptables package with IMQ support

First, the patch - there is no iptables-1.4.4 imq patch available on linuximq.net I'm afraid. I have used iptables-1.4.6-imq patch and fixed it to compile with iptables-1.4.4.

Original patch can be found here.

Changes:

diff -Naurw iptables-1.4.6-imq.diff iptables-1.4.4-imq.diff
--- iptables-1.4.6-imq.diff	2010-01-27 11:53:22.000000000 +0100
+++ iptables-1.4.4-imq.diff	2010-05-08 13:18:21.000000000 +0200
@@ -43,7 +43,7 @@
 +
 +	switch(c) {
 +	case '1':
-+		if (xtables_check_inverse(optarg, &invert, NULL, 0, argv))
++		if (xtables_check_inverse(optarg, &invert, 0, argv))
 +			xtables_error(PARAMETER_PROBLEM,
 +				   "Unexpected `!' after --todev");
 +		mr->todev=atoi(optarg);

Ready to use patch can be downloaded from here using command below:

wget http://nme.pl/pub/patches/iptables-1.4.4-imq.diff

Ok, now since we got patch ready, we can download iptables sources and compile our deb package:

apt-get source iptables

cd iptables-1.4.4

cp ../iptables-1.4.4-imq.diff debian/patch/1009-iptables-1.4.4-imq.diff
echo "1009-iptables-1.4.4-imq.diff" >>debian/patch/series

patch -p0 < ../iptables-1.4.4-imq.diff

dpkg-buildpackage -rfakeroot -uc -b

In case You are recompiling for some reason, one of the distro patches might fail - in this case edit debian/patches/series using Your favourite editor and comment out the following patch:

0902-docs-version-reference.diff    ->    #0902-docs-version-reference.diff

Operation above might be archived by in place edition of debian/patch/series using command below:

sed -i 's/^0902/#0902/' debian/patch/series

When compilation ends, You should get two packages in parent directory: iptables and iptables-dev.

Installation & freezing our changes

Now we can install our packages:

dpkg -i *.deb

It will install following packages:

iptables_1.4.4-2ubuntu2_i386.deb
linux-image-2.6.32.11+drm33.2imq_2.6.32.11+drm33.2imq-10.00.Custom_i386.deb
iptables-dev_1.4.4-2ubuntu2_i386.deb

You might also consider holding packages to be sure that they will not be replaced during standard regular-basis upgrade:

aptitude hold linux-image iptables iptables-dev

IMQ development, status and replacement discussion

It is not true that recent IMQ patches are not stable as I have read on some web pages. Since Jussi joined the IMQ team, problems I have had with 2.6.18-24 kernels have gone to past.

Kernel 2.6.28.9 with iptables 1.4.0 works perfectly stable taking care of huge loads of network traffic. I think that current patch described above will work the same (im making before-production tests currently and it seems to work fine).

On the other hand - IFB - which is meant as replacement for IMQ - as for me - it does not offer the same functionality for bridge environment I need... Of course - I might be mistaken. Thats why - if anyone of You have replaced IMQ with IFB for bridge devices with ingress and egress traffic shaping - I'm very interested in the solution.