Linux on Mac Mini – power on after power loss

Posted on February 17, 2012

The Mac Mini doesn't save this information in its BIOS (or equivalent), so you need to set it on each boot. I use my distribution's /etc/rc.local file for this.

Either way, these are the commands to run (copy, and uncomment the correct line for your Mini):

## PPC Mac Mini
#echo server_mode=1 > /proc/pmu/options

## Intel Mac Mini
#setpci -s 0:1f.0 0xa4.b=0

## nVidia Mac Mini
#setpci -s 00:03.0 0x7b.b=0x19

## Unibody Mac Mini
#setpci -s 0:3.0 -0x7b=20

gitolite: ‘foo’ does not appear to be a git repository – ForceCommand

Posted on January 11, 2012

Many people seem to get the following error message when trying to manipulate a remote git/-olite repository:
fatal: 'foo' does not appear to be a git repository
fatal: The remote end hung up unexpectedly

The problem here, which is absolutely not explained by the above error message, is likely to be that the remote command gitolite specifies in "~/.ssh/authorized_keys" is not used.

This can in turn be caused by two things, as far as I know:

  • You are using an ssh key which appears in the authorized_keys file without gitolite's "command=..." configuration, in which case the solution is to use a separate public/private key pair for git
  • Your SSH server has a ForceCommand directive in sshd_config (/etc/ssh/sshd_config on debian) which overrides the "command=..." setting in authorized_keys. To solve this, that directive has to go, or an exception needs to be added for your git user with a Match clause in sshd_config.

In the latter case, there does not seem to be any sane way to retrieve the contents of the "command=..." statement. While the user supplied command is available in the environment variable $SSH_ORIGINAL_COMMAND while using ForceCommand, the command supplied by authorized_keys seems nowhere to be found. Thus you need an exception for the ForceCommand directive. If you find another way to avoid this, please leave a comment below?

Creating .deb-Packages With Checkinstall

Posted on January 4, 2012

If you've exhausted all other options, it might be time to compile from source, even in Debian.

If you're about to do that though, don't abandon the concept of .deb files and the advantages they bring with versioning and easy removal. Use "checkinstall".

Checkinstall is in the standard Debian repositories and encapsulates your install into a nice, easily installable and distributable .deb file. apt-getting it and reading the manual is easy enough, but if you want a howto, has a nice one, archived here as a PDF.

Filed under: Linux, Reference No Comments

UDP through SSH

Posted on October 5, 2011
Good. Archived for personal reference.

copy here

Filed under: Linux, Reference No Comments

Fixing “shmget() failed: No space left on device”

Posted on September 14, 2011

I had this happen when someone ran a script to kill x11vnc every so often, using kill -9 (don't ask).

Killing x11vnc with SIGTERM (15) allows it to clean up its shared memory segments. SIGKILL (9) will not.

Googling around, I found a script over here (backup copy here).

The problem with that was that it's aimed at being run as the user, and it only supports usernames up to 10 characters, because of how "ipcs -m" prints its entries on Linux.

I wanted a solution that supported any length of username, and that could be run periodically, by root, as a cronjob to clean up after silly users, and that would also give me a report when it cleaned something, so I could see who was causing this.

The result was this script. It only supports Linux, and thus is a bit less portable than the one at, but it does the job, even with long usernames, and generates such nice reports:

Removed SHM Segments:
|   OWNER    |   COUNT    |
| bolt       |         42 |

Total: 42


Updated script, automatically synced with the one I'm actually using available here.

SSH in a while loop – stdin problems

Posted on September 12, 2011

When SSH is used with a line like "while read ....", the while loop will only run once.
This can be seen by running this simple example:

$ seq 1 10 | while read line; do ssh remotehostname "echo x${line}x"; done

You might expect this to connect to the host with the name "remotehostname" 10 times, and each time print one of the numbers in the sequence from 1 to 10. This will, however, not be the case. The result is a single line, saying "1".

Where did the rest of the numbers go? To the SSH process.
By default, SSH runs off with the stdin file descriptor, preventing "read" from reading anything else from it. You can see this by trying the following example:

$ seq 1 10 | while read line; do ssh remotehostname "echo x${line}x; cat -"; done

Now all the numbers were printed, but they were all in a single ssh connection. As you can see, only the number "1" got the X'es on both sides, indicating it was printed by the "echo" instruction. The rest of the numbers come from "cat -", which basically takes whatever comes in on SSH's stdin, and dumps it to the stdout (the screen, in this case). So that's where they went!

Now, how do you remedy this?

Answer: SSH's -n switch. From the manual:
-n Redirects stdin from /dev/null (actually, prevents reading from stdin). This must be used when ssh is run in the background. A common trick is to use this to run X11 programs on a remote machine. For example, ssh -n emacs & will start an emacs on, and the X11 connection will be automatically forwarded over an encrypted channel. The ssh program will be put in the background. (This does not work if ssh needs to ask for a password or passphrase; see also the -f option.)

So let's try that with -n, shall we?

$ seq 1 10 | while read line; do ssh -n remotehostname "echo x${line}x; cat -"; done

There. 10 SSH connections opened, 1 number printed each time. A total waste of time, but a rather simple example to follow :)

Set php.ini values using .htaccess

Posted on September 10, 2011

Did you know that you can set php.ini values right inside the .htaccess file?
You can do so by adding lines like these:
php_value setting_name setting_value

php_value upload_max_filesize 128M

Filed under: Linux, Reference No Comments

GCC stray X in program

Posted on September 10, 2011

IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn/pi.c:1: error: stray ‘\357’ in program

This is caused by "invalid" characters in the code, specifically I encountered this while trying to compile the Intel EMGD driver for my EEEPC's graphics card.

Thanks to the helpful folks over here, there's a solution:
cd IEMGD_HEAD_Linux/common/drm/emgd/display/pi/cmn
cat -v pi.c | awk '{if(NR>1) print $0}' > tmp # make strange characters on first visible and remove
mv tmp pi.c

That makes the invalid characters visible and removes them.
In this case, it leaves some partial, garbage comments behind, so the file still wont compile.
To resolve this, I opened the file in vim, and quickly searched for and removed the faulty comments (and some I didn't have to remove).
Remember to answer "no" to the question of re-extracting the tarball each time you retry building this.
Attached is the original driver file, and my modified copy of pi.c

"Completed EMGD Installation"

modified pi.c

xorg.conf for KVM

Posted on September 3, 2011

Found this somewhere.
Works for me.

Section "ServerLayout"
Identifier "BodhiZazen's KVM xorg.conf"
Screen 0 "Screen0" 0 0
InputDevice "Mouse0" "CorePointer"
InputDevice "Keyboard0" "CoreKeyboard"

Section "Module"
Load "record"
Load "dri"
Load "extmod"
Load "glx"
Load "dbe"
Load "dri2"

Section "InputDevice"
Identifier "Keyboard0"
Driver "kbd"

Section "InputDevice"
Identifier "Mouse0"
Driver "vmmouse"
Option "Protocol" "SysMouse"
Option "Device" "/dev/sysmouse"
Option "ZAxisMapping" "4 5 6 7"

Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 20.0 - 50.0
VertRefresh 40.0 - 80.0
Option "DPMS"


Section "Device"
Identifier "Card0"
Driver "vesa"
VendorName "KVM - std"
BoardName "GD 5446"
BusID "PCI:0:2:0"

Section "Screen"
Identifier "Screen0"
Device "Card0"
Monitor "Monitor0"
SubSection "Display"
Viewport 0 0
Modes "800x600"

Filed under: Linux, Reference No Comments

bash time limit on commands

Posted on September 1, 2011

Several programs, like "timelimit" and "timeout", exist to prevent a process from running for too long.
However, if you want to do this on a box where neither is installed, there's a way to do so with bash alone.

Based on the original script I found at

# Execute a command with a timeout

# Author:
# Notes:
# If the timeout occurs the exit status is 128.
# There is an asynchronous (and buggy) equivalent of this
# script packaged with bash (under /usr/share/doc/ in my distro),
# which I only noticed after writing this.
# I noticed later again that there is a C equivalent of this packaged
# with satan by Wietse Venema, and copied to forensics by Dan Farmer.
# Changes:
# V1.0, Nov 3 2006, Initial release
# V1.1, Nov 20 2007, Brad Greenlee
# Make more portable by using the 'CHLD'
# signal spec rather than 17.

if [ "$#" -lt "2" ]; then
echo "Usage: `basename $0` timeout_in_seconds command" >&2
echo "Example: `basename $0` 2 sleep 3 || echo timeout" >&2
exit 1

cleanup() {
{ kill %1 2>/dev/null; }& # kill sleep $timeout if running
kill %2 2>/dev/null && exit 128 # kill monitored job if running

set -m # enable job control
trap "cleanup" CHLD # cleanup after timeout or command
timeout=$1 && shift # first param is timeout in seconds
sleep $timeout& # start the timeout
"$@" # start the job

I made a new script in bash, which also returns the correct exit status if the command completed before the timeout:

Works well for me, at least :)