Thursday, April 11, 2013

Configuring a 4-port Sun Happy Meal card

Some time ago I rescued a pair of 4 port Oracle/SUN Happy Meal 10/100 Ethernet cards and I decided it was time to play with them. There was an issue with the sunhme driver, so I created an akmod package for Fedora 18 to patch the bug on my system so that the patch would be picked up automatically on every kernel update as well. The akmod package is available on github.

There's another quirk to these cards as well. At least on my system there is an issue with renaming the interface names that leads to one of the interfaces being renamed inconsistently(interface name ends up being something like "rename6"). I wanted to rename the interfaces nicely so that I could tell the sunhme interfaces from other interfaces in my system.

In addition to weird renames these cards have only one shared mac-address assigned to each interface, so you can't just match the interfaces by their mac-address, since they're the same.

These quirks made getting the udev rules to match rather challenging. Eventually I found a nice script that scans for the interfaces and creates a template for a proper matching udev rule.

In order to be able to use just on interface without having packets disappearing on the other interfaces, which might not be physically connected I also set unique mac-addresses for all the interfaces.

/etc/udev/rules.d/30-sun-hme.rules

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNELS=="0000:06:00.1", \
    KERNEL=="eth*", NAME="hme0", RUN+="/usr/local/bin/sunmacchanger %k 00:03:ba:a8:58:e5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNELS=="0000:06:01.1", \
    KERNEL=="eth*", NAME="hme1", RUN+="/usr/local/bin/sunmacchanger %k 00:03:ba:a8:58:e6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNELS=="0000:06:02.1", \
    KERNEL=="eth*", NAME="hme2", RUN+="/usr/local/bin/sunmacchanger %k 00:03:ba:a8:58:e7"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNELS=="0000:06:03.1", \
    KERNEL=="eth*", NAME="hme3", RUN+="/usr/local/bin/sunmacchanger %k 00:03:ba:a6:58:e8"

/usr/local/bin/sunmacchanger

#!/bin/bash

#make sure the interface is down, otherwise setting the mac will fail
/sbin/ifconfig $1 down
/usr/bin/macchanger --mac=$2 $1

After the changes I just needed to unload the driver, reload the rules and load the driver again and udev magic would happen
chmod +x /usr/local/bin/sunmacchanger
rmmod sunhme
udevadm control --reload-rules
#loading my patched version of sunhme driver
modprobe sunhme2g

Now I have 4 100M interfaces on one card. It'll come handy when routing traffic outside my LAN and I could have redundancy in case one WAN connection goes down.

Unless I spesifically tell NetworkManager not to bring up interfaces hme1-hme3, NetworkManager will bring those interfaces up. This causes some log spam:

output of dmesg

[ 6438.361078] hme1: Auto-Negotiation unsuccessful, trying force link mode
[ 6438.369059] hme2: Auto-Negotiation unsuccessful, trying force link mode
[ 6438.373052] hme3: Auto-Negotiation unsuccessful, trying force link mode
[ 6447.974274] hme1: Link down, cable problem?
[ 6447.982269] hme2: Link down, cable problem?
[ 6447.986242] hme3: Link down, cable problem?
[ 6459.990561] hme1: Auto-Negotiation unsuccessful, trying force link mode
[ 6459.998551] hme2: Auto-Negotiation unsuccessful, trying force link mode
[ 6460.002549] hme3: Auto-Negotiation unsuccessful, trying force link mode
[ 6469.603795] hme1: Link down, cable problem?
[ 6469.611764] hme2: Link down, cable problem?
[ 6469.615756] hme3: Link down, cable problem?

You can prevent NetworkManager from needlessly bringing up these interfaces by adding the macs to the unmanaged-devices parameter in [keyfile] section and checking that keyfile plugin is loaded in [main] section's plugins parameter.

/etc/NetworkManager/NetworkManager.conf

[main]
plugins=ifcfg-rh,keyfile

[keyfile]
unmanaged-devices=mac:00:03:ba:a8:58:e6;mac:00:03:ba:a8:58:e7;mac:00:03:ba:a8:58:e8

It's not exactly plug and play, but playing with these cards is a good learning opportunity. It wouldn't hurt to have some kind of graphical configuration tools for doing some of this stuff. It requires some knowledge about udev and NetworkManager + a search engine to do this "manually".

Sunday, April 7, 2013

Google Redirect Rewrite memory usage

Image courtesy of Open Clip Art Library
I previously found out that you can pretty easily rewrite url's for Squid. Today I noticed Squid launches a bunch of child processes to do the url rewriting. I got curious about the memory usage. I had a feeling that the Perl version would not consume as much memory as PHP and it appears it is indeed so.

I tested both PHP and Perl versions to see how much memory they would consume. First I checked the memory usage of the PHP version after browsing a bit. Then I changed squid.conf to use the Perl version and again checked the memory usage. Squid had just launched one googlerewriter child process, so I browsed some more and then checked again. I'm guessing Squid starts the processes when it actually needs them.(ps. Documentation confirmes this) Anyway some processes then appeared to have been launched.

Fields

MAJFL
Major page fault: The number of major page faults that have occurred with this process
TRS (kB)
Text resident set: The amount of physical memory devoted to executable code
DRS (kB)
Data resident set: The amount of physical memory devoted to other than executable code
RSS (kB)
Resident set size: The portion of a process's memory that is held in RAM. The rest of the memory exists in swap or the filesystem (never loaded or previously unloaded parts of the executable).

Even for a tiny script php version caused some page faults and it's using way too much memory for the task it's doing.

PHP

$ ps faxv
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
13098 ?        Ss     0:00      0  5047 12668  2608  0.0 /usr/sbin/squid -a 3128 -f /etc/squid/squid.conf
13100 ?        S      0:01      5  5047 35240 25052  0.4  \_ (squid-1) -a 3128 -f /etc/squid/squid.conf
13101 ?        S      0:00      0     5  3942   992  0.0      \_ (logfile-daemon) /var/log/squid/access.log
13102 ?        S      0:00      1     2  3793   740  0.0      \_ (unlinkd)
13109 ?        S      0:00     50  3385 43962  7812  0.1      \_ /usr/bin/php /usr/local/bin/googlerewriter.php
13111 ?        S      0:00      0  3385 43962  7816  0.1      \_ /usr/bin/php /usr/local/bin/googlerewriter.php
13115 ?        S      0:00      0  3385 43962  7816  0.1      \_ /usr/bin/php /usr/local/bin/googlerewriter.php
13116 ?        S      0:00      0  3385 43962  7812  0.1      \_ /usr/bin/php /usr/local/bin/googlerewriter.php
13117 ?        S      0:00      0  3385 43962  7816  0.1      \_ /usr/bin/php /usr/local/bin/googlerewriter.php

$ top
  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
15552 squid     20   0 47348 7812 5428 S   0.0  0.1   0:00.05 googlerewriter.
15735 squid     20   0 47348 7816 5428 S   0.0  0.1   0:00.03 googlerewriter.
15736 squid     20   0 47348 7816 5428 S   0.0  0.1   0:00.03 googlerewriter.
15741 squid     20   0 47348 7816 5428 S   0.0  0.1   0:00.03 googlerewriter.
The resident set size of the Perl version is 31% that of the PHP version, or in other words the PHP version is using 3 times as much memory per process. By using the Perl version you'd save at least 5.2MiB. Not that this matters much on my current proxy server, but for an embedded server it would matter.

Perl

$ ps faxv
  PID TTY      STAT   TIME  MAJFL   TRS   DRS   RSS %MEM COMMAND
13382 ?        Ss     0:00      0  5047 12668  2608  0.0 /usr/sbin/squid -a 3128 -f /etc/squid/squid.conf
13384 ?        S      0:01      0  5047 37988 25308  0.4  \_ (squid-1) -a 3128 -f /etc/squid/squid.conf
13387 ?        S      0:00      0     5  3942   992  0.0      \_ (logfile-daemon) /var/log/squid/access.log
13388 ?        S      0:00      0     2  3793   740  0.0      \_ (unlinkd)
13396 ?        S      0:00      0     3  8700  2460  0.0      \_ /usr/bin/perl /usr/local/bin/googlerewriter.pl
13426 ?        S      0:00      0     3  8700  2376  0.0      \_ /usr/bin/perl /usr/local/bin/googlerewriter.pl
13427 ?        S      0:00      0     3  8700  2372  0.0      \_ /usr/bin/perl /usr/local/bin/googlerewriter.pl
13429 ?        S      0:00      0     3  8700  2460  0.0      \_ /usr/bin/perl /usr/local/bin/googlerewriter.pl
13430 ?        S      0:00      0     3  8700  2460  0.0      \_ /usr/bin/perl /usr/local/bin/googlerewriter.pl
13431 ?        S      0:00      0     3  8700  2460  0.0      \_ /usr/bin/perl /usr/local/bin/googlerewriter.pl

$ top
  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND
13396 squid     20   0  8704 2460 1724 S   0.0  0.0   0:00.19 googlerewriter.
13429 squid     20   0  8704 2460 1724 S   0.0  0.0   0:00.03 googlerewriter.
13430 squid     20   0  8704 2460 1724 S   0.0  0.0   0:00.02 googlerewriter.
13431 squid     20   0  8704 2460 1724 S   0.0  0.0   0:00.02 googlerewriter.
13426 squid     20   0  8704 2376 1716 S   0.0  0.0   0:00.04 googlerewriter.
13427 squid     20   0  8704 2372 1716 S   0.0  0.0   0:00.03 googlerewriter.

Saturday, April 6, 2013

Faster browsing aka Google Redirect Rewrite

Image courtesy of Open Clip Art Library
Once again I got annoyed by having to wait for Google to redirect me. I also think it's none of Google's business to know which sites I do visit especially if they can't be quick about it. So I decided to get rid of the delay.
I checked if there's a plugin for that and it seems there is. You can install Remove Google Redirects from Chrome Web Store. Being a paranoid weirdo like I am that still wasn't enough. I already had a Squid proxy that I had configured to make it so that you couldn't even know that some websites were blocked by my ISP(Sonera). It made sense to try and figure out if there was a trick that I could do with squid that allows me to get rid of the middle man(Google) in the redirect process.

And behold for the creators of Squid have indeed been so wise as to add a way to mangle the urls. All I had to do was to write a script that takes the url, checks if it's a google redirect url and if so, parses the url to get the actual url where we want to go and return that. The example on Squid feature page was a good place to start and this is what I came up with:

Perl Version


#!/usr/bin/perl

use URI;
use URI::QueryParam;

$|=1;
while (<>) {
    chomp;
    @X = split;
    $url = $X[1];
    #check if this is a google redirect url
    if ($url =~ /\/\/.*\.google\.[^\/]+\/url/) {
        my $uri = URI->new($url);
        $url = $uri->query_param("url");
        print $X[0]." 302:$url\n";
    } else {
        print $X[0]." \n";
    }
}
I had to install a couple of Perl modules while I was trying to refamiliarize myself with Perl so I wanted make a PHP version of the same helper. With PHP I wouldn't have to install any extra modules when some day I decide to use this on some other machine. I usually have PHP installed everywhere.

PHP Version


#!/usr/bin/php
<?php

function convertUrlQuery($query) {
    $queryParts = explode('&', $query);

    $params = array();
    foreach ($queryParts as $param) {
        $item = explode('=', $param);
        $params[$item[0]] = $item[1];
    }

    return $params;
}
while(1){
    $line = trim(fgets(STDIN)); // reads one line from STDIN
    $params = explode(" ", $line);
    $pattern = '/\/\/.*\.google\.[^\/]+\/url/';

    if (preg_match($pattern, $params[1], $matches, PREG_OFFSET_CAPTURE, 3)) {
        $parts = parse_url($params[1]);
        $query = convertUrlQuery($parts['query']);
        $url = urldecode($query['url']);
        echo $params[0]." 302:$url\n";
    } else {
        echo $params[0]." \n";
    }
}


In the end I like that with Perl I didn't have to write any functions for simple things like url parsing, but unless I package this as an installable package I could not just drop it in and expect it to work since I had to install the extra stuff as modules.(Yes I could have written my own implementation, but I'm not that much into reinventing the wheel. Also I was a bit impatient to get the script ready so I could see the results) With the PHP version I could just drop it in and as long as I had PHP installed it would work.

I strongly recommend adding a line in squid.conf It really makes a difference.

url_rewrite_program /path/to/googleredirectrewriter

Tuesday, April 2, 2013

Setting up Prestashop file permissions on Fedora

Sometimes I need to write important things somewhere I can find them. That's the case again with setting up Prestashop file permissions on a SElinux enabled system such as Fedora.


cd prestashop
chown -R apache:sebastian
# allow user and group search directories and set the new files inherit the group of parent folder 
find . -type d -exec chmod ug+xs {} \;
# don't allow others to do anything and allow my group to read and write all, don't allow apache to write anything
chmod -R u-w,o-rwxs,g+rw .
# set permissions of newly created files so that others cannot do anything them
umask o-rwx
# set selinux context so that apache can access everything
chcon -t httpd_sys_content_t -R .
# set selinux context and permissions so that apache can write into places it needs to be able to write
chcon -t httpd_sys_rw_content_t -R config cache log img mails modules translations upload download sitemap.xml
chmod -R u+rw config cache log img mails modules translations upload download sitemap.xml

Tip me if you like what you're reading