<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2018-01-16 11:58 GMT+01:00 Reindl Harald <span dir="ltr"><<a href="mailto:h.reindl@thelounge.net" target="_blank">h.reindl@thelounge.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
Am 16.01.2018 um 11:46 schrieb Tony Finch:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Robert Edmonds <<a href="mailto:edmonds@mycre.ws" target="_blank">edmonds@mycre.ws</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I would guess that retaining CAP_NET_BIND_SERVICE and CAP_SYS_RESOURCE<br>
during the process runtime permits open-ended reloading of the config at<br>
runtime (e.g., binding to a new IP address on port 53 without needing to<br>
restart the daemon).<br>
</blockquote>
<br>
BIND since 9.10 listens on the routing socket so it can spot network<br>
interfaces coming and going automatically, without needing an explicit<br>
`rndc reconfig` or `rndc scan`. This works very nicely with `keepalived` -<br>
I use it for failover in my production resolver cluster.<br></blockquote></span></blockquote><div><br></div><div>Good to know, thanks for the information.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(I avoid systemd: journald makes it so difficult to get logs out that I<br>
get angry every time I encounter it, and systemd has a habit of believing<br>
that a service is working when it isn't. I've had enough pain in test<br>
environments that I don't want to use it in production.)<br>
</blockquote>
<br></span>
well, complete infrastructure running from 2011 until now with systemd</blockquote><div><br></div><div>The goal of my e-mail wasn't to have a debate about the interest of systemd :-)</div><div><br></div><div>Personally, we use systemd+journald on production since 2015. Even if the beginning was complicated, the time we needed to learn and especially about performances issues in journald, since we use systemd backports on Debian, it's OK now. And we have upgraded to Debian stretch, nothing special to do anymore.</div><div><br></div><div>However, it's technically possible to replace most systemd features by several other technologies, and certainly with more options.</div><div>Nevertheless, from my past experience with other solutions, systemd is good enough for most use cases.</div><div><br></div><div>While nobody forbids me to use systemd features, it's OK for me that other people use other technologies ;-)</div></div></div></div>