On ti, 02 maalis 2021, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 02, 2021 at 11:29:21AM +0200, Alexander Bokovoy wrote:
On ma, 01 maalis 2021, Lennart Poettering wrote:
>On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
>
>>> 1. Dots (".") for separating IPV4 address byt
On Tue, Mar 02, 2021 at 11:29:21AM +0200, Alexander Bokovoy wrote:
> On ma, 01 maalis 2021, Lennart Poettering wrote:
> >On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
> >
> >>> 1. Dots (".") for separating IPV4 address bytes
> >>> 2. Colons (":") for separating IPv6 address
On 02/03/2021 17:30, Alexander Bokovoy wrote:
On ti, 02 maalis 2021, Ed Greshko wrote:
On 02/03/2021 06:03, Lennart Poettering wrote:
On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native sup
On ti, 02 maalis 2021, Ed Greshko wrote:
On 02/03/2021 06:03, Lennart Poettering wrote:
On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native support for systemd-resolved. It means it writes
s
On ma, 01 maalis 2021, Lennart Poettering wrote:
On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
> 1. Dots (".") for separating IPV4 address bytes
> 2. Colons (":") for separating IPv6 address parts, as well as separating
> port numbers from the IP addres
> 3. Brackets (
On Mon, Mar 1, 2021 at 11:03 pm, Lennart Poettering
wrote:
Hmm, cloud-init has no direct support for resolved.conf? But how is it
then that that file is modified? I don't get it?
I think they've deployed something entirely custom.
___
devel mailing
On 02/03/2021 06:03, Lennart Poettering wrote:
On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
Digital Ocean updates pushed with cloud-init use. Cloud-init does not
have any native support for systemd-resolved. It means it writes
something that systemd-resolved imports int
On Fr, 26.02.21 21:01, Alexander Bokovoy (aboko...@redhat.com) wrote:
> > 1. Dots (".") for separating IPV4 address bytes
> > 2. Colons (":") for separating IPv6 address parts, as well as separating
> > port numbers from the IP addres
> > 3. Brackets ("[]") for separating ipv6 addresses from the
On 2/26/21 12:10 PM, Marius Schwarz wrote:
> Am 25.02.21 um 10:51 schrieb Florian Weimer:
>>
>> Why do you think that?
>>
>> Caching DNS server availability is a commonly requested feature even in
>> data center deployments. The way Fedora currently implements its DNS
>> client, it more or less de
On pe, 26 helmi 2021, Lennart Poettering wrote:
On Mi, 24.02.21 22:08, Alexander Bokovoy (aboko...@redhat.com) wrote:
I think one of the issues reported in the discussion you mention was
that systemd-resolved considered invalid a DNS= line where addresses
were separated by a comma rather than s
On Fri, Feb 26, 2021 at 9:06 am, Lennart Poettering
wrote:
Note that as I understood it the original reporter's issue wasn't even
caused by concious editing of the configuration file, but was done
automatically by some other tool/copy pasted from elsewhere? i.e. it's
a bit much to expect peop
Am 25.02.21 um 10:51 schrieb Florian Weimer:
Why do you think that?
Caching DNS server availability is a commonly requested feature even in
data center deployments. The way Fedora currently implements its DNS
client, it more or less defeats the built-in high availability mechanism
of DNS, and
On 2/26/21 9:06 AM, Lennart Poettering wrote:
> On Do, 25.02.21 23:58, Petr Menšík (pemen...@redhat.com) wrote:
>
>> No, I don't think so. Anyone who manages the system should have basic
>> understanding how to configure it. If not obvious, needs good
>> documentation at hand. Extremely high level
On Mi, 24.02.21 15:08, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> FWIW I agree that systemd-resolved is *much* less important for servers and
> containers than it is on desktops.
>
> That said, the benefit of having a DNS cache is very real, as is the benefit
> of a unified, standardized AP
On Do, 25.02.21 23:58, Petr Menšík (pemen...@redhat.com) wrote:
> No, I don't think so. Anyone who manages the system should have basic
> understanding how to configure it. If not obvious, needs good
> documentation at hand. Extremely high level is not writing lines into
> configuration file in do
On Mi, 24.02.21 22:08, Alexander Bokovoy (aboko...@redhat.com) wrote:
> I think one of the issues reported in the discussion you mention was
> that systemd-resolved considered invalid a DNS= line where addresses
> were separated by a comma rather than space. Can systemd-resolved be
> improved to a
I disagree and do more below :)
On 2/23/21 2:49 PM, Lennart Poettering wrote:
> On Mo, 22.02.21 09:45, Michael Catanzaro (mcatanz...@gnome.org) wrote:
> 65;6201;1c
>> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote:
>>> 3) Configure DNS resolvers if you want to use DNS.
>>> Or dig deeper: wh
Michael Catanzaro wrote:
> Servers don't need split DNS. Desktops do. Without a DNS cache, your
> DNS will be slower. Without split DNS, your DNS may not work properly
> at all.
Not all desktops need split DNS. Most desktop users don't even have anything
to split the DNS over. (It needs either at
No, this is not true. DNS servers had for ages ability to forward
selected domains to specified list of addresses. All DNS caches have the
ability to do it for no reason.
Servers do not have automatic configuration of split DNS only, because
often do not have multiple connections. But I think VPNs
On Thu, Feb 25, 2021 at 10:51 am, Florian Weimer
wrote:
Why do you think that?
Servers don't need split DNS. Desktops do. Without a DNS cache, your
DNS will be slower. Without split DNS, your DNS may not work properly
at all.
___
devel mailing li
* Michael Catanzaro:
> FWIW I agree that systemd-resolved is *much* less important for
> servers and containers than it is on desktops.
Why do you think that?
Caching DNS server availability is a commonly requested feature even in
data center deployments. The way Fedora currently implements its
> Am 24.02.2021 um 20:19 schrieb Lennart Poettering :
>
> On Mi, 24.02.21 12:49, Paul Wouters (p...@nohats.ca) wrote:
>
>
> I think the caching and DoT stuff that resolved provides is useful on
> any system, and that includes servers, and I think it would be good to
> minimize the difference i
FWIW I agree that systemd-resolved is *much* less important for servers
and containers than it is on desktops.
That said, the benefit of having a DNS cache is very real, as is the
benefit of a unified, standardized API for controlling your DNS
configuration that's the same regardless of which
On Wed, 24 Feb 2021, Colin Walters wrote:
It's trickier than that because local caching nameservers can provide real
benefits in various server scenarios, and also the IoT/edge case (as usual)
blurs the traditional datacenter/mobile boundary. (IoT can be servers with
WiFi)
We ended up enabl
On ke, 24 helmi 2021, Lennart Poettering wrote:
On Mi, 24.02.21 12:49, Paul Wouters (p...@nohats.ca) wrote:
The scenario of roaming laptops/phones is completely different from
this. Which is why I have argued for a long time now that
systemd-resolved should not be installed by default on server
On Mi, 24.02.21 12:49, Paul Wouters (p...@nohats.ca) wrote:
> The scenario of roaming laptops/phones is completely different from
> this. Which is why I have argued for a long time now that
> systemd-resolved should not be installed by default on servers or
> containers. It adds complexity without
On Wed, Feb 24, 2021, at 12:49 PM, Paul Wouters wrote:
> Which is why I have argued for a long time now that
> systemd-resolved should not be installed by default on servers or
> containers. It adds complexity without any real gain in these
> deployments and makes DNS issues harder to troublesho
On Tue, 23 Feb 2021, Lennart Poettering wrote:
And yeah, call me a hypocrite, but if I have the choice between having
no Internet at all or using some public DNS servers for DNS, and
leaking a tiny bit of information to those DNS server providers then I
am definitely preferring to have Internet,
On Wed, Feb 24, 2021, at 9:19 AM, Tadej Janež wrote:
>
> This is the thing that is probably hurting users the most. They have a
> working F33 cloud instance and after systemd is upgraded, the instance
> will *probably* (i.e. if users didn't configure DNS themselves and
> relied on cloud-init) be
Tadej Janež wrote:
> On Tue, 2021-02-23 at 00:02 +0100, Kevin Kofler via devel wrote:
>> It is unfortunate that this behavior has changed in an update.
>
> This is the thing that is probably hurting users the most. They have a
> working F33 cloud instance and after systemd is upgraded, the instanc
On Tue, 2021-02-23 at 00:02 +0100, Kevin Kofler via devel wrote:
> Well, this silent fallback behavior is one of the reasons I have
> refused to
> use systemd-resolved at all so far.
>
> The issue with the cloud setups would also have been caught much
> earlier if
> it had failed right away and
Am 23.02.21 um 20:34 schrieb Zbigniew Jędrzejewski-Szmek:
Everything, that is not prepresenting a person, is not regulated by
GDPR, therefor it does not "need" to comply.
No. GDPR is about "personally identifying information". In particular,
it talks about information which may be combined with
On Tue, Feb 23, 2021 at 01:18:08PM +0100, Marius Schwarz wrote:
> Am 22.02.21 um 11:17 schrieb Zbigniew Jędrzejewski-Szmek:
> >>1) Use different defaults for different Fedora editions, e.g. container
> >>and cloud images include the fallback DNS servers list while
> >>workstation (and similar) imag
On Tue, 2021-02-23 at 08:19 -0600, Michael Catanzaro wrote:
> On Tue, Feb 23, 2021 at 10:37 am, Tadej Janež wrote:
> > I guess this is a simple solution that would work, but from what I
> > understand it would also disable the use of systemd-resolved?
>
> Nah, it should just switch systemd-resolv
On Tue, Feb 23, 2021 at 9:20 AM Michael Catanzaro wrote:
>
> On Tue, Feb 23, 2021 at 11:18 am, Petr Menšík
> wrote:
> > Who uses cloud-init to prepare containers? Is it end user on his
> > system?
>
> cloud-init is designed for VPS systems. I don't think it's expected to
> be used in containers.
On Tue, Feb 23, 2021 at 11:18 am, Petr Menšík
wrote:
Who uses cloud-init to prepare containers? Is it end user on his
system?
cloud-init is designed for VPS systems. I don't think it's expected to
be used in containers. I'm sympathetic to your view that running
systemd-resolved in containers
On Tue, Feb 23, 2021 at 10:37 am, Tadej Janež wrote:
I guess this is a simple solution that would work, but from what I
understand it would also disable the use of systemd-resolved?
Nah, it should just switch systemd-resolved into a consumer mode, where
it reads configuration from /etc/resolv
On Mo, 22.02.21 09:45, Michael Catanzaro (mcatanz...@gnome.org) wrote:
65;6201;1c
> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote:
> > 3) Configure DNS resolvers if you want to use DNS.
> > Or dig deeper: why cloud-init disabled DNS on your installation?
>
> I'm pretty sure cloud-init just
Am 22.02.21 um 11:17 schrieb Zbigniew Jędrzejewski-Szmek:
1) Use different defaults for different Fedora editions, e.g. container
and cloud images include the fallback DNS servers list while
workstation (and similar) images don't.
Yes, I think this would be the way to go.
Everything, that is not
On Tue, 2021-02-23 at 11:18 +0100, Petr Menšík wrote:
> Sure, this part is more complex. But only this part can fix this
> problem
> from inside the container IMO. Ie. we could fix it faster for any
> involved parties.
>
> I don't really run any container on any cloud service so this is just
> my
Hi Tadej,
thanks for confirmation.
On 2/23/21 10:37 AM, Tadej Janež wrote:
> Petr,
>
> thanks for looking into this.
>
> On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote:
>> After a quick glance at cloud-init code, it seems to me it does not
>> check /etc/resolv.conf for symlinks.
>>
>> It
Petr,
thanks for looking into this.
On Mon, 2021-02-22 at 18:30 +0100, Petr Menšík wrote:
> After a quick glance at cloud-init code, it seems to me it does not
> check /etc/resolv.conf for symlinks.
>
> It just reads /etc/resolv.conf if it is a file, then writes its own
> nameservers into target
Tadej Janež wrote:
> I would argue that the change causes noticeable problems and we want to
> reconsider this change.
> In particular, I think cloud image users would prefer to have their
> cloud instances usable out of the box, i.e. have DNS working out-of-the
> box.
>
> Don't get me wrong, I un
On Mon, 2021-02-22 at 11:14 -0600, Michael Catanzaro wrote:
> On Mon, Feb 22, 2021 at 5:46 pm, Tomasz Torcz
> wrote:
> > But "dns = none" seems wrong.
>
> Well it would be the right choice if cloud-init were to manually
> configure a static list of DNS servers in /etc/systemd/resolved.conf
> (
On Mon, 2021-02-22 at 09:45 -0600, Michael Catanzaro wrote:
> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz
> wrote:
> > 3) Configure DNS resolvers if you want to use DNS.
> > Or dig deeper: why cloud-init disabled DNS on your installation?
>
> I'm pretty sure cloud-init just doesn't know how to
After a quick glance at cloud-init code, it seems to me it does not
check /etc/resolv.conf for symlinks.
It just reads /etc/resolv.conf if it is a file, then writes its own
nameservers into target. I have seen no rm of original /etc/resolv.conf,
so I guess it rewritten target of symlink on Fedora
On Mon, Feb 22, 2021 at 5:46 pm, Tomasz Torcz
wrote:
But "dns = none" seems wrong.
Well it would be the right choice if cloud-init were to manually
configure a static list of DNS servers in /etc/systemd/resolved.conf
(or, previously, /etc/resolv.conf), which is probably what you want for
a
Dnia Mon, Feb 22, 2021 at 09:45:58AM -0600, Michael Catanzaro napisał(a):
> On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote:
> > 3) Configure DNS resolvers if you want to use DNS.
> > Or dig deeper: why cloud-init disabled DNS on your installation?
>
> I'm pretty sure cloud-init just doesn't
On Mon, Feb 22, 2021 at 10:57 am, David Both
wrote:
do not think this is a cloud-init problem. None of my hosts are in
any cloud
and most failed to resolve after upgrade to F33. Only after reverting
to nss
resolver by disabling systemd-resolved did the problem disappear.
Hi David, your issu
Janež
Subject: Re: systemd-resolved fallback DNS servers: usability vs. GDPR
On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz wrote:
3) Configure DNS resolvers if you want to use DNS.
Or dig deeper: why cloud-init disabled DNS on your installation?
I'm pretty sure cloud-init just doesn&#
On Mon, Feb 22, 2021 at 12:05 pm, Tomasz Torcz
wrote:
3) Configure DNS resolvers if you want to use DNS.
Or dig deeper: why cloud-init disabled DNS on your installation?
I'm pretty sure cloud-init just doesn't know how to configure
systemd-resolved at all. So I suspect this is a cloud-init bu
On 2/22/21 11:17 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež wrote:
>> Hi,
>>
>> I would like to question the decision that was made by systemd
>> maintainers to remove the fallback DNS server list:
>> https://src.fedoraproject.org/rpms/systemd/c
Dnia Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež napisał(a):
> Hi,
>
> I would like to question the decision that was made by systemd
> maintainers to remove the fallback DNS server list:
> https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d
>
> And then b
Hi Tadej,
I think more effort should be put to configure the instance correctly by
provider. No default should save invalid configuration of container host.
I think there is actually little benefit in systemd-resolved usage in a
container. I would guess the container host would run proper dns cac
On Mon, Feb 22, 2021 at 10:58:09AM +0100, Tadej Janež wrote:
> Hi,
>
> I would like to question the decision that was made by systemd
> maintainers to remove the fallback DNS server list:
> https://src.fedoraproject.org/rpms/systemd/c/14b2fafb3688a4170a9c15235d1c3feb7ddeaf9d
>
> And then backport
55 matches
Mail list logo
