Monthly Archives: April 2014

irssi, Tor and SSL on linux

I’ve noticed that I cannot connect to an SSL port of an IRC server running on an .onion address using torsocks on a linux. Using the OpenBSD’s irssi-0.8.15p3-socks works fine, though, just as using Xchat with usewithtor option. For instance, using

vanja@ip:~> usewithtor irssi

and then

/connect -ssl tn3zho2yrhkdpmo7.onion 6697

simply hangs the connection. There are a few traces in the terminal about the problem:

libtorsocks(17204): The symbol res_querydomain() was not found in any shared library. The error reported was: not found!

Similar traces get spilled in the very irssi’s window if proxychains are used:

-!- Irssi: Unable to connect server tn3zho2yrhkdpmo7.onion port 6697
[Connection refused]

and

[(status)] |DNS-request| tn3zho2yrhkdpmo7.onion
|S-chain|-<>-127.0.0.1:9050-<>-127.0.0.1:8123-<–timeout
|DNS-response|: tn3zho2yrhkdpmo7.onion is not exist

The solution that works well for irssi on OpenSuSE 13.1, Debian 7, and Scientific Linux 6.5 is to use socat, just like it is explained at Tor’s pages for irssi:

$ socat TCP4-LISTEN:4242,fork SOCKS4A:localhost:tn3zho2yrhkdpmo7.onion:6697,socksport=9050

and then from within irssi:

/connect -ssl localhost 4242

That should allow irssi to connect to an SSL port of an IRC server running on an .onion address.

Jenkins’ reports verbosity on IRC and XMPP

I’ve swapped the verbosity levels for Jenkins’ bot at IRC and XMPP, so Jenkins now briefly reports on IRC ( #buildbot@ircer.simulakrum.org ) and fully reports over XMPP ( buildbot@conference.jabber.simulakrum.org ) because this is far more acceptable behaviour for the spamming levels set for the IRC, while XMPP doesn’t kick the bot out of the room.

Apache 2 and LDAP group auth on OpenBSD 5.4

Recently I’ve ended up with only OpenBSD’s Apache 2 available to serve some pages that had to be authorised and authenticated through LDAP’s groups. Installing a few packages before that set-up pulled /usr/port/devel/apr-util that Apache’s FLAVOR=ldap simply didn’t like, because apr-utils were missing ldap flavour, too:

# FLAVOR=ldap make 
===> apache-httpd-2.2.25-ldap depends on: groff->=1.21 -> groff-1.22.2p1
===> apache-httpd-2.2.25-ldap depends on: pcre-* -> pcre-8.33
===> apache-httpd-2.2.25-ldap depends on: openldap-client-* -> openldap-client-2.4.35p1
===> apache-httpd-2.2.25-ldap depends on: apr-util-*-ldap – not found
===>  Verifying install for apr-util-*-ldap in devel/apr-util
`/usr/ports/bulk/amd64/apr-util-1.4.1p2-ldap’ is up to date.
===>  Installing apr-util-1.4.1p2-ldap from /usr/ports/packages/amd64/all/
Can’t install apr-util-1.4.1p2-ldap because of conflicts (apr-util-1.4.1p2)
— apr-util-1.4.1p2-ldap ——————-
Can’t install apr-util-1.4.1p2-ldap: conflicts
*** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/bsd.port.mk:1876 ‘/var/db/pkg/apr-util-1.4.1p2-ldap/+CONTENTS’: @ /us…)
*** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/bsd.port.mk:2388 ‘install’)
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2016 ‘/usr/ports/pobj/apache-httpd-2.2.25-ldap/.dep-apr-util-ANY-ldap-devel-apr-util,ldap’)
*** Error 1 in /usr/ports/www/apache-httpd (/usr/ports/infrastructure/mk/bsd.port.mk:2388 ‘all’)

Removing apr-util, subversion and apache-httpd helped, so I was able to build Apache 2 with support for LDAP from ports. If you need subversion, too, don’t forget to add it again, because Apache will, of course, build only apr-util as a dependency. Trying to remove apr-util on its own won’t be successful:

# FLAVOR=ldap make deinstall
===> Deinstalling for apr-util-1.4.1p2-ldap
Problem finding apr-util-1.4.1p2-ldap
*** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/bsd.port.mk:3360 ‘deinstall’: @ /usr/sbin/pkg_delete -m apr-util-1.4….)
# FLAVOR=ldap make reinstall 
===>  Cleaning for apr-util-1.4.1p2-ldap
/usr/sbin/pkg_delete -m apr-util-1.4.1p2-ldap
Problem finding apr-util-1.4.1p2-ldap
*** Error 1 in target ‘_internal-clean’ (ignored)
===>  Installing apr-util-1.4.1p2-ldap from /usr/ports/packages/amd64/all/
Can’t install apr-util-1.4.1p2-ldap because of conflicts (apr-util-1.4.1p2)
— apr-util-1.4.1p2-ldap ——————-
Can’t install apr-util-1.4.1p2-ldap: conflicts
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1876 ‘/var/db/pkg/apr-util-1.4.1p2-ldap/+CONTENTS’: @ /usr/bin/env -i PKG_TMPDIR=…)
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2388 ‘install’)
*** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/bsd.port.mk:3348 ‘reinstall’)

Using SSL for LDAP was the other part of the problem. The combination that makes it all play nicely is the following: in the root, we need

LDAPVerifyServerCert off
LDAPTrustedGlobalCert CA_BASE64 /etc/apache2/ldap/ldap.pem
LDAPTrustedGlobalCert CERT_BASE64 /etc/apache2/ldap/ldap.pem

and for the directory we need

<Directory “/directory/that/we/auth/through/ldap/”>
Order allow,deny
Allow from all
AuthType Basic
AuthBasicProvider ldap
AuthName “Protected zone”
AuthLDAPBindDN “cn=ldapproxy,ou=users,dc=example,dc=com”
AuthLDAPBindPassword averysecretpass
AuthLDAPURL ldaps://thesslldap.example.com/ou=users,dc=example,dc=com?cn?sub
AuthzLDAPAuthoritative on
Require ldap-group cn=ThePrivilegedGroup,ou=bands,dc=example,dc=com
</Directory>

Your distinguished names will vary, though, as well as the pass, but this should be sufficient for the group auth with Apache 2 and OpenLDAP on OpenBSD.

DKIM and amavisd-new problems

Creating DKIM keys and using them with amavisd should be straightforward. However, I managed to complicate it, because I failed to notice that amavisd for OpenBSD came with p5-Mail-DKIM module, and so I installed dkim-milter.

Running both in parallel started leaving double dkim flags entries in my mail log, and got me totally confused, ultimately because I used amavisd to generate certificate, and then used the cert for both amavisd and dkim-milter. On top of the confusion, one of them, dkim-milter, wouldn’t recognise the signatures, and the other, p5-Mail-DKIM, wasn’t able to read the key; nevertheless, both happily worked in parallel, former being called by main.cf, and latter by amavisd-new.

When I figured what was I doing and choosing to sort this mess, I turned off dkim-milter, and decided to use the amavisd-new module. The problem that remained was that amavisd would show the certs for virtual domains, but asked to test them, it would reply with:

# amavisd testkeys
TESTING#1: mail._domainkey.domain1.org    => invalid (public key: Can’t locate object method “new_public_key” via package “Crypt::OpenSSL::RSA” at /usr/local/libdata/perl5/site_perl/Mail/DKIM/PublicKey.pm line 351.)
TESTING#2: mail._domainkey.domain2.com => invalid (public key: Can’t locate object method “new_public_key” via package “Crypt::OpenSSL::RSA” at /usr/local/libdata/perl5/site_perl/Mail/DKIM/PublicKey.pm line 351.)

Backup the  /usr/local/libdata/perl5/site_perl/amd64-openbsd/Crypt/OpenSSL/RSA.pm file, and change line:

require AutoLoader;

with line:

use AutoLoader ‘AUTOLOAD’;

After that, the p5-Mail-DKIM module should work just fine, and testing keys should be alright now:

# amavisd testkeys
TESTING#1: mail._domainkey.domain1.org    => pass
TESTING#2: mail._domainkey.domain2.com => pass

Restart amavisd-new and postfix, and there should be no more double or erroneous entries in the mail log. The implications of the change of the perl file are described in the bug 84444.

slapd won’t start after a power failure

I had a power failure earlier in the day, and apparently all of the services came back to normal afterward. However, a warning message from PWM Password Self Service said it could not connect to LDAP.  Since nothing was listening neither at port 389 nor port 636, I had to restart the daemon. Trying to start the slapd manually resulted in failure, indeed:

 # /etc/rc.d/slapd start 
slapd(failed)

Starting the daemon directly, but with -u and -g options, and -h, while skipping the rest of the rc.d script worked (sometimes :))

# /usr/local/libexec/slapd -u _openldap -g _openldap -h ldap://192.168.1.102\ ldaps://192.168.1.102

# netstat -anf inet |grep 389
tcp          0      0  192.168.1.102.389          *.*                    LISTEN

and stopping the daemon immediately after such starting worked, but a subsequent start would fail again.

A brief insight in slightly re-crafted /etc/rc.d/slapd exposed the problem:

cat /etc/rc.d/slapd
#!/bin/sh
# $OpenBSD: slapd.rc,v 1.4 2012/05/05 14:41:30 sthen Exp $

daemon=”/usr/local/libexec/slapd”
daemon_flags=”-u _openldap -g _openldap -h ldap://192.168.1.102\ ldaps://192.168.1.102\ ldapi://%2fvar%2frun%2fslapd.sock”

# To bind to multiple URLs, pass this to rc.d(8) via /etc/rc.conf.local:
# slapd_flags=”-u _openldap -h ldap:///\ ldaps:///”
# Note the escaped space between URLs. ^^

. /etc/rc.d/rc.subr

rc_reload=NO

rc_pre() {
/usr/bin/install -d -o _openldap /var/run/openldap
rm /var/run/slapd.sock
}

rc_cmd $1

And there was no /var/run/slapd.sock, required once the rc.subr is sourced later in the script, and I wasn’t re-creating one with the above-mentioned manual command, which ultimately lead to this confusion! After touching it and a chown to _openldap, the script worked well again.

A linux BackupPC fails when backing up an OpenBSD?

Your BackupPC is on a GNU/Linux? You’ve triple-checked the set-up and dependencies, and all but an OpenBSD machine works, while the OpenBSD fails, with

backup failed (fileListReceive failed)

in logs? That is just Scientific Linux BackupPC failing to find OpenBSD’s rsync under /usr/bin. Make a symlink in OpenBSD, from /usr/local/bin/rsync to /usr/bin/rsync, and everything should start as expected…