ctdb - public ip is assigned to us but not on an interface - error

Martin Schwenke martin at meltin.net
Sat Jan 28 00:13:43 UTC 2017


On Fri, 27 Jan 2017 11:30:22 +0000, lejeczek <peljasz at yahoo.co.uk>
wrote:

> On 27/01/17 08:02, Martin Schwenke wrote:
> > On Wed, 25 Jan 2017 20:11:03 +0000, lejeczek <peljasz at yahoo.co.uk>
> > wrote:
> >  
> >> Cluster runs on Centos 7.x
> >> I believe it worked with distro's ctdb-4.4.4-9.el7.x86_64.
> >> Now when it fails it is ctdb-4.4.4-12.el7_3.x86_64.
> >> It loops forever:
> >>
> >> 2017/01/25 20:09:43.763947 [recoverd:17247]: Trigger takeoverrun
> >> 2017/01/25 20:09:43.765976 [recoverd:17247]: Takeover run
> >> starting
> >> 2017/01/25 20:09:43.777047 [17145]: Takeover of IP
> >> 10.5.10.51/28 on interface eth0
> >> 2017/01/25 20:09:45.360099 [recoverd:17247]: Takeover run
> >> completed successfully
> >> 2017/01/25 20:09:45.371403 [recoverd:17247]: Public IP
> >> '10.5.10.51' is assigned to us but not on an interface
> >> 2017/01/25 20:09:45.371436 [recoverd:17247]: Trigger takeoverrun
> >> 2017/01/25 20:09:45.371824 [recoverd:17247]: Takeover run
> >> starting
> >> 2017/01/25 20:09:45.372434 [17145]: Takeover of IP
> >> 10.5.10.51/28 on interface eth0
> >> 2017/01/25 20:09:47.136951 [recoverd:17247]: Takeover run
> >> completed successfully
> >> 2017/01/25 20:09:47.152961 [recoverd:17247]: Public IP
> >> '10.5.10.51' is assigned to us but not on an interface
> >> 2017/01/25 20:09:47.152987 [recoverd:17247]: Trigger takeoverrun
> >> 2017/01/25 20:09:47.154833 [recoverd:17247]: Takeover run
> >> starting
> >> 2017/01/25 20:09:47.156935 [17145]: Takeover of IP
> >> 10.5.10.51/28 on interface eth0  
> > It might be worth seeing the changelog for the RPM to see what has
> > changed, since it is actually the same CTDB version, perhaps with
> > distro patches on top.
> >
> > The other thing to check is whether the IP address is actually on the
> > interface.   If not, are you able to add it using:
> >
> >    ip addr add 10.5.10.51/28 dev eth0
> >
> > or similar?
> >
> > If CTDB can't add it then there should be an error from the
> > 10.interface event script... but we're not seeing an error.
> >
> > The relevant code has seen some improvement in recent versions but I
> > don't remember it failing like this...
> >
> > peace & happiness,
> > martin  
> 
> I'm afraid it is the case, bare-metal same ctdb versions(all 
> rest of samba suite) runs it just fine, at least here for me.
> Well.. I'd have question, I've been just introduced to ctdb 
> and learning, trying samba list first but not much feedback 
> on ctdb there, so I'd hope here, so..
> 
> this - https://wiki.samba.org/index.php/CTDB_Setup - gives 
> out an impression that ".. These are the addresses that the 
> SMBD daemons will bind to.."
> But - before I share software versions - it does not. My 
> smbd attaches to and listens on all interfaces: is this 
> normal, expected?
> And if it is, then how to tell/force smdb(under CTDB) to 
> bind to only specific NICs?
> I try usual:
> 
>    bind interfaces only = yes
>    interfaces = 127.0.0.1 em1(which is the NIC used in 
> public_addresses)
> 
> I put there public IP(s) too, but to no avail, smbd would 
> not go to that public IP, daemon does not respond on that 
> IP(unless of course these directives are absent, or... I 
> restart smbd manually later)... which, seems loco to me.
> 
> How does one make samba run off only those public IPs?

On my virtual cluster I have public IPs on interfaces eth1 and eth2.
I add the following to my Samba configuration:

        bind interfaces only = yes
        interfaces = lo eth1 eth2

Then I restart smbd and ss tells me:

# ss -tlnp '( sport = :445 )'
State       Recv-Q Send-Q                                                                         Local Address:Port                                                                           Peer Address:Port 
LISTEN      0      50                                                                                       ::1:445                                                                                      :::*      users:(("smbd",9364,53))
LISTEN      0      50                                                                                 127.0.0.1:445                                                                                       *:*      users:(("smbd",9364,51))
LISTEN      0      50                                                                           fc00:10:0:1::32:445                                                                                      :::*      users:(("smbd",9364,49))
LISTEN      0      50                                                              fc00:10:0:1:44:b0ff:fe00:202:445                                                                                      :::*      users:(("smbd",9364,47))
LISTEN      0      50                                                                                 10.0.1.32:445                                                                                       *:*      users:(("smbd",9364,45))
LISTEN      0      50                                                                                10.0.1.130:445                                                                                       *:*      users:(("smbd",9364,43))
LISTEN      0      50                                                                           fc00:10:0:2::32:445                                                                                      :::*      users:(("smbd",9364,41))
LISTEN      0      50                                                              fc00:10:0:2:44:b0ff:fe00:203:445                                                                                      :::*      users:(("smbd",9364,39))
LISTEN      0      50                                                                                 10.0.2.32:445                                                                                       *:*      users:(("smbd",9364,37))
LISTEN      0      50                                                                                10.0.2.131:445                                                                                       *:*      users:(("smbd",9364,35))

Here, only the 10.0.x.13y addresses are the public ones.  The others
are static IPs.  However, in particular, smbd isn't listening on any
10.0.0.x addresses.

If I drop those configuration items and restart smbd, I see smbd
listening on a wildcard address:

# ss -tlnp '( sport = :445 )'
State       Recv-Q Send-Q                                                                         Local Address:Port                                                                           Peer Address:Port 
LISTEN      0      50                                                                                         *:445                                                                                       *:*      users:(("smbd",14072,37))
LISTEN      0      50                                                                                        :::445                                                                                      :::*      users:(("smbd",14072,35))

However, I don't think using "bind interfaces only" is a good idea for
failover.  When IPs are failed over to a node then smbd won't be
listening on those addresses.  In fact, it is worse than that!  Since
smbd is started before any public IPs are assigned, smbd won't listen
on any public IPs.

If you really want to restrict which IP addresses smbd will accept
client connections from then I suggest using firewall (e.g. iptables)
rules.

peace & happiness,
martin



More information about the samba-technical mailing list