cat php.ini | grep -v "^;" | grep -v "^$"

First, I tried to assign multiple interfaces to the VM, but that didn’t really work as the kernel was confused on which route it was supposed to send out data. Turns out it’s even easier. Let’s say you have the two IPs 1.2.3.4 and 5.6.7.8 which you want to assign to your domU. First, you need to put a line like this into your domU config:

vif=["ip=1.2.3.4/32 5.6.7.8/32,mac=00:1D:92:AA:BB:CC"]

Within the domU, you would then create an interface (eth0) with a static configuration for the IP 1.2.3.4. Afterwards, you would simply create an alias with the second ip:

ifconfig eth0:1 5.6.7.8 up

Now you should be able to reach your domU on both interfaces.

WebcamStudio is a software for modifying existing webcam streams or creating fake webcams, it comes with a kernel module to create virtual webcams. There are several input sources available, the most important one being the one called “Desktop”.

I will not give you detailed instructions of how to do it, as it probably violates the Chatroulette terms of use, but with WebcamStudio it is possible to connect two different chat partners, while sitting in the middle and watching them talk. The only obstacles left is sound (probably not an issue if you’ve got a sound card with a mixer supported by Alsa) and chat content. For the latter one, you’ll probably need to write a Greasemonkey script and a little server which exchanges messages between browser instances.

In order to fix this problem, one needs to export the xmodmap from the client system (running the NX client) to the server and, afterwards, setting this xmodmap from within the session. Of course, this can also be automated.

First of all, you need to export the xmodmap of the client you’re connecting from:

xmodmap -pke > nxclient.xmodmap

Now you need to transfer it to the system you’re using as the server. Afterwards, whenever you start a NX session, you need to call the following command from within the session (assuming you put the file obtained above in your home directory):

xmodmap ~/nxclient.xmodmap

Of course, you can automate this by calling the command from within the .profile file. The following code only makes sense though, when you connect from clients which all use the same keymap:

if [ -n "$NXSESSIONID" ]; then
 /usr/bin/xmodmap ~/nxclient.xmodmap
fi

This snippet works by checking for the environment variable $NXSESSIONID, which indicates that the session is running from within NX.

The program 'Eclipse' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadPicture (invalid Picture parameter)'.
(Details: serial 43551 error_code 158 request_code 148 minor_code 7)
...

After a short websearch, I found this Eclipse bugreport, which also contains a solution to the problem. It appears that Eclipse tries to load a wrong/nonexistent version of Mozilla’s XULRunner, which is responsible for rendering HTML parts within the IDE. Obviously, I encountered the problem as the autocompletion tried to display HTML code within a popup.

The solution is simple, you need to point Eclipse to the correct version of XULRunner. On a current openSUSE 11.3 installation, I used the direct path to XULrunner 1.9.2, the default is to rely on the update-alternatives system – and I’m not sure whether this might have caused the problem.
So if you encounter the error, you simply need to add the following line to your eclipse.ini file:

-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-1.9.2/xulrunner

On a 64 bit installtion, it needs to look like this, though:

-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib64/xulrunner-1.9.2/xulrunner

Of course, a lot of other people have already done the same thing, so I read around in some blogs/forums…the usual. Most posts pointed out that you need to write a Typo3 backend extension which would do that task for you.

Since I was too lazy to do so, I looked around a bit in the database and the code and came up with a solution which sometimes works and sometimes not…more on that later.

First of all, there was the issue of obtaining the backend user-ID which is stored in the table be_users. You can query that database with anything you got on a user, I used the e-mail address:

SELECT
  `uid`
FROM
  `be_users`
WHERE
  `email`=:email
LIMIT 1;

This is of course done without checking the password. Now the next thing that should be done is to remove all logins, which the following query does:

DELETE FROM
  `be_sessions`
WHERE
  `ses_userid`=:userId;

Typo secures its sessions in several ways, the most tricky one of them is by calculating a hash out of the browser’s user-agent. I believe this one is likely to change in future versions (the original code looks like there could be some additions), but here’s the code that does the magic for the current 4.4 release:

$hashLock=hexdec(substr(md5(":".$_SERVER['HTTP_USER_AGENT']),0,7));

Ok, now with that information (plus a random $sessionId you need to generate), the new session can be created in the database, here’s the query:

INSERT INTO `be_sessions` (
  `ses_id`,
  `ses_name`,
  `ses_iplock`,
  `ses_hashlock`,
  `ses_userid`,
  `ses_tstamp`,
  `ses_data`,
  `ses_backuserid`
) VALUES (
  :sessionId,
  'be_typo_user',
  :userIp,
  :hashlock,
  :userId,
  UNIX_TIMESTAMP(),
  NULL,
  0
);

The last part is to push the cookies to the client, and here lies the most important challenge. By default, Typo locks all cookies to the URL of the backend. However, if no cookies were present yet, one can create & send cookies which are accepted by Typo. First, here’s the code to create the cookies (assuming the backend is located at /typo3, also the cookies here are locked to a SSL-connection):

setcookie("be_typo_user",$sessionId,0,"/typo3/",$_SERVER['SERVER_NAME'],true);
setcookie("typo3-login-cookiecheck","true",0,"/",$_SERVER['SERVER_NAME'],false);

Conclusion

Now in my short tests, the above system always worked when there were no Typo3-generated cookies present yet. So if you want this method to REALLY work, you need to place the script within the same directory as the Typo3 backend so you can write the correct cookies, and you might want to make sure no cookies remain by deleting them first.

So all in all, this method was just a quick hack and currently fits my needs, the better approach is certainly to create an auth extension.

The most probable cause to this is a database which contains (large) blobs, as they somehow might not get encoded to the right format.

Easy solution to this problem: Use the –hex-blob option:

mysqldump -uusername -p --hex-blob db_name > db_name.sql

This will force mysqldump to encode all blobs in binary format, which won’t get messed up in encoding problems.

Lets say you want to mirror the remote repository http://example.com/svn, which you are allowed to access with the username svnsync, to a local repository located at /srv/svnMirror.

First step: Create the local (empty) repository:

svnadmin create /srv/svnMirror

Now you have a choice: Is access to this repository only available to the syncing user or will other users have access to it as well? In the first case, you only need to execute the following commands:

echo "#!/bin/bash" > /srv/svnMirror/hooks/pre-revprop-change
chmod u+x /srv/svnMirror/hooks/pre-revprop-change

If other users have access to the mirrored repository as well, I would recommend putting the following lines into /srv/svnMirror/hooks/pre-revprop-change and making it executable afterwards:

#!/bin/sh
USER="$3"
if [ "$USER" = "svnsync" ]; then exit 0; fi
echo "Only the svnsync user can change revprops" >&2
exit 1

With the first solution, all users with access to the mirrored repository would have unlimited control over it.

The next step is to perform an initial synchronization:

svnsync init --username=svnsync /srv/svnMirror

If this step was successful, you can begin the synchronization by issuing:

svnsync /srv/svnMirror

This will successively transfer all revisions available in the original repository, so this might take a while. For continuing synchronization, I’d recommend putting this command in your crontab.

The problem is, that Typo uses something like the following code to check for safe_mode:

if(ini_get('safe_mode')){
  //safe mode is enabled
}

This is fine as long as you use 1 or 0 to active or deactivate the safe_mode. But since PHP allows to use the words “on” and “off” as well, setting

safe_mode=off

will result in Typo thinking that safe_mode is enabled – although it is off.

I guess the bug will be fixed pretty soon according to the bug report, in the meantime, just replace off with 0 as a workaround.

However, my setup is a little bit different as – thanks to my hoster’s secure routing – all my domUs need to route their traffic through the main IP of the dom0, thus preventing me from setting the right network information (netmask 255.255.255.255 and a point-to-point route to the default gw) in YaST installation.

As a solution to the problem, I first installed openSUSE as a HVM domain from a downloaded DVD-ISO. Afterwards, I made some small changes and ran the system in paravirtualized mode. In order to do so, you need twice as much space as the installation takes, since you need to copy the data from the HVM disk to the paravirtualized disk.

So for this example, let’s say you have a volume group named opensuse with two logical volumes disk1 and disk2, where you start the HVM on disk2 and disk1 will be your root device for the paravirtualized machine. You’ll also need to download the openSUSE DVD image in ISO format.

Create a HVM domain

First of all, we need a HVM enabled config. Be sure to enable PAE, otherwise you’ll get an error when booting from the DVD. Here’s the config I used:

name="opensuse1"
memory=768
vcpus=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="restart"
disk=["phy:/dev/opensuse/disk2,xvda,w", "file:/path/to/openSUSE-11.3-DVD-x86_64.iso,xvdb:cdrom,r"]
kernel="/usr/lib/xen/boot/hvmloader"
builder="hvm"
device_model ="/usr/lib64/xen/bin/qemu-dm"
boot="d"
sdl=0
vnc=1
vncconsole=1
usbdevice="tablet"
shadowmemory=8
pae=1
acpi=0

Of course, you need to adapt the path to your local setting. If you install the domU on a remote host, make sure you’ve got X11 forwarding enabled, otherwise the VNC window will not pop up. You’ll be greeted with the standard openSUSE boot promt, so you can just carry out the installation as you normally. Just be sure to include the package kernel-xen in the installation. And if you’re smart, you’ll only create a single partition (no swap etc) on which the system gets installed, saving you the hassle of copying data from several partitions.

Copying data from HVM disk to paravirtualized disk

Once the domU has been set up, shut it down. Now, you need to copy all files from the HVM disk (/dev/opensuse/disk2) to the disk designated for the paravirtualized domain (/dev/opensuse/disk1). If you haven’t done this yet, put a file system of your choice on that disk, e.g.

mkfs.ext3 /dev/opensuse/disk1

Since the HVM domain uses a complete disk structure (including MBR etc) instead of a single partition, you need to mount only a single partition out of the disk structure. You can either specify an offset in the mount command or, if you’re a little lazy, use kpartx:

kpartx -av /dev/opensuse/disk2

This will create mappings for all partitions found in /dev/opensuse/disk2. If you only created one partition as I suggested, you’ll find the mapping at /dev/mapper/opensuse-disk21.

Now, mount the two disks to seperate mount points and begin copying:

mkdir /mnt/disk1
mkdir /mnt/disk2
mount /dev/opensuse/disk1 /mnt/disk1
mount /dev/mapper/opensuse-disk21 /mnt/disk2
cp -ax /mnt/disk2/* /mnt/disk1

After the process has completed, you need to make some small changes.

Change the file /mnt/disk1/boot/grub/menu.lst to boot the Xen enabled kernel. It only needs one entry like this:

default 0
timeout 0

title Xen
  root (hd0,0)
  kernel /boot/vmlinuz-xen root=/dev/hda1 splash=none showopts vga=0x314 console=xvc0
  initrd /boot/vmlinuz-xen

Make sure the kernel and the initrd exist. The console parameter is also important, otherwise you won’t see anything on the Xen console. We also need to make sure to enable this console in two more files.

Edit /mnt/disk1/etc/inittab and change the following line

1:2345:respawn:/sbin/mingetty --noclear tty1

to look like this:

1:2345:respawn:/sbin/mingetty --noclear xvc0

Now edit /mnt/disk1/etc/securetty and append xvc0 to the list. The last change isin /mnt/disk1/etc/fstab: Make sure you set the root device to the one from the domU config (e.g. /dev/hda1), as YaST will have put something like /dev/disk-by-id… in there.

Afterwards, you can umount the two disks:

umount /mnt/disk1
umount /mnt/disk2

Starting in paravirtualized mode

You still need to adapt the domU’s config to start in paravirtualized mode. Here’s what my config reads like:

name="opensuse1"
memory=768
vcpus=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="restart"
disk=["phy:/dev/opensuse/disk1,hda1,w"]
bootloader="/usr/bin/pygrub"
vif=["ip=192.168.1.1"]

The network setting looks slightly different, but you need to change this file anyway

Now, you can simply start the domU and it will get created as a paravirtualized domain.

Cleanup & Conclusion

If you don’t plan on restarting the dom0 in the next days, you should clear the mapping kpartx created by invoking:

kpartx -dv /dev/opensuse/disk2

Also, you are now free to either remove disk2 or add it to the paravirtualized machine for additional space.

I know the solution described in this post is not the most elegant one, but it worked for me right now. Hope it helps someone else, too…