Hi All,
Tip: by default the dhcp leases file does not exist under Fedora32. You have to create it firs, then it gets uses
-T
My notes:
DHCP Client leases file:
The file does not exist by default.
# New to Fedora 32. Set up a leases file if it does not exist: if [ -n /var/lib/dhclient/dhclient.lease]; then touch /var/lib/dhclient/dhclient.lease; # release DHCP address dhclient -r # renew DHCP address dhclient fi
On Sun, 2020-04-26 at 16:05 -0700, ToddAndMargo via users wrote:
Tip: by default the dhcp leases file does not exist under Fedora32. You have to create it firs, then it gets uses
If true, I'd call that a bug. It's a ludicrous requirement for users to create *that* file. DHCP is supposed to be a *fully* automatic address assignment system. Have you reported it to bugzilla?
On 2020-04-27 13:43, Tim via users wrote:
On Sun, 2020-04-26 at 16:05 -0700, ToddAndMargo via users wrote:
Tip: by default the dhcp leases file does not exist under Fedora32. You have to create it firs, then it gets uses
If true, I'd call that a bug. It's a ludicrous requirement for users to create *that* file. DHCP is supposed to be a *fully* automatic address assignment system. Have you reported it to bugzilla?
I don't think it is a bug. It would be more about how NetworkManger handles things.
[root@f31k dhclient]# pwd /var/lib/dhclient
[root@f31k dhclient]# ls [root@f31k dhclient]# dhclient -r Removed stale PID file [root@f31k dhclient]# ls dhclient.leases
No touching needed.
Tim:
If true, I'd call that a bug. It's a ludicrous requirement for users to create *that* file. DHCP is supposed to be a *fully* automatic address assignment system. Have you reported it to bugzilla?
Ed Greshko:
I don't think it is a bug. It would be more about how NetworkManger handles things.
I'd certainly call that a bug (having to manually intervene to get a DHCP client to work). Where it's attributable is another matter (DHCP itself, or NetworkManager).
On 2020-04-27 15:07, Tim via users wrote:
Tim:
If true, I'd call that a bug. It's a ludicrous requirement for users to create *that* file. DHCP is supposed to be a *fully* automatic address assignment system. Have you reported it to bugzilla?
Ed Greshko:
I don't think it is a bug. It would be more about how NetworkManger handles things.
I'd certainly call that a bug (having to manually intervene to get a DHCP client to work). Where it's attributable is another matter (DHCP itself, or NetworkManager).
So far I've not seen any indication of what doesn't work. Have you?
On 2020-04-27 00:11, Ed Greshko wrote:
On 2020-04-27 15:07, Tim via users wrote:
Tim:
If true, I'd call that a bug. It's a ludicrous requirement for users to create *that* file. DHCP is supposed to be a *fully* automatic address assignment system. Have you reported it to bugzilla?
Ed Greshko:
I don't think it is a bug. It would be more about how NetworkManger handles things.
I'd certainly call that a bug (having to manually intervene to get a DHCP client to work). Where it's attributable is another matter (DHCP itself, or NetworkManager).
So far I've not seen any indication of what doesn't work. Have you?
Unless you create the file yourself, it does not get written to. I have seen references to this on google, so I presume it was done on purpose, although I think it is ill advised.
And to make matter even worse,
$ ls /var/lib/dhclient dhclient-a056777e-8a75-4da5-9585-6aacf150b862-eno2.lease dhclient.lease dhclient--eno2.lease dhclient.leases
dhclient--eno2.lease deos not get created either until you create /var/lib/dhclient/dhclient.lease
And now dhclient.lease ONLY contains the IP number
AAAA HHHHHH !!!!!
On 2020-04-27 18:58, ToddAndMargo via users wrote:
On 2020-04-27 00:11, Ed Greshko wrote:
On 2020-04-27 15:07, Tim via users wrote:
Tim:
If true, I'd call that a bug. It's a ludicrous requirement for users to create *that* file. DHCP is supposed to be a *fully* automatic address assignment system. Have you reported it to bugzilla?
Ed Greshko:
I don't think it is a bug. It would be more about how NetworkManger handles things.
I'd certainly call that a bug (having to manually intervene to get a DHCP client to work). Where it's attributable is another matter (DHCP itself, or NetworkManager).
So far I've not seen any indication of what doesn't work. Have you?
Unless you create the file yourself, it does not get written to. I have seen references to this on google, so I presume it was done on purpose, although I think it is ill advised.
What functionality is lost?
And to make matter even worse,
$ ls /var/lib/dhclient dhclient-a056777e-8a75-4da5-9585-6aacf150b862-eno2.lease dhclient.lease dhclient--eno2.lease dhclient.leases
dhclient--eno2.lease deos not get created either until you create /var/lib/dhclient/dhclient.lease
And now dhclient.lease ONLY contains the IP number
I've not seen a reference to dhclient.lease only dhclient.leases. Are you calling dhclient with parameters to create that file?
Are the connections you reference above being controlled by NetworkManager?
On 2020-04-27 05:16, Ed Greshko wrote:
On 2020-04-27 18:58, ToddAndMargo via users wrote:
On 2020-04-27 00:11, Ed Greshko wrote:
On 2020-04-27 15:07, Tim via users wrote:
Tim:
If true, I'd call that a bug. It's a ludicrous requirement for users to create *that* file. DHCP is supposed to be a *fully* automatic address assignment system. Have you reported it to bugzilla?
Ed Greshko:
I don't think it is a bug. It would be more about how NetworkManger handles things.
I'd certainly call that a bug (having to manually intervene to get a DHCP client to work). Where it's attributable is another matter (DHCP itself, or NetworkManager).
So far I've not seen any indication of what doesn't work. Have you?
Unless you create the file yourself, it does not get written to. I have seen references to this on google, so I presume it was done on purpose, although I think it is ill advised.
What functionality is lost?
The information in /var/lib/dhclient/dhclient.leases:
lease { interface "br0"; fixed-address 192.168.255.116; option subnet-mask 255.255.255.0; option time-offset 39600; option routers 192.168.255.10; option dhcp-lease-time 10355267; option dhcp-message-type 5; option domain-name-servers 192.168.255.10; option dhcp-server-identifier 192.168.255.10; option broadcast-address 192.168.255.255; option domain-name "rent-a-nerd.local"; renew 2 2020/06/23 01:34:08; rebind 0 2020/08/09 22:11:01; expire 1 2020/08/24 21:44:30; }
And to make matter even worse,
$ ls /var/lib/dhclient dhclient-a056777e-8a75-4da5-9585-6aacf150b862-eno2.lease dhclient.lease dhclient--eno2.lease dhclient.leases
dhclient--eno2.lease deos not get created either until you create /var/lib/dhclient/dhclient.lease
And now dhclient.lease ONLY contains the IP number
I've not seen a reference to dhclient.lease only dhclient.leases. Are you calling dhclient with parameters to create that file?
Typo on my part
Are the connections you reference above being controlled by NetworkManager?
I presume
Once upon a time, ToddAndMargo via users users@lists.fedoraproject.org said:
The information in /var/lib/dhclient/dhclient.leases:
File contents are not what people usually mean by "functionality". If you are using NetworkManager and looking for the DHCP information, that's provided by NetworkManager - for example "nmcli con show br0" (which is a lot more complete about the DHCP request and reply).
On 2020-04-27 12:54, Chris Adams wrote:
Once upon a time, ToddAndMargo via users users@lists.fedoraproject.org said:
The information in /var/lib/dhclient/dhclient.leases:
File contents are not what people usually mean by "functionality". If you are using NetworkManager and looking for the DHCP information, that's provided by NetworkManager - for example "nmcli con show br0" (which is a lot more complete about the DHCP request and reply).
$ nmcli con show br0 Error: br0 - no such connection profile.
Hmmm. Something is wrong
On 4/27/20 1:43 PM, ToddAndMargo via users wrote:
On 2020-04-27 12:54, Chris Adams wrote:
Once upon a time, ToddAndMargo via users users@lists.fedoraproject.org said:
The information in /var/lib/dhclient/dhclient.leases:
File contents are not what people usually mean by "functionality". If you are using NetworkManager and looking for the DHCP information, that's provided by NetworkManager - for example "nmcli con show br0" (which is a lot more complete about the DHCP request and reply).
$ nmcli con show br0 Error: br0 - no such connection profile.
Hmmm. Something is wrong
According to an earlier email from you, "br0" is not managed by NetworkManager, so that won't work. Is there a reason you did that?
On 2020-04-27 14:15, Samuel Sieb wrote:
On 4/27/20 1:43 PM, ToddAndMargo via users wrote:
On 2020-04-27 12:54, Chris Adams wrote:
Once upon a time, ToddAndMargo via users users@lists.fedoraproject.org said:
The information in /var/lib/dhclient/dhclient.leases:
File contents are not what people usually mean by "functionality". If you are using NetworkManager and looking for the DHCP information, that's provided by NetworkManager - for example "nmcli con show br0" (which is a lot more complete about the DHCP request and reply).
$ nmcli con show br0 Error: br0 - no such connection profile.
Hmmm. Something is wrong
According to an earlier email from you, "br0" is not managed by NetworkManager, so that won't work. Is there a reason you did that?
Because Chris suggested it
On 4/27/20 2:37 PM, ToddAndMargo via users wrote:
On 2020-04-27 14:15, Samuel Sieb wrote:
On 4/27/20 1:43 PM, ToddAndMargo via users wrote:
On 2020-04-27 12:54, Chris Adams wrote:
Once upon a time, ToddAndMargo via users users@lists.fedoraproject.org said:
The information in /var/lib/dhclient/dhclient.leases:
File contents are not what people usually mean by "functionality". If you are using NetworkManager and looking for the DHCP information, that's provided by NetworkManager - for example "nmcli con show br0" (which is a lot more complete about the DHCP request and reply).
$ nmcli con show br0 Error: br0 - no such connection profile.
Hmmm. Something is wrong
According to an earlier email from you, "br0" is not managed by NetworkManager, so that won't work. Is there a reason you did that?
Because Chris suggested it
As soon as I sent that message I realized it was ambiguous, but was hoping you would pick the right meaning. :-)
My question was why aren't you letting NetworkManager manage br0?
On 2020-04-27 15:03, ToddAndMargo via users wrote:
On 2020-04-27 14:55, Samuel Sieb wrote:
My question was why aren't you letting NetworkManager manage br0?
Because I am doing it the way I learned back when I suffered with RHEL clones.
And it works
$64,000.00 question. Why is NetworkManager not picking up
/etc/sysconfig/network-scripts/ifcfg-br0
?
On 4/27/20 3:07 PM, ToddAndMargo via users wrote:
On 2020-04-27 15:03, ToddAndMargo via users wrote:
On 2020-04-27 14:55, Samuel Sieb wrote:
My question was why aren't you letting NetworkManager manage br0?
Because I am doing it the way I learned back when I suffered with RHEL clones.
And it works
$64,000.00 question. Why is NetworkManager not picking up
/etc/sysconfig/network-scripts/ifcfg-br0
From the earlier email you sent, in that file you have: NM_CONTROLLED=no
So NetworkManager won't touch it.
On 2020-04-27 15:17, Samuel Sieb wrote:
On 4/27/20 3:07 PM, ToddAndMargo via users wrote:
On 2020-04-27 15:03, ToddAndMargo via users wrote:
On 2020-04-27 14:55, Samuel Sieb wrote:
My question was why aren't you letting NetworkManager manage br0?
Because I am doing it the way I learned back when I suffered with RHEL clones.
And it works
$64,000.00 question. Why is NetworkManager not picking up
/etc/sysconfig/network-scripts/ifcfg-br0
From the earlier email you sent, in that file you have: NM_CONTROLLED=no
So NetworkManager won't touch it.
Hi Sam,
So that is what that means. All these years and I never bother to look up what it meant.
I flipped to yes and rebooted. Seems to be working fine. Show up in the applet too. I was able to contact go to assist with Brave on my Windows 10 VM, where is anything was to go wrong ...
Thank you!
-T
On 2020-04-28 07:27, ToddAndMargo via users wrote:
So that is what that means. All these years and I never bother to look up what it meant.
I flipped to yes and rebooted. Seems to be working fine. Show up in the applet too. I was able to contact go to assist with Brave on my Windows 10 VM, where is anything was to go wrong ...
Now that you're using NetworkManager to control br0 you may need to revisit the changes you made to your iptables scripts to point to the correct NetworkManager versions of ifup and ifdown.
On 2020-04-27 16:51, Ed Greshko wrote:
On 2020-04-28 07:27, ToddAndMargo via users wrote:
So that is what that means. All these years and I never bother to look up what it meant.
I flipped to yes and rebooted. Seems to be working fine. Show up in the applet too. I was able to contact go to assist with Brave on my Windows 10 VM, where is anything was to go wrong ...
Now that you're using NetworkManager to control br0 you may need to revisit the changes you made to your iptables scripts to point to the correct NetworkManager versions of ifup and ifdown.
This is what I have been using:
ipgw="$(ip route list | grep -i "default via" | awk '{print $3}')" if [ -z "$ipgw" ]; then echo "eth1 is not reporting that it is a gateway." echo "downing and upping eth1" # /etc/sysconfig/network-scripts/ifdown eth1 # /etc/sysconfig/network-scripts/ifup eth1
# this works too, but use nm-ifdown and nm-ifup instead # nmcli dev disconnect eno2 # nmcli dev connect eno2
/usr/libexec/nm-ifdown eno2 /usr/libexec/nm-ifup eno2 fi
$ nmcli con show NAME UUID TYPE DEVICE eno2 a056777e-8a75-4da5-9585-6aacf150b862 ethernet eno2 System br0 d2d68553-f97e-7549-7a26-b34a26f29318 bridge br0 virbr0 1961b652-01e8-4000-8a67-c6289045e5aa bridge virbr0 eno1 be0f8dfa-9939-4f9e-a20a-cadf593452c2 ethernet eno1
I still get: $ nmcli con show br0 Error: br0 - no such connection profile. But, that is because NM calls br0 "System br0"
$ nmcli con show "System br0" connection.id: System br0 connection.uuid: d2d68553-f97e-7549-7a26-b34a26f29318 connection.stable-id: -- connection.type: bridge connection.interface-name: br0 connection.autoconnect: yes connection.autoconnect-priority: -999 connection.autoconnect-retries: -1 (default) connection.multi-connect: 0 (default) connection.auth-retries: -1 connection.timestamp: 1588031969 connection.read-only: no connection.permissions: -- connection.zone: -- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: -- connection.gateway-ping-timeout: 0 connection.metered: unknown connection.lldp: default connection.mdns: -1 (default) connection.llmnr: -1 (default) connection.wait-device-timeout: -1
And nothing in it that I need.
On 2020-04-28 08:02, ToddAndMargo via users wrote:
On 2020-04-27 16:51, Ed Greshko wrote:
On 2020-04-28 07:27, ToddAndMargo via users wrote:
So that is what that means. All these years and I never bother to look up what it meant.
I flipped to yes and rebooted. Seems to be working fine. Show up in the applet too. I was able to contact go to assist with Brave on my Windows 10 VM, where is anything was to go wrong ...
Now that you're using NetworkManager to control br0 you may need to revisit the changes you made to your iptables scripts to point to the correct NetworkManager versions of ifup and ifdown.
This is what I have been using:
ipgw="$(ip route list | grep -i "default via" | awk '{print $3}')" if [ -z "$ipgw" ]; then echo "eth1 is not reporting that it is a gateway." echo "downing and upping eth1" # /etc/sysconfig/network-scripts/ifdown eth1 # /etc/sysconfig/network-scripts/ifup eth1
# this works too, but use nm-ifdown and nm-ifup instead # nmcli dev disconnect eno2 # nmcli dev connect eno2
/usr/libexec/nm-ifdown eno2 /usr/libexec/nm-ifup eno2 fi
$ nmcli con show NAME UUID TYPE DEVICE eno2 a056777e-8a75-4da5-9585-6aacf150b862 ethernet eno2 System br0 d2d68553-f97e-7549-7a26-b34a26f29318 bridge br0 virbr0 1961b652-01e8-4000-8a67-c6289045e5aa bridge virbr0 eno1 be0f8dfa-9939-4f9e-a20a-cadf593452c2 ethernet eno1
I still get: $ nmcli con show br0 Error: br0 - no such connection profile. But, that is because NM calls br0 "System br0"
In a previous thread you included the /etc/sysconfig/network-scripts/ifcfg-br0 file. It contains
NAME="System br0"
Which is where NM gets that info. You can change it.
ToddAndMargo via users writes:
On 2020-04-27 14:55, Samuel Sieb wrote:
My question was why aren't you letting NetworkManager manage br0?
Because I am doing it the way I learned back when I suffered with RHEL clones.
And it works
"…now". That's the operative word here. It might work now, but it will not work forever.
You've finally managed to get it to work, it seems, by having NM manage it. Although it seems that right now you can still own your network interfaces yourself, it's a certain bet that at some point things will only work with NM under Fedora, and the response to any complaints will be "well, you're free to choose some other distro which works without NetworkManager".
The same thing, pretty much, goes with everything else. Here's another, very similar situation right now, which is rolling your local iptables rules versus firewalld.
I saw the handwriting on the wall, on that account, one several releases ago, and slogged my way through converting what I was doing with iptables into the equivalent deal with firewalld.
You have to always keep your ears to the ground, for these kinds of things. Anytime you hear about a new bit of technology that gets introduced as an alleged successor and a superiod alternative to something that's already here, don't quite take it, on the face value, any assurances that the old ways still work. They might still work now, but they won't work forever. Rest assured. So, start figuring out what you gotta do, while you still have some time…
On 2020-04-28 09:24, Sam Varshavchik wrote:
ToddAndMargo via users writes:
On 2020-04-27 14:55, Samuel Sieb wrote:
My question was why aren't you letting NetworkManager manage br0?
Because I am doing it the way I learned back when I suffered with RHEL clones.
And it works
"…now". That's the operative word here. It might work now, but it will not work forever.
You've finally managed to get it to work, it seems, by having NM manage it. Although it seems that right now you can still own your network interfaces yourself, it's a certain bet that at some point things will only work with NM under Fedora, and the response to any complaints will be "well, you're free to choose some other distro which works without NetworkManager".
The same thing, pretty much, goes with everything else. Here's another, very similar situation right now, which is rolling your local iptables rules versus firewalld.
I saw the handwriting on the wall, on that account, one several releases ago, and slogged my way through converting what I was doing with iptables into the equivalent deal with firewalld.
You have to always keep your ears to the ground, for these kinds of things. Anytime you hear about a new bit of technology that gets introduced as an alleged successor and a superiod alternative to something that's already here, don't quite take it, on the face value, any assurances that the old ways still work. They might still work now, but they won't work forever. Rest assured. So, start figuring out what you gotta do, while you still have some time…
+1
Very Well Said
On 4/27/20 6:24 PM, Sam Varshavchik wrote:
The same thing, pretty much, goes with everything else. Here's another, very similar situation right now, which is rolling your local iptables rules versus firewalld.
I saw the handwriting on the wall, on that account, one several releases ago, and slogged my way through converting what I was doing with iptables into the equivalent deal with firewalld.
I still make my own iptables scripts, mostly using fwbuilder. I think it might be possible to add the dynamic rules I would like to have if I switch to firewalld, but I haven't had the time for that yet. And then there's nftables which is the new replacement for iptables.
Once upon a time, Samuel Sieb samuel@sieb.net said:
I still make my own iptables scripts, mostly using fwbuilder. I think it might be possible to add the dynamic rules I would like to have if I switch to firewalld, but I haven't had the time for that yet. And then there's nftables which is the new replacement for iptables.
Just to clear up some misconception: firewalld is not a replacement for iptables. firewalld is a front-end to iptables, similar to shorewall and some other firewall management tools. firewalld (and shorewall and so on) is a replacement for manually writing rules and putting them in /etc/sysconfig/iptables though.
However, iptables is being replaced by nftables (similar to how iptables replaced ipchains in the past). firewalld can use either as a back end. nftables can also be configured using an iptables front-end translator (so if all you want to do is manually write iptables-style rules, that will actually still work with the nftables back-end).
On 2020-04-28 20:15, Chris Adams wrote:
Once upon a time, Samuel Sieb samuel@sieb.net said:
I still make my own iptables scripts, mostly using fwbuilder. I think it might be possible to add the dynamic rules I would like to have if I switch to firewalld, but I haven't had the time for that yet. And then there's nftables which is the new replacement for iptables.
Just to clear up some misconception: firewalld is not a replacement for iptables. firewalld is a front-end to iptables, similar to shorewall and some other firewall management tools. firewalld (and shorewall and so on) is a replacement for manually writing rules and putting them in /etc/sysconfig/iptables though.
However, iptables is being replaced by nftables (similar to how iptables replaced ipchains in the past). firewalld can use either as a back end. nftables can also be configured using an iptables front-end translator (so if all you want to do is manually write iptables-style rules, that will actually still work with the nftables back-end).
Thanks for bringing this up as I hadn't thought about this in quite some time.
I just checked and nftables is now the backend to firewalld. I think this happened awhile ago. A quick google search said it happened around version 0.6 of firewalld. Indeed, the man page for firewalld.conf states:
FirewallBackend Selects the firewall backend implementation. Possible values are; nftables (default), or iptables. This applies to all firewalld primitives. The only exception is direct and passthrough rules which always use the traditional iptables, ip6tables, and ebtables backends.
Time to explore the nft command. :-)
On 4/28/20 5:15 AM, Chris Adams wrote:
Once upon a time, Samuel Sieb samuel@sieb.net said:
I still make my own iptables scripts, mostly using fwbuilder. I think it might be possible to add the dynamic rules I would like to have if I switch to firewalld, but I haven't had the time for that yet. And then there's nftables which is the new replacement for iptables.
Just to clear up some misconception: firewalld is not a replacement for iptables. firewalld is a front-end to iptables, similar to shorewall and some other firewall management tools. firewalld (and shorewall and so on) is a replacement for manually writing rules and putting them in /etc/sysconfig/iptables though.
I hope you didn't think I was implying otherwise. I was just saying that firewalld might be able to replace me having to write my own iptables scripts. I also mentioned nftables.
On 2020-04-28 05:15, Chris Adams wrote:
Once upon a time, Samuel Sieb samuel@sieb.net said:
I still make my own iptables scripts, mostly using fwbuilder. I think it might be possible to add the dynamic rules I would like to have if I switch to firewalld, but I haven't had the time for that yet. And then there's nftables which is the new replacement for iptables.
Just to clear up some misconception: firewalld is not a replacement for iptables. firewalld is a front-end to iptables, similar to shorewall and some other firewall management tools. firewalld (and shorewall and so on) is a replacement for manually writing rules and putting them in /etc/sysconfig/iptables though.
However, iptables is being replaced by nftables (similar to how iptables replaced ipchains in the past). firewalld can use either as a back end. nftables can also be configured using an iptables front-end translator (so if all you want to do is manually write iptables-style rules, that will actually still work with the nftables back-end).
I use firewalld for workstations and iptables for servers doubling as a perimeter firewall.
Gots to look up nftables. Have you converted iptables to nftables yet? Does it follow any of the iptables syntax? (I have HUNDREDS of line of iptables.)
On Tue, Apr 28, 2020 at 01:12:03PM -0700, ToddAndMargo via users wrote:
Gots to look up nftables. Have you converted iptables to nftables yet? Does it follow any of the iptables syntax? (I have HUNDREDS of line of iptables.)
If you replace your 'iptables' package with 'iptables-nft', it'll install iptables-equivalent commands that'll create nft configuration.
On 2020-04-28 13:30, Jonathan Billings wrote:
On Tue, Apr 28, 2020 at 01:12:03PM -0700, ToddAndMargo via users wrote:
Gots to look up nftables. Have you converted iptables to nftables yet? Does it follow any of the iptables syntax? (I have HUNDREDS of line of iptables.)
If you replace your 'iptables' package with 'iptables-nft', it'll install iptables-equivalent commands that'll create nft configuration.
Do you have a help/how to page on that?
On Mon, 27 Apr 2020 at 22:25, Sam Varshavchik mrsam@courier-mta.com wrote:
You have to always keep your ears to the ground, for these kinds of things. Anytime you hear about a new bit of technology that gets introduced as an alleged successor and a superiod alternative to something that's already here, don't quite take it, on the face value, any assurances that the old ways still work. They might still work now, but they won't work forever. Rest assured. So, start figuring out what you gotta do, while you still have some time…
Fully agree. Fedora provides advanced warning of things to come. Some new bits will turn out to be bad for your use case, so you don't want to let things go to far without raising issues, and developers working to resolve issues will do a better job with guidance from users.
On Sun, Apr 26, 2020 at 04:05:30PM -0700, ToddAndMargo via users wrote:
Hi All,
Tip: by default the dhcp leases file does not exist under Fedora32. You have to create it firs, then it gets uses
-T
My notes:
DHCP Client leases file:
The file does not exist by default.
# New to Fedora 32. Set up a leases file if it does not exist: if [ -n /var/lib/dhclient/dhclient.lease]; then touch /var/lib/dhclient/dhclient.lease; # release DHCP address dhclient -r # renew DHCP address dhclient fi
By default on my F32 system, NetworkManager uses the internal DHCP client and not dhclient. So there will not be a typical dhclient lease file.
# journalctl -xl --since today -u NetworkManager.service|grep dhcp-init Apr 27 07:51:33 proton NetworkManager[1380]: <info> [1587988293.2807] dhcp-init: Using DHCP client 'internal'
Read the man page for NetworkManager.conf in the dhcp section to tell it to use the dhclient plugin.
The NetworkManager package is built with dhcp_default=internal on versions of Fedora >= 31 (and RHEL/CentOS 8).
https://src.fedoraproject.org/rpms/NetworkManager/blob/f31/f/NetworkManager....
On 2020-04-27 05:51, Jonathan Billings wrote:
On Sun, Apr 26, 2020 at 04:05:30PM -0700, ToddAndMargo via users wrote:
Hi All,
Tip: by default the dhcp leases file does not exist under Fedora32. You have to create it firs, then it gets uses
-T
My notes:
DHCP Client leases file:
The file does not exist by default.
# New to Fedora 32. Set up a leases file if it does not exist: if [ -n /var/lib/dhclient/dhclient.lease]; then touch /var/lib/dhclient/dhclient.lease; # release DHCP address dhclient -r # renew DHCP address dhclient fi
By default on my F32 system, NetworkManager uses the internal DHCP client and not dhclient. So there will not be a typical dhclient lease file.
# journalctl -xl --since today -u NetworkManager.service|grep dhcp-init Apr 27 07:51:33 proton NetworkManager[1380]: <info> [1587988293.2807] dhcp-init: Using DHCP client 'internal'
Read the man page for NetworkManager.conf in the dhcp section to tell it to use the dhclient plugin.
The NetworkManager package is built with dhcp_default=internal on versions of Fedora >= 31 (and RHEL/CentOS 8).
https://src.fedoraproject.org/rpms/NetworkManager/blob/f31/f/NetworkManager....
I forgot the "s" at the end of "leases"
On 2020-04-26 16:05, ToddAndMargo via users wrote:
Hi All,
Tip: by default the dhcp leases file does not exist under Fedora32. You have to create it firs, then it gets uses
-T
My notes:
DHCP Client leases file:
The file does not exist by default.
# New to Fedora 32. Set up a leases file if it does not exist: if [ -n /var/lib/dhclient/dhclient.lease]; then touch /var/lib/dhclient/dhclient.lease; # release DHCP address dhclient -r # renew DHCP address dhclient fi
Opps, I forgot the "s" at the end of "leases"
-
Chris Adams -
Ed Greshko -
George N. White III -
Jonathan Billings -
Sam Varshavchik -
Samuel Sieb -
Tim -
ToddAndMargo