boltblog

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?

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 karlrunge.com, but it does the job, even with long usernames, and generates such nice reports:

Removed SHM Segments:
___________________________
|   OWNER    |   COUNT    |
|------------|------------|
| bolt       |         42 |
|____________|____________|

Total: 42

Oops...

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
x1x

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
x1x
2
3
4
5
6
7
8
9
10

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 shadows.cs.hut.fi emacs & will start an emacs on shadows.cs.hut.fi, 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
x1x
x2x
x3x
x4x
x5x
x6x
x7x
x8x
x9x
x10x

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

GCC stray X in program

Posted on September 10, 2011

Problem:
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

Result:
"Completed EMGD Installation"

Lin_EMGD_1_6_RC_1922
modified pi.c

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 pixelbeat.org...
#!/bin/sh

# Execute a command with a timeout

# Author:
# http://www.pixelbeat.org/
# 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
fi

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:
http://www.dhampir.no/stuff/bash/timeout.bash

Works well for me, at least :)

Remote desktop does not support colour depth 24; falling back to 16

Posted on May 18, 2011

rdesktop on Linux will give this warning message when connecting to a Windows machine which has not been configured for 24-bit color RDP connections. This has, amongst other things, the effect of showing some horrible, jaggy desktop icons. See the pictures on the right for reference.

On Vista, Windows 7 and later (?), the solution is simple: Use 32-bit colors (-a 32)

On XP, which doesn't support 32-bit colors, it gets a little more complicated. XP does support 24-bit connections, but this mode is disabled by default because of bandwidth concerns and bad choices.

To fix this problem on XP (nothing needs changing on the Linux or Windows client) you need to access the Local Machine Group Policy editor.

If you're lucky, going to Start -> Run -> "gpedit.msc" will work for you. Type "gpedit.msc" without the quotes (and click "Run").

If that does not open the group policy editor, this is the long way around:

  • Start -> Run and type in "mmc"
  • Add the Group Policy snap-in by going to File -> Add/Remove Snap-in -> Add -> Group Policy Object Editor -> Add -> Finish (Local Machine) -> Close -> Ok

In the Group Policy Editor, navigate to Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services, and double-click on the 'Limit maximum Color Depth' object.

Set the item to "Enabled" and set "Color Depth" to "24 bit"

Click OK, then log in with the remote client. If the changes haven't been applied, reboot the server.

Rejoice with your new, shiny desktop icons and full 24-bit desktop.

What’s touching that config file?!

Posted on October 21, 2010

Recently I started wondering what the heck was putting "root: bolt" at the end of /etc/aliases "every time" I did an upgrade of something.

I asked #debian on irc.freenode.net, who told me to run this:

grep /etc/aliases /var/lib/dpkg/info/*postinst

What it does is basically to look though all files which names end in "postinst" in the /var/lib/dpkg/info/ directory, showing all lines which contain "/etc/aliases", and where they're at.

The result was this:

$ grep /etc/aliases /var/lib/dpkg/info/*postinst
/var/lib/dpkg/info/exim4-config.postinst:    echo "root: ${poma}" >> /etc/aliases
/var/lib/dpkg/info/exim4-config.postinst:#initialize /etc/aliases
/var/lib/dpkg/info/exim4-config.postinst:echo '# /etc/aliases' > /etc/aliases.tmp
/var/lib/dpkg/info/exim4-config.postinst:echo 'mailer-daemon: postmaster' >> /etc/aliases.tmp
/var/lib/dpkg/info/exim4-config.postinst:done >> /etc/aliases.tmp
/var/lib/dpkg/info/exim4-config.postinst:mv /etc/aliases.tmp /etc/aliases
/var/lib/dpkg/info/exim4-config.postinst:    if [ ! -e /etc/aliases ] ; then
/var/lib/dpkg/info/exim4-config.postinst:    if ! grep -q '^root:[[:space:]]*[[:alnum:]]' /etc/aliases && \

This tells you a lot of things. Firstly, exim4 is likely the culprit here. Upgrading it will likely cause "root: bolt" (or whoever is set as your postmaster in exim4) to be added to the end of the file again. Also, if you notice the last line there, it's actually grepping for a line starting with "root:", followed by a space and something alpha-numeric.

This means that if I, instead of removing or commenting the "root: bolt" line, replace it with "root: root", directing all of root's mail... to root, there will be a line matching the aforementioned description, and exim4's postinst script will leave /etc/aliases alone.

Hooray!

Putty keeps disconnecting

Posted on September 19, 2010

On a recent vacation, taking a train across the entire country, I was using my cell phone's 3G connection to provide my Internet connection. Every little tunnel and other signal interference along the way would cut off the SSH connection I was sending all my traffic through.

While googling, still on the train, I found the PuTTY FAQ, which says this is actually a Windows problem. In short, the solution is to increase the amount of times Windows will attempt to resend lost TCP packets.

This is done by going into the Windows registry, using "regedit" or another suitable tool You can launch regedit by typing WinKey+r, then entering "regedit" into the dialog box.

Once in, browse to the following path:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\

In there, change (or create, if missing), the following keys and values:

TcpMaxConnectRetransmissions => 16
TcpMaxDataRetransmissions => 32

Depending on your registry tool, it might ask you to specify a type for the (new) variables. Use DWORD, and the 32-bit kind of DWORD if your tool allows you to specify that.

Reboot and try again.

After doing this, no railroad tunnel could break my SSH connection. Everything would just pause for a few seconds while Windows was sending the same packets over and over, trying to reach the server.

You can probably set these variables to higher numbers too, but I already increased them quite a bit from the values the PuTTY FAQ told me to use, and these are the ones that worked for me.

Windows XP activation doesn’t pop up after repair or ghost

Posted on August 15, 2010

Also, how to log on without activating Windows :)

------------------------------------------------------------

Ghosted a machine to a new harddrive today, as the old one was failing.

Windows activation pops up on the first boot, as is to be expected, but when I clicked "Activate", nothing happened. The activation wizard simply wouldn't continue. And of course I couldn't get in and activate the system normally, because Windows didn't let me log on without activating. Gah!

The solution, it turns out, is the following:

  • Start the machine, while repeatedly hitting F8 from just after the initial BIOS image disappears
  • Choose "Safe-mode with command prompt"
  • When the command prompt appears, type "explorer" and press <enter>

You're in!

Now you need to (re-)install a hotfix, and Internet Explorer 8. Download them on another machine, and put them on a CD, a USB-stick, or whatever you have available. Install the hotfix first.

Hotfix KB946501: http://support.microsoft.com/default.aspx/kb/946501
Internet Explorer 8: http://www.microsoft.com/windows/internet-explorer/default.aspx

The files you need are called (for English Windows XP):
WindowsXP-KB946501-v2-x86-ENU (hotfix)
IE8-WindowsXP-x86-ENU (Internet Explorer 8)

Anyway, after they're installed, reboot and activate as usual.

Worked for me :)

Error -6003 during Creative X-fi driver install

Posted on August 15, 2010

So the installer says something like:

---------------------------------------
Setup has experienced an error.

Please do the following:
- Close any running programs
- Empty your temporary folder
- Check your Internet connection (Internet-based Setups)

Then try to run the Setup again.

Error code: -6003
---------------------------------------

What do you do to solve this?

Why, erase any folder with a number as it's name (mine was named "09", but I'm sure it can be something else) in the following directory:
%System Drive%\Program Files\Common Files\InstallShield\Professional\RunTime\

No, it doesn't make sense, but it worked perfectly. No reboot or anything. Just remove (or simply move) that folder, and things will start working. Brilliant.