Started today by getting a call from a client telling us one of their Internet circuits was having problems. Turned out to be the USLEC circuit. Called them, they said they were having some big routing issue and that it’s pretty much covered. OK, no problem, tell the client that USLEC is aware of it and they’re working on it. Several hours pass and the client wants to know what’s going on. I offer to open a ticket with USLEC. First call: open a ticket, think she pulled the wrong customer address up in her database. Call back in 15m to correct. Call 2: corrected address. Call 3, a good three to four hours later: guy calling me asking why I can’t get my e-mail. “Actually, I said that our address seems to be unreachable from certain providers, like Level 3 and Qwest.” Now, maybe I’m wrong here, but that’s how I interpret it when their routers start throwing back ICMP network unreachable messages to me in a traceroute. I know the circuit isn’t completely down because I can get to it from at least one circuit that goes to TWTC. This guy probably called me at least six times, and it took him the first three to get the right physical address of the client’s site. Then he was trying to insist that, because he couldn’t ping the WAN side IP, LMI must be down. … Yeah. In his last call, he asked me “if I had ‘ip classless’.” When I responded affirmatively, he informed me that they were going to have to escalate. By now this is like 2030. He says the team he’s escalating to doesn’t have anyone there at night (or maybe just this night) so it’ll be until morning. Needless to say, my client is endlessly pleased with USLEC right now.
Anyway, after some squabbling in the morning I was off to working on RT. It was pretty much set up, I just had to learn how to do a few things. Oh, and troubleshoot the e-mail, which was kind of a bitch. Because of the DNS setup we have (explained in past entries) everything we use pretty much gets CNAME’d to a host in one particular zone. Unfortunately, here I had support.foo.com that needed to receive mail via mail.foo.com. If you use a CNAME with a label (host) you can’t use any other data, including an MX. What I ended up having to do was make a duplicate name for the IP in our “master” zone and then add the MX to that, then CNAME to that from outside the master zone. More unfortunateness: when support.foo.com is CNAME’d to support.bar.com, and you send mail to support.foo.com, the mail actually ends up trying to be delivered to support.bar.com. Not a big problem, but I set everything up to look for support.foo.com. Fixed soon enough.
Another problem I thought I was having with RT was that replies to ticket comments weren’t getting sent to the person listed in the Cc field. As it turns out, this is because the address associated with my user was in the Cc field, and it prevent you from sending yourself your own comments in e-mail. I just didn’t see this clearly documented, so I ended up dicking with it for a long time.
Oh ho ho, one more problem I had with RT. Using $MailCommand =
'sendmailpipe' it complained about an insecure $ENV{PATH}
because it was running in taint mode. Somehow, though $ENV{PATH} gets
set in webmux.pl which is PerlRequire‘d in the Apache
configuration for the virtual host, it doesn’t care about this and
still thinks it unclean. So I had to explicitly local $ENV{PATH} =
'/bin:/usr/bin' in lib/RT/Actions:SendEmail.pm around line 119
IIRC. Additionally, it may be helpful to note that the other options
for $MailCommand are documented in the man page for
Mail::Mailer. As it turned out, since I was using qmail I could just
set $MailCommand = 'qmail' and everything seems to be working out.
In other more exiting news, I’ve fixed my problem with Kerberos and
OpenSSH that I described last night! The key is a patch to add
Kerberos/GSSAPI support in
OpenSSH. As it
turns out, in the openssh-3.1p1-6.src.rpm that’s used to build the
packages for (I think) Red Hat 7.x, you just need to change the
release of the package to end in gss and the patch will be
applied. In RH 8.0′s OpenSSH SRPM the patch isn’t included, but you
can download it from the above page and put it in place of the patch
that is commented out in the spec file. Then just tag gss on the
end of the release, rebuild, and there you are. Also, note that
apparently the OpenSSH SRPM for RH 7.x needs autoconf 2.53 or so from
RH 8.0, yet this package itself apparently requires RH 8.0′s Perl
5.8.0 RPM because of a dependency on perl(find.pl). Rather than
totally hose up my system by trying to go to this new version of perl,
I opted to --nodeps the install of the two autoconf* RPMs from
RH 8.0. It worked for building openssh-3.1p1-6.src.rpm on a RH
7.2 box. If it breaks in the future I’ll try and remember to speak of
it.
One more note that’s crucial to make the above work: your KDC doesn’t
have a host principal by default. You need to create one, as in the
instructions for setting up a Kerberos client in the RH docs. If you
don’t have /etc/krb5.keytab, you apparently don’t have a host
principal set up and the seamless authentication of Kerberos won’t
help you when connecting to that machine. At least, this was the case
with OpenSSH.
Finally, for Andy we have a screenshot from darkbook.
