dead fish » Tips

Tip: Enforce specific key usage for a single SSH connection

Thomas Keller — Thu, 04 Feb 2010 09:46:32 +0000

In case you have to access a very restricted SSH server which only accepts a single key (ie. the one which is set up in ~/.ssh/authorized_keys) and otherwise fails, its the easiest to set the specific key in your local ~/.ssh/config file as follows:

Host very.secure.server
    IdentityFile ~/.ssh/id_dsa
    IdentitiesOnly true

The second entry, IdentitiesOnly, forces SSH to only use known identity files and not look for more available identities f.e. from a running ssh_agent instance (which are always tried in first instance as it seems).

Tip: Logging with Symfony >= 1.2

Thomas Keller — Mon, 25 Jan 2010 15:00:31 +0000

Imagine you have a business method in your model which needs to be accessed by two environments: once from a symfony task and once from the web. So far so good, now what if this business method should be able to log contents somewhere visibly, in case of the command line task to console and to a file and in case of the web application to the default logging mechanisms used there?

Getting the logger in web context is easy, all you have to do is

$logger = sfContext::getInstance()->getLogger();

but its a little harder to do for the command line task.

By default no symfony context is created for a command line task and even if it is created, the above call returns an instance of sfNoLogger. Logging in command applications happens through the sfTask::logSection() method, which basically throws an event at the created dispatcher in SYMFONYDIR/lib/command/cli.php. There you can also see that an instance of sfCommandLogger is created, but there is no way to get your fingers at this instance, because its purely local.

So what can we do? Parametricizing the business method with the sfTask instance and using the logSection() is obviously no solution, because this would break in web context where no such sfTask instance exists…

My solution was a bit more straight forward – I simply decided to not use the task-supplied logging schema at all, but created my own logger like this:

$dispatcher = new sfEventDispatcher();
$logger = new sfAggregateLogger($dispatcher);
$logger->addLogger(new sfCommandLogger($dispatcher));
// optionally add another file logger
if ($logToFile)
{
$logger->addLogger(
new sfFileLogger($this->dispatcher, …)
);
}

Hope this helps somebody.

Configure Thunderbird 3′s indexing behaviour

Thomas Keller — Wed, 23 Dec 2009 23:01:26 +0000

The current version of Thunderbird comes with a terrific global search functionality, but sometimes its cumbersome to watch it reindex the email history if something corrupted the database or to get emails in the search results which you’re absolutely not interested in (commit messages, f.e.).

Unfortunately Thunderbird 3 has only a global option to enable / disable the search database and the indexer, but a smart guy has filled this gap with his extension GlodaQuilla. After you’ve installed it you can configure so-called “inherited properties” for every account

… and every folder, easily overridable simply by toggling the “inherit” option:

I’d prefer that the Thunderbird guys would build this right into the product itself, but until that has been done this add-on is a life saver!

Tip: Ctrl-R with zsh in GNU screen

Thomas Keller — Fri, 18 Dec 2009 12:34:42 +0000

If you can’t search the history with zsh in GNU screen, check if Ctrl-R is issued at all through your terminal, ie. by

$ cat
^R

If this works, append the following keybinding to your ~/.zshrc:

bindkey '^R' history-incremental-search-backward

(Source)

Quick Tip: NetworkManager and /etc/resolv.conf

Thomas Keller — Fri, 06 Nov 2009 09:31:08 +0000

If you have trouble with NetworkManager overwriting your search and domain configuration after every startup and you’re using DHCP, add the following line to your /etc/dhclient.conf:

append domain-name " company.local other.company.local";

So whenever your DHCP server doesn’t provide these information (the one in my company does not), it’ll add this

domain company.local
search company.local other.company.local

to your /etc/resolv.conf.

Useful Gotcha #27

Thomas Keller — Thu, 09 Apr 2009 07:57:03 +0000

If you get this error ssl_error_rx_record_too_long when browsing an SSL-secured virtual host and wonder what the heck is going on (hey, it worked the day before), ensure that you’ve noticed that your admins have changed the IP address of the machine and that you have to adapt the IP-based VHost configuration accordingly… not that this SSL error wouldn’t have said that in first place!

Enable more locales in stock Debian installations

Thomas Keller — Tue, 13 Jan 2009 16:59:53 +0000

If you wonder why

 $ php -r "setlocale(LC_TIME, 'de_DE.UTF-8'); echo strftime ('%A %e %B %Y', mktime (0, 0, 0, 12, 22, 1978));"

gives you Freitag 22 Dezember 1978 on most systems like f.e. openSuSE and Ubuntu, but Friday 22 December 1978 on Debian, you need to remember that the Debian guys outsmart everything and everybody with a shell script and a configuration file, just to keep your installation lean and clean.

In this particular example, edit /etc/locale.gen and add de_DE.UTF-8 UTF-8 (or anything else listed in /usr/share/i18n/SUPPORTED), hit save and then execute

 $ sudo /usr/sbin/locale-gen

and voila, the above PHP call (and everything else which requests a German locale) works!

Hint #746: How to preserve alternative names when signing certificate requests

Thomas Keller — Mon, 12 Jan 2009 09:34:47 +0000

If you follow this guide to setup your own CA and your certificate requests contain subjectAltNames (i.e. to match multiple virtual hosts with the same certificate), don’t forget to add

copy_extensions = copy

under the [ CA_default ] section of the default openssl.cnf file. Took me a while to realize…

Happy signing!

If you’re setting up exim from scratch…

Thomas Keller — Fri, 26 Sep 2008 22:53:46 +0000

…and you’re a bloody novice like me, you’ll probably stumble upon Marc Merlin’s “Very detailled and featureful configuration example”. If you use that one and you wonder why on earth people can’t authenticate against your local SMTP via PAM, you seek hours and hours in different places, forums, IRC and whatnot, and all you get in /var/log/exim4/mainlog is a couple of these:

2008-09-26 22:35:15 svr_auth_login authenticator failed for []:61588 I=[]:25: 535 Incorrect authentication data (set_id=)

make sure /etc/shadow is actually readable by Debian-exim, the exim4 user, f.e. by adding him to the shadow group… D’oh!

Don’t ask me how this worked in the original debian configuration (which unfortunately did not work for me in a couple of other places, otherwise I’d have stuck to it) – from what I’ve seen I believe it somehow used the courier installed on the same machine to do the authentification.

Kudos to this page which made me find the problem.

$_POST empty?!

Thomas Keller — Fri, 19 Sep 2008 22:22:45 +0000

So I was about to SSL-secure my new webmail setup, created a new cert on CAcert, installed it, configured my vhost accordingly, went to the webmail login page and… boom. Login was not possible. No error message, no log message, nothing.

What happened?

To make a long story short, the PHP superglobal $_POST which stores data from POST requests was completly empty, though a valid POST request has been triggered. Not even $HTTP_RAW_POST_DATA was set and a hint I found on the net about a not set content-type didn’t help either.

So I went back to my vhost configuration again, where I configured a simple redirect for the *:80 vhost to the *:443 vhost. I copied over my original configuration (PHP FCGI) from the SSL one over to the non-ssl one to check if the problem also persists on non-SSL connections. And apparently it did not! Weird enough, now it even worked when doing the request over SSL…! Even weirder was, as soon as I commented out certain (uneccessary) options like ErrorLog from the SSL one, it broke again…

Something must have been messed with my FastCGI php processes – since I only did a reload after each configuration change before, I decided to make a hard apache restart – and voila! The problem was gone completly!

Hrm… this reminds me that there was this one operating system which could also be fixed by a restart. If I could only remember its name…