Linux

vim syntax control

I’ve google’ed this one countless times. I’ll store it here
When vim doesn’t recognize what kind of syntax highlighting to use you can set it manually with

: set syn=sh

(in vim command mode)

If you wonder what syntax highlighting modes are available, in Fedora (and I see Ubuntu and Debian got them at the same place) they’re here:

[joar@saturn syntax]$ pwd
/usr/share/vim/vim73/syntax
[joar@saturn syntax]$ ls | sed 's/\.vim//' | head # showing only the first 10 ones
2html
a2ps
a65
aap
abap
abaqus
abc
abel
acedb
ada
[joar@saturn syntax]$ 

FreeBSD got those in /usr/local/share/vim/vim73/syntax/

Wrong keyboard layout in lightdm for (k)ubuntu

I’ve had this annoying thing about my keyboard layout being US for my login window in Kubuntu 12.10. This happened after I got a new wireless keyboard with this unifying usb thing at work. I recently upgraded to 13.04 and the error followed, so I dug up the workaround / fix at bugs.launchpad.net .
My fix was adding this to /etc/lightdm/lightdm.conf

[...]
display-setup-script=setxkbmap no
[...]

Kubuntu update manager has been complaining about failed package download / update

If you, like me, got that really annoying message from update manager regarding failed download of additional data ( usually flashplugin-installer in my case) every time you login, I just found the answer at ubuntu forums .

root@saturn:/var/lib/update-notifier/user.d# pwd
/var/lib/update-notifier/user.d
root@saturn:/var/lib/update-notifier/user.d# ls -l | grep failed
-rw-r--r-- 1 root root 24155 Dec 17 10:33 data-downloads-failed
-rw-r--r-- 1 root root 27963 Feb 15 08:16 data-downloads-failed-permanently
root@saturn:/var/lib/update-notifier/user.d# rm data-downloads-failed*
root@saturn:/var/lib/update-notifier/user.d# 

Minor munin-node hack

We’ve got a Postgres sql server running 9.1beta3 , and I’m currently setting up some Munin graphs for that server. I ran into an annoying error when I wanted to test one of the postgres_* plugins

# munin-run postgres_bgwriter
Unable to detect PostgreSQL version

It kind of put me off, since I’d already setup those plugins on 4 other servers running postgres …
Google gave me an url for the source code for the munin Pgsql plugin, which is written in Perl . The corresponding plugin on this FreeBSD installation was in :
/usr/local/lib/perl5/site_perl/5.12.4/Munin/Plugin/Pgsql.pm , so I had look at the code there. And it turned out to be this function that spat out my error:

sub get_version {
    my ($self) = @_;

    return if (defined $self->{detected_version});

    my $r = $self->runquery("SELECT version()");
    my $v = $r->[0]->[0];
    die "Unable to detect PostgreSQL version\n"
        unless ($v =~ /^PostgreSQL (\d+)\.(\d+).(\d+) on/);
    $self->{detected_version} = "$1.$2";
}

So the code says that print out “Unable to detect PostgreSQL version\n” unless the query “SELECT version()” returns a string similar to the regula expression /^PostgreSQL (\d+)\.(\d+).(\d+) on/ …
I ran the query on the servers where these plugins worked ok, and compared to the troublesome server.
Working server

=# select version();
                                                     version                                                      
------------------------------------------------------------------------------------------------------------------
 PostgreSQL 8.4.15 on amd64-portbld-freebsd

Non-working server:

select version();
                                                 version                                                 
---------------------------------------------------------------------------------------------------------
 PostgreSQL 9.1beta3 on amd64-portbld-freebsd

Looking at the regular expression /^PostgreSQL (\d+)\.(\d+).(\d+) on/, translated it means something like a string starting with “PostgreSQL [whitespace] [one or more digits] [a period] [one or more digits] [a period] [one or more digits [whitespace] on” This matches the working server which has the string PostgreSQL 8.4.15 on, but the 9.1beta3 doesn’t match (\d+)\.(\d+).(\d+) ! .
Upgrading the Postgres server to 9.1.[something not beta] is out of the question for the moment so I tried to make the regular expression true by changing /^PostgreSQL (\d+)\.(\d+).(\d+) on/ to /^PostgreSQL (\d+)\.(\d+)beta(\d+) on/ , the whole function ended up like this:

sub get_version {
    my ($self) = @_;

    return if (defined $self->{detected_version});

    my $r = $self->runquery("SELECT version()");
    my $v = $r->[0]->[0];
    die "Unable to detect PostgreSQL version\n"
        unless ($v =~ /^PostgreSQL (\d+)\.(\d+)beta(\d+) on/);
    $self->{detected_version} = "$1.$2";
}

And it seem to have been enough to get those munin-node postgres_* plugins working again:

# munin-run postgres_bgwriter
buffers_checkpoint.value 4514399
buffers_clean.value 10922461
buffers_backend.value 63381760
buffers_alloc.value 72530920829

Did I forget about some web server in my dmz (?)

Ok so you’ve been working like h#%”# for a couple months (mabye a year), implementing new application servers, moving around services, upgrading other servers and pretty much been busy. Of course you’re updating documentation all the way ! :p … But for that 1 in a million incident where you just happened to forget about updating the documentation of your servers, say you wonder about “do I have control of all my web servers now ? is it possible I might have forgotten to stop Apache on some random server (?)
nmap comes to the rescue, say I want to find every server in the 192.168.0.0/24 subnet listening to port 80:

nmap -p 80 192.168.0.0/24

bind9 using forwarders

I installed bind9 at localhost so that I could setup forwarders for our LAN dns servers + for my Unix dns servers in DMZ ( I don’t have access to configure the LAN dns server, which would be a better option) . I setup something like this in /etc/bind/named.conf.local (Debian type of distro):

zone "windows.domain.servers." IN {
   type forward;
   forward only;
   forwarders { 10.0.0.1; 10.0.0.2; };
};

zone "unix.dmz.servers." IN {
   type forward;
   forward only;
   forwarders { 192.168.0.1; };
};

domain names and forward ip’s has been changed .
With this setup, I could configure my workstation to use localhost for dns queries, and tell /etc/resolv.conf to search for both the domains I want regular access to without typing the fqdn .
But there was a problem getting answers from my unix dns server in DMZ, /var/log/syslog told me something like:

Nov 15 09:27:07 uranus named[8184]:   validating @0x7f94784dgd70: unix.dmz SOA: got insecure response; parent indicates it should be secure
Nov 15 09:27:07 uranus named[8184]: error (no valid RRSIG) resolving 'lb01.unix.dmz.servers/DS/IN': 192.168.0.1#53
Nov 15 09:27:07 uranus named[8184]: error (no valid DS) resolving 'lb01.unix.dmz.servers/A/IN': 192.168.0.1#53

Since I haven’t got time to debug this stuff in detail, I simply edited /etc/bind/named.conf.options and setup

dnssec-validation no;

And my localhost bind9 could resolv stuff from our DMZ
Thnx isc.org and
groups.google.com

rsync and variables

I ran into this annoying thing about rsync when I was writing this new backup script in BASH . I wanted support for excluding directories in config files for clients being backed up, since rsync support –exclude=’some/path’ I could have config files with stuff like this:

EXCLUDE="--exclude='proc/*' --exclude='dev/*'"

But while testing this I noticed rsync simply ignored the EXCLUDE variable, so I created this little test where I put in some arbitrary proc and dev directories with some arbitrary sub-directories, check out this example:

joar@uranus:~/tmp$ rsync -va --delete --exclude "dev" --exclude "proc/*" rsynctest/ rsynctest2/ | grep proc
jdk1.7.0_07/jre/lib/amd64/libsaproc.so
jdk1.7.0_07/proc/
proc/
joar@uranus:~/tmp$ EXCLUDE="--exclude 'dev' --exclude 'proc/*'"
joar@uranus:~/tmp$ rsync -va --delete $EXCLUDE rsynctest/ rsynctest2/ | grep proc
jdk1.7.0_07/jre/lib/amd64/libsaproc.so
jdk1.7.0_07/proc/
jdk1.7.0_07/proc/1
jdk1.7.0_07/proc/2
jdk1.7.0_07/proc/3
jdk1.7.0_07/proc/4
jdk1.7.0_07/proc/5
jdk1.7.0_07/proc/6
proc/
proc/1/
proc/2/
proc/3/
proc/4/
proc/5/
proc/6/
proc/7/
proc/8/
joar@uranus:~/tmp$ 

Notice when I specify –exclude= in the first rsync, the proc dir is rsync’ed without sub-dirs, but when i put that stuff into the EXCLUDE variable the subdirs of proc is being rsynced (!) . I poked around this for a while trying double quotes VS. single quotes, even tried expansion stuff like $(echo $EXCLUDE) .
After a good night sleep I came up with this workaround:

joar@uranus:~/tmp$ EXCLUDE='proc/* dev/*'
joar@uranus:~/tmp$ for f in $EXCLUDE; do echo $f >> tmpfile; done
joar@uranus:~/tmp$ cat tmpfile 
proc/*
dev/*
joar@uranus:~/tmp$ rsync -va --delete --exclude-from=./tmpfile rsynctest/ rsynctest2/ | grep proc
jdk1.7.0_07/jre/lib/amd64/libsaproc.so
jdk1.7.0_07/proc/
proc/
joar@uranus:~/tmp$ 

So I got what I want 🙂
The reason I want to cat stuff from the EXCLUDE variable into a tmpfile is because I want 1 config file pr. backup client. Those who setup new backups shouldn’t have to remember to setup a 2nd config file with directory exceptions.