Random Tips

• Binary data in CHAR-columns with MySQL
• Never make an (X)HTML-<script>-Tag self-closing
• vpopmail + Maildrop
• maildrop: signal 0x06
• installing gentoo in a chroot while using a GRSecurity kernel denying chmod +s
• Linux kernel compile for x86 on x86_64
• Don't even think about using ADSL-modems from AVM with Linux

Binary data in CHAR-columns with MySQL

• Insert or update data with INSERT INTO table (binary_col) 0x12340a or INSERT INTO table (binary_col) x'12340a') (last time I used the former because the latter caused a syntax error in some cases (version was 4.0.26)
• Trailing spaces may, depending on your version, be stripped. Also, 0x0012340a possibly evaluates to NULL. So I chose to make the column one byte longer than the data I had for it and insert 12340a as 112340a1 which reliably prevents both. (You have to handle that when retrieving the data, of course.)
• For reliable WHERE queries, always do WHERE binary_col = CAST(0x1234 AS CHAR)

Never make an (X)HTML-<script>-Tag self-closing

Never ever write sth like

<script type="text/javascript" src="some/where.js" />

I did so once, and Opera wouldn't execute the script anymore when in HTML mode. (Though in XML mode it did. Really took me some time to figure this out.) Instead, always, always write

<script type="text/javascript" src="some/where.js"></script>

vpopmail + Maildrop

If you execute commands from within your Maildrop-files, keep in mind that the Shell of the vpopmail user usually is /bin/false. This means that any command that Maildrop tries to run will fail, because it is passed to the user's shell. You can either change the vpopmail user's shell or, which I prefer, add a line like this to the beginning of you Maildrop files:

SHELL="/bin/bash"

maildrop: signal 0x06

If you get the above error from Maildrop and CFLAG changes as mentioned in some linked pages don't get you anything, try changing any

EXITCODE=123
to mailboxname

with

EXITCODE=123
cc mailboxname
exit

installing gentoo in a chroot while using a GRSecurity kernel denying chmod +s

If you want to install gentoo in a chroot, but have a GRSecurity-powered kernel runnig, which denies chmod +s, and you don't want to recompile your kernel, you can try this.

ATTENTION: You will have to correct files with missing chmod +s and missing device nodes YOURSELF.

Create a file called ugly-hack.c which contains the following code:

/* taken from uClibc and modified for my purposes. 
GNU Library General Public License (LGPL) version 2 or later.
*/

#include <sys/syscall.h>


#define _GNU_SOURCE
#define _LARGEFILE64_SOURCE
#include <features.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/syscall.h>
#include <endian.h>




#define __NR___syscall_chmod __NR_chmod

static inline _syscall2(int, __syscall_chmod, const char *, path, __kernel_mode_t, mode);

int chmod(const char *path, mode_t mode)
{
    return __syscall_chmod(path, mode & 0777);
}

#define __NR___syscall_fchmod __NR_fchmod
static inline _syscall2(int, __syscall_fchmod,
        int, fildes, __kernel_mode_t, mode);

int fchmod(int fildes, mode_t mode)
{
    return (__syscall_fchmod(fildes, mode & 0777));
}

#define __NR___syscall_mknod __NR_mknod
static inline _syscall3(int, __syscall_mknod, const char *, path,
        __kernel_mode_t, mode, __kernel_dev_t, dev);

int mknod(const char *path, mode_t mode, dev_t dev)
{
    return 0;
    /* We must convert the dev_t value to a __kernel_dev_t */
    __kernel_dev_t k_dev;

    k_dev = ((major(dev) & 0xff) << 8) | (minor(dev) & 0xff);
    return __syscall_mknod(path, mode, k_dev);
}

Then execute

# gcc -fPIC wrapper.c -o /lib/hackfix.so -shared
# export LD_PRELOAD=/lib/hackfix.so

This will override the chmod and fchmod libc library calls, removing possible sticky bits, and replace the mknod libc library call with doing nothing and returing success.

Remove /lib/hackfix.so after you don't need it anymore, but remember to clean LD_PRELOAD first. DO NOT USE THIS SUGGESTION IF YOU'RE NOT AWARE OF ITS IMPLICATIONS.

Linux kernel compile for x86 on x86_64

If you want to compile a kernel for your old, slow x86 box on your new, fast x86_64 machine, then you will probably do linux32 make <menuconfig|bzImage|...>. If you transfer this kernel source tree to the x86 target box, however, you will run into the problem that menuconfig and the other tools in the scripts/ directory are not executables for x86, but for x86_64, as they have been compiled with the system's standard compiler on the x86_64 machine. You can try and delete the binary tools in there, or do a make clean (effectively undoing your efforts in saving time if you want to compile external (WLAN!) modules against that tree, because these usually won't work), or try some other things causing various strange behaviour. (that's what I did at least *hehe*)

However, I've found a more reliable way of doing things: linux32 make HOSTCC="gcc -m32" <whatever>. This way, all the tools in said directory, which are compiled with HOSTCC, will be x86 executables, and you will have no hassles after transfering your kernel. (Given that you have all required libraries, e. g. ncurses for menuconfig, available in 32-bit versions. Of course. I had to add -L/emul/linux/x86/lib32 to HOSTCC on my getoo system to make things work.)

The only annoyance remaining is that menuconfig et alii will be recompiled on the x86 box, as HOSTCC will have changed on the x86 box, because you won't specify it there, as you are just as lazy as I am. You could change the HOSTCC variable in the Makefile, but this can also become annoying if you are building kernels for several machines from your kernel sources.

Don't even think about using ADSL-modems from AVM with Linux

A few years ago. when I first got an ADSL Internet connection, I purchased a AVM Fritz! Card DSL for it. Some time later, when I had a 3 Mbps connection and after AVM had finally released (binary-only-)drivers compatible with 2.6 (they were half a year late), I noticed significant traffic in both directions rather reliably hanging my machine, and I got reports from others using other ADSL-modems from AVM and having the same problems. As AVM doesn't care much about it and I haven't found a solution, I invested some money in a Teledat 431 LAN and have ever been happy with the Linux kernel's built-in PPPoE drivers.

If you do however already own ADSL-modems (I do not consider the router-like devices from them being modems, but I wouldn't buy them any more eiter) from AVM and want to give it a try with Linux, but not with SUSE, you will probaly find my howto (German) handy, as AVM doesn't seem to care about none-SUSE either. Note that it will not see one single further update, as I have given up with AVM.