Jonathan's blog

Today I encountered a problem in my FreeRADIUS setup. Usernames can be sent to my RADIUS servers as a simple username (e.g. jonathan) or with a realm prepended (e.g. DOMAIN\jonathan).

When a username with a realm gets sent to a RADIUS authentication server that is doing MSCHAP, the domain is automatically stripped and you never notice. But when it gets sent to an accounting server (clearly no MSCHAP) there is no stripping or escaping done automatically.

This caught me out.

Users were authenticating on my network successfully. DOMAIN\rachel and DOMAIN\thomas were happily authenticated against the domain controllers and gained access to the wireless. But when they started sending accounting packets, the \r and \t portions of their usernames were sent to the database unquoted, where they were interpreted as a Unix newline and a tabspace respectively.

Eeek!

I didn’t notice until I saw that MySQL had converted these \r and \t characters to the hex equivalents. Where my accounting table should have contained rachel, it actually contained DOMAIN=0Dachel.

Yikes!

I fixed this by creating a local proxy realm. At the end of my proxy.conf, I added these lines:

realm DOMAIN {
}

Obviously substituting DOMAIN for the real name of my domain.

Then in the preacct section of my virtual server I added the module ntdomain to populate the variable %{Stripped-User-Name} with the domain part of the username that was originally in %{User-Name}.

Now, looking at the top of whichever dialup.conf suits your database architecture, make sure the following line is uncommented:

sql_user_name = "%{%{Stripped-User-Name}:-%{%{User-Name}:-DEFAULT}}"

…and that all other definitions of sql_user_name are commented.

Once you’ve done this, your accounting detail logs will contain username likes DOMAIN\\username (with an escaped backslash) and your database table will simply have username.

Yesterday at work I had the need to create a federated table in MySQL. I read about the federated engine and thought I had it sussed. I noted:

Beginning with MySQL 5.1.26, the FEDERATED storage engine is not enabled by default in the running server; to enable FEDERATED, you must start the MySQL server binary using the --federated option.

Turns out it’s also possible simply to add the line federated in the [mysqld] section of /etc/my.cnf

The version of MySQL currently installed on my CentOS box was an older one (5.0.45) but I added this line anyway. The server refused to start. It quickly became clear that the MySQL binary packaged with CentOS was not compiled with the federated engine.

Fedora is currently packaging MySQL 5.1.37 but it seems that this too is lacking the federated engine. That’s annoying – I had wanted to install a version of MySQL from some yum repo or other, so I don’t have to keep upgrading the package every time a new version is released.

Perhaps the lack of federated support is a Red Hat (and derivatives) issue. I downloaded the rpm from MySQL directly, and installed it. Guess what – no federated engine compiled in.

So I downloaded the source tarball. I explicitly configured it with the federated engine, like so:

./configure --with-plugins=federated

And then I built and installed it. Nothing worked properly out of the box, and I was annoyed to find that the make install command doesn’t do half of the things I would normally expect it to do. I found this information and followed the steps to get it working. I had to steal and tweak the /etc/init.d/mysqld script from a different box which was running the bog-standard CentOS package.

Woohoo! The federated engine was finally available.

mysql> show engines;
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine     | Support | Comment                                                        | Transactions | XA   | Savepoints |
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
| InnoDB     | YES     | Supports transactions, row-level locking, and foreign keys     | YES          | YES  | YES        |
| MRG_MYISAM | YES     | Collection of identical MyISAM tables                          | NO           | NO   | NO         |
| BLACKHOLE  | YES     | /dev/null storage engine (anything you write to it disappears) | NO           | NO   | NO         |
| CSV        | YES     | CSV storage engine                                             | NO           | NO   | NO         |
| MEMORY     | YES     | Hash based, stored in memory, useful for temporary tables      | NO           | NO   | NO         |
| FEDERATED  | YES     | Federated MySQL storage engine                                 | NO           | NO   | NO         |
| ARCHIVE    | YES     | Archive storage engine                                         | NO           | NO   | NO         |
| MyISAM     | DEFAULT | Default engine as of MySQL 3.23 with great performance         | NO           | NO   | NO         |
+------------+---------+----------------------------------------------------------------+--------------+------+------------+
8 rows in set (0.00 sec)

But I can’t understand why none of the binary builds of MySQL include it. Fair enough that isn’t enabled by default in the running server – it’s no problem to add a line to my.cnf on a standard CentOS box. But it is a nuisance to have to build from source. It doesn’t break anything to have it enabled in a build, even if unused.

Of course CentOS won’t change the way they build their packages until Red Hat does. So I’m doing what I can, and I have filed a feature request with Fedora in the hope that in the next major release, there will be a version of MySQL built with the federated engine.