Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
On Tue, Sep 27, 2005 at 11:40:35AM +0200, Bas van der Vlies wrote: > Is this also related to portmap or does ypbind secretly an broadcast > what triggers the same bug/feature as above. Hrm. It should jump immediately to trying to access the specified server directly unless something goes wrong with the server. I'll have a look. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
Mark Brown wrote:
On Mon, Sep 26, 2005 at 07:43:07PM +0200, Bas van der Vlies wrote:
Could you try configuring hosts.{allow,deny} for portmap to prevent
access to portmap via the infiniband network (if that is possible).
Doing something like:
portmap: 192.168.
in hosts.allow and
pormap: ALL
in hosts.deny on the servers should I think do the trick (again,
untested so this may not work).
Thanks for all the info. With this the client messages are gone. So your
idea about the portmap daemon is true ;-) Is this an feature or a bug in
the pormap daemon? The portmap daemon hsa an option to listen to an
interface but you can only list one interface ;-(
I now only get the ypserv: refused connect from 10.0.17.130 this i can
not prevent because this is a NIS-server and in the ypbind.conf:
ypserver localhost
Is this also related to portmap or does ypbind secretly an broadcast
what triggers the same bug/feature as above.
Regards
--
--
* *
* Bas van der Vlies e-mail: [EMAIL PROTECTED] *
* SARA - Academic Computing Servicesphone: +31 20 592 8012 *
* Kruislaan 415 fax:+31 20 6683167*
* 1098 SJ Amsterdam *
* *
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
On Mon, Sep 26, 2005 at 07:43:07PM +0200, Bas van der Vlies wrote:
> After an day of debugging and restarting some servers. I have a strace
> of binding to the wrong server. Hopefully t is enough.
Right, this is great.
> sendto(7, "%$e\202\0\0\0\0\0\0\0\2\0\1\206\244\0\0\0\2\0\0\0\1\0\0"..., 52,
> 0, {sa_family=AF_INET, sin_port=htons(666),
> sin_addr=inet_addr("192.168.16.19")}, 16) = 52
> poll([{fd=7, events=POLLIN, revents=POLLERR}], 1, 1000) = 1
> recvmsg(7, {msg_name(16)={sa_family=AF_INET, sin_port=htons(666),
> sin_addr=inet_addr("192.168.16.19")},
> msg_iov(1)=[{"%$e\202\0\0\0\0\0\0\0\2\0\1\206\244\0\0\0\2\0\0\0\1\0\0"...,
> 52}], msg_controllen=44, {cmsg_len=44, cmsg_level=SOL_IP, cmsg_type=, ...},
> msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 52
> write(2, "Server for domain \'elsacafe\' doe"..., 44Server for domain
> 'elsacafe' doesn't answer.) = 44
The server doesn't reply or a network error occurs, forcing a rescan for
servers...
> sendto(6, "_\256\177o\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\5"..., 112,
> 0, {sa_family=AF_INET, sin_port=htons(111),
> sin_addr=inet_addr("10.0.19.255")}, 16) = 112
> sendto(6, "_\256\177o\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\5"..., 112,
> 0, {sa_family=AF_INET, sin_port=htons(111),
> sin_addr=inet_addr("192.168.19.255")}, 16) = 112
...the client broadcasts on both interfaces...
> recvfrom(6, "_\256\177o\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 8800, 0, {sa_family=AF_INET, sin_port=htons(111),
> sin_addr=inet_addr("10.0.17.130")}, [16]) = 36
> socket(PF_FILE, SOCK_STREAM, 0) = 7
...but gets a reply which claims to be from 10.0.17.130 which isn't
supposed to do that.
However, I do have an idea what might be going wrong here: the broadcast
RPC call is proxied through portmap on the server boxes. Unfortunately,
when doing the onward call portmap appears to always send the request to
the localhost. This, of course, defeats the access checking in ypserv
since it sees the request as arriving from localhost.
Could you try configuring hosts.{allow,deny} for portmap to prevent
access to portmap via the infiniband network (if that is possible).
Doing something like:
portmap: 192.168.
in hosts.allow and
pormap: ALL
in hosts.deny on the servers should I think do the trick (again,
untested so this may not work).
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
signature.asc
Description: Digital signature
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
Mark Brown wrote:
On Fri, Sep 23, 2005 at 09:04:19AM +0200, Bas van der Vlies wrote:
After reading your mail i have now configured both ypserv files: (see
attachments)
OK, I'm stumped. Your securenets configuration looks like it will do
what you're looking for and the ypserv logs you provided in the other
report appear to show it doing just what you asked for. Would it be
possible for you to capture trace of ypbind finding the wrong server?
After an day of debugging and restarting some servers. I have a strace
of binding to the wrong server. Hopefully t is enough.
gb-r8n1# ypwhich
ib-r7n15.irc.sara.nl
gb-r8n1# ypcat passwd
No such map passwd.byname. Reason: Internal NIS error
ypserv.securenets:
# Always allow access for localhost
255.0.0.0 127.0.0.0
# Only 192.168.160.0 network
#
255.255.252.0 192.168.16.0
~
ypserv.conf:
# This is the default - restrict access to the shadow password file,
# allow access to all others.
*: * : shadow.byname: port
*: * : passwd.adjunct.byname : port
# Default access is allow everybody on each interface
#*: * : *: none
# New SARA syntax from Debian NIS maintainer, BvdV thanks
#
127.0.0.1 : * : * : none
192.168.16.0/255.255.252.0 : * : * : none
#10.0.16.0/255.255.252.0: * : * : none
# This an bug in ypbind localhost, so list all ypservers
#
10.0.17.130 : * : * : none
145.100.29.212 : * : * : none
145.100.29.214 : * : * : none
# Deny the rest
#
* : * : * : deny
Regards
--
--
* *
* Bas van der Vlies e-mail: [EMAIL PROTECTED] *
* SARA - Academic Computing Servicesphone: +31 20 592 8012 *
* Kruislaan 415 fax:+31 20 6683167*
* 1098 SJ Amsterdam *
* *
Pinging all active server.
[{fd=4, events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND,
revents=POLLIN|POLLRDNORM}, {fd=5,
events=POLLIN|POLLPRI|POLLRDNORM|POLLRDBAND}], 2, -1) = 1
recvmsg(4, {msg_name(16)={sa_family=AF_INET, sin_port=htons(845),
sin_addr=inet_addr("127.0.0.1")},
msg_iov(1)=[{"}\321UV\0\0\0\0\0\0\0\2\0\1\206\247\0\0\0\2\0\0\0\1\0\0"...,
8800}], msg_controllen=24, {cmsg_len=24, cmsg_level=SOL_IP, cmsg_type=, ...},
msg_flags=0}, 0) = 52
write(2, "ypbindproc_domain_2_svc (elsacaf"..., 34ypbindproc_domain_2_svc
(elsacafe)) = 34
write(2, "\n", 1
) = 1
write(2, "Pinging all active server.", 26Pinging all active server.) = 26
write(2, "\n", 1
) = 1
sendto(7, "%$e\202\0\0\0\0\0\0\0\2\0\1\206\244\0\0\0\2\0\0\0\1\0\0"..., 52, 0,
{sa_family=AF_INET, sin_port=htons(666), sin_addr=inet_addr("192.168.16.19")},
16) = 52
poll([{fd=7, events=POLLIN, revents=POLLERR}], 1, 1000) = 1
recvmsg(7, {msg_name(16)={sa_family=AF_INET, sin_port=htons(666),
sin_addr=inet_addr("192.168.16.19")},
msg_iov(1)=[{"%$e\202\0\0\0\0\0\0\0\2\0\1\206\244\0\0\0\2\0\0\0\1\0\0"...,
52}], msg_controllen=44, {cmsg_len=44, cmsg_level=SOL_IP, cmsg_type=, ...},
msg_flags=MSG_ERRQUEUE}, MSG_ERRQUEUE) = 52
write(2, "Server for domain \'elsacafe\' doe"..., 44Server for domain
'elsacafe' doesn't answer.) = 44
write(2, "\n", 1
) = 1
close(7)= 0
write(2, "do_broadcast() for domain \'elsac"..., 46do_broadcast() for domain
'elsacafe' is called) = 46
write(2, "\n", 1
) = 1
uname({sys="Linux", node="ib-r8n1.irc.sara.nl", ...}) = 0
geteuid32() = 0
getegid32() = 0
getgroups32(32, [0])= 1
gettimeofday({1127756111, 931571}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP) = 6
setsockopt(6, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
ioctl(6, SIOCGIFCONF, {96, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"ib0",
{AF_INET, inet_addr("10.0.17.135")}}, {"eth0", {AF_INET,
inet_addr("192.168.17.135")) = 0
ioctl(6, SIOCGIFFLAGS, 0xbfd08f1c) = 0
ioctl(6, SIOCGIFFLAGS, 0xbfd08f1c) = 0
ioctl(6, SIOCGIFBRDADDR, 0xbfd08f1c)= 0
ioctl(6, SIOCGIFFLAGS, 0xbfd08f1c) = 0
ioctl(6, SIOCGIFBRDADDR, 0xbfd08f1c)= 0
sendto(6, "_\256\177o\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\5"..., 112, 0,
{sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("10.0.19.255")},
16) = 112
sendto(6, "_\256\177o\0\0\0\0\0\0\0\2\0\1\206\240\0\0\0\2\0\0\0\5"..., 112, 0,
{sa_family=AF_INET, sin_port=htons(111), sin_addr=inet_addr("192.168.19.255")},
16) = 112
poll([{fd=6, events=POLLI
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
On Fri, Sep 23, 2005 at 09:04:19AM +0200, Bas van der Vlies wrote: > After reading your mail i have now configured both ypserv files: (see > attachments) OK, I'm stumped. Your securenets configuration looks like it will do what you're looking for and the ypserv logs you provided in the other report appear to show it doing just what you asked for. Would it be possible for you to capture trace of ypbind finding the wrong server? -- "You grabbed my hand and we fell into it, like a daydream - or a fever." signature.asc Description: Digital signature
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
Mark Brown wrote: On Thu, Sep 22, 2005 at 02:49:10PM +0200, Bas van der Vlies wrote: It is still an bug and maybe it is correlated with the other one. Or can nis not handle two interfaces with broadcast mode? Could you please describe your entire current configuration, including the ypserv.conf and ypserv.securenets from the server and the ypbind.conf from the client? Feel free to send them by private e-mail if you are concerned about having the entire configuration appear in the bug log. Oke we have an cluster of 275 nodes and all nodes has two internal networks: eth0 - system administration network ib0 - infiniband network for MPI-programs I have serveral NIS-servers and it is dynamic, we can add or remove servers. That is why i want the broadcast option. The eth0 (192.168.16.0) is allowed to connect to the NIS-servers and ib0 ( 10.0.168.0 ) not. The hostname of the machine is the ib-interface. After reading your mail i have now configured both ypserv files: (see attachments) - ypserv.conf - ypserv.securenets To be honest, you're probably better off explicitly configuring the server or servers to use on the clients than trying to use the broadcast option. This is especially true given that you're running on stable and something like this is unlikely to be addressed in the stable release (though of course if we can work out what's going on it will be looked at for the next release). I will consider it. As the remark about Debian stable we usually backport programs from testing/unstable to Sarge if it fixes errors or improves functionality. Regards PS) I have run in ypserv in debug mode zie bug Bug#329382 -- -- * * * Bas van der Vlies e-mail: [EMAIL PROTECTED] * * SARA - Academic Computing Servicesphone: +31 20 592 8012 * * Kruislaan 415 fax:+31 20 6683167* * 1098 SJ Amsterdam * * * # # ypserv.conf In this file you can set certain options for the NIS server, # and you can deny or restrict access to certain maps based # on the originating host. # # See ypserv.conf(5) for a description of the syntax. # # The following, when uncommented, will give you shadow like passwords. # Note that it will not work if you have slave NIS servers in your # network that do not run the same server as you. # Host : Domain : Map : Security # # * : * : passwd.byname: port/mangle # * : * : passwd.byuid : port/mangle # This is the default - restrict access to the shadow password file, # allow access to all others. *: * : shadow.byname: port *: * : passwd.adjunct.byname : port # Default access is allow everybody on each interface #*: * : *: none # New SARA syntax from Debian NIS maintainer, BvdV thanks # 127.0.0.1 : * : * : none 192.168.16.0/255.255.252.0 : * : * : none #10.0.16.0/255.255.252.0: * : * : none # This an bug in ypbind localhost, so list all ypservers # #10.0.17.130: * : * : none 145.100.29.212 : * : * : none 145.100.29.214 : * : * : none # Deny the rest # * : * : * : deny # # securenetsThis file defines the access rights to your NIS server # for NIS clients (and slave servers - ypxfrd uses this # file too). This file contains netmask/network pairs. # A clients IP address needs to match with at least one # of those. # # One can use the word "host" instead of a netmask of # 255.255.255.255. Only IP addresses are allowed in this # file, not hostnames. # # USE ypserv.conf this file does NOT work for US BvdV 22/Sep/2005 # # Always allow access for localhost 255.0.0.0 127.0.0.0 # And the eth0 network # 255.255.252.0 192.168.16.0
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
On Thu, Sep 22, 2005 at 02:49:10PM +0200, Bas van der Vlies wrote: > It is still an bug and maybe it is correlated with the other one. Or can > nis not handle two interfaces with broadcast mode? Could you please describe your entire current configuration, including the ypserv.conf and ypserv.securenets from the server and the ypbind.conf from the client? Feel free to send them by private e-mail if you are concerned about having the entire configuration appear in the bug log. I'm not 100% clear on the configuration you're using when you see this problem - given what we've discussed earlier I suspect that you are no longer using ypserv.securenets which is required to stop binding when broadcasting (I misread your original report, focusing on the incorrect syntax for the configuration file). To be honest, you're probably better off explicitly configuring the server or servers to use on the clients than trying to use the broadcast option. This is especially true given that you're running on stable and something like this is unlikely to be addressed in the stable release (though of course if we can work out what's going on it will be looked at for the next release). -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
On Thu, Sep 22, 2005 at 11:06:32AM +0200, Bas van der Vlies wrote: > Thanks a lot it is an bit confusing that there are two config files > where we can specify access rules. In one config it works as desired an > in the other not. Will the ypserv.securenets file be obsoleted in the > future? They do different things: ypserv.securenets controls which machines the server will talk to at all while the settings in yp.conf provide finer grained access control over individual maps and how they are served but doesn't restrict other server functionality, including the "do you serve this domain" query used for binding. -- "You grabbed my hand and we fell into it, like a daydream - or a fever." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
Mark, I have switched from ypserv.securenets to ypserv.conf and the problem still exists ;-( The ypbind broadcast clients gets once in an while the wrong nis server name and uses an interface that is not allowed in the ypserv.conf, eg: gb-r7n15 (192.168.17.130) and ib-r7n15 (10.0.17.130) # New SARA syntax from Debian NIS maintainer, BvdV thanks # 127.0.0.1 : * : * : none 192.168.16.0/255.255.252.0 : * : * : none # Deny the rest # * : * : * : deny --- client broadcast, yp.conf: domain elsacafe broadcast On gb-r8n1 (192.168.17.135) en ib-r8n1 (10.0.17.135) # /etc/init.d/nis restart # ypwhich ib-r7n15 <- This not allowed!! Sylog gb-r7n15: Sep 22 14:40:01 gb-r7n15 ypserv[23579]: refused connect from 10.0.17.135:997 to procedure ypproc_all (elsacafe,group.byname;-1) It is still an bug and maybe it is correlated with the other one. Or can nis not handle two interfaces with broadcast mode? Regards -- -- * * * Bas van der Vlies e-mail: [EMAIL PROTECTED] * * SARA - Academic Computing Servicesphone: +31 20 592 8012 * * Kruislaan 415 fax:+31 20 6683167* * 1098 SJ Amsterdam * * * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
Debian Bug Tracking System wrote: On our NIS servers we only allow binding to eth0 interface, ypserv.conf: # Always allow access for localhost 255.0.0.0 127.0.0.0 255.255.252.0 192.168.16.0 (eth0) That's not the documented format for ypserv.conf. It should say something more like (untested, so it may need some modification): 127.0.0.0/8:*:*:none 192.168.16.0/255.255.252.0:*:*:none *:*:*:deny for what you seem to be looking for. Please see the manual page for ypserv.conf or look at the commented entries in the default ypserv.conf for examples. The example you sent me works ;-) The only change is this line: 127.0.0.0/8:*:*:none must be 127.0.0.1:*:*:none Thanks a lot it is an bit confusing that there are two config files where we can specify access rules. In one config it works as desired an in the other not. Will the ypserv.securenets file be obsoleted in the future? Thanks a lot for the info -- -- * * * Bas van der Vlies e-mail: [EMAIL PROTECTED] * * SARA - Academic Computing Servicesphone: +31 20 592 8012 * * Kruislaan 415 fax:+31 20 6683167* * 1098 SJ Amsterdam * * * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#329371: acknowledged by developer (Re: Bug#329371: nis: ypbind/ypserv and broadcast option)
Debian Bug Tracking System wrote: On Wed, Sep 21, 2005 at 02:53:54PM +0200, root wrote: On our NIS servers we only allow binding to eth0 interface, ypserv.conf: # Always allow access for localhost 255.0.0.0 127.0.0.0 255.255.252.0 192.168.16.0 (eth0) That's not the documented format for ypserv.conf. It should say something more like (untested, so it may need some modification): 127.0.0.0/8:*:*:none 192.168.16.0/255.255.252.0:*:*:none *:*:*:deny for what you seem to be looking for. Please see the manual page for ypserv.conf or look at the commented entries in the default ypserv.conf for examples. Sorry but mentioned the wrong file i use 'ypserv.securenets'. I shall try your suggestion. For this file it is the right format but does not work. Thanks -- -- * * * Bas van der Vlies e-mail: [EMAIL PROTECTED] * * SARA - Academic Computing Servicesphone: +31 20 592 8012 * * Kruislaan 415 fax:+31 20 6683167* * 1098 SJ Amsterdam * * * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
