Re: Blocked high ports
Hmmm. If I telnet to some random high port on one of my boxes, I also
get "connection refused"
Hmmm. Could it be because there's nothing LISTENING on that port?
Hmmm. So back to the log he mentions, where he says Bind couldn't
connect to E.ROOT-SERVERS.NET
PING e.root-servers.net: 56 data bytes
----e.root-servers.net PING Statistics----
10 packets transmitted, 0 packets received, 100% packet loss
Hmmm. Looks like E.ROOT-SERVERS.NET is down. So maybe he should
remove E.ROOT-SERVERS.NET from his named.root file?
Cheers!
Eric
On Tue, 25 Jan 2000 10:59:52 +1100, Craig Sanders wrote:
>On Mon, Jan 24, 2000 at 11:35:19AM -0800, David Bristel wrote:
>> Have you checked to make sure that inetd is running? After an
>> upgrade, be sure to reboot to make sure that library differences have
>> taken effect, and to make sure the system is in sync. I have found
>> that in too many cases, things LOOK fine after an upgrade, but until
>> that final reboot, it won't be fully cut-over to the new version.
>>
>> Dave Bristel
>
>i've been upgrading debian on dozens of systems for nearly 5 years and
>have NEVER noticed what you describe. in fact, smooth upgrades where
>everything *just continues working* after being upgraded with no hassle
>and no fuss is one of debian's major benefits.
>
>i upgrade my systems regularly (every week or two on average) and
>generally only reboot for hardware changes (once every few months at
>most) or because of kernal bugs.
>
>what you suggest is not necessary - it's a windows-type approach to
>computing: "reboot and it might fix itself" (it's also a slackware and
>freebsd type approach because they use ugly monolithic rc scripts,
>rather than the clean sysvinit scripts).
>
>debian packages provide and use scripts in /etc/init.d to stop
>and re-start the daemons as required during an upgrade. rebooting
>is not required - in fact, it's so far from being "required" that
>rebooting should be one of the last things you consider when trying to
>diagnose/solve a fault. rebooting doesn't solve anything, at best it's
>cargo-cult systems administration...perform the magic reboot and maybe
>the problem will go away for a while. the trouble with that is that
>you still don't know what *caused* the problem and you have no way of
>knowing that it isn't going to happen again.
>
>aside from kernel upgrades, the only time that a reboot has ever been
>necessary when upgrading debian was during the libc5 to libc6 migration,
>which was (as everyone who went through it knows) a major change....and
>even that was optional rather than required if you didn't care about the
>wtmp file being corrupted because the file format changed. it was highly
>recommended to reboot, but not absolutely required.
>
>
>it is far more likely that Bradley's problem is due to incorrectly set
>firewall or masquerading rules or similar. or a misconfigured network
>interface, or some other misconfiguration.
>
>craig
>
>--
>craig sanders
>
>
>--
>To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: