# apt-get install sni-qt:i386
thanks askubuntu.com
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/
Arg ! skype segfaults in my fresh 13.04 install ! It’s a rather easy fix discussed at community.skype.com simply load skype like this:
LD_PRELOAD=/usr/lib/i386-linux-gnu/mesa/libGL.so.1 skype
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 [...]
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#
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
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
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
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.
I ran into :
Failure: ubuntu_sso.utils.webclient.common.WebClientError: (u'SSL handshake failed', u'')
when running ubuntuone-client .
It could be that ubuntuone didn’t like me switching from ubuntu-desktop to kubuntu-desktop, I found the solution for this one at:
one.ubuntu.com/help/faq/
Remove, purge, install :p
thnx to:
askubuntu.com
launchpad.net