On 19/06/2024 16:27, Julien Petit wrote:
Does it have some logic to avoid descending into bind mounts? Maybe I am
wrong with my expectation that it does not use anything besides st_dev
from stat result. It may be promising case to demonstrate the issue in a
way independent of systemd and
Julien Petit wrote:
> How Linux is supposed to be used? That's why i'm here. There wasn't
> until kernel 4.19 an official limit to the number of mounts in the
> documentation. Even though we use mounts a lot, we're still far from
> the official limit. Did we get lucky for 15 years and we should ch
> This can be solved with ACLs. Instead of creating a bind mount, this process
> that allows the user to share the directory can set an ACL and create a
> symlink.
For a few users maybe but not that easy when you have many thousands
users (that on top do not have local accounts). We&#
> PS: if you maintain your own software and aren't able to find a way for your
> user to do shares - especially while systems that most likely have such
> functionality built-in out of the box surely exist, think Nextcloud etc -
> that is covered by how Linux is supposed to be used, by definitio
> At this point, I kinda doubt this issue has anything to do with Debian
> itself, but will most likely be an issue/limitation of the Linux Kernel
> itself.
>From my latest tests, it seems to point that way. Kernel 5.4 came with
a new mount API and it seems to break since then.
During my search,
PS: if you maintain your own software and aren't able to find a way for
your user to do shares - especially while systems that most likely have
such functionality built-in out of the box surely exist, think Nextcloud
etc - that is covered by how Linux is supposed to be used, by definition
it's pret
Software is only tested to a certain degree. So mounts are tested to a
sensible number, if you move outside it, you have to bet on luck if it's
supported or not. At this point, I kinda doubt this issue has anything to
do with Debian itself, but will most likely be an issue/limitation of the
Linux K
directory. I.e: John/Sales/Invoices is
mounted in Alice/Shared with me/Invoices.
Can be done with symlinks.
I imagine there's some process that creates these bind mounts, so the
process could create symlinks.
Symlinks are no good since the user sharing his directory can decide
to share
> For this, probably the easiest is to set up a common directory/a few common
> directories, set up proper permissions through use of groups and worst case
> create some symlinks from the user's home directories, if these directories
> really need to be accessible from within their home director
> Does it really have to be in the home directory? Can't the software (and/or
> the users) open files in, say, /shared/accounting?
It doesn't really matter where folders/mounts are. Users can share any
directory (and subdirectories) in their home directory with any other
user. The shared folder i
>> However do you need shared subtrees?
> I'm gonna test the effect of setting them to private.
This doesn't seem to fix the problem either
For this, probably the easiest is to set up a common directory/a few common
directories, set up proper permissions through use of groups and worst case
create some symlinks from the user's home directories, if these directories
really need to be accessible from within their home directories. That's
On 19/06/2024 05:46, Julien Petit wrote:
Rights are not the challenge here. It's to be able to share a
directory across multiple users.
For instance you would have : /users/bob/accounting shared with Alice
and accessible in her home directory /users/alice/accounting
Does it really have to be in
> Does it have some logic to avoid descending into bind mounts? Maybe I am
> wrong with my expectation that it does not use anything besides st_dev from
> stat result. It may be promising case to demonstrate the issue in a way
> independent of systemd and sandboxing. You can obtain
> Just to learn about it.
> What about using acl rather than bind mounts? What should be the
> problem in this solution?
As i said to Richard, rights are not the challenge here. It's to be
able to share a directory across multiple users. For instance you
would have : /users/bob/acc
> If there's a better way should be judged on what exactly that app expects.
> For the web interface, maybe the http server - or whatever makes the web
> interface accessible to the users - can limit permissions. For the rest of
> the use cases it would be interesting which circumstances would n
sandboxing setting in its unit file, but
perhaps it is irrelevant.
find
Does it have some logic to avoid descending into bind mounts? Maybe I am
wrong with my expectation that it does not use anything besides st_dev
from stat result. It may be promising case to demonstrate the issue in a
ked to sandboxing.
>
> > However do you need shared subtrees? It may cause exponential
> > growth of number of moutpoints, see
>
> We only use mount bind to share an initial folder with other users
> with different access rights (rw or ro). So we probably don't
On 14.06.24 11:38, Julien Petit wrote:
We use the mounts to share an initial folder with either rw or ro
wrights in a user directory. The user directory is then accessible
through a web interface, sftp, webdav and rsync. There is probably
better ways to do that now but that's a legacy app (2009)
> Best question probably is: what exactly are you needing 14.000 mounts for?
> Even snaps shouldn't be that ridiculous. So what's your use case? Maybe
> there's a better solution to what you are doing. If it's just about having a
> place that is rw only without execution permissions, just crate
We only use mount bind to share an initial folder with other users
with different access rights (rw or ro). So we probably don't need
shared subtrees (as long as mount bind doesn't rely on it). I'm not
really familiar with subtrees though. In my understanding, it is used
for chroot or c
000}
> do
>echo "Mounting dir $i"
>mkdir "/home/test/directories/dir_$i"
>mkdir "/home/test/mounts/dir_$i"
>mount --bind -o rw "/home/test/directories/dir_$i"
> "/home/test/mounts/dir_$i"
> done
>
> After that, the "top" command will show processes getting stuck using
> 100% of CPU never ending.
>
> Has anyone a clue if this is fixable? Should i report a bug?
> Thanks for your help.
>
>
On 12/06/2024 17:02, Julien Petit wrote:
for i in {1..14000}
do
echo "Mounting dir $i"
mkdir "/home/test/directories/dir_$i"
mkdir "/home/test/mounts/dir_$i"
mount --bind -o rw "/home/test/directories/dir_$i"
"/home/test/mounts/dir
mkdir "/home/test/directories/dir_$i"
mkdir "/home/test/mounts/dir_$i"
mount --bind -o rw "/home/test/directories/dir_$i" "/home/test/mounts/dir_$i"
done
After that, the "top" command will show processes getting stuck using
100% of CPU neve
On Tue, Mar 14, 2023 at 08:05:55PM +, Darac Marjal wrote:
> On 13/03/2023 23:23, Greg Wooledge wrote:
> > I have not to this day figured out what "vendor preset" means here.
> It would appear to be
> https://www.freedesktop.org/software/systemd/man/systemd.preset.html. If I'm
> reading the intr
On 13/03/2023 23:23, Greg Wooledge wrote:
On Tue, Mar 14, 2023 at 07:04:02AM +0800, Jeremy Ardley wrote:
I replicated your test above and it seems your listing has been accidentally
truncated...
Pipe it through cat to avoid the "left/right scrolling" crap.
If you want to do this regularly, yo
Mar 13, 2023, 23:33 by jer...@ardley.org:
> You may be happy to learn you can't even install it as a separate package any
> more.
>
> apt install --reinstall systemd-resolved
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> Package systemd-
On Tue, Mar 14, 2023 at 07:33:00AM +0800, Jeremy Ardley wrote:
> So the mystery is how it gets onto a system using a standard install and
> which package it comes from now and what is done with any presets
unicorn:~$ dpkg -S systemd-resolved
systemd: /usr/share/man/man8/systemd-resolved.8.gz
syste
On 14/3/23 07:23, Greg Wooledge wrote:
I have not to this day figured out what "vendor preset" means here.
Mine shows the same as yours -- "disabled; vendor preset: enabled".
All I care about is the part that says "disabled". That's the actual
state.
You may be happy to learn you can't ev
On Tue, Mar 14, 2023 at 07:04:02AM +0800, Jeremy Ardley wrote:
> I replicated your test above and it seems your listing has been accidentally
> truncated...
Pipe it through cat to avoid the "left/right scrolling" crap.
> jeremy@testldap:~$ systemctl status systemd-resolved
> ● systemd-resolved.se
On 14/3/23 06:34, Greg Wooledge wrote:
On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:
FYI systed-resolved is the inbuilt debian caching DNS server which may be
enabled by default.
It is NOT enabled by default.
unicorn:~$ systemctl status systemd-resolved
● systemd-resolved.se
On 14/3/23 06:34, Greg Wooledge wrote:
On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:
FYI systed-resolved is the inbuilt debian caching DNS server which may be
enabled by default.
It is NOT enabled by default.
It is if you are using NetworkManager
--
Jeremy
(Lists)
On 14/3/23 06:23, Jeremy Ardley wrote:
I had a signed DNS error in a similar configuration using a bind
authoritive and caching server. It turned out it was systemd-resolved
interfering and/or replacing part of the DNS chain
FYI systed-resolved is the inbuilt debian caching DNS server
On Tue, Mar 14, 2023 at 06:23:09AM +0800, Jeremy Ardley wrote:
> FYI systed-resolved is the inbuilt debian caching DNS server which may be
> enabled by default.
It is NOT enabled by default.
unicorn:~$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
Loa
> dig's message say that there was "communications error to 127.0.0.1#53: timed
> out"? It really gives an impression that dig was failing to connect 127.0.0.1
> port 53, on which bind was running.
>
> # dig www.yahoo.com <http://www.yahoo.com>
> ;;
e was
"communications error to 127.0.0.1#53: timed out"? It really gives an
impression that dig was failing to connect 127.0.0.1 port 53, on which bind was running.
# dig www.yahoo.com <http://www.yahoo.com>
;; communications error to 127.0.0.1#53: timed out
;; communications error t
ni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53
>> Bounce BIND, wait for a minute at least.
>> Do some DNS queries. One or two will do.
>> Interrupt tcpdump unless it completes by itself.
>> Post dns.pcap.
>>
>
>
> Strangely, the issue re
Mar 13, 2023, 21:42 by recovery...@enotuniq.net:
> Well, it was worth to check it.
>
>
> Next idea is somewhat more complicated.
>
> Install tcpdump.
> Run:
> tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53
> Bounce BIND, wait for a minute at l
e/dns/root.key. Compare its contents with
> > /etc/bind/bind.keys. Replace the latter if needed.
> >
> > "dpkg-reconfigure -plow bind9" is probably more preferred way of doing
> > it.
> >
>
> They keys in the "/etc/bind/bind.keys" and "/u
Mar 13, 2023, 11:50 by mv...@free.fr:
> Did you check memory and disk space as suggested by jeremy ?
>
There's plenty of free RAM (4GB) and disk space (hundreds of GBs).
Regards,
.0.4#53(198.41.0.4) (UDP)
;; WHEN: Mon Mar 13 15:54:28 EDT 2023
;; MSG SIZE rcvd: 811
# Note that I'm running bind with "-4" option, that is, IPv4 only
$ dig +norec @2001:503:ba3e::2:30 . NS
;; UDP setup with 2001:503:ba3e::2:30#53(2001:503:ba3e::2:30) for . failed:
network u
Mar 13, 2023, 12:06 by recovery...@enotuniq.net:
> Looks correct, assuming that the contents of the key start with AwEAAaz
> and end with V74bU=.
>
>
> Look at /usr/share/dns/root.key. Compare its contents with
> /etc/bind/bind.keys. Replace the latter if needed.
>
>
> On Mar 13, 2023, at 12:08 AM, local10 wrote:
>
> I have a local caching DNS server that was working fine for a long time but
> today, all of a sudden, it stopped resolving queries.
>
> More info: https://pastebin.com/iW5YeXgS
>
> Any ideas? Thanks
Based on what I saw in the logs, your res
etup, every
> > time you deal with DNSSEC you're dealing with a ticking bomb anyway.
> >
> > Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
> > which should provide a current DNSSEC root key (KSK to be precise), but
> > bind9 could al
Le 13 mars 2023 local a écrit :
> Sure, I could have used some public DNS server and I may have to do that if I
> can't get this issue resolved. Still, I'd like to understand why BIND
> suddenly stopped working[1] for me and how to fix it.
>
> Regards,
>
> 1. It w
Mar 13, 2023, 11:24 by g...@wooledge.org:
> For the record:
>
> unicorn:~$ sudo ss -ntlp | grep :53
> [sudo] password for greg:
> LISTEN 0 20 0.0.0.0:53 0.0.0.0:*
> users:(("dnscache",pid=664,fd=4))
>
> In general, ss replaces netstat for this kind of query. I don't kn
oot-data,
> which should provide a current DNSSEC root key (KSK to be precise), but
> bind9 could also take said key from /etc/bind/bind.keys.
>
>
> In conclusion:
>
> 1) Check the contents of your /etc/bind/bind.keys, update if needed.
> 2) Check the version of your dns-roo
On Mon, Mar 13, 2023 at 09:19:41AM +0100, local10 wrote:
> Mar 13, 2023, 07:25 by jer...@ardley.org:
>
> > Try
> >
> > netstat -tulpnW | grep 53
> >
> > and see what's listening
> >
>
> Bind seems to be listening on 127.0.0.1 port 53.
>
&
Hi.
On Mon, Mar 13, 2023 at 10:57:48AM +0100, local10 wrote:
> Mar 13, 2023, 09:32 by jer...@ardley.org:
>
> > My next best option is simply to remove your bind caching server (it sounds
> > like it's not really necessary in your application)
> >
> > B
Mar 13, 2023, 09:32 by jer...@ardley.org:
> My next best option is simply to remove your bind caching server (it sounds
> like it's not really necessary in your application)
>
> Backup /etc/bind and /var/cache/bind
>
> then
>
> systemctl remove bind9
>
> syst
On 13/3/23 17:12, local10 wrote:
"debug 1;" doesn't seem to be a valid option, couldn't start BIND with it. Anyhow, the
following is what I get when running "dig www.yahoo.com"
Mar 13 05:03:11 tst systemd[1]: Started named.service - BIND Domain Name Server.
M
Mar 13, 2023, 08:31 by jer...@ardley.org:
> Sorry. Last message was garbled. Try this in /etc/bind/named.conf.options
>
> options {
> // other configuration options ...
> debug 1;
> logging {
> channel debug_log {
>
On 13/3/23 16:19, local10 wrote:
Mar 13, 2023, 07:25 by jer...@ardley.org:
Try
netstat -tulpnW | grep 53
and see what's listening
Bind seems to be listening on 127.0.0.1 port 53.
I don't have netstat installed and can't easily install it as aptitude can't
resolve
On 13/3/23 16:19, local10 wrote:
Bind seems to be listening on 127.0.0.1 port 53.
I don't have netstat installed and can't easily install it as aptitude can't
resolve Debian server's name to an IP, so the following is what I tried:
# telnet -4 127.0.0.1 53
Trying 127.0
Mar 13, 2023, 07:25 by jer...@ardley.org:
> Try
>
> netstat -tulpnW | grep 53
>
> and see what's listening
>
Bind seems to be listening on 127.0.0.1 port 53.
I don't have netstat installed and can't easily install it as aptitude can't
resolve Debian serve
should also check if there are any new firewall issues, and that you
haven't run out of space somewhere.
Finally, you may have forwarder(s) in your bind. It's best to check if that is
working
No changes were made to the firewall and there are no firewall issues I'm aware o
eck if there are any new firewall issues, and that you
> haven't run out of space somewhere.
>
> Finally, you may have forwarder(s) in your bind. It's best to check if that
> is working
>
No changes were made to the firewall and there are no firewall issues I'm
.
That and /etc/nsswitch.conf a/etc/hosts
You should also check if there are any new firewall issues, and that you
haven't run out of space somewhere.
Finally, you may have forwarder(s) in your bind. It's best to check if
that is working
--
Jeremy
(Lists)
Hi,
I have a local caching DNS server that was working fine for a long time but
today, all of a sudden, it stopped resolving queries.
More info: https://pastebin.com/iW5YeXgS
Any ideas? Thanks
On Thu, Jan 19, 2023 at 09:12:19PM +0100, Maurizio Caloro wrote:
> # host -t A pluto.sternbild.m 127.0.0.1
> Using domain server:
> Name: 127.0.0.1
> Address: 127.0.0.1#53
> Aliases:
>
> Host pluto.sternbild.m not found: 3(NXDOMAIN)
Hmm. In your previous message, you hav
esol
tcp6 0 0 :::53 :::* LISTEN 17207/named
# systemctl stop systemd-resolved.service
# netstat -plnt | grep ':53'
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN
17207/named
tcp6 0 0 :::53 :::* LIS
On Thu, Jan 19, 2023 at 07:45:34PM +0100, Maurizio Caloro wrote:
> fighting little with bind9, on Debian 10.13, in my opinion appair right, but
> # cat /etc/resolv.conf
> search sternbild.m
> nameserver 127.0.0.1
> nameserver A.B.C.D -> other Nameservers
> nameserver A.B.C.D -> other Nameservers
hello
fighting little with bind9, on Debian 10.13, in my opinion appair right,
but arn't possible
to ping local/inside the Client that i have add to my config.
information this machine running
on a VPS envirment.
also the checks are positiv
# named-checkzone sternbild.m /var/cache
On Wed, Jun 22, 2022 at 09:13:20PM +0200, Maurizio Caloro wrote:
> pls, why this key arnt found? the file are here in this folder and write
> *root:bind* it's set
>
> Jun 22 21:03:56 nmail named[27607]: zone 127.in-addr.arpa/IN: loaded serial
> 1
> Jun 22 21:03:56 nmail named[27607]: zone 190.120.
pls, why this key arnt found? the file are here in this folder and write
*root:bind* it's set
Jun 22 21:03:56 nmail named[27607]: zone 127.in-addr.arpa/IN: loaded
serial 1
Jun 22 21:03:56 nmail named[27607]: zone 190.120.37.in-addr.arpa/IN:
loaded serial 1
Jun 22 21:03:56 nmail named[27607]: z
On Mon, 16 Aug 2021, raf wrote:
> If like me, you've been eagerly awaiting debian11 to
> get bind-9.16.15, which finally lets you implement
> DNSSEC extremely easily on debian stable, I have a
> warning.
And I have another: make sure your system clock is correct. DNSSEC will
fa
Hi,
If like me, you've been eagerly awaiting debian11 to
get bind-9.16.15, which finally lets you implement
DNSSEC extremely easily on debian stable, I have a
warning.
Bind has a dnssec-policy {} stanza for defining your
own policy if you're feeling adventurous, but there's
also a
solved issue ... thank u
On Fri, Sep 27, 2019 at 11:55 AM Greg Wooledge wrote:
> On Fri, Sep 27, 2019 at 11:44:25AM -0400, yoda woya wrote:
> > The public interface is listed defined as
> >
> > # The public network interface
> > allow-hotplug eno1
> > iface eno1 inet static
> > address x
On Fri, Sep 27, 2019 at 11:44:25AM -0400, yoda woya wrote:
> The public interface is listed defined as
>
> # The public network interface
> allow-hotplug eno1
> iface eno1 inet static
> address x.x.x.x
>
>
> But I have that same configuration on another server and it works fine.
Replace
Hi.
Please do not top-post.
On Fri, Sep 27, 2019 at 11:51:08AM -0400, yoda woya wrote:
> How can I use to solve the problem:
>
> "ssh.service has "After=network.target", and network.target only waits
> for interfaces marked as "auto" to come up."
You have this in your /etc/network/inter
art job for unit ssh.service has begun execution.
> > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
> > failed: Cannot assign requested address.
> > Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address.
> > Sep 27 10:52:31 nat6pub systemd
commented out or set to 0.0.0.0. The service works
>> > manually ( /etc/init.d/ssh start)
>> > -- Subject: A start job for unit ssh.service has begun execution
>> > -- A start job for unit ssh.service has begun execution.
>> > Sep 27 10:52:31 nat6pub sshd[690]:
d out or set to 0.0.0.0. The service works
> > manually ( /etc/init.d/ssh start)
> > -- Subject: A start job for unit ssh.service has begun execution
> > -- A start job for unit ssh.service has begun execution.
> > Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.
ce has begun execution
> -- A start job for unit ssh.service has begun execution.
> Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
> failed: Cannot assign requested address.
> Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address.
> Sep 27 10:52:31 nat6
nit ssh.service has begun execution.
> Sep 27 10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
> failed: Cannot assign requested address.
Do you have an existing interface with x.x.x.x assigned to it?
-dsr-
10:52:31 nat6pub sshd[690]: error: Bind to port 2022 on x.x.x.x
failed: Cannot assign requested address.
Sep 27 10:52:31 nat6pub sshd[690]: fatal: Cannot bind any address.
Sep 27 10:52:31 nat6pub systemd[1]: ssh.service: Main process exited,
code=exited, status=255/EXCEPTION
-- An ExecStart= process
On Thu, Sep 26, 2019 at 05:34:02PM -0400, yoda woya wrote:
> when I use this, the binding fails:
> Port 2022
> #AddressFamily any
> ListenAddress x.x.x.x
> #ListenAddress ::
>
> but if I do , it binds it to the ip on boot
> Port 2022
> #AddressFamily any
> #ListenAddress x.x.x
> #ListenAddress ::
On Thu, Sep 26, 2019 at 05:34:02PM -0400, yoda woya wrote:
>when I use this, the binding fails:
>Port 2022
>#AddressFamily any
>ListenAddress x.x.x.x
>#ListenAddress ::
>but if I do , it binds it to the ip on boot
>Port 2022
>#AddressFamily any
>#ListenAddress x.
when I use this, the binding fails:
Port 2022
#AddressFamily any
ListenAddress x.x.x.x
#ListenAddress ::
but if I do , it binds it to the ip on boot
Port 2022
#AddressFamily any
#ListenAddress x.x.x
#ListenAddress ::
How can i fix this. I want sshd to run only on this one IP
I tested my suspicion that bind9-resolvconf was somehow implicated in
the bind9 start problems by returning bind9-resolvconf to its
original, disabled, state and restarting the system. Unfortunately,
it didn't help:
May 25 19:05:34 barley named[804]: /etc/bind/named.conf.options:2:
c
#x27;t work. After rebooting I still get
------
May 22 18:38:49 barley named[829]: loading configuration from
'/etc/bind/named.conf'
May 22 18:38:49 barley named[829]: /etc/bind/named.conf.options:2:
change directory to '/var/cache/bind' failed: file not f
hing services while some of the mounts (and the
> required decryption) are still to be done?
>
> Is there some systemd way to ensure the file system is mounted before
> launching bind? But I'd think if /var weren't available, bind
> wouldn't be the only one with a
decryption) are still to be done?
Is there some systemd way to ensure the file system is mounted before
launching bind? But I'd think if /var weren't available, bind
wouldn't be the only one with a problem.
Ross
On 23/05/19 8:00 AM, Ross Boylan wrote:
> At system start, bind9 fails to start on a recently created buster
> system. Some of the local bind is based on configuration from an
> earlier bind. The logs show
> /etc/bind/named.conf.options:2: change directory to '/var/cache/bind&#x
At system start, bind9 fails to start on a recently created buster
system. Some of the local bind is based on configuration from an
earlier bind. The logs show
/etc/bind/named.conf.options:2: change directory to '/var/cache/bind'
failed: file not found
But if I then start it ma
just below that is
# some people like to put logs in /var/log/named/ instead of having
# syslog do the heavy lifting.
/var/log/named/** rw,
/var/log/named/ rw,
so if I switch my logs to there (and rename the directory), instead of
/var/log/bind,
the logging should work too. Or I could ad
I also have a similar problem accessing /run/named. bind can't create the
directory or any files in it. The error messages:
couldn't mkdir '//run/named': Permission denied
could not create //run/named/session.key
Apparmor problems can be fixed by running aa-logprof an
On 2019-05-15 09:33 -0700, Ross Boylan wrote:
> Sven, thanks for the tip about AppArmor. Yet another presumably
> complicated system I've avoided learning about til now. I guess it's
> time.
>
> As to why bind is trying to open /run/named/named.resolvers: that is a
>
On Wed, May 15, 2019 at 12:11:58PM -0400, Lee wrote:
> The way I fixed my permission problems after telling bind to log to a
> file instead of syslog was
> su -
> to become root
> su bind
> which didn't work because
> # grep bind /etc/passwd
> bind:x:116:11
Sven, thanks for the tip about AppArmor. Yet another presumably
complicated system I've avoided learning about til now. I guess it's
time.
As to why bind is trying to open /run/named/named.resolvers: that is a
customized integration with resolvconf. It is not the default, but it
is s
On 5/15/19, Ross Boylan wrote:
> I have a new buster system with a bind setup based on (much) older*
> systems, on which it worked fine. On buster, it doesn't.
> In two different places in my configuration I referred to files or
> directories that were outside of bind proper,
On 2019-05-14 21:50 -0700, Ross Boylan wrote:
> I have a new buster system with a bind setup based on (much) older*
> systems, on which it worked fine. On buster, it doesn't.
> In two different places in my configuration I referred to files or
> directories that were outside of
I have a new buster system with a bind setup based on (much) older*
systems, on which it worked fine. On buster, it doesn't.
In two different places in my configuration I referred to files or
directories that were outside of bind proper, and in both cases this
failed with permission problems
ehaviour that a cached record is discarded when its TTL
> expires.
> Check if BIND has options to force a minimal TTL on cached records.
>
Bind, as I understand it, does not have a setting that allows to change the
minimal TTL but unbound and dnsmasq (the later versions) do. Instead o
On Mon, Sep 17, 2018 at 12:20:51AM +0200, local10 wrote:
;; ANSWER SECTION:
old.reddit.com. 241 IN CNAME reddit.map.fastly.net.
reddit.map.fastly.net. 8 IN A 151.101.21.140
this number ^^^
is the TTL/"time to live" in seconds. It is set by the s
Le 17/09/2018 à 00:20, local10 a écrit :
Hi,
So I set up a local caching server with bind. It seems to work, kind of, the problem is that cached
results do not stay in cache for long, if they placed in cache at all. For example, in the example
below bind caches the result for "old.reddi
Hi,
So I set up a local caching server with bind. It seems to work, kind of, the
problem is that cached results do not stay in cache for long, if they placed in
cache at all. For example, in the example below bind caches the result for
"old.reddit.com" but 8 minutes later tries
Hi there
See;
https://kb.isc.org/article/AA-01639/0
I don't think not using deny-answer-aliases is really an option.
Regards,
Rob
t; Hello,
> > > no your english was good enough to describe your setup. And I would say
> > > that 90% of "us" have a form of "dialup" with on routable ip address and a
> > > NAT setup.
> > > First bind is not "standard" in this
Because when I did , witen iI just installed Jessie in April 2016, my
mailbox which is dedicated to debian-user was flooded with useless or even
stupid posts. Sorry for my fellow countrymen.
Salut. Jacques
1 - 100 of 979 matches
Mail list logo
