Month: November 2009

sudo and xauth

Ok, last week I tried to switch my OpenSUSE system to use sudo rather than su for running things like YaST as root. This works relatively well, apart from the fact that I am not able to run X11 programs. My first guess was to edit the sudoers file so that the $DISPLAY does not get reset. So when I would do something like this:

$ sudo echo $DISPLAY
I would not get an empty line, but something like “localhost:10.0“. However, this does not work. Would have been too easy. The problem here is that of course the xauth cookie gets in the way. X11 uses cookie based authentication, which is stored in a file in the user’s home directory. After some googling I found out that an automatic xauth handling could be implemented in sudo using pam (pluggable authentication modules), but no one has done that so far. There are some people trying to do some magic tricks, involving the merging of root’s and the user’s xauth files, but I don’t like that this needs so many commands and not only a simple sudo command anymore. If I find anything more simple, I will post it here…
UPDATE:
Well, one simple solution is as follows:
$ export XAUTHORITY=~/.Xauthority
$ sudo -E xeyes
Instead of using the -E flag (preserve environment), one could add DISPLAY and XAUTHORITY to the variables which are not reset in the /etc/sudoers file. Actually I think that is the most comfortable solution.

sudo vs su

Today I updated my home machine, running OpenSUSE 11.1 at the moment (yeah, I know 11.2 is out, but I always wait a couple of months, for the first round of updates to settle in). I got used so much to OS X’s and Ubuntu’s style of not having an explicit root user, that I wanted to emulate it in OpenSUSE. So, first thing is to edit the sudoers file:

$ su -c visudo

Then find these two lines and comment them out, and add the other line:

#Defaults targetpw
#ALL ALL = (ALL) ALL
youruser ALL = (ALL) ALL

This will enable your user called youruser to run any program as the root user (actually any user), only needing his own password. You can of course make this more fine grained. You can allow this user only to run programs as a certain user, but that’s not the point here.

What’s now still missing is to disable interactive logins or rather the su command. Edit the file /etc/shadow and replace the root password with a *:

root:*:13917::::::

The encrypted password is always stored in the second field, delimited by the colons (“:”). One problem which I haven’t solved yet: I can run sudo /sbin/yast2 now, but that will only fire up the ncurses frontend of yast. I still need to find a way to run the Qt or gtk frontend. Well, this is for another post…

How to set up git email notifications

This is not very well documented in the git user manual. Here is what I did:

Go to your central repository, not your working copy. There, change to the hooks directory:

cd /path/to/yourproject/hooks
cp post-receive.sample post-receive

If your repo is not a bare repository, you have to change to .git/hooks to do this. The post-receive-email script can be found under contrib/hooks/ in the git documentation (e.g. in /usr/share/doc/git/contrib/hooks on most Linux distributions).
Now configure the email hook:

git config hooks.mailinglist “email1@bla.com, email2@bla.com”
git config hooks.envelopesender yourname@informatik.rwth-aachen.de
git config hooks.emailprefix “New commit: “

Also you should give your project a name:

$EDITOR /path/to/yourproject/description