Hi all,
I only received one reply to this message, so I didn't have much to work with. I
believe however that I have solved the problem.
Thanks to:
Dr Thomas Blinn
for his help. His answer didn't solve my problem but it may solve the problem at
my old place of employment. His solution was to change:
ubc-nfsloopback = 1.
In the sysconfigtab file. Of course a reboot is necessary.
My original question was :
> I have a question on a subject that has bitten me twice now. I have in
> my time worked on a few trucluster environments. Twice now I have seen
> instances of an enterprising network person deciding to port scan
> entire subnets. On one occasion it caused the ase agent and host
> status monitor to die. This was on a pair of 8400's running 4.0D patch
> kit #2 (TC 1.5). In this case the problem was not noticed until I came
> back from holiday's a week later. When it decided "Hey the sys admin
> is back, I will fall over now".
>
> The other case happened just now. This is on a pair of 2100's running
> 4.0D, 1.5 patch kit #2. In this situation it seems to have started an
> incredible number of inetd's (about 32740 odd). In other words it has
> taken over the system allowing no other processes to start. They seem
> to keep popping up over and over again.
>
> My question, I guess is, is this a known problem? Related possibly to
> patch kit #2? It would seem ridiculous in the extreme that a
> truclustered environment cannot handle a port scan. Bored network
> types also seem to do things like that and port scan tools are not
> rare. Any comments/similar situations/solutions would be welcomed.
What I found is an entry in the inetd.conf file that said:
rpc.ttdbserverd stream rpc/tcp wait root /usr/dt/bin/rpc.ttdbserverd
rpc.ttdbserverd
I have no idea what this is. But as the console kept saying:
inetd[xxxxx]: /usr/dt/bin/rpc.ttdbserverd file/directory not found
then I could guess that it wouldn't matter if I disabled it.
Fortunately the machine is a non-production machine so I could perform tests to
my liking. Unfortunately the machine now seems to have developed some memory
fault.
Robert Mulley
Unix Administrator
GNS
Consulting
Received on Sun Feb 14 1999 - 22:44:18 NZDT