ctdb - public ip is assigned to us but not on an interface - error
lejeczek
peljasz at yahoo.co.uk
Sat Jan 28 11:53:07 UTC 2017
On 28/01/17 00:13, Martin Schwenke wrote:
> 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:
yes, but we should not have to restart anything!
If we should that obviously someone, or everybody
collectively made a joke out of CTDB and not! HA system.
Also Samba's own wiki gets it, makes it wrong. Something,
someone is very wrong here.
> # 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
gee, to anybody like me(beginning to) trying to make sense
out of how it works it soon becomes... useless.
What one would expect is that:
a) there will be a public IP(s) on which smbd will be
listening specifically, exclusively.
In any mid-size and upwards, set-ups there will be multiple
interfaces and users/admins will need to tie smdb to only
some NICs. CTDB should not be an obstacle in any form nor
shape in such cases.
b) not knowing inner workings of samba/kernel/networking but
knowing how Samba is smart, and are people who made her, one
would ... just.. assume that it would just work - one
specifies: bind interfaces only + interfaces (in my mind one
should not, after reading all the howtos/docs I could find,
first I was convinced that public_addresses will only be
used) and CTDB would (after publicIP is up&responding) just
"poke" smbd and tell it: hey, here, on the iface you are
bound too is yet another IP, serve it, now! We ought not
restart anything!
so, I'd have more questions:
1) does it make difference whether NIC(s) for
public_addresses are configured by the system or completely
left out inconfigured, to CTBD disposal. Is there a preference?
2) what about nmbd, is it doing anything in CTDB cluster?
and so, I'll go back to tampering ctdb..
thanks!
More information about the samba-technical
mailing list