darkness

[Updated 2002-01-18 02:21 EST: I found out later about the bos adduser comand I forgot. By the time I found out about this in the OpenAFS section "Configuring the Top Levels of the AFS Filespace" I had already stopped running with no authentcation. This meant I couldn't figure out how to issue the command since it wouldn't give me permission to bos adduser. Reading some documentation I found out about the -localauth argument. This argument, apparently accepted by many commands, instructs the command to authenticate you as root. In other words, if you want to use -localauth you have to be root. Anyway, I found I could do a bos adduser verin.caliginous.net afsmaster.admin -cell caliginous.net -localauth as root and be on my way.]

OpenAFS seems very easy to set up. The OpenAFS documentation is quite good and has specific sections for Linux. They have OpenAFS RPMS for Red Hat going back to something like 6.2.

I installed all the RPMS on my first AFS cell, then went to the part of the quick start guide that’s entitled “Installing the First AFS Machine.” However, I was aware that AFS has its own Kerberos IV server, but that I wanted to use my MIT Kerberos V installation instead. The documentation on the OpenAFS site is not helpful here, instructing you to contact IBM for more information. Yeah, right.

Thankfully, someone wrote instructions on installing OpenAFS with another Kerberos implementation. These instructions are pretty good, but they’re a bit sketchy at points. I’ll try to fill in some holes here. If I feel brave maybe I’ll add them to the Wiki page, or at least a link to this log entry. This log entry was written for revision 1.10 of the Wiki page mentioned above.

Starting on the Wiki page at “Starting the Install” I followed all instructions. They don’t explicit state at what step you’re supposed to stop following the OpenAFS documentation and start following their steps. I stopped before I started the section in the OpenAFS documentation entitled “Initializing Cell Security.” You’re going to basically skip this entire step, though the instructions on the Wiki page are the same as the instructions in the OpenAFS documentation in several places.

Once I got to the section in the Wiki page entitled “Create AFS Keys and Administrators,” I created a principle called afs/myrealm.com using kadmin. At first I tried just doing addprinc -randkey afs/mycell.com, but that seemed to potentially be in conflict with the instructions that are given in the Heimdal KTH instructions (which are referred to and somewhat used in the MIT Kerberos V instructions). Here’s what I ended up doing:

[darkness@servername ~]# kadmin -p kmaster/admin
kadmin:  addprinc -randkey -e des-cbc-crc:v4 afs/mycell.com
WARNING: no policy specified for afs/mycell.com@MYREALM.COM;
defaulting to no policy
Principal "afs/mycell.com@MYREALM.COM" created.
kadmin:  getprinc afs/mycell.com
Principal: afs/mycell.com@MYREALM.COM
Expiration date: [never]
Last password change: Fri Jan 17 05:35:43 EST 2003
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Fri Jan 17 05:35:43 EST 2003 (kmaster/admin@MYREALM.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, no salt
Principal: afs/mycell.com@MYREALM.COM
Expiration date: [never]
Last password change: Fri Jan 17 05:35:43 EST 2003
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Fri Jan 17 05:35:43 EST 2003 (kmaster/admin@MYREALM.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

I did the getprinc just to see if it worked. You presumably have to add the -e des-cbc-crc:v4 to make it generate only the key type that’ll be understood by AFS. In retrospect I suspect you can leave the -e switch out and use the parameters to ktadd to only export the des-cbc-crc:v4 key; someone is welcome to try this.

Note that there are instructions here about how your Kerberos V realm must respond to Kerberos IV requests. If you followed the RH documentation on setting up your Kerberos server, you’ve got krb524 running and you’re set to go with Kerberos IV requests.

Next the Wiki page instructs you to create the /usr/afs/etc/KeyFile file with the key for the principle we just created, above. This is where I had to feel my way around just a little bit. For your benefit, I’ll quote important parts of my session below. Keep in mind that we’re still on the Wiki page instructions here, having left the OpenAFS documentation when we hit the “Initializing Cell Security” section. Also note that the following starts in the same kadmin session as above that we never exited.

kadmin:  ktadd -k /etc/afskeytabfile.krb5 -e des-cbc-crc:v4 afs/mycell.com
Entry for principal afs/mycell.com with kvno 4, encryption type
DES cbc mode with CRC-32 added to keytab WRFILE:/etc/afskeytabfile.krb5.
kadmin:  quit
[darkness@servername afs-working]$ sudo /usr/kerberos/sbin/ktutil
ktutil:  read_kt /etc/afskeytabfile.krb5
ktutil:  list
slot KVNO Principal
---- ----

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.