21 Srp
2014
21 Srp
'14
23:36
Hello Knot folk,
I'm building Knot RPM packages for use on CentOS 7, and I have to write
systemd unit files. Before I write anything, I'd love to hear from
others who may already have done such work, to learn from it. Let me
describe my ideas.
On my existing Knot servers running on CentOS 6 with upstart, I have 2
upstart scripts, viz. knot.conf, and knot-instance.conf. The knot.conf
upstart script looks in /etc/knot for .conf files, and for each one,
runs knot-instance with the config file as a parameter. This way, a
simple "start knot" will start all instances.
In systemd, there is better support for instances, so I want to create a
knot@.service template unit, and a knot.target target unit. Then, I can
create new instances with "systemctl enable knot(a)conf1.conf" and
"systemctl enable knot(a)conf2.conf"quot;. Finally, running "systemctl start
knot.target" should start all configured instances. Does this sound
reasonable?
I would also like to know about Knot's built-in support for systemd. I
can't find any documentation about it. Could one of the devs please
describe what Knot actually does if it's compiled with systemd support?
Would you mind adding this information to the online documentation?
Regards,
Anand
22 Srp
22 Srp
10:59
Hello Anand,
I'm building Knot RPM packages for use on CentOS
7, and I have to write
systemd unit files. Before I write anything, I'd love to hear from
others who may already have done such work, to learn from it. Let me
describe my ideas.
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:
http://pkgs.fedoraproject.org/cgit/knot.git/tree/?h=epel7
If you don't require any special patches, you can also send me your changes or
requirements and I can incorporate them into these "official" builds.
EPEL 7 is still beta (I think), so there is not update process at the moment
and Knot DNS 1.5.1 should be already in the repositories. Alternatively, you
can download the package from the build system:
http://koji.fedoraproject.org/koji/buildinfo?buildID=569206
In systemd, there is better support for instances, so
I want to create a
knot@.service template unit, and a knot.target target unit. Then, I can
create new instances with "systemctl enable knot(a)conf1.conf" and
"systemctl enable knot(a)conf2.conf"quot;. Finally, running "systemctl start
knot.target" should start all configured instances. Does this sound
reasonable?
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.
I would also like to know about Knot's built-in
support for systemd. I
can't find any documentation about it. Could one of the devs please
describe what Knot actually does if it's compiled with systemd support?
Would you mind adding this information to the online documentation?
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.
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
We do not support socket activation. We had some request for this feature
recently, however it is somewhere down on our TODO list.
We will definitely update documentation to include information about systemd.
Best regards,
Jan
12:14
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 knot@.service 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 knot(a)conf1.conf
systemctl enable knot(a)conf2.conf
systemctl enable knot(a)conf3.conf
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 knot(a)conf1.conf
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.
14:16
Hello.
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?
Yes, I do. I maintain the package both in Fedora and EPEL. And I usually
update the package immediately after the release. Then the package goes
through the usual update process.
See https://fedoraproject.org/wiki/EPEL_Updates_Policy for more details.
Till now, this worked very well and nobody complained about rebasing the
package even if there were some backward incompatible changes (e.g, with
respect to configuration file). And I hope this will work in the future as
well.
There cannot be multiple versions of a package in the EPEL repository. I.e,
I cannot maintain both 1.4 and 1.5 in EPEL. If you are interested only in the
last stable version, then EPEL should work for you.
If I was unable to maintain the package (which I hope is very unlikely), then
somebody from Fedora will take over. At the moment, the knot package in EPEL
is owner by Paul Wouters from Red Hat and me.
Btw. we also have a bleeding-edge nightly-builds for of Knot from git master:
https://copr.fedoraproject.org/coprs/jvcelak/knot
Now, what I would like is to have a knot@.service
file, which is a
template. In this template, the ExecStart line would be something like:
ExecStart=/usr/sbin/knotd -c /etc/knot/%i
I understand the motivation. This is completely fine. Nothing prevents you
from creating the knot@.service file in /etc/systemd/system. It will work and
the config will not get overwritten by the package update.
But yes, I can include the knot@.service file in the RPM as well.
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:
I didn't know this worked for other operations than start. OK then. :-)
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.
I think your use case is perfectly reasonable. Send me the temple and target
files and I will take a look at them. :-)
Thanks and regards,
Jan
3536
days inactive
3537
days old
3 comments
2 participants
participants (2)
-
Anand Buddhdev -
Jan Včelák