Weekend in a nutshell

Played with kids
Played Kingdom Hearts
worked-around sendmail difficulty which is really a DNS problem of some kind
Still need to fix dns problem

About Kevin Sonney

Kevin Sonney - who, contrary to popular opinion was NOT raised by wolves - grew up in central North Carolina. He fell into the technology field by accident in 1991, when he gave up the wild and crazy lifestyle of an on-air AM radio DJ to become a mundane technical support monkey. The technology industry has never really recovered from this. Kevin has worked for such names as IBM, Red Hat, webslingerZ, and Lulu Technologies (we won't mention the ones that didn't survive the experience). He currently works as a Linux Administrator for Apptio. In his spare time he rescues stray animals and plays video games with his two sons. His wife, we're sad to say, helps him get past the really hard bits. Kevin is still not very mundane, he just got better at hiding it.
This entry was posted in Uncategorized. Bookmark the permalink.

10 Responses to Weekend in a nutshell

  1. ratnix says:

    ooo ooo i &heart; DNS problems. shaaare!

  2. alchemist says:

    sendmail thinks it’s on “localhost” on my desktop. OK, I can live with that, since it’s sole purpose in this case is to relay mail to the main in-house server (midgard.darkcanvas.com) which will send from there. No problem, right?

    Wrong. Even with a smartHost of DSmidgard (or the IP, or fqdn) it’s attempting to relay to [mailhost].redhat.com. After much wailing and gnashing of teeth, I realize that when sendmail does a ns query for type mx for “localhost” it’s getting records from the other search domains. Which is bad, since [mailhost].redhat.com won’t relay mail from *@darkcanvas.com.

    I end up removing the redhat/vpn dns servers from /etc/resolv.conf, and it’s relays to midgard every time like it’s supposed to. So I have two problems :

    1) I should turn off DNS lookup in sendmail so that it just relays, dammit, which is what I told it to do
    2) fix the darkcanvas.com dns so that if I do this :

    [[email protected]](/home/alchemist)> nslookup
    > set type=mx
    > localhost

    I get an answer, and not a host-not-found-ish error.

    OTOH, I finally converted to the dark side and started using the m4 file(s) to maintain a sendmail.cf instead of hacking sendmail.cf directly. At least on that system. *grin*

  3. ratnix says:

    How weird. Unless the mail is destined for localhost, I don’t know why it’d be doing querytype=MX on localhost. Can you get a valid and timely lookup for midgard with the vpn dns running?

    What’s your setup like? Like, how do pikachu and midgard reach one another and the network?

  4. alchemist says:

    that’s the weird thing – /etc/resolv.conf has midgard listed as the first DNS. If I query MX for “darkcanvas.com” I get the proper records. If I query for any host *IN* darkcanvas.com I get “No Answer” messages. If I add any domains for the RH vpn to the search list, I get the mail relay for redhat.com as the response to *ANY* MX query.

    Midgard a Pikachu are connected to each other via a 10meg hub. They sit literally 3 feet from each other. Midgard is 192.168.2.29, and pikachu is 192.168.2.2. midgard is mail, DNS, http, https and ssh for darkcanvas.com. pik is RHL 8.0, mid is 6.2+fixes and updates.

    I *THINK* perhaps a wildcard MX entry would clear it up. Or turn off DNS lookups for the proper MX for localhost in sendmail….

  5. ratnix says:

    How about if you make forward-only zones?

    zone “redhat.com” {
    type forward;
    forwarders { wh.er.ev.er1; wh.er.ev.er2; };
    };

    Then eliminate the VPN references outside of that. Maybe?

  6. alchemist says:

    Nope. Happens on machines without a vpn connection. I think it’s an issue with the darkcanvas.com zone file. Go ahead – try it for yourself (and yuo can s/localhost/any [valid|invalid] host name/g and it does the same thing):
    [[email protected]](~)$ nslookup
    > set type=mx
    > localhost
    Server: 208.17.72.2
    Address: 208.17.72.2#53

    *** Can’t find localhost: No answer
    > midgard
    Server: 208.17.72.2
    Address: 208.17.72.2#53

    *** Can’t find midgard: No answer
    > darkcanvas.com
    Server: 208.17.72.2
    Address: 208.17.72.2#53

    darkcanvas.com mail exchanger = 10 lord.technomancer.com.
    darkcanvas.com mail exchanger = 10 midgard.darkcanvas.com.
    > localhost.darkcanvas.com
    Server: 208.17.72.2
    Address: 208.17.72.2#53

    *** Can’t find localhost.darkcanvas.com: No answer
    > localhost.redhat.com
    Server: 208.17.72.2
    Address: 208.17.72.2#53

    Non-authoritative answer:
    localhost.redhat.com mail exchanger = 10 mx1.redhat.com.
    localhost.redhat.com mail exchanger = 20 mx2.redhat.com.

    Authoritative answers can be found from:
    redhat.com nameserver = ns1.redhat.com.
    redhat.com nameserver = ns2.redhat.com.
    redhat.com nameserver = ns3.redhat.com.
    mx1.redhat.com internet address = 66.187.233.31
    mx2.redhat.com internet address = 12.150.115.133
    > set type=A
    > localhost.redhat.com
    Server: 208.17.72.2
    Address: 208.17.72.2#53

    Non-authoritative answer:
    *** Can’t find localhost.redhat.com: No answer
    > localhost
    Server: 208.17.72.2
    Address: 208.17.72.2#53

    Name: localhost.darkcanvas.com
    Address: 127.0.0.1
    >

  7. ratnix says:

    I’m still thinking that you’re looking up the wrong thing with following the MX trail of localhost. In my mind, if you’re sending to [email protected] from pikachu, pikachu dumps to localhost (because that’s what your outgoing SMTP server is set to), pikachu sees midgard as smarthost, does an A lookup of midgard, gets it to mid, then, midgard accepts the mail and does the MX lookup for bar.org, then ships it out.

    But if midgard isn’t getting the relay /at all/, then, well… why. VPN reset firewalling rules on pik? Did the VPN mangle routing? Your nslookup showed midgard as a 208 instead of a 192.168; are there reachability issues, can’t get to the 208 when the VPN is going because of a default route? I guess the real question are, while VPN is up:
    pik$ nslookup -querytype=A midgard.darkcanvas.com.
    mid$ nslookup -querytype=MX wherever.org.

    Hsm. If you want to send it under private cover, I wouldn’t mind looking at resolv.conf, nsswitch.conf, named.conf, and sendmail.mc from both guys.

  8. alchemist says:

    I forgot to mention midgard is multi-homed, and 208.x.x.x is it’s public address. So that’s behaving as it’s supposed to.

    I can get to 208 with the VPN up. Otherwise I couldn’t read my mail since I ssh to it. When i did the quesries above I was on a non-VPN host – it works the same with or without the VPN, so I’m pretty sure it’s *NOT* a VPN issue – it’s a DNS issue. With redhat.con in the resolv.conf on pikachu (and no vpn connected) sendmail thinks the mx for itself or any host is the ones listed in the query above. With darkcanvas.com *ONLY* in the resolv.conf, it relays to the smart host as specified in sendmail.mc/cf.

    Looking over sendmail.mc, I think the problem is :
    FEATURE(`relay_based_on_MX’)dnl

    that is, relay everything based on a MX record *FIRST*, then relay to the smarthost. Whch would work properly if the MX for darkcanvas.com was returned whenever I did an MX query on random hostnames. With redhat.com in the seach list for resolv.conf, that’s exactly what I’m getting.

    And now m4 is complaining that sendmail.mc has an unexpected EOF in it, *GRAND*. now my sendmail.cf is basically null since i ran make instead of m4 to test it beforehand.

    Serves me right for hacking at sendmail pre-coffee….

  9. alchemist says:

    Ah-yup. Aparently relay_based_on_MX takes precidence over the smart host setting, and commenting it out fixes the problem.

    Oh, and the unexpected EOF was an open “(” in the mc file. I figured it was somethign stupid.

    it’s not happily relaying mail with the pre-Saturday DNS config and such in place. I’ll have to remember this one…

  10. alchemist says:

    *SMACKS SELF*

    s/not/now/

Comments are closed.