Archive for the ‘Unix-type stuff’ Category
racoon only matches against the first IP subjectAltName?
I haven’t examined the source yet to make sure that I’m right, but imperical evidence leads me to believe that racoon is only recognizing the first IP field in an x509v3 subjectAltName extension. That is, for the following certificate:
X509v3 Subject Alternative Name:
DNS:arthur.example.org, IP Address:192.168.35.24, IP Address:10.14.82.152
It appears that only the 192.168.x.x address will be accepted as a valid ID by racoon. Requests with an ID of 10.14.82.152 will be discarded with the error message: ID mismatched with subjectAltName. So far I’ve only tested this with anonymous remote nodes.
Sierra Wireless mobile broadband modem differences
As I was recently signing up for Sprint’s mobile broadband solution, I was presented with the choice between the Sierra Wireless USB 598 modem and the older Sierra Wireless Compass 597 USB. I couldn’t find any explanation of the differences between them, so here’s what I’ve found so far:
- The 598 is prettier with bright, attractive LEDs.
- The 598 supports higher capacity micro-SD cards
- The 598 comes with a longer USB extension cable and a laptop clip to attach the modem to the top of your laptop screen. (I miss this quite a bit, surprisingly)
- The 598 has a power saving mode that turns off the modem when the Sprint Smartview application isn’t running (OS X)
- I can’t get the USB disk feature to work at all with a 2GB micro-SD card on my 597, though I suppose mine could be broken
In the end I went with the 597 because of the out-of-the-box Ubuntu support in 8.10, but the 598 is better for non-Linux use. Of course, I get the impression that Sprint won’t be carrying the 597 for much longer, so the point may be moot…
So far I’ve gotten excellent customer support from Sprint. I’m really not used to such kind, helpful and competent assistance from a mobile company, so I felt like I should mention it.
Simple encrypted disk images in Linux
The Linux kernel supports encrypted loop images via the cryptoloop driver, so you can use losetup(8) to create simple encrypted loop devices for those situation when cryptsetup/LUKS/device-mapper is unavailable or too complicated.
You’ll need the following modules loaded (or compiled in):
- loop
- cryptoloop
- twofish (or whatever algorithm you prefer)
First you’ll need to allocate the file:
# dd if=/dev/zero of=<file> bs=1k count=<fs-size-in-kilobytes>
After that, you can ask losetup to loop it to the first free loop device and report back which it chose:
# losetup -e twofish -f -s <file>
The first time out you’ll want to format the device (e.g. mke2fs -j /dev/loop0), after that it’s just a matter of mounting (mount /dev/loop0 /mnt). After you’re done you can use losetup to close the file and remove the device:
# losetup -d /dev/loop0
An important note about this method is that there is no sort of password validation. Whatever password you enter will be used by the encryption algorithm. That means if you enter the incorrect password then you’ll just read (or worse: write) a bunch of garbled data from the device.
Helping openssl find your cert
For those situations where you end up with a directory of certificates — openssl will use a hash to look up the cert it needs in that directory. You can generate that hash using the following command:
openssl x509 -hash -in <cert.pem> -noout
openssl will then look for HASH.0 for the certificate and HASH.r0 for the CRL associated with that cert.
For example, the following could be useful:
# ln -s ca.crt `openssl x509 -hash -noout -in ca.crt `.0
# ln -s ca.crl `openssl x509 -hash -noout -in ca.crt `.r0
racoon requires subjectAltName for x509 IKE
Having trouble getting your ipsec working with x509 certs? It would appear that racoon requires the subjectAltName extension to be set. It won’t use the CN. You have to set a subjectAltName field even if it contains nothing besides a copy of the CN.
Heed this warning, or you’ll fall victim to the following:
racoon: 2008-12-02 14:47:21: ERROR:
racoon: 2008-12-02 14:47:21: ERROR: failed to get subjectAltName
racoon: 2008-12-02 14:47:21: ERROR: no peer's CERT payload found.
Of course… the misery that is tricking openssl to create a cert with the subjectAltName in it is outside the scope of this simple blog entry. Maybe a lengthy one at a later date…
http://www.mail-archive.com/openssl-users@openssl.org/msg47641.html
Installing Apache modules on Mac OS X Leopard
Installing mod_python on my mac laptop was surprisingly difficult. My first attempt of simply compiling it with {LD,C}FLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64" failed in a bit of a strange way. It appeared to create a universal binary for the DSO, but apache failed to load it with the following error message:
httpd: Syntax error on line 118 of /Volumes/Workplace/pflex/2.1.x/Build/build/ValidationWeb/apache/etc/httpd.conf: Syntax error on line 22 of /Volumes/Workplace/pflex/2.1.x/Build/build/ValidationWeb/apache/etc/platform/i386.Mac OS X/httpd.conf: Can't locate API module structure `python_module' in file /usr/libexec/apache2/mod_python.so: dlsym(0x100201000, python_module): symbol not found
As it turns out, the build process was respecting the LDFLAGS & CFLAGS for processes called directly by make, but it was not passing them on to apxs. Adding the following to src/Makefile (after the initial INCLUDE declaration) worked to put apxs on the right track:
INCLUDES+= -Wc,-arch -Wc,ppc -Wc,-arch -Wc,ppc64 -Wc,-arch -Wc,i386 -Wc,-arch -Wc,x86_64
INCLUDES+= -Wl,-arch -Wl,ppc -Wl,-arch -Wl,ppc64 -Wl,-arch -Wl,i386 -Wl,-arch -Wl,x86_64
So, the procedure to install mod_python is:
- Download source here
- ./configure
- Add above two lines to src/Makefile
- make
- sudo make install or sudo make install_dso
UnCommentToLineMatching doesn’t work in cfengine-2.2.8
And — once again — cfengine has wasted part of my life. I’ve never had more trouble with software than I’ve had with cfengine. This time I had to delve into the source code to find the problem, and what I found hilights poor coding and even poorer testing.
Stop me if you’ve heard this one already…
For the life of my I can’t get the following editfiles snippet:
{ /etc/syslog-ng/syslog-ng.conf
LocateLineMatching "### Begin Section loghost ###"
UnCommentToLineMatching "### End .*"
}
To do what I expect on the following bit of syslog-ng.conf:
### Begin Section loghost ###
# source s_remote {
# tcp(ip(0.0.0.0) port(514));
# udp(ip(0.0.0.0) port(514));
# };
### End Section loghost ###
### Begin Section loghost_sys ###
# destination d_messages_byhost {
# file("/var/log/$HOST/messages");
# };
#
# log { source(s_remote); destination(d_messages_byhost); };
### End Section loghost_web ###
I want it to only uncomment the first section. What it does is uncomment the entire rest of the file.
Here’s some interesting debugging output:
Edit action: UnCommentToLineMatching
CommentToRegExp(list,# ### End .*)
Uncomment line # source s_remote {
Uncomment line # tcp(ip(0.0.0.0) port(514));
Uncomment line # udp(ip(0.0.0.0) port(514));
Uncomment line # };
Terminating line: ### End Section loghost ### (Done)
Uncomment line # destination d_messages_byhost {
Uncomment line # file("/var/log/$HOST/messages");
Uncomment line # };
Uncomment line #
Uncomment line # log { source(s_remote); destination(d_messages_byhost); };
It looks like it detects the correct line on which to Terminate, but then Uncomments the rest of the file anyway.
From UnCommentToRegExp() in item-ext.c (line 1282 in cfengine-2.2.8):
for (ip = CURRENTLINEPTR; ip != NULL; ip = CURRENTLINEPTR)
{
if (ip == ip_end)
{
EditVerbose("Terminating line: %s (Done)\n",ip->name);
done = true;
}
“done” is a local variable that is not used anywhere else in UnCommentToRegExp(). Based on the incorrect function name in the Debug2() statement, I take it UnCommentToRegExp() was copied from CommentToRegExp() and the if (done) { break; } was lost somewhere along the way. I attempted to see if this is also the case in cfengine-3.0.0a3, but UnCommentToRegExp() has been removed entirely, it seems.
This also raises a larger question — will cfengine-2.2 be bugfixed after 3.0.0 is released, or will I have to upgrade to 3.0.0 to fix this issue? I certainly don’t want to upgrade to 3.0.0. I’m there’ll be no limit to the number of bugs introduced in that major release.
postfix nags about a domain in BOTH relay_domains and virtual_alias_domains, when it isn’t
I’ve been struggling with the following warning in postfix for a while now:
postfix/trivial-rewrite[xxxx]: warning: do not list domain subdomain.blarg.org in BOTH virtual_alias_domains and relay_domains
The problem is, I’m not listing it in both. I swear.
% postconf relay_domains relay_domains = $mydestination % postconf mydestination mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain % postconf virtual_alias_domains virtual_alias_domains = subdomain.blarg.org
I finally tracked it down today to a relatively obscure (to me, anyway) feature in postfix that causes subdomains to be implicitly matched for certain coniguration parameters. From postconf(5):
parent_domain_matches_subdomains (default: see postconf -d output)
What Postfix features match subdomains of “domain.tld” automatically, instead of requiring an explicit “.domain.tld” pattern. This is planned backwards compatibility: eventually, all Postfix features are expected to require explicit “.domain.tld” style patterns when you really want to match subdomains.
This was exactly what was happening in my case. I was being explicit in my relay_domains and mydestinations, but postfix was matching subdomains for relay_domains:
% postconf parent_domain_matches_subdomains parent_domain_matches_subdomains = debug_peer_list,fast_flush_domains,mynetworks,permit_mx_backup_networks,qmqpd_authorized_clients,relay_domains,smtpd_access_maps
Since this is a feature with planned obsolescence that I’m not really using anyway (afaik), I just completely disabled it:
# Fixes the "do not list domain in BOTH" nags, also the future default behavior # To enable subdomain matching, use .domain.com parent_domain_matches_subdomains =
Apparently it’s still possible to explicitly use subdomain matching by specifying the domain as .blarg.org, which makes things a lot more self-evident, anyway.
Forcing CARP failover using pfSense
Anything that has a master/slave cluster should have some sort of mechanism for failing from the master to the slave, right? We’ll see…
pfSense provides HA via OpenBSD’s (very excellent) CARP. Of course I could just increment the advskew on all of the interfaces to fail them over individually, but that doesn’t really work for me. That involves spending some amount of time in a partially failed-over state. Having quite a bit of experience with OpenBSD, I expected there to be a more elegant solution and I certainly wasn’t disappointed. It looks like OpenBSD provides interface groups and a setting called “carpdemote”. Incrementing carpdemote on the master’s “carp” group would cause all carp interfaces to fail over to the next-in-line. nice.
I guess I was just expecting FreeBSD to have the same functionality. FreeBSD 7.0 does have interface groups, but I can’t find carpdemote in the documentation. Still, maybe pfSense 1.2.1 will be worth the upgrade afterall.
All-in-all, forcing the failover one at a time wasn’t so bad. Upping the advskew on all interfaces to 200 from a shell loop like the following got the job done, but that race condition just doesn’t sit well.
for i in 0 1 2 3; do
ifconfig carp$i advskew 200
done
Then I did my work and rebooted the master. When the master came up, all of the interfaces were reset to an advskew of 0, which is less-than-ideal-but-still-expected. Strangely, this didn’t cause the interfaces to fail back to the master. For about 5 minutes the master interfaces remained BACKUP even though the master interfaces had an advskew of 0 and the backup had an advskew of 100.
After about 5 minutes all of the interfaces failed back to the master. I expect this is just a relic of how the advskew parameter actually works by tuning carp announcement intervals.