|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On Thu, 16 Oct 2008, Rick Stevens wrote:
Karl Pearson wrote:On Thu, October 16, 2008 12:05 pm, Rick Stevens wrote:Karl Pearson wrote:On Thu, October 16, 2008 11:31 am, Rick Stevens wrote:I had already tried DNS settings. I edited nsswitch.conf and changed it toI should have mentioned that you'll need to "service sshd restart" after making the change to sshd_config. You'll need to restart sendmail as well if you change its config. And if you're asking "why doesn't it fail when I specify 'localhost'?" remember that localhost is in your /etc/hosts file. When you "ssh localhost" or "telnet localhost 25", the host AND CLIENT IPs are 127.0.0.1 which corresponds to "localhost" in /etc/hosts. I try to give full explanations when I post and I missed it that time. Sorry!files first, then dns, with this line: hosts: files dns [NOTFOUND=return] filesand made sure the IPs are in /etc/hosts, which they already were. One emailwent out with alpine from another PC, but nothing more and it took just about long enough to time out. Watching it in ps ax showed startup with 172.20.20.100 then cmd read: 172.20.20.100but all the other ones show the startup line only, then when it times out on the client, it changes from the IP to the entry in the hosts file. It's likesomething is preventing things from moving. I'm wondering if I have a bad cable or switch. I am going to try sshd_config right now and see if that works. Remember, thisis the box that got duplicate libs which I had to manually delete. There area few duplicates again. It may not be related....Okay, changing UseDNS no didn't help at all. Still taking a couple minutesto connect via ssh.Ok, then check your default routes, "netstat -rn" and verify that the one with "UG" is indeed your default gateway.It checks out okay.Okey doke. Just checking. With updates and such (and that goddamn POS called "NetworkManager"), anything's possible.
I disable NetworkMangler on my servers at install time.
I'm not sure how, but it works fine. Let me 'splain... In checking for things in /etc/mail/sendmail.mc and /etc/mail/submit.mc I found that one can just type make (or make -C /etc/mail)in /etc/mail and submit.mc will be transferred to submit.cf as if m4 had beenrun. Same with sendmail.mcActually, sendmail.cf is the output of m4 after processing sendmail.mc (and others).
Yes, nice, huh? Why doesn't sendmail.cf actually act like a .conf file one can just modify? Like I haven't manually modified them for years anyway :)
I've also seen that using make restart works on some distros, and so tried it,and that works, too.Most of them to a "cd /etc/mail;make" before they actually start sendmail (either in a "restart" or a "start" scenario).
Yes, but new to me.
In any case, that's not the apparent solution, which IS DNS related, but notin the way you or I thought. I changed the line in sendmail.mc: FEATURE(`accept_unresolvable_domains')dnl to dnl FEATURE(`accept_unresolvable_domains')dnl and things started working again as they had several days ago. Now then,please understand that nothing had been changed on the server at all. Nothing. That's why I still think there may be a hardware issue somewhere. The featureabove has been enabled since the system was installed 7 weeks ago.Yes, anything that's to be put into the sendmail.cf must begin with "dnl". Things without "dnl" are directives to m4 itself.
dnl is the starting line of a not-to-be-used feature, so adding dnl turned it off. Or am I missing something?
BTW, m4 is a right pain in the arse...why sendmail.org decided to standardize on it is beyond my comprehension.
Yes it is. Which is why I was happy to see that 'make' does the same thing now.
As far as DNS issues are concerned...well, there's much to check. Verify that /etc/resolv.conf has the actual DNS servers in it and verify you can ping them from the host in question. In some cases, your router does DNS for you via a proxy.
I had checked that stuff before emailing the list. I should have mentioned it. The solution isn't a real solution as some email still times out, but the majority is able to be delivered to port 25
Next, verify that you have TCP and UDP port 53 open so DNS queries can be handled, both in the iptables config and in your external firewall (amazing how many of them block DNS). You can use "related,established" in your iptables rules if you are concerned about security.
DNS is open. I do my own DNS and my ISP 'secondary's my changes on a schedule based on serial. iptables is set to related,established already. That's been in place for a few years now across server upgrades.
But, like email sending, ssh is now slow again... But not as slow as before. I'm still leaning toward hardware being the issue, though I haven't been able to track it down yet.
One thing I just tried for grins and giggles is to switch nsswitch.conf from:
hosts: dns files to hosts: files dnsand things seem much faster again. But, that was at dns files forever (okay, seven weeks on this server).
---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks@xxxxxxxx - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Polygon: A dead parrot (With apologies to John Cleese) - ---------------------------------------------------------------------- _______________________________________________ Redhat-install-list mailing list Redhat-install-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/redhat-install-list To Unsubscribe Go To ABOVE URL or send a message to: redhat-install-list-request@xxxxxxxxxx Subject: unsubscribe
--- _/ _/ _/ _/_/_/ ____________ __o _/ _/ _/ _/ _/ ____________ _-\\<._ _/_/ _/ _/_/_/ (_)/ (_) _/ _/ _/ _/ ...................... _/ _/ arl _/_/_/ _/ earson KarlP@xxxxxxxxxxxxxxxx --- http://consulting.ourldsfamily.com --- _______________________________________________ Redhat-install-list mailing list Redhat-install-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/redhat-install-list To Unsubscribe Go To ABOVE URL or send a message to: redhat-install-list-request@xxxxxxxxxx Subject: unsubscribe