quick and dirty hack to make BIND less verbose

In case you're providing DNS hosting in any form chances are one day you'll notice your syslog is flooded with messages like

Jan 12 17:34:27 pry-ns-vm1 named[6774]: client 74.125.xx.yy#41026: query (cache) 'deleted_domain.tld/A/IN' denied

Jan 12 17:34:27 pry-ns-vm1 named[6774]: client 74.125.xx.yy#56524: query (cache) 'deleted_domain.tld/A/IN' denied

Jan 12 17:34:28 pry-ns-vm1 named[6774]: client 61.50.zz.nn#51215: query (cache) 'deleted_domain.tld/A/IN' denied

Jan 12 17:34:29 pry-ns-vm1 named[6774]: client 61.50.zz.nn#49405: query (cache) 'deleted_domain.tld/A/IN' denied

This may be fixed with by adding following to your BIND config (as a top level section):

logging {
    category security { null; };
    channel default_syslog {
        syslog daemon;
        severity warning;
    };
};

postgres outfile

postgres "select into outfile" == use \copy meta-command, e.g.\copy (SELECT * FROM tbl) TO '/tmp/result.csv' WITH CSV

How-to: fix non-working sound in tvtime

Non-working sound in a legacy apps like tvtime which rely on OSS is a common problem these days. The easiest way to fix it is to install the alsa-oss compatibility package and add yourself to the 'audio' group:

$ sudo aptitude install alsa-oss
$ sudo usermod -G audio `whoami`

After doing that either re-login (or at least open new shell) and check the output of the 'id' command - it should contain 'audio'.

Sometimes after doing that you'll have mute working, but still no volume adjustment. If so, simply specify the correct mixer channel in your tvtime config:

<option name="MixerDevice" value="/dev/mixer:line"/>

One may need to use 'pcm' or 'vol' insteam of 'line'.

Shit happens, they say, and even the most advanced and careful administrators may fail. So did I: instead of syncing /etc/passwd to Postfix chroot I deleted them both. What was really bad about this was the fact that the server is shared webhosting, having (at the moment of writing these lines) total of 288 accounts created. I don't have a idea why I didn't restore it from backup; probably I was so shocked by what I did that it just didn't come to my mind. Anyway, here comes the story.

First, I checked possible sources of data for recovery: /etc/shadow, /etc/passwd-, /etc/group, list of homedirs, and /etc/mail/virtusertable for virtual e-mail accounts. After checking all of them I wrote two tiny bash scripts which generate pieces of resulting passwd.

genpasswd.sh

#!/bin/sh
rm usrs 

COMMON_GID=502 
NUM_SYS_USERS=50 

for USER in `cut -d : -f 1 /etc/shadow|egrep -v 'virtuser|ftp'|sed -n "$NUM_SYS_USERS,$ p"`	do 
	UID=`ls -l /var/www/$USER|awk '{print $3}'` > /dev/null 2>&1 
	GID=`cat /etc/group|grep -w $USER|grep -v $COMMON_GID|cut -d : -f 3` 
	echo -n "$USER:x:$UID:$GID:$USER:/var/www/$USER/data:/bin/date\n" >> usrs 
done

genmailpasswd.sh

#!/bin/sh 

for USER in `cat service_users` do 
	EMAIL=`grep $USER /etc/mail/virtusertable|awk '{print $1}'`
	MAILBOX=`echo $EMAIL|cut -d @ -f 1`
	DOMAIN=`echo $EMAIL|cut -d @ -f 2`
	UID=`echo $USER|cut -d _ -f 2`
	PARENT_USER=`locate $DOMAIN|grep email|cut -d \/ -f 4|head -1`
	GID=`id -g $PARENT_USER`
	PASSWD_ENTRY="$USER:x:$UID:$GID::/var/www/$PARENT_USER/data/email/$DOMAIN/$MAILBOX:/sbin/nologin"
	echo $PASSWD_ENTRY
done

A short explanation about the scripts:

COMMON_GID - GID of the service group to which has all users' accounts belong

NUM_SYS_USERS - number of service users (daemons, etc.) to skip while reading shadow;

usrs - temporary file which will hold almost-ready piece of passwd; I didn't want to mess with string formatting inside the script, so to make it ready for pasting inside /etc/passwd one will have to use vim/sed a little: `:%s/\/nologin/\/nologin\r/g` `:%s/:x:\n/:x:/g :wq`

I'm back

Внезапно куда-то исчезла БД бложека, вместе с пользователем. В логах пустота. Мистика?


Somehow the whole blog DB has gone, /dev/null'ing everything I've written during a year. Mystic.