On Mon, Jul 10, 2023 at 12:11:01PM +0200, Lennart Poettering wrote:
> ProtectHome= protects /home/, nothing else. Hence you can use it, and
> it should not collide with bind's use of the home dir, because it's
> not in /home.
>
> Actually, correcting myself: use ReadOnlyBindPaths= for this.
On Mo, 10.07.23 11:37, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> Hi Lennart,
>
> On Mon, Jul 10, 2023 at 10:28:52AM +0200, Lennart Poettering wrote:
> > On So, 09.07.23 20:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> >
> > > > It should suffice bind mounting just the notify
Hi Lennart,
On Mon, Jul 10, 2023 at 10:28:52AM +0200, Lennart Poettering wrote:
> On So, 09.07.23 20:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
>
> > > It should suffice bind mounting just the notify socket, not the full
> > > dir.
> >
> > Is it intended behavior that an empty file is
On So, 09.07.23 20:14, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> > It should suffice bind mounting just the notify socket, not the full
> > dir.
>
> Is it intended behavior that an empty file is left at the "mount point"
> (what Where= points to) after the unit was stopped?
We need an
Hi Lennart,
thanks for this helpful answer.
On Tue, Jul 04, 2023 at 10:37:55AM +0200, Lennart Poettering wrote:
> On Mo, 03.07.23 20:52, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> > (1) go fully systemd
> > That would mean to get rid of bind's -t option completely but use
> > systemd's
I would not recommend using own chroot to anyone, who has enabled
SELinux or similar security technology.
We still offer subpackage bind-chroot, which has prepared
named-chroot.service for doing just that. But SELinux provides better
enforcement, while not complicating deployment and usage of
On Mo, 03.07.23 20:52, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
> (1) go fully systemd
> That would mean to get rid of bind's -t option completely but use
> systemd's RootDirectory directive instead. I have not tried this but I
> think that the bind community might be reluctant to
On Mon, Jul 03, 2023 at 11:21:22PM +0200, Silvio Knizek wrote:
> why is it suggested to run `named` within its own chroot? For security
> reasons? This can be achieved much easier with systemd native options.
That feature is two decades older than systemd, and name server
operators are darn
Hi Marc,
why is it suggested to run `named` within its own chroot? For security reasons?
This can be achieved much easier with systemd native options.
Something like
`/etc/systemd/system/named.service`
```ini
[Unit]
Description=Internet domain name server
After=network.target
[Service]
Hi,
this is a user-level question from someone who wants to make use of
systemd but has not quite grown the gut feeling about which way is the
right way to go.
I am running bind 9 on more than a handful of systems providing name
services as recursive and/or authoritative name servers. As it has
10 matches
Mail list logo
