On 17 January 2017 at 10:28, Oberdorfer Patrick
<patrick.oberdorfer@xxxxxxxxxxxx> wrote:
> Thank you very much James for your deep explaining answer!
> That cleared everything up for me and yes that helped a lot.
>
> Have a nice day :)
>
>
No problem, glad it was helpful.
Incidentally if there are services you need ordered after
network-online.target you don't need to (and shouldn't) edit the unit
files for the services directly.
Instead you should just provide an override with the additional
dependency so that systemd merges the two automatically and so future
updates of $package don't break on changes to the unit file in
/usr/lib/systemd/system and any changes to the unit file get picked up
for your system automatically, if the route you go down to resolve
your use case is via systemd dependency declaration rather than kernel
sysctl or application freebind behaviour.
In the case of nginx, for example, you'd do this:
mkdir /etc/systemd/systemd/nginx.service.d
cat > /etc/systemd/systemd/nginx.service.d/after-network-online.conf <<EOF
[Unit]
After=network-online.target
EOF
systemctl daemon-reload
This snippet you could drop in for any service that you needed
ordering after network-online, ideally via some CM solution like
ansible, puppet, chef or saltstack of course.
As an incidental note to this whole thing ... nonlocal_bind and
freebind are both viable answers and good methods for handling things
like postgres, mysql, haproxy and similar where you need them to bind
on a specific IP which is a VIP moved by keepalived (or pacemaker or
similar tool) and not always existent on a box without having to start
the service after IP is moved via an orchestration (eg via pacemaker)
...
Of course *that* need is avoided if you just tell the app to bind on
0.0.0.0 or :: which, as mentioned, doesn't have these issues and is
the default behaviour on a lot of applications, with limiting the
connectivity via iptables where it should only be visible on a single
interface.
Of course there are occasions where you specifically do need to bind
to a specific interface, either to differentiate sshd configs or for
other reasons, and that's when the dependency, sysctl and network
socket options are various tools to solve the issue.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
