[ClusterLabs] [ClusterLabs Developers] Help! Can packmaker launch resource from new network namespace automatically

[Jan Pokorný]

[forwarding to users list as it seems a better audience to me]

On 22/12/16 05:08 +0800, Hao QingFeng wrote:
> I am newbie for pacemaker and using it to manage resource haproxy on ubuntu
> 16.04.
> 
> I met a problem that haproxy can't start listening for some services
> in vip because the related ports were occupied by some native
> services which listened on 0.0.0.0.
> 
> So I would like just  to confirm that if pacemaker can create a new
> network namespace for haproxy(or other manged resource)
> automatically to avoid such socket binding conflict?

No, pacemaker does not have that ability per se and I don't expect it
will ever go in systemd direction (i.e. piece of software that is so
tailored to particular OS since some particular version because of
depending on recent kernel features that it cannot be run elsewhere,
as opposed to portability across various more or less POSIX compliant
systems).

However, that does not mean that you cannot achieve such extra
behavior at all -- quite the opposite as shell scripting in resource
agents, where the core business logic for particular resource happens
to be outsourced, allows you to do whatever available through command
line tools.  And for your goal, there indeed are tools that may come
useful, see ip-netns(8) and nsenter(1) from iproute and util-linux
packages, respectively.

> If yes, how to configure it? If no, do you have any advice on how to
> solve the problem?

See above.

Still, I would start with checking that haproxy or the conflicting
services indeed cannot be instructed which local addresses (not) to
listen at before rolling out anything as complex as per-resources
namespaces.  Alternatively, there's a PrivateNetwork directive
that can be used in systemd unit file of haproxy, and let pacemaker
start it through systemd.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20161222/32abf195/attachment-0003.sig>