Category: UNIX

Automatic security updates for Debian

I was wondering how to configure automatic security updates for Debian. Especially for Debian stable, which I am running. Turns out it’s easy. First, you just install cron-apt. Second, you can configure it by editing /etc/cron-apt/config. I learned from some other blog, that setting one variable helps in getting actually emails for the upgrades, namely setting MAILON=”upgrade” in this file does the trick. And lastly, there is a directory /etc/cron-apt/action.d, which contains all the actions that cron-apt will execute. In there is a file named 3-download, which I changed to look as follows:

autoclean -y
upgrade -y -o APT::Get::Show-Upgraded=true
The second line is changed from “dist-upgrade -d …”, because you don’t want any automatic dist-upgrades. That might leave your server in a horrible state. Also, instead of only downloading (-d), you want it to install the upgrades as well. That’s all and should help you keep up with security patches more easily.
Update: The updates seem to work fine! Tonight I got the first email that notified me of a successful security update.

Tivoli Storage Manager: Servername not found

The infamous Tivoli Storage Manager client (a.k.a. dsmc) uses two configuration files: dsm.sys for the system wide configuration, specifying which directories to backup and so on, and the dsm.opt for the backup/restore client. The problem is, if you specify the backup SERVERNAME in both files, this will lead to problems, if they are not the same. So, e.g. I misconfigured the dsm.opt via the dsmj wizard, and had “SERVERNAME myhost” in the dsm.opt, while the dsm.sys said “SERVERNAME something.at.rwth-aachen.de”. The first entry obviously was complete bull, and confused the dsmc, so that it answered “ANS1217E Server name not found in System Options File”. Aligning both entries to the correct, real server name solves this problem.

Printing the SSH host key fingerprint

Whenever you update your SSH host keys, your machine becomes compromised, or you re-install your system, the SSH host key will change. To check if there is really a man in the middle attack, it is nice to be able to print out the fingerprint of the SSH host key on the host itself. So locally log onto your machine, and do the following:

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

If you are using the DSA key, you should replace rsa with dsa, naturally.

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…