On 22/08/2014 10:59, Jan Včelák wrote: Hi Jan,
> I build up-to-date Knot DNS packages for EPEL 7. The sources are in Fedora > git, so you can use them as a starting point if you want: Thank you for this pointer. I hadn't actually noticed that Knot was in EPEL 7 :) My first question is: do you intend to keep Knot in EPEL fully up to date? And how long for? If you are unable to maintain it, who will take over your task? I have had a look at your Knot package, and it looks very reasonable to me. However, it's missing one thing. See below. > Yes, the usage of templates is completely reasonable. But I'm not sure about > the .target unit. The targets are designed for services starting - I think > that it won't work for other operations (e.g., service restart). Maybe > someone > can clarify it, I do not have experience with this systemd feature. Let me explain this a bit more. Since Knot doesn't have views, and we need to serve different zones on different addresses, we run multiple instances of Knot on a server. The way your Knot package in EPEL is packaged, it won't easily allow us to instantiate multiple copies of Knot, because it only provides a single .service file, which starts a single copy of Knot. Now, what I would like is to have a [email protected] file, which is a template. In this template, the ExecStart line would be something like: ExecStart=/usr/sbin/knotd -c /etc/knot/%i This way, I can drop multiple config files into /etc/knot, and then make systemd instantiate multiple instances of Knot just by doing: systemctl enable [email protected] systemctl enable [email protected] systemctl enable [email protected] However, in order to start/stop/restart these, I would have to individually call systemctl for each instance. There is no easy way to start/stop/restart all of them in a single call. This is where targets come in. By defining a knot target in a knot.target file, I can group knot instances. Then, I can simply do: systemctl start knot.target (to start all instances) systemctl stop knot.target (to stop all instances) systemctl restart.target (to stop all instances) This setup does not exclude individual instance control. For example, if I just want to restart a single instance, I can still do: systemctl restart [email protected] This setup is flexible enough for both the simple use case of a single copy of knot, as well as our use case of multiple copies. For the single copy, there is just a single instance. I have described all this here for the benefit of other users, and to get feedback on this idea, but I'm happy to send you some template and target files for inclusion into the package. And if you commit to maintaining this package in this form, then I would be happy to stop building our own RPMs, and use yours. > Knot DNS supports startup notifications (sd_notify), however we do not have > any feedback on this feature from our users. And there might be some space > for > improvements. I see. I don't have any experience for now either. > We also support structured logging into journal, which is also a feature we > intend to improve - thoughts are welcome. At the moment, we just append a > field with zone name to the logged messages. Therefore, you can query journal > for messages for one zone by running: > > # journalctl _SYSTEMD_UNIT=knot.service ZONE=example.com Ok, this is useful. _______________________________________________ knot-dns-users mailing list [email protected] https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users
