ChaseVenters.org

I thought I'd post a quick tip for anyone upgrading a set of clients in a kerberized NFSv4 network. I'm in the process of pushing out CentOS 6 to a cluster currently supported by NFSv4 on CentOS 5 and my standard "setup krb5/nfsv4 client" script didn't leave me with a working client. Instead, I got this error on the NFS server every time I attempted the NFS mount:

gss_kerberos_mech: unsupported algorithm 6

or

gss_kerberos_mech: unsupported algorithm 23

Some advice pointed out that the keytab might need to be written out without the newer key types, but attempting to limit to des-cbc-crc did not fix the problem.

Instead, I found that the following settings in the [libdefaults] section of /etc/krb5.conf fixed my environment:

[libdefaults]
 # cventers: These overrides are TEMPORARY until we have abandoned CentOS 5
 default_tgs_enctypes = des-cbc-md5 des-cbc-crc arcfour-hmac-md5 arcfour-hmac-exp
 default_tkt_enctypes = des-cbc-md5 des-cbc-crc arcfour-hmac-md5 arcfour-hmac-exp
 permitted_enctypes = des-cbc-md5 des-cbc-crc arcfour-hmac-md5 arcfour-hmac-exp
 allow_weak_crypto = true

As part of deploying a new Postfix-and-qpsmtpd based mail architecture at work, I have developed some qpsmtpd plugins and extended its native queue/smtp-forward plugin.

1. filter/dkimsign: Signs e-mail using Mail::DKIM. There are a other dkimsign plugins out there but I wanted to take a stab at doing one myself.
2. filter/header_whitelist: Possibly controversial, could break many things if misused. I wanted a way to clean up all the extra garbage version headers, etc added by the multitude of scripts and platforms generating email in our environment. If the mere existence of this plugin doesn't violate RFC2822 or e-mail best practices, certain configurations certainly would. Use with care.
3. queue/smtp-forward: I have extended the stock plugin to support the Postfix XCLIENT verb. This allows a qpsmtpd to pass information about the client (their IP and HELO, in particular) which Postfix can then use for access control and/or logging. I'll try and submit this back upstream.

You can find the plugins at my GitHub page.

I just took a Southwest Airlines flight that was wifi enabled. I couldn't resist the temptation to give the wifi a spin.

My review, in a nutshell? It costs $5, it appears to work with (at least) HTTP(S), Outlook, and ssh... but the performance leaves something to be desired.

The Wifi gateway also appears to mangle HTML passing through it in order to display a Southwest airlines banner over the top of the pages. This does provide some function -- it indicates your current altitude and ETA. But they could have included a way to disable the behavior.

The bottom line? It works, and that much is neat. But given the performance limitations (and keep in mind this is just one data point), I doubt its utility for anything but basic surfing. But on a long flight, I don't think books or magazines could make the time pass by with such ease.

I wanted to share a little VIM plugin I just got done writing, makesd.vim. This plugin is pretty straightforward, and is adapted from a couple of Perl command-line scripts I tend to haul around called makesd and makecsd.

In short, they produce clean looking separators for use inside source code:

:Makesd "Public Interface"
# ========================================================================== #
# ============================ Public Interface ============================ #
# ========================================================================== #

:Makecsd "Public Interface"
/* ======================================================================== */
/* =========================== Public Interface =========================== */
/* ======================================================================== */

It's my first VIM script. VIM scripting is pretty easy -- give it a try!

Another one for the record books. Once again, the kind folks at Redmond have proven how truly incompetent they are, and why at the end of the day, a power user can only survive on an open source platform.

Microsoft has stripped the ability to save raw e-mail messages from Outlook 2007. Supposedly this capability exists in Outlook Express and/or Windows Mail. But there are mountains of bad advice suggesting that export to those programs, followed by an import, or an export to .txt, is an acceptable alternative. (It isn't, in all cases, the transport headers aren't included. Who knows how else Microsoft is molesting the message).

Commercial solutions exist - one for only $14 (are you kidding me?) and one for over $60 (are you kidding me???)

I've put out a new transocks_ev patch transocks_ev-performance-reliability-dns-logging.patch. transocks_ev is a neat little program by Bernd Holzmueller at tiggersWelt.net that uses the Linux netfilter/iptables stack to intercept outgoing TCP connections and transparently convert them into SOCKS5 proxy connections. It's based on transocks which does the same thing. transocks uses a forking model, while transocks_ev uses libevent to multiplex connections in a single process's event loop.

I'm planning on using these changes to transparently intercept outgoing Postfix SMTP connections on some backend mail servers and to use DNS-based load balancing to fan those connections out across multiple proxy servers/Internet connections.

In addition, I've improved the logging support of transocks_ev, giving it three levels of verbosity with basic statistics collection for the connections. All blocking operations have been converted to non-block (connect(), write(), the new DNS). The code is using libevent bufferevent to manage low level socket access.

I've been using libsoup to run a small SOAP engine for one of the back-office programs I maintain. We've recently upgraded to a new load-balanced architecture, and we are using DNS-based load balancing to fan these SOAP requests out across our servers.

It only took a few days in production to realize that libsoup was doing something nasty. Prior to any HTTP request, you need to create a SoupSession object. This object manages things like connection pools / keepalive. It contains a GHashTable called hosts, which it uses as a cache of connections to a given hostname.

/* Requires host_lock to be locked */
static SoupSessionHost *
get_host_for_uri (SoupSession *session, SoupURI *uri)
{
    SoupSessionPrivate *priv = SOUP_SESSION_GET_PRIVATE (session);
    SoupSessionHost *host;

    host = g_hash_table_lookup (priv->hosts, uri);
    if (host)
        return host;

    host = soup_session_host_new (session, uri);
    g_hash_table_insert (priv->hosts, host->uri, host);

    return host;
}

Unfortunately, entries in this hash table are never removed or expired unless the SoupSession object itself goes away. This sucks for a few reasons:

1. DNS TTL values are ignored. Instead, the result of the DNS query is cached forever. Obviously this means that if the record is ever changed, libsoup clients need to be restarted to know about it.
2. DNS load balancing is broken by libsoup, which will repeatedly connect to the same IP address regardless of whether multiple IPs are included in the response to an A query.
3. You really wouldn't want to write a robot or some other long lived program that would make lots of connections to lots of different hosts using libsoup, as it stands. Aside from the obvious correctness issues listed above, the hosts hash table will experience unbounded growth. Thankfully all of our connections are to the same small set of URLs and hostnames.

I'm not sure how easy it would be to patch libsoup to behave correctly. As far as I can tell the GResolver that libsoup relies on doesn't even report TTLs.

Given the nature of this bug I can only see a few workarounds:

1. Set the Host HTTP header yourself, do the DNS query yourself using GResolver, and supply the server's IP address to the SoupURI instead of a hostname. This breaks SSL certificate validation.
2. Recycle/create the SoupSession per-request. This breaks keepalive/connection pooling and has obvious overhead issues.

Given the nature of how I'm using libsoup, I chose the latter option. YMMV.

I'm doing another small code release. This one is asterisk-func_dns, a dialplan function DNS() to do an explicit DNS query without requiring you to launch an external program. It's an alpha release currently intended for Asterisk 1.4 and only supporting IPv4 / DNS A record types.

I'm using this to implement DNS-based load-balancing for outgoing calls across a series of proxies and internet connections.

In my dialplan, I request the IP addresses of my proxy servers ahead of any attempt to Dial(). This module returns the list of IP addresses published in the record, separated by commas. This allows me to sequentially fork across the proxy servers, and since I don't need to rely on Dial()'s forking support, I can add additional processing in between attempts. Since I obtain the proxy set by looking up a single DNS name, my Asterisk dialer configurations do not have to change if I add more proxy servers to my network, also meaning that those Asterisk dialers will not waste time trying to contact outbound proxy servers that have gone offline for maintenance or due to a failure. Each Asterisk dialer will try every call amongst all the working proxy servers, up to one attempt each, in a random order.

This code could benefit from some obvious todos: forward port to modern Asterisk versions, implementation of the ability to grab other record types like SRV or AAAA, etc. I may address these eventually but at the moment this is "good enough for me". I release this code (under the same Asterisk licensing terms: GPLv2) with the hopes that someone finds it useful.

Okay, I'm pleading with developers. I'm very impressed at the number of options and switches that your program exposes via its configuration file(s) / directories / databases. Bonus points for those of you who have managed to extensively document each switch and its default setting with inline comments.

Actually, that strategy even works up to a point. But once your configuration file exceeds a few screens in length you're starting to go off the deep end. Your program's defaults should be minimal, sensible and secure, especially in the case of network daemons.

There are some hideous offenders out there like Asterisk, whose Christmas tree default configuration is often only lightly modified by novice administrators. A default RPM installation of Asterisk on my development virtual machine ships with 63 configuration files -- 7511 lines in total. But I run some perfectly good inbound SIP IVRs with 10 files and 251 lines.

When you throw a huge mess of a default configuration in my face, you leave me with the feeling that I can't even approach your software until I have had the time to digest the security implications of every one of the switches you are exposing.

There are other programs which do it well like OpenVPN. They ship sample configuration files for different configurations, from which you can copy and paste your own configuration files together. This approach is much saner than editing a huge file -- take what you need, leave what you don't.

I advise all system administrators faced with such configuration mountains to grit their teeth and write their own configs from scratch after carefully studying the stock configuration. Turn on and configure only the specific features you need, lightly document your intent with comments, and leave the other garbage out of the configuration files. The more scrolling past heaps of irrelevant comments and settings you must do to scan the configuration file, the less you will be able to focus on the big picture of how your system is set up.

I'm working on releasing a small piece of useful Perl XS module code to the world... Corosync::CPG. This allows you to use the corosync cluster stack's reliable, ordered multicast messaging bus from within Perl.

I have applied for a PAUSE id and plan on submitting this module to CPAN as well. For now, this is a super-early alpha. It works for me, but the POD documentation is incomplete and there is obviously no warranty.

The terms of this release are the same licensing terms as Perl itself (GPL/Artistic).