So I installed the hard disks and booted it up. I created a big RAID 6 volume over all disks and then realized that it wasn't helping a lot because, while there was a menu option to enable NFS support in the first place, there was none whatsoever to export my new file system via NFS. Also, showmount confirmed that it wasn't exported.

Follow the manual

As I couldn't find anything in the online help or the user manual about exporting file systems to NFS, I found Thecus N5200 Debian on the Chaoswiki and tried to follow the procedure outlined there. However, it turned out that my NAS was running a much more recent version of the Thecus supplied Linux distribution and couldn't install any of the mentioned packages. Also, Thecus itself doesn't seem to offer any SSH server.

Do It Yourself, maybe?

So since the whole thing is just an i386 which runs Linux I decided to try and go in to fix things up myself. I installed Debian onto an SD card and tried in kvm whether it boots up fine and configures the system. Then I got myself an adapter from PC Engines to mount the SD card into the Thecus NAS and tried to boot it up.

Well, so much for the theory. The system did something but there was no output on any of the two serial consoles, ever. Not even the firmware of the box write anything anywhere. The system is really hard to interact with. And while, in qemu, I get a serial console, it didn't work at all in the Thecus.

And while the network card was configured and the firmware installed, nothing moved on that front either. According to Running Debian on Thecus n5200 on wpkg, the only way to tell what the NAS is doing seems to be to solder a VGA adapter onto the mainboard and attach a monitor.

Picking up the pieces

So to summarize, so far I wasted more than CHF 1'000.- and 10 TB of space. All I got in return is a brick which sits on the ground and can only share files with Windows boxes. Yes, I know, most systems can mount SMB shares, but that's really not an option.

So I really wonder where this is going. What I'd love is a tiny box with space for 5 hard disks which can at least do 1 Gbit/s and can be integrated easily with my LDAP and Kerberos setup. In my world, this shouldn't be too much to ask.

However, instead of this, vendors seem to throw very expensive closed systems at us which attempt to prevent us to customize them or to really interact with them in any way which the vendor wasn't planning for. I don't see the reason though.

What's the loss for Thecus if I can easily install my own operating system, like I can with my ALIX? They aren't losing any money form this or anything. What's the cost of making everything output to the existing serial port? It's not like this is expensive to implement or anything. And the operating system used in the box suppports it just as well.

So far I'm getting the feeling that I just found a new brick I can use as a door stopper. But I guess I'll try to do some more stuff with it before I loot the hard disks. Perhaps I should buy a regular Mini-ITX PC and use that.

I booted into grml, set up the partitions and file systems (/dev/md0 as /boot, /dev/md1 with lvm and the root file system). Then I mounted them in place and ran debootstrap. However, debootstrap said the configuration phase of the packages failed. So I chrooted into the system and ran dpkg --configure -a.

Then, I figured that Debian prefers to leave the most important programs uninstalled, so I ran apt-get install less bzip2 pax openssh-server sysklogd grub-pc linux-image-2.6.32-5-amd64. However, grub-pc decided it doesn't want to install itself successfully. A manual run of grub-install fixed this glitch as well. Then I set up a root password, enabled root logins for now in the ssh configuration and configured /etc/fstab and /etc/network/interfaces. I added a netconsole to the grub configuration, just in case.

Then I figured it was time to test the system, so I rebooted. However, I never saw the system come up. Also, the netconsole didn't log a thing. So I booted back into grml, installed kvm and tried to boot the system, only to find grub saying:

error while parsing number

So I fixed the device paths and re-ran update-grub2. Then the system booted but still didn't respond to ping, and had nothing on the netconsole. So I booted grml and saw that there was finally at least a dmesg.0 file. This file contained a number of hints:

netconsole: eth0 doesn't exist, aborting.
e100: eth0: e100_request_firmware: Failed to load firmware "e100/dm101m_ucode.bin"

So I figured that apparently the Debianists no longer ship firmwares anymore. I found a package called linux-firmware in the non-free repository and installed it. Then I rebooted and received ping replies from the system, but ssh never came up, the connection remained refused. So I booted into grml and found all logs in the chroot to be empty:

grml# ls -l  
-rw-r----- 1 root adm 0 Aug 31 23:20 /mnt/vms-planck--root/var/log/messages
-rw-r----- 1 root adm 0 Aug 31 23:20 /mnt/vms-planck--root/var/log/syslog
-rw-r----- 1 root adm 0 Aug 31 23:20 /mnt/vms-planck--root/var/log/daemon.log
grml#

So I installed Dropbear and configured it to listen to port 2222, then rebooted. The system pinged, but ports 22 and 2222 remained refused. When running the system in kvm again, I discovered strange messsages though and found the root cause to be a popular debootstrap bug:

grml# cat /sbin/start-stop-daemon
#!/bin/sh
echo
echo "Warning: Fake start-stop-daemon called, doing nothing"
grml#

So I moved /sbin/start-stop-daemon.REAL back to /sbin/start-stop-daemon, but instead of typing reboot I accidentally typed poweroff, and now I have to wait for the hoster to flip the power switch of the server again before I can continue, so things will remain interesting.

I guess being bitten by debootstrap, defaults, grub, netconsole, firmware and start-stop-daemon on the same day was a bit too much. Time to watch V for Vendetta and go to bed.

Update: Note to those who didn't realize: no, I didn't watch the film, I just found it fitting.

I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way.

gforge_base/evolvisforge/gforge/common/include/utils.php:1009

I was really, really bad at writing parsers. I still am really bad at writing parsers.

gforge_base/evolvisforge/gforge/common/include/minijson.php

I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say "yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I'll just restart apache every 10 requests.

gforge_base/evolvisforge/gforge/www/pm/t_follow.php

We have things like protected properties. We have abstract methods. We have all this stuff that your computer science teacher told you you should be using. I don't care about this crap at all.

gforge_base/evolvisforge/gforge/www/pm/t_lookup.php

I think people like Rasmus explain a lot about the poor design and the many implementation flaws of the PHP programming language.

Thanks as well to Benny Siegert who provided the quotes.

Being the automation freak I am, I rolled an RPM package of the PHP application which installs it into /usr/share. Then, a Puppet rule creates an Apache vhost in /home/www and union mounts the shared installation into htdocs, with a vhost subdirectory named confdata as read-write layer.

It turned out I had better used NetBSD for the task. The only unionfs implementation available in CentOS 5.5 is fuse based and called funionfs. However, funionfs doesn't support SElinux contexts, so everything ends up in the context fusefs_t, leaving it inaccessible to Apache. A small SElinux module fixed that:

module serendipity 1.0;

require {
    type httpd_t;
    type fusefs_t;
    class lnk_file read;
    class dir { read write remove_name getattr create search add_name };
    class file { read write getattr create setattr rename };
}

#============= httpd_t ==============
allow httpd_t fusefs_t:dir { read write remove_name getattr create search add_name };
allow httpd_t fusefs_t:file { read write getattr create setattr rename };
allow httpd_t fusefs_t:lnk_file read;

This might not be the most secure solution but nothing other than Apache runs on this VM anyway, so I didn't care enough. It's still better than turning off SElinux entirely.

In order to allow the software to access the database, I had to flip another SElinux switch:

httpd_can_network_connect_db --> on

Now things almost worked. However, installing templates via the web interface does not, so I went on to investigate:

% cd /home/www/s9y.zrh.internetputzen.com/htdocs/templates
% mkdir test
mkdir: cannot create directory `test': No such file or directory
% ls -ld test
ls: test: No such file or directory
% touch test
touch: setting times of `test': File exists
% ls -ld test
-rw-r--r-- 1 root root 0 May 24 20:49 test
% rm test

It's impossible to create directories in the funionfs. Apparently it's some kind of bug. Creating the template in confdir worked but it means the web interface is not working.

Looking forward to aufs2 in later versions of CentOS.

In Oops, we did it again, Monty names a number of these bugs and outlines variety of bad management decisions which have lead to the current situation, and which apparently have lead to similar situations in the past.

To me, it does not really come as a surprise. As you may or may not know, I have been following the MySQL company, community and products for years, and haven't seen too many different types of releases so far. In any case, I strongly support the suggestion of Monty and also strictly recommend staying with MySQL 5.0 for now &mash; or to migrate to PostgreSQL, if possible.

The fact that the Python core team deliberately keeps breaking compatibility for Zope is probably bad enough, but at least SQLAlchemy appears to work well enough with the various versions. Well, but how does it work?

The answer is: bizarre.

Never trust the database to get sequences right!

The first thing I discovered was with PostgreSQL and sequences. Some tables use sequences for creating their primary key, which is then going to be a 64-bit integer. This is done automatically by either not naming the primary key column on insert, or by using the keyword DEFAULT.

Looking through the debug output, however, items like these can be spotted:

2008-11-04 09:26:24,258 INFO sqlalchemy.engine.base.Engine.0x..d0 select nextval('data_from_box_id_seq')

This is wrong on a number of levels. At this point, SQLalchemy manually queries the next value returned by the sequence for the id column. This value is consequently used in the insert statement for the id column. This breaks the atomicity of the insert statement — rather than letting PostgreSQL handle things internally as it's supposed to, the insert statement is artificially split into two statements. Of course, this also means that two SQL operations are performed, which almost doubles the network overhead (especially over encrypted connections).

The most likely reason why this is done is to have the row ID of the newly inserted row for use in the client side object representation. However, PostgreSQL has two much better mechanisms achieving the same: Firstly, the ID can be queried using the last_insert_id operation, or, even better, everything can be handled in one statement by using the RETURNING keyword:

INSERT INTO data_from_box VALUES (DEFAULT, something, else) RETURNING id;

Prepared statements are for the weak and timid

An even more bizarre affection manifests itself in the support for MySQL. Rather than to make use of the prepared statements, which are mandated by the API specification, SQLAlchemy attempts to reproduce prepared statements in the SQLAlchemy code, and to naturalize SQL statements manually. Then, the resulting statement is PREPAREd and EXECUTEd.

This of course constitutes a duplication of functionality, and more than this, the SQLAlchemy users are now prone to SQLAlchemy prepared statement naturalization bugs which cannot really occurr in SQL prepared statements (because they are never synchronized into a string but used as-is).

Overall, it is very hard to say what the SQLAlchemy developers had in mind, but it seems clear that it was nothing useful.

• iter(collection) -> iterator
• iter(callable, sentinel) -> iterator

The first call is rather unproblematic for sure. It calls a class method, it gets its object and that's it.

The second variant is however utterly useless. The callable is not called with any object — in fact, the call to iter does not even know what object is being iterated. This requires the programmer to store the state externally in some kind of global variable, or not to have any state at all. The latter would render the iterator rather pointless, since a crucial part of the purpose of an iterator is to externalize the state.

All operations? Not quite! A single function parameter is holding out, strong as ever, against the integer compatibility. Life is not easy for the programmers attempting to make use of the resulting objects.

In fact it's quite funny: the problem is with the function pow. As the documentation says:

In [1]: pow.__doc__
Out[1]: 'pow(x, y[, z]) -> number\n\nWith two arguments, equivalent to x**y. With three arguments,\nequivalent to (x**y) % z, but may be more efficient (e.g. for longs).'

Since crypto wants speed, and ASN.1 is frequently used in crypto, we now try to combine pyasn1 and the amk crypto toolkit, since Python itself does not contain any crypto. We use the DSA sign function, which basically only calls pow() for us. This is where we get bitten. The reason is simple and astonishing:

In [2]: i = pyasn1.type.univ.Integer(23)
In [3]: pow(i, 23)
Out[3]: Integer('20880467999847912034355032910567')
In [4]: pow(23, i)
Out[4]: Integer('20880467999847912034355032910567')
In [5]: pow(23, 23, i)
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)

/home/tonnerre/<ipython console> in <module>()

TypeError: unsupported operand type(s) for pow(): 'int', 'int', 'instance'

In [6]:

Astonishingly, the Integer instance is allowed as the first and second argument to pow(), but not as the third one. More astonishingly, all of them are supposed to be ints. Even more weirdly, if pow is called with 3 pyasn1 Integer()s, the error message is still the same: the first two Integer()s are said to be int, the last one remains an instance.