Wandering Thoughts archives

A little habit: cat >/dev/null

If you were to haunt me, every so often you would see me open up a new terminal window, run 'cat >/dev/null', and paste or type something there.

What I am doing with this peculiar behavior is simple: I'm arranging for a slightly more persistent text storage than my X selection. I park any number of things depending on what I'm doing; snippets of text from fishing back in editor undo, commands that I'm temporarily re-running, and so on.

There's nothing particularly special about cat in a terminal window for this. There's any number of other programs and ways that I could do this; it's just that this way is the fastest and most convenient in my environment. Your environment is probably different, especially if you keep an editor going all of the time (if I always had Emacs running, I'd probably just paste things into a scratch Emacs buffer).

(In theory xclipboard should be ideal for this. In practice it sadly doesn't work out, partly because its version of cut & paste is significantly worse than that of terminal programs.)

Note that in some ways using a terminal window is a bad idea. I always have to make sure that any tabs are unimportant, because they're probably going to turn into spaces by the time I paste the text back into its eventual destination.

(I would really like an X terminal program that was smart enough to preserve tabs, but I haven't run into one yet.)

How our 'plug in and go' laptop network DHCP portal works

As I mentioned in the last entry, we have an internal subnet for laptops and other generic user machines. For various reasons, we require machines on this subnet to be registered so that we can identify who is (theoretically) responsible for them. One of the ways that people can do this is with a 'plug in and go' registration portal; you plug in, try to go somewhere, and you wind up on a simple registration web page instead.

Behind the scenes, it works like this:

• our DHCP server gives unregistered machines IP addresses from a special subnet. Our internal firewall doesn't allow these IP addresses access to the outside world.

• as part of the DHCP information, the unregistered machines are pointed at a special DNS server that is essentially a fake DNS server. The DNS server simply has a zone file for ., the root zone, with only two entries; one entry for our registration portal's public name that points to one internal IP, and a wildcard ('*') A record that claims everything else has another internal IP address.

  (In the terms of the last entry, these IP addresses are Inside-2 and Inside-1 respectively.)

• the two IP addresses that the DNS server tells people about run some web servers, including the registration CGI.

• the registration CGI gets and validates the user's credentials, picks the Ethernet address of their machine out of the web server's ARP cache, and pokes the DHCP server to get the new machine registered (using a method beyond the scope of this entry).

  (In practice, not having to ask users for their machine's Ethernet address is a big win for all parties.)

• once registered, users have to renew their DHCP lease (which will cause their machine to get an IP address that can talk to the network, along with a gateway and our proper DNS servers) and flush any cached DNS information they picked up from our fake DNS server. We tell users that the easiest way to do this is to reboot their machine.

In terms of servers, the special fake DNS server and all of the web stuff run on one machine, while the DHCP stuff runs on another (and the firewall is a third machine). This is mostly a historical accident, in that we already had the DHCP server running in production before we started building this registration portal system.

Redirecting people's connections with DNS instead of with firewall magic is much simpler but has some side effects, especially since the machine that responds to the wildcard A record's IP address does have an ssh server. We should probably do some work to make the wildcard record's IP address block access to at least the ssh server.

Postfix versus Exim

We use both Postfix and Exim here, and in the process of working with both of them I've formed some opinions. My view on the two is this:

Postfix is easier to do simple things with. Exim is much easier to do complex things with.

A Postfix null-client configuration (one that sends all mail to a smart machine somewhere, putting a default domain on any address that doesn't already have one) is maybe ten lines of configuration. If you can do that in ten lines of configuration in Exim, it is only because someone has already written a highly conditional superintelligent Exim configuration for you and you are just plugging in some values.

(As a result, all of our client machines run Postfix.)

On the other hand, you can actually write a superintelligent Exim configuration and do crazy things with it. This may be possible with Postfix but my distinct impression is that it is not sensible, and I am confidant that it will not be directly expressed in the way that you can in Exim.

(Thus, all of our machines that actually process email run Exim.)

Another way to put the difference is this: Postfix is a mailer. Exim is a mailer construction kit.

Which should you pick? My opinion is that if Postfix does what you want or has a direct customization to make it do what you want, it is probably the right choice. If it does not, use Exim; it's more work in the short term but less pain in the long term.

I would be wary of using someone else's Exim configuration. I understand why Debian and Ubuntu and Fedora and so on feel the need to ship default Exim configurations that work, but I am at least half of the opinion that if you aren't writing your Exim configuration from scratch, maybe you don't actually need Exim. (And it's not like Postfix is short on features; it probably already has a way to do more or less anything common or obvious.)

Some ways to avoid needing a public ticketing system

Suppose that you are in the situation from yesterday's entry, where your support volume is too high to let you use a single support alias that everyone is on but particular support requests are passed from person to person. As it happens, I think that there are still ways to avoid having a public ticketing system as your primary support method.

The problem that a public ticketing system is really solving here is that you need a separate point of contact for each ticket that goes to several people (but not everyone). In a ticketing system, this is your ticket's URL, but there are lots of other ways to create such contact points that are less awkward and user-hostile.

The most obvious one is simply to automatically create mail aliases for each new ticket (and then route these to whatever internal tracking system you use). You can then send your email out in such a way that it directs responses to the ticket's mail alias; the most thorough one is to give all email about a ticket an appropriate From: address, regardless of who's sending it.

(I think that this is somewhat unfriendly because of its impersonality, so I suggest sending email as yourself but cc:'ing the ticket alias and setting a Reply-To:.)

The sophisticated approach is to have a single support alias but have a smart request routing system sitting behind it. The routing would usually key off a magic identifier in the Subject: line, but if your message didn't have the marker it could do smart things like seeing if you only had one open issue (hopefully the usual case) and routing your message to it. If it couldn't route your message at all, well, that's when people get involved.

(It might be convenient to have a separate email address for 'start a new issue'; for all of the usual reasons I tend to think that this should not be directly wired to the internal ticketing system but go to people.)

A use for ticketing systems as your primary support method

In the past, I've been somewhat negative about having a ticketing system as the primary method of talking with the sysadmins. But I have to admit that sometimes such a ticketing system actually makes sense, and here's one example:

Suppose that your support group is sufficiently busy (you serve either a large organization or one with a lot of problems) that a single support alias would have too much traffic to be read by everyone all of the time. In this environment you have to hand support requests to a particular person, who then interacts directly with the user.

Now, consider what happens when a support request is handed back and forth between your people. Especially, how does the user know who to email with more information, a new sub-issue, or the like? As a user, you don't want to just email the last person you talked to, because you could be emailing someone who is now off-shift or the like and thus won't read your email (and add it to whatever internal issue tracker your support organization uses) for a while.

(In practice I suspect that people just send their email to more or less everyone who has ever sent them email about the issue, because you never know.)

An actual ticketing system that users use neatly solves this issue; regardless of who is involved with working on your issue, you always have just one place to put information. In a sense, it's abstracted away who exactly is currently handling your request.

The appeal of this likely depends on how large and busy your support group is. In a small organization where everyone can just be on the main support alias, there's no need for this at all (well, mostly). As the organization gets bigger and bigger, the attraction is going to grow, and at a certain point I suspect that a ticketing system becomes inevitable.