-----BEGIN PGP SIGNED MESSAGE-----
Thanks to Jim Belonis <belonis_at_dirac.phys.washington.edu> for a
helpful discussion.
The problem turned out to be related to the database style of the
affected NIS Slave server. The master uses standard dbm NIS maps,
the slave was changed, on an experimental basis, to btree maps.
That was when the trouble started, although I don't understand
the problem, since the other NIS maps, like group,
passwd... worked right.
I simply overlooked this difference when I tried to figure the
inetd problems and noted them when Jim asked to recheck the NIS DB files.
After resetting the slave to dbm nis maps everything is fine
again.
Maybe someone knows why the btree services map, although it had
been updated regularly, did not work in this case ?
Tschüß,
Dieter
_____________________________*__________________________________
/ * dieter.meinert_at_aip.de \
\ Dieter Meinert (- **
http://www.aip.de/~dieter/ \
\__________________A______*__*___________________________________/
(public pgp key from
http://www.aip.de/~dieter/)
Discussion summary and original question:
From: Jim Belonis <belonis_at_dirac.phys.washington.edu>
Subject: Re: strange inetd behaviour with NIS
In-Reply-To: <200104270846.f3R8kBa411867_at_calypso.aip.de> from Dieter Meinert
at "Apr 27, 2001 10:46:11 am"
To: dieter.meinert_at_aip.de
Date: Fri, 27 Apr 2001 04:03:49 -0700 (PDT)
Content-Type: text/plain; charset=US-ASCII
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> I did not mention those tests explicitly, since all results are
> identical for the working and non-working machines....
>
> indeed two of the machines are slave servers, the third one is
> the only one served by one of those !
So that sounds like a good reason for these three and only these three
machines to have trouble. You have apparently narrowed the problem to
these two slave servers.
I don't remember where
You can view the bogus cache file(s) and see when they were last updated
with the 'ls -l' command.
You might turn off their slave server function, delete their copies of
the NIS maps files, and copy them from the master
and re-initialize their slave server-ness.
> two of the machines are in the same subnet, one slave has three network
> cards connecting it directly to all our subnets, so the 3rd
> machine is connected directly to its server, and the servers
> directly, via a different subnet, to the NIS master.
>
> The other maps seem to work fine, no users complained.
>
> ypwhich -m yields on all hosts, both working and not
> working:(besides other services, all identical)
>
> services.byname multivac
I assume 'multivac' is your real master NIS server ?
If you are using DNS for your Internet maps, you should verify that
'multivac' gives the right IP address on all the machines with nslookup.
If you use /etc/hosts to define the IP addresses, you should verify those are
correct on all machines. Just to make sure that 'multivac' means the same thing
on all of them, so neither of them think the other (or some bogus machine)
is the master NIS server.
> ypcat -k services yields:
>
> 10080/udp amanda 10080/udp # Amanda
> 10082/tcp amandaidx 10082/tcp #
> 10083/tcp amidxtape 10083/tcp #
>
> I don't see how these should point to a bogus server.
So, is this the good or bad services map ? Or are the maps ok
according to ypcat on all good and bad machines ?
Very strange if the good and bad machines both see the map.
If so, then NIS is probably working completely correctly, and you have to
start looking at amanda itself, so error messages or other indications of
what you mean by "the other three lately refuse to listen to the amanda ports"
would be helpful.
Do you mean that the amanda executable aborts with or without an error message ?
Or does inetd not trigger amanda (I don't know if that's how amanda is
supposed to start). If so, you can try
kill -HUP <inetd's pid>
to make sure inetd has read the current services map and inetd.conf .
I think it is even safe to
kill <inetd's pid>
./inetd
to kill and restart it from scratch (in case its memory has gotten corrupted).
Or does amanda run but
netstat -a
doesn't show the ports being listened on ?
What does inetd.conf have to say about amanda on the various good and bad
machines ?
Sorry, I don't know anything about amanda.
Pop having the same problem, though, implies that it might be an inetd problem.
Jim Belonis
>
> |=>
> |=>
> |=> You don't say whether all other NIS maps are working, or if
> |=> the services map is all you use.
> |=>
> |=> what happens when you do
> |=>
> |=> ypcat -k services
> |=> ypwhich
> |=> ypwhich -m (does it think the master of the bad maps is some bogus machine ?)
> |=>
> |=> Are all the bad and good machines on the same subnet ?
> |=>
> |=> Are any of the three bad machines NIS slave servers ?
> |=> Are they pointing to a bad slave server ?
> |=>
> |=> My first guess would be that the three bad machines are on a different subnet
> |=> or otherwise have had slow communication with the good NIS server at some time
> |=> and they have somehow lost contact with the NIS server
> |=> and possibly are talking to a bogus machine on their own subnet which they
> |=> think is an NIS server.
> |=>
> |=> > -----BEGIN PGP SIGNED MESSAGE-----
> |=> >
> |=> >
> |=> > Hi folks,
> |=> > I stumbled over some strange behavior of inetd in connection with
> |=> > a NIS served services map:
> |=> >
> |=> > I'm backing up 45 Alphas and several Linux boxes with amanda, and
> |=> > the amanda ports are defined in the NIS services map.
> |=> >
> |=> > This is fine with 42 of our Alphas, but the other three lately
> |=> > refuse to listen to those ports (10080/udp, 10082/tcp, 10083/tcp)
> |=> >
> |=> > Now after I finally inserted the ports into the local services
> |=> > file of these 3 hosts they listen again.
> |=> >
> |=> > /etc/svc.conf says : services=local,yp on all machines.
> |=> >
> |=> > Getting stranger even: a couple of weeks ago ALL our alphas where
> |=> > able to use the NIS services map...., and the map still exists on
> |=> > ALL machines. And I did not change anything in the meantime.
> |=> >
> |=> > The same is true for the pop3 service (port 110/tcp) which for
> |=> > most hosts is served by NIS, but only for the same three hosts
> |=> > fails to connect.
> |=> >
> |=> > There is no special security level involved.
> |=> >
> |=> > Could anyone explain this behaviour to me ?
> |=> >
> |=> > TIA
> |=> >
> |=> >
> |=> > Tsch__,
> |=> > Dieter
> |=> >
> |=> > _____________________________*__________________________________
> |=> > / * dieter.meinert_at_aip.de \
> |=> > \ Dieter Meinert (- ** http://www.aip.de/~dieter/ \
> |=> > \__________________A______*__*___________________________________/
> |=> > (public pgp key from http://www.aip.de/~dieter/)
> |=> >
> |=> > -----BEGIN PGP SIGNATURE-----
> |=> > Version: 2.6.3ia
> |=> > Charset: latin1
> |=> >
> |=> > iQCVAwUBOuglYvYksnFoaQ6JAQEAugP/Rm9vw2Hmz40m9KkV6nz1Ddtgp1ghq/Rq
> |=> > 0mHQPUdSDjPm6CYBNb6or25nPCJH/fn0Fqd/GYKKb0Ys6sRXRRmi9JYUMkeHVDEo
> |=> > qZrfENANIVErFAF/f532epLS+i2R/dJMbz6DCLdZDe4cZD6G93FtfGLVaBMWTvD2
> |=> > t7F0DcDsdok=
> |=> > =JJgw
> |=> > -----END PGP SIGNATURE-----
> |=> >
> |=>
> |=>
> |=> --
> |=> J.James(Jim)Belonis II, U of Washington Physics Computer Cost Center Manager
> |=> belonis_at_phys.washington.edu Internet University of Washington Physics Dept.
> |=> http://www.phys.washington.edu/~belonis r. B234 Physics Astronomy Building
> |=> 1pm to midnite 7 days (206) 685-8695 Box 351560 Seattle, WA 98195-1560
> |=>
>
>
> Tsch__,
> Dieter
>
> _____________________________*__________________________________
> / * dieter.meinert_at_aip.de \
> \ Dieter Meinert (- ** http://www.aip.de/~dieter/ \
> \__________________A______*__*___________________________________/
> (public pgp key from http://www.aip.de/~dieter/)
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
>
> iQCVAwUBOukx0vYksnFoaQ6JAQFszAP+OCbt7V7f8rWWNs/XUgCTzJ5ybQd1N2xo
> vI60E0wUrRi6G/5WOuF1duqO/qwvJcY5IAc3K1ztA5n65xfbC33zAME0bFe62CMV
> ENLYexf37rTGWC1PR95KuumAU9A5aAi61yftgdixo0D4vBHdOWn2kvNmblVar/I7
> cQn7Fo+ynKk=
> =3B7D
> -----END PGP SIGNATURE-----
>
- --
J.James(Jim)Belonis II, U of Washington Physics Computer Cost Center Manager
belonis_at_phys.washington.edu Internet University of Washington Physics Dept.
http://www.phys.washington.edu/~belonis r. B234 Physics Astronomy Building
1pm to midnite 7 days (206) 685-8695 Box 351560 Seattle, WA 98195-1560
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
iQCVAwUBOul7Q/YksnFoaQ6JAQEtvAQAzpqER5vsFbroktJrkNUtbl3FEwYQSUZB
f+m86Vtne8H/MmCnzniXCadlMWVQ6U3SNj0cKp8RdaGcgj8pVxV91DCZhoebzQcf
QEIcu+25y+6A7QNYQqjxkYZ5JKkdC8pqnrCeot8w7nj/j7YsMN2cbgjYqu3GzUJ5
gxRN9aS3K2o=
=dNuW
-----END PGP SIGNATURE-----
Received on Fri Apr 27 2001 - 14:00:52 NZST