Tadek’s Blog

Ever wondered where to get some electronic components in Zurich and was unhappy with what quadruple “M” Migros offers in the hobby section? Or looking for a non-typical power supply for your favorite toy that just died? Or need some fancy cables? Or maybe just want to look at cool stuff?

I found a really nice electronic store in Zurich – Pusterla Elektronik to help you.

While connecting to PostgreSQL using UnixODBC (from R, but this doesn’t matter) I got the following error:

[unixODBC]client encoding mismatch

It seems that there is some problem with PostgreSQL 8.1 and the encoding names: see this post or google. It looks that UTF8 used by default with the new Postgres is not compatible with old ODBC drivers. I am not sure where the problem really is, but a quick fix is to change default encoding for the user connecting to the database:

alter user <user> SET client_encoding to LATIN1;

(thanks to Diego): perl -ne ‘while ((/condition/g)) { print “something”; }’

Use flip:

flip -u <file_name> flip -m <file_name>

apt-get install flip

• Getting a list of unused packages (not the installed ones): dpkg –list | grep -v -E “^ii”

• Purging packages list: dpkg –purge packagename

So doing all this in one line would be something like: dpkg –purge dpkg --list | grep -v -E "^ii" | perl -ne '/^rc\s+([^\s]+)/ && print "$1 ";'

Be careful!

I’ve recently tired to do a nessus scan from an X-less gentoo machine. The task is quite simple, but there are a few quirks that are not obvious.

The easy part:

1. emerge nessus
2. nessus-mkcert
3. nessus-user-add
4. register at nessus website to get the actiovation code for plugin feeds (FYI: #GPL plugins: 1299, #registered plugins: 9575), so unless you register you get a very small subset of (probably outdated) scanners.
5. nessus-fetch –register <activation-code>
6. nessus-update-plugins (it probably makes sense to add it to cron).

Ok, now for scanning the most obvious choice is to run a nessus client with GTK interface. If we don’t want to do this we can either:

• run the graphical console remotely
• run a command-line interface.

The tricky part: Scanning using command line interface:

nessus -V -q 127.0.0.1 1241 <user> <password> <host file> <output file.nbe>

It works fine although generates a warning that “potentially unsafe plugins have been disabled”. While it makes sense for a big and critical network, you may also want to do the “unsafe” scan occasionally. How to enable it?

The first trick, is that nessus creates a “.nessusrc” file in your home directory. The first try — “safe_checks=no” – doesn’t help. Second, you figure out that there is also a nessus-wide file /etc/nessus/nessusd.conf”, which has the same option (overriding the local one) by default set to “yes”. Unfortuantely, no warning is generated when this happenes. Unfortunately, this doesn’t help either

I found the solution analyzing the config file that was created after using nessus with a GUI (with all the plugins enabled). It turns out that such a file the following entry is being added:

begin(PLUGIN_SET)
 14250 = yes
 15094 = yes
 15185 = yes
...
end(PLUGIN_SET)

So all the plugins are explicitly enabled. Only then AND if both safe_checks in the global and local config files are set to “no”, unsafe plugins are executed. Unfortuantely, I don’t know how to set this option from the command line. Also as the new plugins are being instaled, the list would need to be kept updated (does nessus client do this?).

Another solution can be using Net::Nessus::ScanLite from CPAN (unfortunately it seems a bit outdated ~Dec 2003). I haven’t tried it, but it looks ok, and also it supports reading of plugins (so that we can enable/disable some) and also relieves us from parsing the NBE file. Problem: Net::Nessus::ScanLite uses Net:Nessus::Client, which doesn’t compile (for a number of reasons) and, moreover, is not aware that Nessus uses SSL. Surprisingly enough, ScanLite is aware of this and it somehow works around this. How — I don’t know.

It’s quite often the case that in a normalized database there is a one-to-many relation that are being populated in a following fashin: loop: - one insert to “one” relation - multiple inserts to “many” relations.

We want to use autoincremented types like SERIAL for IDs linking these two relations and avoid unnecessary queries.

create table one( one_id serial primary_key, something….); create table many(many-id serial primary key, one_id references one(one_id) default currval(‘one_one_id_seq’), something…);

And inserting like these: insert into one(something) values (some_values); insert into many(something) values(some_values1); insert into many(something) values(some_values2); …

If there is no string one-one, many-many pattern, you can still get the last value of the sequence by calling select currval(‘one_one_id_seq’); and stroing it somewhere.

This works well in Postgres, but other databases have similar capabilities. BTW: currval() is stored per session, so there is no threat that the sequences get screwed with concurrent access.

Suppose table A has a primary key id of the type SERIAL. This means that Postgres implicity creates a sequence called A_id_seq, which is automatically incremented on insert with no value or DEFAULT value.

To enforce referential integrity with B within a session we use it as follows:

insert into A (<not A>) values (<values>) insert into B values( CURRVAL(‘A_id_seq’), <other values;>)

Note that CURRVAL is defined per session so concurrent access is not a problem.

Recently learned about .ssh/config file, in which you can customize parameters used for connecting to different hosts. The complete syntax is described in “man ssh_config”, here is just a few highlights:

Host <short hostname> Hostname <full hostname> Port port User user LocalForward 54320 localhost:5432 Dynamic Forward 9050