6:38 p.m.
Hi All,
If you are tired of all the bugs and Micky Mouse
surrounding /etc/resolv.conf, here is how to make
your own that Micky can't alter:
-T
How to make your own permanent entries in /etc/resolv.conf
1) remove resolvconf and systemd-resolved
# dnf remove resolvconf systemd-resolved
2) /etc/resolv.conf is a link:
# readlink /etc/resolv.conf.000
../run/NetworkManager/resolv.conf
Rename it:
# mv /etc/resolv.conf /etc/resolv.conf.000
3) create your own resolv.conf file
# vi /etc/resolv.conf.rn
For example:
# alternate resolv.conf to get around FC37 micky mouse
#
# nameserver 8.8.8.8
# nameserver 208.67.222.123
# nameserver 127.0.0.1
nameserver 192.168.250.10
options edns0 trust-ad
# search .
6:54 p.m.
On Sat, 17 Dec 2022 16:38:43 -0800
ToddAndMargo via users wrote:
3) create your own resolv.conf file
Not good enough. In the /etc/NetworkManager/NetworkManager.conf
file under the "[main]" section add a line like so:
[main]
dns=none
Otherwise a DHCP lease renewal will replace resolv.conf yet again.
7:04 p.m.
On 12/17/22 16:54, Tom Horsley wrote:
On Sat, 17 Dec 2022 16:38:43 -0800
ToddAndMargo via users wrote:
> 3) create your own resolv.conf file
Not good enough. In the /etc/NetworkManager/NetworkManager.conf
file under the "[main]" section add a line like so:
[main]
dns=none
Otherwise a DHCP lease renewal will replace resolv.conf yet again.
Good luck with that!
The file that DHCP lease renewal alters is not
/etc/names.conf, but /run/NetworkManager/resolv.conf.
Named.conf is a link to it.
So in my tip, what see is /etc/named.conf.000 getting
updated.
Micky and friends can't find my stuff! Raspberries!!!
Maybe when Fedora fixes Micky and Friends, I
will alter it back.
7:30 p.m.
Add a chattr +i /etc/resolv.conf as the last step to be save. You will
have to -i it if you want to change the file later.
On Sat, Dec 17, 2022 at 7:05 PM ToddAndMargo via users <
users(a)lists.fedoraproject.org> wrote:
On 12/17/22 16:54, Tom Horsley wrote:
> On Sat, 17 Dec 2022 16:38:43 -0800
> ToddAndMargo via users wrote:
>
>> 3) create your own resolv.conf file
>
> Not good enough. In the /etc/NetworkManager/NetworkManager.conf
> file under the "[main]" section add a line like so:
>
> [main]
> dns=none
>
> Otherwise a DHCP lease renewal will replace resolv.conf yet again.
Good luck with that!
The file that DHCP lease renewal alters is not
/etc/names.conf, but /run/NetworkManager/resolv.conf.
Named.conf is a link to it.
So in my tip, what see is /etc/named.conf.000 getting
updated.
Micky and friends can't find my stuff! Raspberries!!!
Maybe when Fedora fixes Micky and Friends, I
will alter it back.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
7:39 p.m.
On 12/17/22 17:30, Roger Heflin wrote:
Add a chattr +i /etc/resolv.conf as the last step to be save. You
will
have to -i it if you want to change the file later.
I tried that. I does not work on a link.
I threw that on the source file it links to.
Micky and Friends found a way around it.
Micky and Friends was a new feature of
FC37. FC36 worked fine
8:11 p.m.
On Sat, 17 Dec 2022 19:30:32 -0600
Roger Heflin wrote:
Add a chattr +i /etc/resolv.conf as the last step to be save. You
will
have to -i it if you want to change the file later.
That may work on Fedora, but the last time I tried it on Ubuntu, the system
refused to boot past trying to initialize the network :-(.
8:24 p.m.
You have to love developers erroring out on boot because they cannot update
resolv.conf.
I have written enough code to evaluate errors and report minor errors and
not give up. If you give up on all errors the system is not going to be
very robust.
On Sat, Dec 17, 2022 at 8:13 PM Tom Horsley <horsley1953(a)gmail.com> wrote:
On Sat, 17 Dec 2022 19:30:32 -0600
Roger Heflin wrote:
> Add a chattr +i /etc/resolv.conf as the last step to be save. You will
> have to -i it if you want to change the file later.
That may work on Fedora, but the last time I tried it on Ubuntu, the system
refused to boot past trying to initialize the network :-(.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
7:34 p.m.
Tom Horsley composed on 2022-12-17 19:54 (UTC-0500):
On Sat, 17 Dec 2022 16:38:43 -0800 ToddAndMargo wrote:
> 3) create your own resolv.conf file
Not good enough. In the /etc/NetworkManager/NetworkManager.conf
file under the "[main]" section add a line like so:
[main]
dns=none
Otherwise a DHCP lease renewal will replace resolv.conf yet again.
Not when you don't have networkmangler installed. All my current Fedora
installations have been migrated to using systemd-network. They don't need
"managing".
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
8:44 p.m.
New subject: configuring systemd-networkd (was: Tip: how to make your own
resolv.conf)
ToddAndMargo via users composed on 2022-12-17 17:40 (UTC-0800):
Felix Miata wrote:
> All my current Fedora
> installations have been migrated to using systemd-network. They don't need
"managing".
Details please!
Largely copied from:
<https://lists.opensuse.org/archives/list/support@lists.opensuse.org/messa...
Static IPs don't need managing. Disable or uninstall networkmangler and install
systemd-network if not aready installed, then enable systemd-networkd:
# inxi -S
System:
Host: big41 Kernel: 6.0.13-300.fc37.x86_64 arch: x86_64 bits: 64
Console: pty pts/0 Distro: Fedora release 37 (Thirty Seven)
# systemctl list-unit-files | grep -Ei 'net|solv'
dbus-org.freedesktop.network1.service alias -
netconsole.service disabled disabled
network.service generated -
systemd-network-generator.service enabled enabled
systemd-networkd-wait-online.service masked disabled
systemd-networkd-wait-online@.service disabled disabled
systemd-networkd.service enabled disabled
systemd-resolved.service masked enabled
systemd-networkd.socket enabled disabled
network-online.target static -
network-pre.target static -
network.target static -
Configuration is in /etc/systemd/network/<NIC>.network:
# cat /etc/systemd/network/eth0.network
[Match]
Name=eth0
[Network]
Address=192.168.nnn.qqq/24
DNS=192.168.nnn.mmm 1.1.1.1 1.0.0.1
Gateway=192.168.nnn.mmm
IPv6AcceptRA=no
LinkLocalAddressing=no
# inxi -naz
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: Biostar Microtech Intl Corp driver: r8169 v: kernel pcie: gen: 1
speed: 2.5 GT/s lanes: 1 port: d800 bus-ID: 01:00.0 chip-ID: 10ec:8168
class-ID: 0200
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: <filter>
Make /etc/resolv.conf a regular file and disable whatever is doing your
resolv "management".
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
9:24 p.m.
On Sat, 2022-12-17 at 16:38 -0800, ToddAndMargo via users wrote:
If you are tired of all the bugs and Micky Mouse
surrounding /etc/resolv.conf, here is how to make
your own that Micky can't alter:
What I don't get is *why* it does this interference when you've either
manually configured your network settings on your PC, or you
specifically configure your DHCP server to configure your client the
way you want. What good can come of doing unexpected things to a
network configuration?
--
uname -rsvp
Linux 3.10.0-1160.80.1.el7.x86_64 #1 SMP Tue Nov 8 15:48:59 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
2:24 a.m.
On 12/17/22 19:24, Tim via users wrote:
On Sat, 2022-12-17 at 16:38 -0800, ToddAndMargo via users wrote:
> If you are tired of all the bugs and Micky Mouse
> surrounding /etc/resolv.conf, here is how to make
> your own that Micky can't alter:
What I don't get is *why* it does this interference when you've either
manually configured your network settings on your PC, or you
specifically configure your DHCP server to configure your client the
way you want. What good can come of doing unexpected things to a
network configuration?
I do not know what FC37 did.
By the way, I have two network cards.
The Internet facing was using dhclient to get
an IP from my router's dhcp server. I have now
switched it to fixed IP.
My other network card has a DHCP server connected
to an internal DDNS server on it to to service
the comptuers on the internal side of the network.
Both cards are connected through iptables.
What ever helpful tools FC37 installed or updated
did not realize the comlexitiy of the network
and made things a nightmare for me.
3:19 p.m.
On 18 Dec 2022, at 08:25, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
On 12/17/22 19:24, Tim via users wrote:
>> On Sat, 2022-12-17 at 16:38 -0800, ToddAndMargo via users wrote:
>> If you are tired of all the bugs and Micky Mouse
>> surrounding /etc/resolv.conf, here is how to make
>> your own that Micky can't alter:
> What I don't get is *why* it does this interference when you've either
> manually configured your network settings on your PC, or you
> specifically configure your DHCP server to configure your client the
> way you want. What good can come of doing unexpected things to a
> network configuration?
I do not know what FC37 did.
By the way, I have two network cards.
The Internet facing was using dhclient to get
an IP from my router's dhcp server. I have now
switched it to fixed IP.
My other network card has a DHCP server connected
to an internal DDNS server on it to to service
the comptuers on the internal side of the network.
Both cards are connected through iptables.
That like my router config. Except I use systemd-networkd not networkmanager.
Its been stable over lots of fedora releases.
Barry
What ever helpful tools FC37 installed or updated
did not realize the comlexitiy of the network
and made things a nightmare for me.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
3:27 p.m.
On Sun, 18 Dec 2022 21:19:02 +0000
Barry wrote:
That like my router config. Except I use systemd-networkd not
networkmanager.
Its been stable over lots of fedora releases.
Right up till the release when they decide to eradicate it
because everyone must use NetworkManager :-).
That's why I gave up and figured out how to beat NetworkManager
into submission sicne I figured I'd be forced to use it in the
not too distant future.
3:42 p.m.
Tom Horsley composed on 2022-12-18 16:27 (UTC-0500):
On Sun, 18 Dec 2022 21:19:02 +0000 Barry wrote:
> That like my router config. Except I use systemd-networkd not
networkmanager.
> Its been stable over lots of fedora releases.
Right up till the release when they decide to eradicate it
because everyone must use NetworkManager :-).
Eradicate an easy-to-use component of systemd from systemd's flagship distro?
Heresy!!!
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata
5:37 p.m.
On 12/18/22 13:42, Felix Miata wrote:
Tom Horsley composed on 2022-12-18 16:27 (UTC-0500):
> On Sun, 18 Dec 2022 21:19:02 +0000 Barry wrote:
>> That like my router config. Except I use systemd-networkd not networkmanager.
>> Its been stable over lots of fedora releases.
> Right up till the release when they decide to eradicate it
> because everyone must use NetworkManager :-).
Eradicate an easy-to-use component of systemd from systemd's flagship distro?
Heresy!!!
No fooling!
11:57 a.m.
On 18 Dec 2022, at 21:28, Tom Horsley <horsley1953(a)gmail.com>
wrote:
On Sun, 18 Dec 2022 21:19:02 +0000
Barry wrote:
> That like my router config. Except I use systemd-networkd not networkmanager.
> Its been stable over lots of fedora releases.
Right up till the release when they decide to eradicate it
because everyone must use NetworkManager :-).
I remove network manager years ago and it has not come back in f37.
I do see NetworkManager-libnm that is a dep of lots of stuff so that cannot be removed.
But all my interfaces are .network units in /etc/systemd/network
That's why I gave up and figured out how to beat NetworkManager
into submission sicne I figured I'd be forced to use it in the
not too distant future.
No you are not forced to use it.
Barry
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
1:49 p.m.
On 12/19/22 09:57, Barry wrote:
> On 18 Dec 2022, at 21:28, Tom Horsley <horsley1953(a)gmail.com> wrote:
>
> On Sun, 18 Dec 2022 21:19:02 +0000
> Barry wrote:
>
>> That like my router config. Except I use systemd-networkd not networkmanager.
>> Its been stable over lots of fedora releases.
>
> Right up till the release when they decide to eradicate it
> because everyone must use NetworkManager :-).
I remove network manager years ago and it has not come back in f37.
I do see NetworkManager-libnm that is a dep of lots of stuff so that cannot be removed.
But all my interfaces are .network units in /etc/systemd/network
>
> That's why I gave up and figured out how to beat NetworkManager
> into submission sicne I figured I'd be forced to use it in the
> not too distant future.
No you are not forced to use it.
Barry
I have all my network configured in
/etc/sysconfig/network-scripts/
which is probably were most of the issue lies
2:07 p.m.
On Mon, 19 Dec 2022 11:49:26 -0800
ToddAndMargo via users wrote:
I have all my network configured in
/etc/sysconfig/network-scripts/
which is probably were most of the issue lies
Those ifcfg files aren't even supported in a fresh install
of fedora these days. As attempting to avoid NetworkManager
is a hopeless task, I converted all my ifcfg files to keyfiles
and it seemed to work OK.
https://fedoramagazine.org/converting-networkmanager-from-ifcfg-to-keyfiles/
It took a long time to define all my network stuff correctly,
and I found I could only do it with the nmcli command because
the GUI provided is utterly useless. It leaves buttons I want to
push disabled, and won't tell you why they are disabled.
2:12 p.m.
On 12/19/22 12:07, Tom Horsley wrote:
It took a long time to define all my network stuff correctly,
and I found I could only do it with the nmcli command because
the GUI provided is utterly useless. It leaves buttons I want to
push disabled, and won't tell you why they are disabled.
Which gui are you using? I use nm-connection-editor and have had no
issues with any network types I've setup. Which buttons are you finding
disabled?
2:45 p.m.
On Mon, 19 Dec 2022 12:12:44 -0800
Samuel Sieb wrote:
Which gui are you using? I use nm-connection-editor and have had no
issues with any network types I've setup. Which buttons are you finding
disabled?
That's the gui I was using. According to my old notes I could
never figure out how to create a bridge with no attached physical
interface. These commands did what I wanted, but nothing I tried
with the connection editor would work:
nmcli con add ifname bifrost type bridge con-name bifrost
nmcli con modify bifrost bridge.stp no
nmcli con modify bifrost ipv4.method manual
nmcli con modify bifrost ipv4.address 192.168.2.99/24
nmcli con modify bifrost ipv4.gateway 192.168.2.1
nmcli con modify bifrost ipv4.never-default true
Don't remember specifically what it wouldn't let me do, but I
remember thinking it would be a hell of a lot more useful if
instead of disabling controls, it left them enabled and popped
up an error saying why it won't work.
3:34 p.m.
On 12/19/22 12:45, Tom Horsley wrote:
On Mon, 19 Dec 2022 12:12:44 -0800
Samuel Sieb wrote:
> Which gui are you using? I use nm-connection-editor and have had no
> issues with any network types I've setup. Which buttons are you finding
> disabled?
That's the gui I was using. According to my old notes I could
never figure out how to create a bridge with no attached physical
interface. These commands did what I wanted, but nothing I tried
with the connection editor would work:
nmcli con add ifname bifrost type bridge con-name bifrost
nmcli con modify bifrost bridge.stp no
nmcli con modify bifrost ipv4.method manual
nmcli con modify bifrost ipv4.address 192.168.2.99/24
nmcli con modify bifrost ipv4.gateway 192.168.2.1
nmcli con modify bifrost ipv4.never-default true
Don't remember specifically what it wouldn't let me do, but I
remember thinking it would be a hell of a lot more useful if
instead of disabling controls, it left them enabled and popped
up an error saying why it won't work.
Maybe it's time to try again. I just tested it. I clicked new bridge
and it let me save with the default settings which includes no
interfaces added. I also tried with your settings and there was no problem.
3:49 p.m.
On 19 Dec 2022, at 19:50, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
On 12/19/22 09:57, Barry wrote:
>>> On 18 Dec 2022, at 21:28, Tom Horsley <horsley1953(a)gmail.com> wrote:
>>
>> On Sun, 18 Dec 2022 21:19:02 +0000
>> Barry wrote:
>>
>>> That like my router config. Except I use systemd-networkd not
networkmanager.
>>> Its been stable over lots of fedora releases.
>>
>> Right up till the release when they decide to eradicate it
>> because everyone must use NetworkManager :-).
> I remove network manager years ago and it has not come back in f37.
> I do see NetworkManager-libnm that is a dep of lots of stuff so that cannot be
removed.
> But all my interfaces are .network units in /etc/systemd/network
>>
>> That's why I gave up and figured out how to beat NetworkManager
>> into submission sicne I figured I'd be forced to use it in the
>> not too distant future.
> No you are not forced to use it.
> Barry
I have all my network configured in
/etc/sysconfig/network-scripts/
which is probably were most of the issue lies
That has been legacy for a while now. And you suspect you are right it is the source of
your trouble.
You need to either use systemd-networkd or native NetworkManager config to replace the
legacy setup. Both support your multi interface setup.
Maybe f37 shipped something that dropped/broke some of the legacy support?
Barry
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
3:53 p.m.
On 12/19/22 13:49, Barry wrote:
> On 19 Dec 2022, at 19:50, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 12/19/22 09:57, Barry wrote:
>>>> On 18 Dec 2022, at 21:28, Tom Horsley <horsley1953(a)gmail.com>
wrote:
>>>
>>> On Sun, 18 Dec 2022 21:19:02 +0000
>>> Barry wrote:
>>>
>>>> That like my router config. Except I use systemd-networkd not
networkmanager.
>>>> Its been stable over lots of fedora releases.
>>>
>>> Right up till the release when they decide to eradicate it
>>> because everyone must use NetworkManager :-).
>> I remove network manager years ago and it has not come back in f37.
>> I do see NetworkManager-libnm that is a dep of lots of stuff so that cannot be
removed.
>> But all my interfaces are .network units in /etc/systemd/network
>>>
>>> That's why I gave up and figured out how to beat NetworkManager
>>> into submission sicne I figured I'd be forced to use it in the
>>> not too distant future.
>> No you are not forced to use it.
>> Barry
>
> I have all my network configured in
> /etc/sysconfig/network-scripts/
> which is probably were most of the issue lies
That has been legacy for a while now. And you suspect you are right it is the source of
your trouble.
You need to either use systemd-networkd or native NetworkManager config to replace the
legacy setup. Both support your multi interface setup.
Maybe f37 shipped something that dropped/broke some of the legacy support?
My systems are using a combination of legacy and new configs with no
problems.
4:01 p.m.
On Mon, 19 Dec 2022 13:53:13 -0800
Samuel Sieb wrote:
My systems are using a combination of legacy and new configs with no
problems.
If you install f37 from scratch, you have to install
NetworkManager-initscripts-ifcfg-rh.x86_64
to get NetworkManager to pay any attention to the old
style ifcfg files. Or run
nmcli connection migrate
to move all the ifcfg files to "keyfiles".
I did break down and do the migrate and it seemed to work. I didn't
have to tweak anything.
6:05 p.m.
On 12/19/22 14:01, Tom Horsley wrote:
On Mon, 19 Dec 2022 13:53:13 -0800
Samuel Sieb wrote:
> My systems are using a combination of legacy and new configs with no
> problems.
If you install f37 from scratch, you have to install
NetworkManager-initscripts-ifcfg-rh.x86_64
to get NetworkManager to pay any attention to the old
style ifcfg files. Or run
nmcli connection migrate
to move all the ifcfg files to "keyfiles".
Oh, nice! They did implement something for that.
6:14 p.m.
On Mon, 19 Dec 2022 16:05:38 -0800
Samuel Sieb wrote:
> nmcli connection migrate
>
> to move all the ifcfg files to "keyfiles".
Oh, nice! They did implement something for that.
I waited one release cycle to try it in the hopes that
any possible bugs might be resolved by then. Worked OK for
me.
7:11 p.m.
On 12/19/22 14:01, Tom Horsley wrote:
On Mon, 19 Dec 2022 13:53:13 -0800
Samuel Sieb wrote:
> My systems are using a combination of legacy and new configs with no
> problems.
If you install f37 from scratch, you have to install
NetworkManager-initscripts-ifcfg-rh.x86_64
to get NetworkManager to pay any attention to the old
style ifcfg files. Or run
nmcli connection migrate
to move all the ifcfg files to "keyfiles".
I did break down and do the migrate and it seemed to work. I didn't
have to tweak anything.
Awesome! Thank you!
4:32 p.m.
On 12/19/22 13:49, Barry wrote:
> On 19 Dec 2022, at 19:50, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 12/19/22 09:57, Barry wrote:
>>>> On 18 Dec 2022, at 21:28, Tom Horsley <horsley1953(a)gmail.com>
wrote:
>>>
>>> On Sun, 18 Dec 2022 21:19:02 +0000
>>> Barry wrote:
>>>
>>>> That like my router config. Except I use systemd-networkd not
networkmanager.
>>>> Its been stable over lots of fedora releases.
>>>
>>> Right up till the release when they decide to eradicate it
>>> because everyone must use NetworkManager :-).
>> I remove network manager years ago and it has not come back in f37.
>> I do see NetworkManager-libnm that is a dep of lots of stuff so that cannot be
removed.
>> But all my interfaces are .network units in /etc/systemd/network
>>>
>>> That's why I gave up and figured out how to beat NetworkManager
>>> into submission sicne I figured I'd be forced to use it in the
>>> not too distant future.
>> No you are not forced to use it.
>> Barry
>
> I have all my network configured in
> /etc/sysconfig/network-scripts/
> which is probably were most of the issue lies
That has been legacy for a while now. And you suspect you are right it is the source of
your trouble.
You need to either use systemd-networkd or native NetworkManager config to replace the
legacy setup. Both support your multi interface setup.
Maybe f37 shipped something that dropped/broke some of the legacy support?
It is obviously reading something from those files, but goofs up on
others, such as the DNS
Barry
>
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computers are like air conditioners.
They malfunction when you open windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4:03 a.m.
Am 18.12.2022 um 09:24 schrieb ToddAndMargo via users
<users(a)lists.fedoraproject.org>:
> On Sat, 2022-12-17 at 16:38 -0800, ToddAndMargo via users wrote:
>> If you are tired of all the bugs and Micky Mouse
>> surrounding /etc/resolv.conf, here is how to make
>> your own that Micky can't alter:
I do not know what FC37 did.
By the way, I have two network cards.
The Internet facing was using dhclient to get
an IP from my router's dhcp server. I have now
switched it to fixed IP.
My other network card has a DHCP server connected
to an internal DDNS server on it to to service
the comptuers on the internal side of the network.
Both cards are connected through iptables.
What ever helpful tools FC37 installed or updated
did not realize the comlexitiy of the network
and made things a nightmare for me.
I really hope that nobody takes the subject line literally. This thread contains so much
of terminological incorrectness, technical errors and shows in large parts such a lack of
understanding of basic technical concepts, that is breathtaking. And various attempts to
correct the errors were ignored further on - for whatever reason.
Please, everyone who has issues with their network connection, better ignore this kind of
advise completely! Do not ruin your system.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
pboy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora docs team contributor and board member
Java developer and enthusiast
1:51 p.m.
On 12/19/22 02:03, Peter Boy wrote:
> Am 18.12.2022 um 09:24 schrieb ToddAndMargo via users
<users(a)lists.fedoraproject.org>:
>
>
>> On Sat, 2022-12-17 at 16:38 -0800, ToddAndMargo via users wrote:
>>> If you are tired of all the bugs and Micky Mouse
>>> surrounding /etc/resolv.conf, here is how to make
>>> your own that Micky can't alter:
>
>
> I do not know what FC37 did.
>
> By the way, I have two network cards.
>
> The Internet facing was using dhclient to get
> an IP from my router's dhcp server. I have now
> switched it to fixed IP.
>
> My other network card has a DHCP server connected
> to an internal DDNS server on it to to service
> the comptuers on the internal side of the network.
>
> Both cards are connected through iptables.
>
> What ever helpful tools FC37 installed or updated
> did not realize the comlexitiy of the network
> and made things a nightmare for me.
>
I really hope that nobody takes the subject line literally. This thread contains so much
of terminological incorrectness, technical errors and shows in large parts such a lack of
understanding of basic technical concepts, that is breathtaking. And various attempts to
correct the errors were ignored further on - for whatever reason.
Why don't you post the proper terminology?
Please, everyone who has issues with their network connection, better ignore this kind of
advise completely! Do not ruin your system.
My system was already ruined. The tip I posted fixed it.
And Yes, only use my tip if your system is already ruined,
as mine was.
8:22 a.m.
From what I can tell they developers expect everyone to do the config in
exactly one way.
If you do the config differently (ie the old way, and if dns is not
configured/defined I assume from dhcp and/or directly in the Network
manager config), then the software rewrites the file with a valid entry in
it, to have no entry.
Developers seem to ignore backward compatibility and/or supporting how
something has been configured since before they were born.
On Sat, Dec 17, 2022 at 9:24 PM Tim via users <users(a)lists.fedoraproject.org>
wrote:
On Sat, 2022-12-17 at 16:38 -0800, ToddAndMargo via users wrote:
> If you are tired of all the bugs and Micky Mouse
> surrounding /etc/resolv.conf, here is how to make
> your own that Micky can't alter:
What I don't get is *why* it does this interference when you've either
manually configured your network settings on your PC, or you
specifically configure your DHCP server to configure your client the
way you want. What good can come of doing unexpected things to a
network configuration?
--
uname -rsvp
Linux 3.10.0-1160.80.1.el7.x86_64 #1 SMP Tue Nov 8 15:48:59 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
5:34 p.m.
On 12/18/22 06:22, Roger Heflin wrote:
From what I can tell they developers expect everyone to do the
config
in exactly one way.
If you do the config differently (ie the old way, and if dns is not
configured/defined I assume from dhcp and/or directly in the Network
manager config), then the software rewrites the file with a valid entry
in it, to have no entry.
Developers seem to ignore backward compatibility and/or supporting how
something has been configured since before they were born.
After powering down last night and powering up again
this morning, it was awfully nice to have everything
working correctly.
Chuckle. All is took was giving the developers a
"doggy chew toy" (fake resolv.conf) to distract
them from messing up my networking and all suddenly
worked.
The must think everyone only has one network card.
Fedora Server folks must be crying blood.
7:10 p.m.
On 12/18/22 15:34, ToddAndMargo via users wrote:
Chuckle. All is took was giving the developers a
"doggy chew toy" (fake resolv.conf) to distract
them from messing up my networking and all suddenly
worked.
Clearly you missed the documentation that that's how to do it.
The must think everyone only has one network card.
Fedora Server folks must be crying blood.
No, it's specifically designed for multiple interfaces.
e.g. at work I have split-DNS so requests for a particular domain go
over the VPN that provides the connection to that network.
7:57 p.m.
On 12/18/22 17:10, Samuel Sieb wrote:
On 12/18/22 15:34, ToddAndMargo via users wrote:
> Chuckle. All is took was giving the developers a
> "doggy chew toy" (fake resolv.conf) to distract
> them from messing up my networking and all suddenly
> worked.
Clearly you missed the documentation that that's how to do it.
> The must think everyone only has one network card.
> Fedora Server folks must be crying blood.
No, it's specifically designed for multiple interfaces.
e.g. at work I have split-DNS so requests for a particular domain go
over the VPN that provides the connection to that network.
They did a really, really bad job of it.
8 p.m.
On 12/18/22 17:57, ToddAndMargo via users wrote:
On 12/18/22 17:10, Samuel Sieb wrote:
> On 12/18/22 15:34, ToddAndMargo via users wrote:
>> Chuckle. All is took was giving the developers a
>> "doggy chew toy" (fake resolv.conf) to distract
>> them from messing up my networking and all suddenly
>> worked.
>
> Clearly you missed the documentation that that's how to do it.
>
>> The must think everyone only has one network card.
>> Fedora Server folks must be crying blood.
>
> No, it's specifically designed for multiple interfaces.
> e.g. at work I have split-DNS so requests for a particular domain go
> over the VPN that provides the connection to that network.
They did a really, really bad job of it.
Well, you're welcome to your opinion. But it's clearly working for most
people.
12:37 a.m.
On 12/18/22 18:00, Samuel Sieb wrote:
On 12/18/22 17:57, ToddAndMargo via users wrote:
> On 12/18/22 17:10, Samuel Sieb wrote:
>> On 12/18/22 15:34, ToddAndMargo via users wrote:
>>> Chuckle. All is took was giving the developers a
>>> "doggy chew toy" (fake resolv.conf) to distract
>>> them from messing up my networking and all suddenly
>>> worked.
>>
>> Clearly you missed the documentation that that's how to do it.
>>
>>> The must think everyone only has one network card.
>>> Fedora Server folks must be crying blood.
>>
>> No, it's specifically designed for multiple interfaces.
>> e.g. at work I have split-DNS so requests for a particular domain go
>> over the VPN that provides the connection to that network.
>
> They did a really, really bad job of it.
Well, you're welcome to your opinion. But it's clearly working for most
people.
I am also welcome to my experience too.
Do those other people have FIVE network
interfaces (two physical) and an option
for another sixth virtual interface?
You saw how it fell apart when it put different
DNS servers on different interfaces and that
did not match resolv.conf? And how I kept
over riding my manual configurations.
This hurt me more than a Windows upgrade.
I use Linux to avoid that kind of nonsense.
1:08 a.m.
On 12/18/22 22:37, ToddAndMargo via users wrote:
On 12/18/22 18:00, Samuel Sieb wrote:
> On 12/18/22 17:57, ToddAndMargo via users wrote:
>> On 12/18/22 17:10, Samuel Sieb wrote:
>>> On 12/18/22 15:34, ToddAndMargo via users wrote:
>>>> Chuckle. All is took was giving the developers a
>>>> "doggy chew toy" (fake resolv.conf) to distract
>>>> them from messing up my networking and all suddenly
>>>> worked.
>>>
>>> Clearly you missed the documentation that that's how to do it.
>>>
>>>> The must think everyone only has one network card.
>>>> Fedora Server folks must be crying blood.
>>>
>>> No, it's specifically designed for multiple interfaces.
>>> e.g. at work I have split-DNS so requests for a particular domain go
>>> over the VPN that provides the connection to that network.
>>
>> They did a really, really bad job of it.
>
> Well, you're welcome to your opinion. But it's clearly working for
> most people.
I am also welcome to my experience too.
Do those other people have FIVE network
interfaces (two physical) and an option
for another sixth virtual interface?
Do you really want to do this? :-)
I don't know about "those" people, but one server of mine has 12
interfaces including physical, vlans, vpns, and VMs and I have no
problems with it using only NetworkManager. I did override the
resolv.conf on that one with no problems because of some issue with
resolving at boot, probably related to the DNS server being in a VM that
wasn't up yet. Another server has 10 interfaces, but it still has the
default systemd-resolved config and is working fine and it has a similar
freeipa VM for DNS.
1:47 p.m.
On 12/18/22 23:08, Samuel Sieb wrote:
Do you really want to do this? 😄
Yes I do.
I don't know about "those" people, but one server of mine has 12
interfaces including physical, vlans, vpns, and VMs and I have no
problems with it using only NetworkManager. I did override the
resolv.conf on that one with no problems because of some issue with
resolving at boot, probably related to the DNS server being in a VM that
wasn't up yet. Another server has 10 interfaces, but it still has the
default systemd-resolved config and is working fine and it has a similar
freeipa VM for DNS.
You got freaking lucky.
3:01 p.m.
You saw how it fell apart when it put different
DNS servers on different interfaces and that
did not match resolv.conf? And how I kept
over riding my manual configurations.
This hurt me more than a Windows upgrade.
I use Linux to avoid that kind of nonsense.
I'm not sure how that's a good example.
If you are using systemd-resolved, then /etc/resolv.conf should simply have
"nameserver 127.0.0.53" for the nameserver. This is where the OS looks for name
lookups when doing DNS lookups. Then systemd-resolved will have whatever different DNS
servers, defined per interface along with which search paths that should be searched, as
well as priority. That way you can have all your internal names go to one interface
that's on the internal network, a certain name go to the virtual machine interface so
it can manage DNS for local VMs (which libvirtd supports), your work domain goes to your
VPN interface, and the rest go to your external interface for default resolution. If
you're running bind, then you would just need to set the the IP for your installation
as the default name server. For all of this, /etc/resolv.conf should remain using
"nameserver 127.0.0.53".
4:33 p.m.
On 12/19/22 13:01, Jonathan Billings wrote:
> You saw how it fell apart when it put different
> DNS servers on different interfaces and that
> did not match resolv.conf? And how I kept
> over riding my manual configurations.
>
> This hurt me more than a Windows upgrade.
> I use Linux to avoid that kind of nonsense.
I'm not sure how that's a good example.
If you are using systemd-resolved, then /etc/resolv.conf should simply have
"nameserver 127.0.0.53"
It puts it there and things ago foo bar
for the nameserver. This is where the OS looks for name lookups when
doing DNS lookups. Then systemd-resolved will have whatever different DNS servers,
defined per interface along with which search paths that should be searched, as well as
priority. That way you can have all your internal names go to one interface that's on
the internal network, a certain name go to the virtual machine interface so it can manage
DNS for local VMs (which libvirtd supports), your work domain goes to your VPN interface,
and the rest go to your external interface for default resolution. If you're running
bind, then you would just need to set the the IP for your installation as the default name
server. For all of this, /etc/resolv.conf should remain using "nameserver
127.0.0.53".
6:02 p.m.
Jonathan Billings:
> If you are using systemd-resolved, then /etc/resolv.conf should
> simply have "nameserver 127.0.0.53"
ToddAndMargo:
It puts it there and things ago foo bar
There's your new hostname, fubar-a-go-go... ;-)
But being serious, I did start looking through the man files for the
new networking schemes (man systemd-resolved). And supposedly,
/etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf
And when it is, it controls the file its linked to.
If you unlink the file, and edit your /etc/resolv.conf, systemd-
resolved should leave it alone, and you could could manually adjust it.
Of course, something else could, now, edit /etc/resolv.conf.
The DNS server data that comes from the DHCP daemon ends up in
/run/systemd/resolve/resolv.conf (note the different filename), and
systemd-resolved is using that information in conjunction with what it
provides to the traditional /etc/resolve.conf file.
It is all a bit of a maze, and I don't really see how this was an
improvement on the previous methodology.
Likewise with network configuration. If the previous config files
actually did the job, why didn't they keep on using them, and just
update the tools that set them up?
NB: My Fedora 36 installation works as it came out of the box, so to
speak. DHCPD on my CentOS server is configuring the network as
I expect. The F36 does go through its own DNS maze, but is making use
of my BIND DNS server on CentOS. And mDNS does work for the three
other things on my LAN that make use of it. But I'm not using VPNs, or
multi-port networking cards.
But I'd say, start by looking at man systemd-resolved and noodling your
way through the things it mentions in there.
--
uname -rsvp
Linux 3.10.0-1160.80.1.el7.x86_64 #1 SMP Tue Nov 8 15:48:59 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
6:29 p.m.
Once upon a time, Tim <ignored_mailbox(a)yahoo.com.au> said:
But being serious, I did start looking through the man files for the
new networking schemes (man systemd-resolved). And supposedly,
/etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf
And when it is, it controls the file its linked to.
Yeah, if you just edit /etc/resolv.conf without reading it (leaving it a
symlink to /run), your edits will get lost. All you have to do is
remove the symlink and replace it with a file, and systemd-resolved will
stop touching it (again, as documented in the file). It's not some
mystery, or difficult problem to solve, if you read the comments and
referenced documentation.
It is all a bit of a maze, and I don't really see how this was
an
improvement on the previous methodology.
A single system-wide resolv.conf cannot handle more complicated setups,
such as a VPN where lookups for certain domains should be sent to a
server across the VPN. You have to run some form of local DNS server to
handle that (which could be BIND, Unbound, dnsmasq, etc.). Each of
those have their own configuration quirks that can make it more
complicated to programmatically manage, so systemd-resolved was created.
I'm not entirely satisfied with systemd-resolved, but it solves things
for a majority of cases.
Likewise with network configuration. If the previous config files
actually did the job, why didn't they keep on using them, and just
update the tools that set them up?
The previous ifcfg files had many quirks, starting from being created as
shell variable lists to feed to bash scripts for network config. They
were also specific to Red Hat Linux derived OSes (e.g. Fedora, RHEL,
CentOS, etc.). NetworkManager was created to solve multiple things, one
of which was standardizing network configuration across distributions.
The NM plugin to support the RHL-style ifcfg files has been there as a
backwards-compatibility wedge, but it was time to move on from using
that by default (and deprecate the old network-scripts pile of shell
code).
--
Chris Adams <linux(a)cmadams.net>
7:10 p.m.
On 12/19/22 16:29, Chris Adams wrote:
Once upon a time, Tim <ignored_mailbox(a)yahoo.com.au> said:
> But being serious, I did start looking through the man files for the
> new networking schemes (man systemd-resolved). And supposedly,
> /etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf
> And when it is, it controls the file its linked to.
Yeah, if you just edit /etc/resolv.conf without reading it (leaving it a
symlink to /run), your edits will get lost. All you have to do is
remove the symlink and replace it with a file, and systemd-resolved will
stop touching it (again, as documented in the file). It's not some
mystery, or difficult problem to solve, if you read the comments and
referenced documentation.
> It is all a bit of a maze, and I don't really see how this was an
> improvement on the previous methodology.
A single system-wide resolv.conf cannot handle more complicated setups,
such as a VPN where lookups for certain domains should be sent to a
server across the VPN. You have to run some form of local DNS server to
handle that (which could be BIND, Unbound, dnsmasq, etc.). Each of
those have their own configuration quirks that can make it more
complicated to programmatically manage, so systemd-resolved was created.
I have open vpn installed. It communicates through a network bridge and
the old ifcfg files.
I have not used it in a while, as open vpn for Windows
is corked on Windows 10 and 11. I gave up on it.
I did a bug report on it, but they never fixed it.
I'm not entirely satisfied with systemd-resolved, but it solves things
for a majority of cases.
> Likewise with network configuration. If the previous config files
> actually did the job, why didn't they keep on using them, and just
> update the tools that set them up?
The previous ifcfg files had many quirks, starting from being created as
shell variable lists to feed to bash scripts for network config. They
were also specific to Red Hat Linux derived OSes (e.g. Fedora, RHEL,
CentOS, etc.). NetworkManager was created to solve multiple things, one
of which was standardizing network configuration across distributions.
The NM plugin to support the RHL-style ifcfg files has been there as a
backwards-compatibility wedge, but it was time to move on from using
that by default (and deprecate the old network-scripts pile of shell
code).
Maybe some day when I have a ton of time to waste,
I will try to get the official way to work.
7:05 p.m.
On 12/19/22 16:02, Tim via users wrote:
Jonathan Billings:
>> If you are using systemd-resolved, then /etc/resolv.conf should
>> simply have "nameserver 127.0.0.53"
ToddAndMargo:
> It puts it there and things ago foo bar
There's your new hostname, fubar-a-go-go... ;-)
But being serious, I did start looking through the man files for the
new networking schemes (man systemd-resolved). And supposedly,
/etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf
And when it is, it controls the file its linked to.
If you unlink the file, and edit your /etc/resolv.conf, systemd-
resolved should leave it alone, and you could could manually adjust it.
Of course, something else could, now, edit /etc/resolv.conf.
The DNS server data that comes from the DHCP daemon ends up in
/run/systemd/resolve/resolv.conf (note the different filename), and
systemd-resolved is using that information in conjunction with what it
provides to the traditional /etc/resolve.conf file.
It is all a bit of a maze, and I don't really see how this was an
improvement on the previous methodology.
Likewise with network configuration. If the previous config files
actually did the job, why didn't they keep on using them, and just
update the tools that set them up?
NB: My Fedora 36 installation works as it came out of the box, so to
speak. DHCPD on my CentOS server is configuring the network as
I expect. The F36 does go through its own DNS maze, but is making use
of my BIND DNS server on CentOS. And mDNS does work for the three
other things on my LAN that make use of it. But I'm not using VPNs, or
multi-port networking cards.
But I'd say, start by looking at man systemd-resolved and noodling your
way through the things it mentions in there.
I changed the link to point elsewhere. I
did not try unlinking it. I was suspicious that
however was changing things would discover and
recreate it
I guess I am lucky that whoever has not discovered
my shenanigans. Next dnf it probably will. I
will be ready for it.
7:39 p.m.
On 12/19/22 17:05, ToddAndMargo via users wrote:
On 12/19/22 16:02, Tim via users wrote:
> Jonathan Billings:
>>> If you are using systemd-resolved, then /etc/resolv.conf should
>>> simply have "nameserver 127.0.0.53"
>
> ToddAndMargo:
>> It puts it there and things ago foo bar
>
> There's your new hostname, fubar-a-go-go... ;-)
>
> But being serious, I did start looking through the man files for the
> new networking schemes (man systemd-resolved). And supposedly,
> /etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf
> And when it is, it controls the file its linked to.
>
> If you unlink the file, and edit your /etc/resolv.conf, systemd-
> resolved should leave it alone, and you could could manually adjust it.
> Of course, something else could, now, edit /etc/resolv.conf.
>
> The DNS server data that comes from the DHCP daemon ends up in
> /run/systemd/resolve/resolv.conf (note the different filename), and
> systemd-resolved is using that information in conjunction with what it
> provides to the traditional /etc/resolve.conf file.
>
> It is all a bit of a maze, and I don't really see how this was an
> improvement on the previous methodology.
>
> Likewise with network configuration. If the previous config files
> actually did the job, why didn't they keep on using them, and just
> update the tools that set them up?
>
> NB: My Fedora 36 installation works as it came out of the box, so to
> speak. DHCPD on my CentOS server is configuring the network as
> I expect. The F36 does go through its own DNS maze, but is making use
> of my BIND DNS server on CentOS. And mDNS does work for the three
> other things on my LAN that make use of it. But I'm not using VPNs, or
> multi-port networking cards.
>
> But I'd say, start by looking at man systemd-resolved and noodling your
> way through the things it mentions in there.
>
I changed the link to point elsewhere. I
did not try unlinking it. I was suspicious that
however was changing things would discover and
recreate it
I guess I am lucky that whoever has not discovered
my shenanigans. Next dnf it probably will. I
will be ready for it.
Maybe you should read the section on /etc/resolv.conf in "man
systemd-resolved".
7:58 p.m.
On 12/19/22 17:39, Samuel Sieb wrote:
On 12/19/22 17:05, ToddAndMargo via users wrote:
> On 12/19/22 16:02, Tim via users wrote:
>> Jonathan Billings:
>>>> If you are using systemd-resolved, then /etc/resolv.conf should
>>>> simply have "nameserver 127.0.0.53"
>>
>> ToddAndMargo:
>>> It puts it there and things ago foo bar
>>
>> There's your new hostname, fubar-a-go-go... ;-)
>>
>> But being serious, I did start looking through the man files for the
>> new networking schemes (man systemd-resolved). And supposedly,
>> /etc/resolv.conf is a link to /run/systemd/resolve/stub-resolv.conf
>> And when it is, it controls the file its linked to.
>>
>> If you unlink the file, and edit your /etc/resolv.conf, systemd-
>> resolved should leave it alone, and you could could manually adjust it.
>> Of course, something else could, now, edit /etc/resolv.conf.
>>
>> The DNS server data that comes from the DHCP daemon ends up in
>> /run/systemd/resolve/resolv.conf (note the different filename), and
>> systemd-resolved is using that information in conjunction with what it
>> provides to the traditional /etc/resolve.conf file.
>>
>> It is all a bit of a maze, and I don't really see how this was an
>> improvement on the previous methodology.
>>
>> Likewise with network configuration. If the previous config files
>> actually did the job, why didn't they keep on using them, and just
>> update the tools that set them up?
>>
>> NB: My Fedora 36 installation works as it came out of the box, so to
>> speak. DHCPD on my CentOS server is configuring the network as
>> I expect. The F36 does go through its own DNS maze, but is making use
>> of my BIND DNS server on CentOS. And mDNS does work for the three
>> other things on my LAN that make use of it. But I'm not using VPNs, or
>> multi-port networking cards.
>>
>> But I'd say, start by looking at man systemd-resolved and noodling your
>> way through the things it mentions in there.
>>
>
>
> I changed the link to point elsewhere. I
> did not try unlinking it. I was suspicious that
> however was changing things would discover and
> recreate it
>
> I guess I am lucky that whoever has not discovered
> my shenanigans. Next dnf it probably will. I
> will be ready for it.
Maybe you should read the section on /etc/resolv.conf in "man
systemd-resolved".
I will eventually. I am going to look at
NetworkManager-initscripts-ifcfg-rh.x86_64, and
nmcli connection migrate
Right now I have to get passive ftp working again.
3:54 p.m.
On 12/17/22 16:38, ToddAndMargo via users wrote:
If you are tired of all the bugs and Micky Mouse
surrounding /etc/resolv.conf, here is how to make
your own that Micky can't alter:
Your problem appears to be that you're trying to configure your system
outside of the normal tools to do so. Did you try setting the network
manager config for the interface to use the DNS server you wanted
instead of the one it gets from DHCP?
5:37 p.m.
On 12/18/22 13:54, Samuel Sieb wrote:
On 12/17/22 16:38, ToddAndMargo via users wrote:
> If you are tired of all the bugs and Micky Mouse
> surrounding /etc/resolv.conf, here is how to make
> your own that Micky can't alter:
Your problem appears to be that you're trying to configure your system
outside of the normal tools to do so. Did you try setting the network
manager config for the interface to use the DNS server you wanted
instead of the one it gets from DHCP?
Yup. Did not make any difference.
The only thing that kept Micky Mouse
and Friends at bay was giving the a "doggy
chew toy" to distract them from the real
resolv.conf.
By the way, I tried both fixed on floating on
my internet facing interface. No difference.
3:02 p.m.
I don't understand why you keep calling things "Mickey Mouse and Friends"
and acting like you've solved something. As far as I can understand, you renamed
/etc/resolv.conf (which is normally a symlink) and expect it to work?
4:35 p.m.
On 12/19/22 13:02, Jonathan Billings wrote:
I don't understand why you keep calling things "Mickey Mouse
and Friends" and acting like you've solved something. As far as I can
understand, you renamed /etc/resolv.conf (which is normally a symlink) and expect it to
work?
As soon as Micky and Friends started writing their
garbage to the fake resolv.conf, I was able to add
what worked to the real resolv.conf.
5:55 p.m.
On Dec 19, 2022, at 17:36, ToddAndMargo via users <users(a)lists.fedoraproject.org>
wrote:
On 12/19/22 13:02, Jonathan Billings wrote:
> I don't understand why you keep calling things "Mickey Mouse and
Friends" and acting like you've solved something. As far as I can understand,
you renamed /etc/resolv.conf (which is normally a symlink) and expect it to work?
As soon as Micky and Friends started writing their
garbage to the fake resolv.conf, I was able to add
what worked to the real resolv.conf.
You renamed a symlink. It’s not really a solution, and unless you disable or remove
systemd-resolved (and/or NetworkManager) it will be returned.
And it is extremely childish behavior calling it Mickey Mouse. Making fun of something
you don’t understand is not a good way to learn how the world works.
--
Jonathan Billings
7:02 p.m.
On 12/19/22 15:55, Jonathan Billings wrote:
On Dec 19, 2022, at 17:36, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
>
> On 12/19/22 13:02, Jonathan Billings wrote:
>> I don't understand why you keep calling things "Mickey Mouse and
Friends" and acting like you've solved something. As far as I can understand,
you renamed /etc/resolv.conf (which is normally a symlink) and expect it to work?
>
>
> As soon as Micky and Friends started writing their
> garbage to the fake resolv.conf, I was able to add
> what worked to the real resolv.conf.
You renamed a symlink. It’s not really a solution, and unless you disable or remove
systemd-resolved (and/or NetworkManager) it will be returned.
Not so far it has not. And it has had opportunities
out the wazoo to do such:
# cat /etc/resolv.conf
search acme.local
nameserver 127.0.0.1
By the way, you missed the part about me
uninstalling systemd-resolved. Someone
(a.k.a. Micky Mouse and Friends, kept changing
it to the non-functional "127.0.0.53")
I need my machine up and working. I have not got
hours and hours and hours to try and fix something
that should have never been broken.
My tip is definitely a workaround. When I have
eight hours to screw around with it again, maybe
I will try to get the official way to get it
operating again.
In the mean time, I need my machine to work. My
business is on it. Without it, I can't feed
my family or keep a roof over their head.
And it is extremely childish behavior calling it Mickey Mouse.
Making fun of something you don’t understand is not a good way to learn how the world
works.
Oh brother.
And Micky Mouse is big time cleanup of what I
actually called it. This is not the place for
vulgar language.
My machine worked perfectly under FC36. I did
not under FC37. Never, Never, Never, Never
should have happened. Fedora IS NOT WINDOWS.
--
Jonathan Billings
7:25 a.m.
On 12/19/22 15:55, Mickey Mouse wrote:
Not so far it has not. And it has had opportunities
out the wazoo to do such:
# cat /etc/resolv.conf
search acme.local
nameserver 127.0.0.1
By the way, you missed the part about me
uninstalling systemd-resolved. Someone
(a.k.a. Micky Mouse and Friends, kept changing
it to the non-functional "127.0.0.53")
Yes, you removed the package that would modify the contents of the file the symlink
pointed to. Your real solution was to remove the package. Renaming a symlink does
nothing.
But you're basically setting up an unmaintainable mess, something
Oh brother.
And Micky Mouse is big time cleanup of what I
actually called it. This is not the place for
vulgar language.
I appreciate you not using vulgar language, but you are talking about Disney characters
out of the blue, and I can only assume you're calling *ME* and my fellow Fedora users
bad names.
My machine worked perfectly under FC36. I did
not under FC37. Never, Never, Never, Never
should have happened. Fedora IS NOT WINDOWS.
Who is suggesting you install Windows?
This whole thread is full of nonsense.
--
Jonathan Billings
7:50 a.m.
On 12/20/22 05:25, Jonathan Billings wrote:
But you're basically setting up an unmaintainable mess, something
It is really easy for me to maintain.
It also gives me breathing room
to trying and figure out the new mess.
I am missing your point. What part is
not maintainable?
> My machine worked perfectly under FC36. I did
> not under FC37. Never, Never, Never, Never
> should have happened. Fedora IS NOT WINDOWS.
Who is suggesting you install Windows?
Where in the world did you get that idea?
You missed my point. FC37 upgrade went
sideways "like a Windows upgrade". That
is NOT suppose to happen. Fedora is
1000 times more reliable than Windows,
which is why I run Fedora and not Windows.
3:21 p.m.
On 12/20/22 05:25, Mickey Mouse wrote:
It is really easy for me to maintain.
It also gives me breathing room
to trying and figure out the new mess.
I am missing your point. What part is
not maintainable?
Now you have a system that won't do things that most fedora systems do out of the box.
You've got a system that might pull in systemd-resolved at some point in the future
if a dependency of some other package updates, and break your setup. You have a system
that can't support split DNS, so if you end up doing that, you'll have to write a
custom bind configuration to query other sources, which its up to you to maintain.
Its not maintainable because instead of figuring out the solution, you hacked out parts of
the OS until you got something that looks something kinda sorta like what you're used
to in CentOS or earlier versions of Fedora. It would be unrecognizable if someone were to
try to help you.
>> My machine worked perfectly under FC36. I did
>> not under FC37. Never, Never, Never, Never
>> should have happened. Fedora IS NOT WINDOWS.
>
> Who is suggesting you install Windows?
Where in the world did you get that idea?
I wonder?
You missed my point. FC37 upgrade went
sideways "like a Windows upgrade". That
is NOT suppose to happen. Fedora is
1000 times more reliable than Windows,
which is why I run Fedora and not Windows.
Sorry, I've not run windows much so I'm not familiar with how it fails.
However, that seems like a broad brush to paint the issue though. Just because something
didn't work exactly like you expected (and it works just fine for most every one else)
doesn't really make it like windows. If anything, the problem was only exacerbated by
your attempts to fix it.
As for the childish nicknames, I hope I get to be Scrooge McDuck, but I'm most likely
to be Goofy.
--
Jonathan Billings
4:01 p.m.
On 12/20/22 13:21, Jonathan Billings wrote:
Now you have a system that won't do things that most fedora
systems do out of the box. You've got a system that might pull in systemd-resolved at
some point in the future if a dependency of some other package updates, and break your
setup. You have a system that can't support split DNS, so if you end up doing that,
you'll have to write a custom bind configuration to query other sources, which its up
to you to maintain.
Its not maintainable because instead of figuring out the solution, you hacked out parts
of the OS until you got something that looks something kinda sorta like what you're
used to in CentOS or earlier versions of Fedora. It would be unrecognizable if someone
were to try to help you.
As other have pointed out on this thread, breaking
the link is in the man page.
And I ONLY want one DNS.
4:31 p.m.
> On 12/20/22 05:25, Mickey Mouse (A.K.A. His Resplendence) wrote:
On 12/20/22 13:21, Jonathan Billings wrote:
Its not maintainable because instead of figuring out the solution,
you hacked out parts of the OS until you got something that looks something kinda sorta
like what you're used to in CentOS or earlier versions of Fedora. It would be
unrecognizable if someone were to try to help you.
They can always read the man pages, as other have pointed
out to me. That also means it was not "Hacked".
Here you go:
I set
DNS=192.168.255.10:53
And got:
# systemctl restart systemd-resolved.service
# resolvectl
Global
Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 192.168.255.10
DNS Servers: 192.168.255.10
Link 2 (eno2)
Current Scopes: DNS LLMNR/IPv4
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
Link 3 (eno1)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 4 (br0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Link 5 (virbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
DNSSEC=no/unsupported
Global's and eno2's DNS server are different. So
broken. I will wait.And 127.0.0.53 refused to
consistently talk to my caching DNS server.
Something else to fix. Until then, your advice
is not so good.
:'(
the problem was only exacerbated by your attempts
to fix it.
I did fix it. My system is working wonderfully now.
And as I stated before, you can find what I did in
the man page.
-T
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computers are like air conditioners.
They malfunction when you open windows
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6:43 p.m.
On Tue, 2022-12-20 at 21:21 +0000, Jonathan Billings wrote:
Now you have a system that won't do things that most fedora
systems
do out of the box. You've got a system that might pull in systemd-
resolved at some point in the future if a dependency of some other
package updates, and break your setup.
This is why I don't install a new release over the top of the old, you
end up with a Rube Goldberg / Heath Robinson contraption trying to keep
things going.
--
uname -rsvp
Linux 3.10.0-1160.80.1.el7.x86_64 #1 SMP Tue Nov 8 15:48:59 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
7:06 p.m.
On 12/20/22 16:43, Tim via users wrote:
On Tue, 2022-12-20 at 21:21 +0000, Jonathan Billings wrote:
> Now you have a system that won't do things that most fedora systems
> do out of the box. You've got a system that might pull in systemd-
> resolved at some point in the future if a dependency of some other
> package updates, and break your setup.
This is why I don't install a new release over the top of the old, you
end up with a Rube Goldberg / Heath Robinson contraption trying to keep
things going.
I would start fresh if I could, but my main computer simulates a
perimeter firewall and a workgroup file
server with clients. I'd be three weeks restoring
everything.
9:39 a.m.
On Wed, 2022-12-21 at 11:13 +1030, Tim via users wrote:
On Tue, 2022-12-20 at 21:21 +0000, Jonathan Billings wrote:
> Now you have a system that won't do things that most fedora systems
> do out of the box. You've got a system that might pull in systemd-
> resolved at some point in the future if a dependency of some other
> package updates, and break your setup.
This is why I don't install a new release over the top of the old,
you end up with a Rube Goldberg / Heath Robinson contraption trying
to keep things going.
That only happens if you don't make sure that your modifications carry
over into the new version. I regularly update from one release to the
next, check the .rpmnew and .rpmsave files (using rpmconf) and haven't
had any problems. Of course if you change stuff outside what the
package manager installs, all bets are off.
poc
1:11 p.m.
On 12/21/22 07:39, Patrick O'Callaghan wrote:
That only happens if you don't make sure that your modifications
carry
over into the new version. I regularly update from one release to the
next, check the .rpmnew and .rpmsave files (using rpmconf) and haven't
had any problems. Of course if you change stuff outside what the
package manager installs, all bets are off.
poc
Other than the frivolities I experienced this time,
I have the same experience as you.
My (prior to this) hassle was them disabling
my systemctl start up links.
I reported it a couple of times, but got back
that I am suppose to know how to do that if I
am going to use the package. You win some and
you lose some.
This time they disabled named-chroot, but I
caught it instantly.
2 p.m.
On 12/21/22 11:35, Barry Scott wrote:
> On 21 Dec 2022, at 19:11, ToddAndMargo via users
> <users(a)lists.fedoraproject.org> wrote:
>
> This time they disabled named-chroot, but I
> caught it instantly.
Who is they?
Fedora's developers.
I use named-chroot and no one disabled it when I upgraded from f36 to
f37.
Hmmmmmmmm. The plot thickens!
Barry
4:15 p.m.
Tim:
> This is why I don't install a new release over the top of the
old,
> you end up with a Rube Goldberg / Heath Robinson contraption trying
> to keep things going.
Patrick O'Callaghan:
That only happens if you don't make sure that your modifications
carry
over into the new version. I regularly update from one release to the
next, check the .rpmnew and .rpmsave files (using rpmconf) and haven't
had any problems.
That works, up to a point. From one release to another, some method of
doing something changes, apps and services get withdrawn.
--
uname -rsvp
Linux 3.10.0-1160.80.1.el7.x86_64 #1 SMP Tue Nov 8 15:48:59 UTC 2022 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
4:28 p.m.
On Thu, 2022-12-22 at 08:45 +1030, Tim via users wrote:
Tim:
> > This is why I don't install a new release over the top of the
> > old,
> > you end up with a Rube Goldberg / Heath Robinson contraption
> > trying
> > to keep things going.
Patrick O'Callaghan:
> That only happens if you don't make sure that your modifications
> carry
> over into the new version. I regularly update from one release to
> the
> next, check the .rpmnew and .rpmsave files (using rpmconf) and
> haven't
> had any problems.
That works, up to a point. From one release to another, some method
of doing something changes, apps and services get withdrawn.
When that happens, it is generally documented in the Release Notes,
though some things might slip through the cracks. Fedora is a bleeding-
edge distro for a reason.
poc
5:18 p.m.
On 12/21/22 14:28, Patrick O'Callaghan wrote:
Fedora is a bleeding-
edge distro for a reason.
That is a common, forgivable misunderstanding.
Fedora is not next to bleeding edge. Fedora has a
army of testers that keep the junk out that
does not work right.
The only ones I have know the testers to miss is
Wine. But that too is understandable.
Wine is beta at best. And would be next to
impossible for the testers to test every
Windows program against it. Wine 7 is trash.
The testers are very much under appreciated.
3:18 a.m.
On 21 Dec 2022, at 23:19, ToddAndMargo via users
<users(a)lists.fedoraproject.org> wrote:
On 12/21/22 14:28, Patrick O'Callaghan wrote:
> Fedora is a bleeding-
> edge distro for a reason.
That is a common, forgivable misunderstanding.
Fedora is not next to bleeding edge. Fedora has a
army of testers that keep the junk out that
does not work right.
You are not hitting junk that does not work i think.
What you are seeing is that the core network software is moving forward
little by little over time. You need to notice when small admin changes
are needed to keep up with those moves.
Otherwise you end up with technical debt.
F37 included a bind daemon change to its config for example.
I saw bind error out, reaserched the error, and fixed if.
I know that i will hit an issue when firewalld drops support for the iptables backend.
I have an iptables rule that i inject via firewalld .xml.
I will have to learn how to do the same for nftables, but i choose to put that day off.
Barry
The only ones I have know the testers to miss is
Wine. But that too is understandable.
Wine is beta at best. And would be next to
impossible for the testers to test every
Windows program against it. Wine 7 is trash.
The testers are very much under appreciated.
_______________________________________________
users mailing list -- users(a)lists.fedoraproject.org
To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
7:53 a.m.
On Wed, 2022-12-21 at 15:18 -0800, ToddAndMargo via users wrote:
On 12/21/22 14:28, Patrick O'Callaghan wrote:
> Fedora is a bleeding-
> edge distro for a reason.
That is a common, forgivable misunderstanding.
Fedora is not next to bleeding edge. Fedora has a
army of testers that keep the junk out that
does not work right.
I'm well aware of that. Nevertheless, Fedora is for people who don't
mind frequent updates because it is a testbed. Perhaps "bleeding edge"
is hyperbole (compared to, say, Arch) but it's not entirely wrong.
poc
8:01 a.m.
On Thu, 22 Dec 2022 13:53:59 +0000
Patrick O'Callaghan wrote:
compared to, say, Arch
On the other hand, I can't count the number of things I've found
well documented in the Arch web pages that were utterly confusing
in every other particle of documentation I found elsewhere, so it
is good that their documentation is bleeding edge :-).
11:01 a.m.
On Thu, 2022-12-22 at 09:01 -0500, Tom Horsley wrote:
On Thu, 22 Dec 2022 13:53:59 +0000
Patrick O'Callaghan wrote:
> compared to, say, Arch
On the other hand, I can't count the number of things I've found
well documented in the Arch web pages that were utterly confusing
in every other particle of documentation I found elsewhere, so it
is good that their documentation is bleeding edge :-).
Absolutely. The Arch docs are exemplary.
poc
4:19 a.m.
-----Original Message-----
From: Patrick O'Callaghan <pocallaghan(a)gmail.com>
Sent: Thursday, December 22, 2022 2:54 PM
To: users(a)lists.fedoraproject.org
Subject: Re: Tip: how to make your own resolv.conf
On Wed, 2022-12-21 at 15:18 -0800, ToddAndMargo via users wrote:
On 12/21/22 14:28, Patrick O'Callaghan wrote:
> Fedora is a bleeding-
> edge distro for a reason.
That is a common, forgivable misunderstanding.
Fedora is not next to bleeding edge. Fedora has a army of testers
that keep the junk out that does not work right.
I'm well aware of that. Nevertheless, Fedora is for people who don't mind frequent
updates because it is a testbed. Perhaps "bleeding edge"
is hyperbole (compared to, say, Arch) but it's not entirely wrong.
"Bleedng edge"? I had the impression that rawhide was supposed to be that...
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de
geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat
aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen
aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's
verbonden aan het elektronisch verzenden van berichten.
This message may contain information that is not intended for you. If you are not the
addressee or if this message was sent to you by mistake, you are requested to inform the
sender and delete the message. The State accepts no liability for damage of any kind
resulting from the risks inherent in the electronic transmission of messages.
5:56 a.m.
On Fri, 2022-12-23 at 10:19 +0000, J.Witvliet--- via users wrote:
-----Original Message-----
From: Patrick O'Callaghan <pocallaghan(a)gmail.com>
Sent: Thursday, December 22, 2022 2:54 PM
To: users(a)lists.fedoraproject.org
Subject: Re: Tip: how to make your own resolv.conf
On Wed, 2022-12-21 at 15:18 -0800, ToddAndMargo via users wrote:
> On 12/21/22 14:28, Patrick O'Callaghan wrote:
> > Fedora is a bleeding-
> > edge distro for a reason.
>
> That is a common, forgivable misunderstanding.
>
> Fedora is not next to bleeding edge. Fedora has a army of testers
> that keep the junk out that does not work right.
I'm well aware of that. Nevertheless, Fedora is for people who don't
mind frequent updates because it is a testbed. Perhaps "bleeding
edge"
is hyperbole (compared to, say, Arch) but it's not entirely wrong.
"Bleedng edge"? I had the impression that rawhide was supposed to be
that...
You should revise your MUA quoting configuration. You have my comment
and your own reply at the same level, potentially confusing anyone who
hasn't been following the thread.
poc
496
days inactive
501
days old
72 comments
13 participants
participants (13)
-
Barry -
Barry Scott
-
Chris Adams -
Felix Miata -
J.Witvliet＠mindef.nl -
Jonathan Billings -
Patrick O'Callaghan -
Peter Boy -
Roger Heflin -
Samuel Sieb -
Tim -
ToddAndMargo -
Tom Horsley