In a Fedora 35 VM, all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client. The messages logged are of the form:
"name 'xxxx@local' does not map into domain 'localdomain'"
I have no nfs-idmapd service running. This same setup is running fine on a CentOS 8 VM. I didn't have to do anything special to make this work in CentOS 8. What am I missing here in a Fedora 35 installed with default configuration in a QEMU/KVM virtual machine?
Where does Fedora get its domain name? When I type "hostname --fqdn" I get "hostname: Name or service not known". The CentOS 8 VM apparently gets its domain name from the /etc/hostname file, which contains "cent9-vm.local". This does not appear to work in Fedora 35.
On Tue, 25 Jan 2022 10:35:27 -0600 Robert Nichols rnicholsNOSPAM@comcast.net wrote:
In a Fedora 35 VM, all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client. The messages logged are of the form:
"name 'xxxx@local' does not map into domain 'localdomain'"I have no nfs-idmapd service running. This same setup is running fine on a CentOS 8 VM. I didn't have to do anything special to make this work in CentOS 8. What am I missing here in a Fedora 35 installed with default configuration in a QEMU/KVM virtual machine?
Where does Fedora get its domain name? When I type "hostname --fqdn" I get "hostname: Name or service not known". The CentOS 8 VM apparently gets its domain name from the /etc/hostname file, which contains "cent9-vm.local". This does not appear to work in Fedora 35.
A few versions ago, Fedora moved to systemd-resolved as its default, and no longer uses the hostname file by default. This was to solve a problem where systems weren't getting DNS properly. I don't really understand all the ins and outs of this, as I have it disabled because I am using a custom DNS solution via the kresd package. But, it gives you a place to start looking. I have seen many messages about this, and there are ways to turn it off or customize it, so you should be able to do what you want. Though the latest messages I saw were problems with getting virtual machines to use a custom hostname.
Maybe someone else who has wrestled with this can give you simple instructions of how to do what you want.
On 1/25/22 08:35, Robert Nichols wrote:
In a Fedora 35 VM, all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client. The messages logged are of the form:
"name 'xxxx@local' does not map into domain 'localdomain'"
What does the entry for that filesystem in /proc/mounts look like? It should have negotiated mount options that shed some light.
Maybe add the "sec=sys" mount option to the client.
On 1/26/22 7:15 PM, Gordon Messmer wrote:
On 1/25/22 08:35, Robert Nichols wrote:
In a Fedora 35 VM, all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client. The messages logged are of the form:
"name 'xxxx@local' does not map into domain 'localdomain'"
What does the entry for that filesystem in /proc/mounts look like? It should have negotiated mount options that shed some light.
Maybe add the "sec=sys" mount option to the client.
Looks like "sec=sys" is already in there:
plugh-3g:/srv/shared /Public nfs4 rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.172,local_lock=none,addr=192.168.43.49 0 0
Any light shed by that must be in the far infrared, certainly not detectable by me.
I can't find any way to get Fedora 35 to set a domain name. The "domainname" command just returns "(none)", and the system apparently assumes "localdomain".
Hi.
On Thu, 27 Jan 2022 08:10:53 -0600 Robert Nichols wrote:
On 1/26/22 7:15 PM, Gordon Messmer wrote:
What does the entry for that filesystem in /proc/mounts look like?�� It should have negotiated mount options that shed some light.
Maybe add the "sec=sys" mount option to the client.
Looks like "sec=sys" is already in there:
plugh-3g:/srv/shared /Public nfs4 rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.172,local_lock=none,addr=192.168.43.49 0 0
What about using nfs3 ?
You will not have any problem mapping lognames/uids/gids.
On 26/01/2022 00:35, Robert Nichols wrote:
In a Fedora 35 VM, all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client. The messages logged are of the form:
"name 'xxxx@local' does not map into domain 'localdomain'"
I have no nfs-idmapd service running. This same setup is running fine on a CentOS 8 VM. I didn't have to do anything special to make this work in CentOS 8. What am I missing here in a Fedora 35 installed with default configuration in a QEMU/KVM virtual machine?
Where does Fedora get its domain name? When I type "hostname --fqdn" I get "hostname: Name or service not known". The CentOS 8 VM apparently gets its domain name from the /etc/hostname file, which contains "cent9-vm.local". This does not appear to work in Fedora 35.
What do you get when you type "hostnamectl"?
On one of my VM's
[egreshko@f35ser ~]$ hostname --fqdn f35ser.greshko.com
[egreshko@f35ser ~]$ hostnamectl Static hostname: f35ser.greshko.com Icon name: computer-vm Chassis: vm Machine ID: c4783bc505a24a9f973009568932bd82 Boot ID: a98191139f9c4d659faa48e5803d923b Virtualization: kvm Operating System: Fedora Linux 35 (Server Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.15-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009
-- Did 황준호 die?
On 1/28/22 1:03 AM, Ed Greshko wrote:
On 26/01/2022 00:35, Robert Nichols wrote:
In a Fedora 35 VM, all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client. The messages logged are of the form:
"name 'xxxx@local' does not map into domain 'localdomain'"
I have no nfs-idmapd service running. This same setup is running fine on a CentOS 8 VM. I didn't have to do anything special to make this work in CentOS 8. What am I missing here in a Fedora 35 installed with default configuration in a QEMU/KVM virtual machine?
Where does Fedora get its domain name? When I type "hostname --fqdn" I get "hostname: Name or service not known". The CentOS 8 VM apparently gets its domain name from the /etc/hostname file, which contains "cent9-vm.local". This does not appear to work in Fedora 35.
What do you get when you type "hostnamectl"?
On one of my VM's
[egreshko@f35ser ~]$ hostname --fqdn f35ser.greshko.com
[egreshko@f35ser ~]$ hostnamectl Static hostname: f35ser.greshko.com Icon name: computer-vm Chassis: vm Machine ID: c4783bc505a24a9f973009568932bd82 Boot ID: a98191139f9c4d659faa48e5803d923b Virtualization: kvm Operating System: Fedora Linux 35 (Server Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.15-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009
fedora ~]# hostname --fqdn fedora [fedora ~]# domainname (none) [fedora ~]# hostnamectl Static hostname: fedora Icon name: computer-vm Chassis: vm Machine ID: 6e701e7fa0dc4996984b6509b40eb940 Boot ID: 5499ef393bd04028a0e92a6d70f3c6a9 Virtualization: kvm Operating System: Fedora Linux 35 (Workstation Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.16-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: Red Hat Hardware Model: KVM
If I put a fqdn in /etc/hostname, that will show up as the static hostname, but "domainname" still returns "(none)" and everything else is the same.
On 28/01/2022 22:08, Robert Nichols wrote:
On 1/28/22 1:03 AM, Ed Greshko wrote:
On 26/01/2022 00:35, Robert Nichols wrote:
In a Fedora 35 VM, all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client. The messages logged are of the form:
"name 'xxxx@local' does not map into domain 'localdomain'"
I have no nfs-idmapd service running. This same setup is running fine on a CentOS 8 VM. I didn't have to do anything special to make this work in CentOS 8. What am I missing here in a Fedora 35 installed with default configuration in a QEMU/KVM virtual machine?
Where does Fedora get its domain name? When I type "hostname --fqdn" I get "hostname: Name or service not known". The CentOS 8 VM apparently gets its domain name from the /etc/hostname file, which contains "cent9-vm.local". This does not appear to work in Fedora 35.
What do you get when you type "hostnamectl"?
On one of my VM's
[egreshko@f35ser ~]$ hostname --fqdn f35ser.greshko.com
[egreshko@f35ser ~]$ hostnamectl Static hostname: f35ser.greshko.com Icon name: computer-vm Chassis: vm Machine ID: c4783bc505a24a9f973009568932bd82 Boot ID: a98191139f9c4d659faa48e5803d923b Virtualization: kvm Operating System: Fedora Linux 35 (Server Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.15-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009
fedora ~]# hostname --fqdn fedora [fedora ~]# domainname (none)
From the man page....
domainname - show or set the system's NIS/YP domain name
So that comman is irrelevant.
[fedora ~]# hostnamectl Static hostname: fedora Icon name: computer-vm Chassis: vm Machine ID: 6e701e7fa0dc4996984b6509b40eb940 Boot ID: 5499ef393bd04028a0e92a6d70f3c6a9 Virtualization: kvm Operating System: Fedora Linux 35 (Workstation Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.16-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: Red Hat Hardware Model: KVM
If I put a fqdn in /etc/hostname, that will show up as the static hostname, but "domainname" still returns "(none)" and everything else is the same.
Rather than manipulating files which may no longer be used.....
As root: hostnamectl name.domain.com
Example: For the host that I mentioned I used "hostnamectl f35ser.greshko.com"
Then hostname --fqdn returns the desired info.
FWIW, I created a user on that system with the same UID and GID of a user on a NAS. Which I think is similar to your setup.
[egreshko@f35ser ~]$ sudo mount nas:/volume1/homes/djensen /mnt [egreshko@f35ser ~]$ mount | grep nas nas:/volume1/homes/djensen on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=2001:b030:112f:2::f355,local_lock=none,addr=2001:b030:112f::19) [egreshko@f35ser ~]$ ll -d /mnt drwxrwxrwx. 1 djensen users 288 Sep 26 08:11 /mnt
-- Did 황준호 die?
On 1/28/22 8:53 AM, Ed Greshko wrote:
On 28/01/2022 22:08, Robert Nichols wrote:
On 1/28/22 1:03 AM, Ed Greshko wrote:
On 26/01/2022 00:35, Robert Nichols wrote:
In a Fedora 35 VM, all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client. The messages logged are of the form:
"name 'xxxx@local' does not map into domain 'localdomain'"
I have no nfs-idmapd service running. This same setup is running fine on a CentOS 8 VM. I didn't have to do anything special to make this work in CentOS 8. What am I missing here in a Fedora 35 installed with default configuration in a QEMU/KVM virtual machine?
Where does Fedora get its domain name? When I type "hostname --fqdn" I get "hostname: Name or service not known". The CentOS 8 VM apparently gets its domain name from the /etc/hostname file, which contains "cent9-vm.local". This does not appear to work in Fedora 35.
What do you get when you type "hostnamectl"?
On one of my VM's
[egreshko@f35ser ~]$ hostname --fqdn f35ser.greshko.com
[egreshko@f35ser ~]$ hostnamectl Static hostname: f35ser.greshko.com Icon name: computer-vm Chassis: vm Machine ID: c4783bc505a24a9f973009568932bd82 Boot ID: a98191139f9c4d659faa48e5803d923b Virtualization: kvm Operating System: Fedora Linux 35 (Server Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.15-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009
fedora ~]# hostname --fqdn fedora [fedora ~]# domainname (none)
From the man page....
domainname - show or set the system's NIS/YP domain name
So that comman is irrelevant.
[fedora ~]# hostnamectl Static hostname: fedora Icon name: computer-vm Chassis: vm Machine ID: 6e701e7fa0dc4996984b6509b40eb940 Boot ID: 5499ef393bd04028a0e92a6d70f3c6a9 Virtualization: kvm Operating System: Fedora Linux 35 (Workstation Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.16-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: Red Hat Hardware Model: KVM
If I put a fqdn in /etc/hostname, that will show up as the static hostname, but "domainname" still returns "(none)" and everything else is the same.
Rather than manipulating files which may no longer be used.....
As root: hostnamectl name.domain.com
Example: For the host that I mentioned I used "hostnamectl f35ser.greshko.com"
Then hostname --fqdn returns the desired info.
FWIW, I created a user on that system with the same UID and GID of a user on a NAS. Which I think is similar to your setup.
No change:
[fedora ~]# hostnamectl hostname fedora.local [fedora ~]# hostnamectl Static hostname: fedora.local Icon name: computer-vm Chassis: vm Machine ID: 6e701e7fa0dc4996984b6509b40eb940 Boot ID: 256c0a3fa9dd4b88bd61145aacc8e106 Virtualization: kvm Operating System: Fedora Linux 35 (Workstation Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.16-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: Red Hat Hardware Model: KVM [fedora ~]# hostname --fqdn hostname: Name or service not known [fedora ~]# hostname fedora.local [fedora ~]# mount -t nfs plugh-3g:/srv/shared /Public [fedora ~]# ll -d /Public drwxrws--x. 11 nobody nobody 4096 2022-01-28 17:20:50 /Public [fedora ~]# journalctl SYSLOG_IDENTIFIER=nfsidmap | tail -4 Jan 28 21:19:14 fedora.local nfsidmap[2461]: nss_getpwnam: name 'root@local' does not map into domain 'localdomain' Jan 28 21:19:14 fedora.local nfsidmap[2463]: nss_name_to_gid: name 'root@local' does not map into domain 'localdomain' Jan 28 21:19:14 fedora.local nfsidmap[2464]: nss_getpwnam: name 'samba@local' does not map into domain 'localdomain' Jan 28 21:19:14 fedora.local nfsidmap[2465]: nss_name_to_gid: name 'admin@local' does not map into domain 'localdomain'
A reboot after setting the hostname yields the same result. And, it's not because of anything special about a ".local" domain. Nothing I put in there causes a FQDN to be set.
On 1/27/22 9:13 AM, Francis.Montagnac@inria.fr wrote:
Hi.
On Thu, 27 Jan 2022 08:10:53 -0600 Robert Nichols wrote:
On 1/26/22 7:15 PM, Gordon Messmer wrote:
What does the entry for that filesystem in /proc/mounts look like? It should have negotiated mount options that shed some light.
Maybe add the "sec=sys" mount option to the client.
Looks like "sec=sys" is already in there:
plugh-3g:/srv/shared /Public nfs4 rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.122.172,local_lock=none,addr=192.168.43.49 0 0
What about using nfs3 ?
You will not have any problem mapping lognames/uids/gids.
Indeed, "-o vers=3" does work and show the correct user and group names. Thanks.
Of course, I'd still like to know why this system is locked to domain "localdomain" and nothing can change that.
On 1/28/22 06:08, Robert Nichols wrote:
Where does Fedora get its domain name? When I type "hostname --fqdn" I get "hostname: Name or service not known". The CentOS 8 VM apparently gets its domain name from the /etc/hostname file, which contains "cent9-vm.local". This does not appear to work in Fedora 35.
If I put a fqdn in /etc/hostname, that will show up as the static hostname, but "domainname" still returns "(none)" and everything else is the same.
Set the system hostname using "hostnamectl hostname <static>.local". Once you do, hostnamectl, domainname and most importantly "nfsidmap -d" should all output the expected domain. In the latter case, that will be "local", and at that point NFS4 should map names correctly.
On 29/01/2022 11:44, Robert Nichols wrote:
No change:
[fedora ~]# hostnamectl hostname fedora.local [fedora ~]# hostnamectl Static hostname: fedora.local Icon name: computer-vm Chassis: vm Machine ID: 6e701e7fa0dc4996984b6509b40eb940 Boot ID: 256c0a3fa9dd4b88bd61145aacc8e106 Virtualization: kvm Operating System: Fedora Linux 35 (Workstation Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.16-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: Red Hat Hardware Model: KVM [fedora ~]# hostname --fqdn hostname: Name or service not known [fedora ~]# hostname fedora.local [fedora ~]# mount -t nfs plugh-3g:/srv/shared /Public [fedora ~]# ll -d /Public drwxrws--x. 11 nobody nobody 4096 2022-01-28 17:20:50 /Public [fedora ~]# journalctl SYSLOG_IDENTIFIER=nfsidmap | tail -4 Jan 28 21:19:14 fedora.local nfsidmap[2461]: nss_getpwnam: name 'root@local' does not map into domain 'localdomain' Jan 28 21:19:14 fedora.local nfsidmap[2463]: nss_name_to_gid: name 'root@local' does not map into domain 'localdomain' Jan 28 21:19:14 fedora.local nfsidmap[2464]: nss_getpwnam: name 'samba@local' does not map into domain 'localdomain' Jan 28 21:19:14 fedora.local nfsidmap[2465]: nss_name_to_gid: name 'admin@local' does not map into domain 'localdomain'
A reboot after setting the hostname yields the same result. And, it's not because of anything special about a ".local" domain. Nothing I put in there causes a FQDN to be set.
Interesting. Here:
[root@f35ser ~]# hostnamectl hostname fedora.local [root@f35ser ~]# exit logout [egreshko@f35ser ~]$ su - Password: [root@fedora ~]# hostnamectl Static hostname: fedora.local Icon name: computer-vm Chassis: vm Machine ID: c4783bc505a24a9f973009568932bd82 Boot ID: a98191139f9c4d659faa48e5803d923b Virtualization: kvm Operating System: Fedora Linux 35 (Server Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.15-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009_ [root@fedora ~]# hostname --fqdn fedora.local [root@fedora ~]# hostname fedora.local [root@fedora ~]# mount -t nfs nas:/volume1/homes/djensen /mnt [root@fedora ~]# ll -d /mnt drwxrwxrwx. 1 djensen users 288 Sep 26 08:11 /mnt [root@fedora ~]# journalctl -b 0 SYSLOG_IDENTIFIER=nfsidmap | tail -4 -- No entries --
Now, I did things a bit differently...... Thinking maybe you have nfs-idmapd.service running and maybe /srv/shared is a directory with other users below it.
[root@fedora ~]# umount /mnt [root@fedora ~]# systemctl start nfs-idmapd.service [root@fedora ~]# mount -t nfs nas:/volume1/homes /mnt [root@fedora ~]# ll -d /mnt drwxrwxrwx. 1 root root 76 Sep 26 06:39 /mnt [root@fedora ~]# ls /mnt admin djensen egreshko eric yyponpon [root@fedora ~]# ll /mnt total 0 drwxrwxrwx. 1 1024 users 10 Dec 16 2019 admin drwxrwxrwx. 1 djensen users 288 Sep 26 08:11 djensen drwxrwxrwx. 1 egreshko egreshko 30 Nov 10 20:21 egreshko drwxrwxrwx. 1 1028 users 10 Dec 18 2019 eric drwxrwxrwx. 1 1027 users 0 Dec 17 2019 yyponpon [root@fedora ~]# journalctl -b 0 | grep idmap Jan 29 14:07:20 fedora.local rpc.idmapd[6264]: Setting log level to 0 Jan 29 14:07:25 fedora.local audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=nfs-idmapd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
So, I don't know what/why your system wouldn't perform the same.
And you notice nfs4 is being used.
[root@fedora ~]# mount | grep nas nas:/volume1/homes on /mnt type nfs4 (rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=2001:b030:112f:2::f355,local_lock=none,addr=2001:b030:112f::19)
One question then.... What do you get for "host plugh-3g"
nas is in my DNS so I get
[root@fedora ~]# host nas nas.greshko.com has address 192.168.1.142 nas.greshko.com has IPv6 address 2001:b030:112f::19
-- Did 황준호 die?
On 29/01/2022 13:44, Gordon Messmer wrote:
On 1/28/22 06:08, Robert Nichols wrote:
Where does Fedora get its domain name? When I type "hostname --fqdn" I get "hostname: Name or service not known". The CentOS 8 VM apparently gets its domain name from the /etc/hostname file, which contains "cent9-vm.local". This does not appear to work in Fedora 35.
If I put a fqdn in /etc/hostname, that will show up as the static hostname, but "domainname" still returns "(none)" and everything else is the same.
Set the system hostname using "hostnamectl hostname <static>.local". Once you do, hostnamectl, domainname and most importantly "nfsidmap -d" should all output the expected domain. In the latter case, that will be "local", and at that point NFS4 should map names correctly.
I have no problems with NFSv4 even with....
[root@fedora ~]# nfsidmap -d localdomain [root@fedora ~]# hostnamectl hostname fedora.local
But I do have nfs-idmapd.service with "Domain = localdomain" in its configuration file. If I change that to "Domain = local" and restart nfs-idmapd.service I do get
[root@fedora ~]# nfsidmap -d local
But everything works no matter what the setting
-- Did 황준호 die?
On 1/28/22 23:32, Ed Greshko wrote:
But I do have nfs-idmapd.service with "Domain = localdomain" in its configuration file. If I change that to "Domain = local" and restart nfs-idmapd.service I do get
[root@fedora ~]# nfsidmap -d local
But everything works no matter what the setting
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
idmapping on NFSv4 is disabled by default when sec=sys (but will be enabled if the server doesn't support that mode).
On 30/01/2022 07:44, Gordon Messmer wrote:
On 1/28/22 23:32, Ed Greshko wrote:
But I do have nfs-idmapd.service with "Domain = localdomain" in its configuration file. If I change that to "Domain = local" and restart nfs-idmapd.service I do get
[root@fedora ~]# nfsidmap -d local
But everything works no matter what the setting
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
idmapping on NFSv4 is disabled by default when sec=sys (but will be enabled if the server doesn't support that mode).
In the initial posting by Robert he wrote:
"I have no nfs-idmapd service running"
and
"all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client"
So, I don't know why we're going down this path. Also, even though he said "I have no nfs-idmapd service running" he showed the following log entry.
Jan 28 21:19:14 fedora.local nfsidmap[2461]: nss_getpwnam: name 'root@local' does not map into domain 'localdomain'
With a test system following those first two statement, I've go no problems. Thus, I'm totally confused.
-- Did 황준호 die?
On 1/29/22 17:20, Ed Greshko wrote:
In the initial posting by Robert he wrote: "I have no nfs-idmapd service running"
Right, but on recent kernels, the client doesn't use rpc.idmapd, it uses "nfsidmap". The fact that rpc.idmapd isn't running doesn't really tell us anything.
"all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and
numeric IDs are the same on the server and client"
So, I don't know why we're going down this path.
Jan 28 21:19:14 fedora.local nfsidmap[2461]: nss_getpwnam: name 'root@local' does not map into domain 'localdomain'
Right, that log entry indicates that idmap is being used on his system. That might mean that the server doesn't support NFSv4 without idmap. Or it might mean the client was configured to enable idmapping.
Without knowing which, we don't really know the right thing to do, except to set the client's domain to match the servers, so that idmapping works as expected.
With a test system following those first two statement, I've go no problems.
I would imagine that idmapping is disabled on your client (and supported by your server).
Check the value of /sys/module/nfsd/parameters/nfs4_disable_idmapping on your NFS server, if it's Linux. And check the value of /sys/module/nfs/parameters/nfs4_disable_idmapping on the client.
On 1/29/22 8:25 PM, Gordon Messmer wrote:
On 1/29/22 17:20, Ed Greshko wrote:
In the initial posting by Robert he wrote: "I have no nfs-idmapd service running"
Right, but on recent kernels, the client doesn't use rpc.idmapd, it uses "nfsidmap". The fact that rpc.idmapd isn't running doesn't really tell us anything.
"all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client"
So, I don't know why we're going down this path.
Jan 28 21:19:14 fedora.local nfsidmap[2461]: nss_getpwnam: name 'root@local' does not map into domain 'localdomain'
Right, that log entry indicates that idmap is being used on his system. That might mean that the server doesn't support NFSv4 without idmap. Or it might mean the client was configured to enable idmapping.
Without knowing which, we don't really know the right thing to do, except to set the client's domain to match the servers, so that idmapping works as expected.
If I could find any way to set the client's domain name, I would. Nothing I try has any effect on the domain name. When I try to set a FQDN with hostnamectl, then "hostnamectl" (with no arguments) shows that FQDN as the static hostname, but "hostname --fqdn" responds with "hostname: Name or service not known", and "mount -t nfs ..." causes the various "... does not map into domain 'localdomain'" messages to be logged.
With a test system following those first two statement, I've go no problems.
I would imagine that idmapping is disabled on your client (and supported by your server).
Check the value of /sys/module/nfsd/parameters/nfs4_disable_idmapping on your NFS server, if it's Linux. And check the value of /sys/module/nfs/parameters/nfs4_disable_idmapping on the client.
On the server: [plugh-3g ~]# cat /sys/module/nfsd/parameters/nfs4_disable_idmapping N
On 30/01/2022 12:36, Robert Nichols wrote:
On 1/29/22 8:25 PM, Gordon Messmer wrote:
On 1/29/22 17:20, Ed Greshko wrote:
In the initial posting by Robert he wrote: "I have no nfs-idmapd service running"
Right, but on recent kernels, the client doesn't use rpc.idmapd, it uses "nfsidmap". The fact that rpc.idmapd isn't running doesn't really tell us anything.
"all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client"
So, I don't know why we're going down this path.
Jan 28 21:19:14 fedora.local nfsidmap[2461]: nss_getpwnam: name 'root@local' does not map into domain 'localdomain'
Right, that log entry indicates that idmap is being used on his system. That might mean that the server doesn't support NFSv4 without idmap. Or it might mean the client was configured to enable idmapping.
Without knowing which, we don't really know the right thing to do, except to set the client's domain to match the servers, so that idmapping works as expected.
If I could find any way to set the client's domain name, I would. Nothing I try has any effect on the domain name. When I try to set a FQDN with hostnamectl, then "hostnamectl" (with no arguments) shows that FQDN as the static hostname, but "hostname --fqdn" responds with "hostname: Name or service not known", and "mount -t nfs ..." causes the various "... does not map into domain 'localdomain'" messages to be logged.
I think you need to be a bit more specific in your replies. Are the client and the server both Fedora systems, or at least Linux? Mine are now. I was using a NAS but I don't have full root privileges.
In both cases the "Domain" line /etc/idmapd.conf are commented out. The line starts with "#".
So on the server.....
[root@f35ser ~]# hostnamectl Static hostname: f35ser.greshko.com Icon name: computer-vm Chassis: vm Machine ID: c4783bc505a24a9f973009568932bd82 Boot ID: e49e999bf75949b6a27dba21bc96c15e Virtualization: kvm Operating System: Fedora Linux 35 (Server Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.15-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009
and
[root@f35ser ~]# hostname --fqdn f35ser.greshko.com
What is the fqdn for the host you are looking for? ________________________________________________________________________
On the client
[root@f35m ~]# hostnamectl Static hostname: f35m.greshko.com Icon name: computer-vm Chassis: vm Machine ID: c0682edcc202402dbe806170e81bf3dd Boot ID: c962ece869f941e3becd43982ae96394 Virtualization: kvm Operating System: Fedora Linux 35 (MATE-Compiz) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.12-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009_
[root@f35m ~]# hostname --fqdn f35m.greshko.com
__________________________________________________________________________
Oh the client
[root@f35m ~]# mount f35ser:/home /mnt [root@f35m ~]# ll /mnt total 0 drwx------. 1 djensen users 76 Jan 28 15:42 djensen drwx------. 1 egreshko egreshko 240 Jan 30 12:59 egreshko
And....
[root@f35m ~]# systemctl status nfs-idmapd.service ○ nfs-idmapd.service - NFSv4 ID-name mapping service Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static) Active: inactive (dead)
So, it never ran.
Also,
[root@f35m ~]# cat /sys/module/nfs/parameters/nfs4_disable cat: /sys/module/nfs/parameters/nfs4_disable: No such file or directory
_____________________________________________________________________
On the server
[root@f35ser ~]# cat /sys/module/nfsd/parameters/nfs4_disable_idmapping Y
● nfs-idmapd.service - NFSv4 ID-name mapping service Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static) Active: active (running) since Sun 2022-01-30 13:15:20 CST; 1h 20min ago Process: 1530 ExecStart=/usr/sbin/rpc.idmapd (code=exited, status=0/SUCCESS) Main PID: 1535 (rpc.idmapd) Tasks: 1 (limit: 2314) Memory: 844.0K CPU: 6ms CGroup: /system.slice/nfs-idmapd.service └─1535 /usr/sbin/rpc.idmapd
Jan 30 13:15:19 f35ser.greshko.com systemd[1]: Starting NFSv4 ID-name mapping sevice
Sio, what hostname and domainname do you want to us/
-- Did 황준호 die?
On 1/29/22 20:36, Robert Nichols wrote:
If I could find any way to set the client's domain name, I would. Nothing I try has any effect on the domain name. When I try to set a FQDN with hostnamectl, then "hostnamectl" (with no arguments) shows that FQDN as the static hostname, but "hostname --fqdn" responds with "hostname: Name or service not known", and "mount -t nfs ..." causes the various "... does not map into domain 'localdomain'" messages to be logged.
I *think* the "name or service not known" message means that the hostname you've set isn't in /etc/hosts, which is the normal config. That doesn't mean your domain name isn't being set.
I also think that your client's domain name is "local", while your NFS server's domain name is "localdomain", and you've enabled mapping, which is why everything is mapped to "nobody".
So, you've got several problems that aren't necessarily related, and aren't influencing the other.
In any case, you should be checking the output of "nfsidmap -d", not "hostname --fqdn".
On the server: [plugh-3g ~]# cat /sys/module/nfsd/parameters/nfs4_disable_idmapping N
I believe the default is 'Y'.
You should be able to resolve the problem by setting hostnames with matching domains on both systems, or setting a domain name in /etc/idmapd.conf, or disabling idmapping on both server and client.
On 1/30/22 1:34 AM, Ed Greshko wrote:
On 30/01/2022 12:36, Robert Nichols wrote:
On 1/29/22 8:25 PM, Gordon Messmer wrote:
On 1/29/22 17:20, Ed Greshko wrote:
In the initial posting by Robert he wrote: "I have no nfs-idmapd service running"
Right, but on recent kernels, the client doesn't use rpc.idmapd, it uses "nfsidmap". The fact that rpc.idmapd isn't running doesn't really tell us anything.
"all users and groups in an NFS mounted filesystem are mapped to "nobody" even though the names and numeric IDs are the same on the server and client"
So, I don't know why we're going down this path.
Jan 28 21:19:14 fedora.local nfsidmap[2461]: nss_getpwnam: name 'root@local' does not map into domain 'localdomain'
Right, that log entry indicates that idmap is being used on his system. That might mean that the server doesn't support NFSv4 without idmap. Or it might mean the client was configured to enable idmapping.
Without knowing which, we don't really know the right thing to do, except to set the client's domain to match the servers, so that idmapping works as expected.
If I could find any way to set the client's domain name, I would. Nothing I try has any effect on the domain name. When I try to set a FQDN with hostnamectl, then "hostnamectl" (with no arguments) shows that FQDN as the static hostname, but "hostname --fqdn" responds with "hostname: Name or service not known", and "mount -t nfs ..." causes the various "... does not map into domain 'localdomain'" messages to be logged.
I think you need to be a bit more specific in your replies. Are the client and the server both Fedora systems, or at least Linux? Mine are now. I was using a NAS but I don't have full root privileges.
In both cases the "Domain" line /etc/idmapd.conf are commented out. The line starts with "#".
So on the server.....
[root@f35ser ~]# hostnamectl Static hostname: f35ser.greshko.com Icon name: computer-vm Chassis: vm Machine ID: c4783bc505a24a9f973009568932bd82 Boot ID: e49e999bf75949b6a27dba21bc96c15e Virtualization: kvm Operating System: Fedora Linux 35 (Server Edition) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.15-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009
and
[root@f35ser ~]# hostname --fqdn f35ser.greshko.com
What is the fqdn for the host you are looking for? ________________________________________________________________________
On the client
[root@f35m ~]# hostnamectl Static hostname: f35m.greshko.com Icon name: computer-vm Chassis: vm Machine ID: c0682edcc202402dbe806170e81bf3dd Boot ID: c962ece869f941e3becd43982ae96394 Virtualization: kvm Operating System: Fedora Linux 35 (MATE-Compiz) CPE OS Name: cpe:/o:fedoraproject:fedora:35 Kernel: Linux 5.15.12-200.fc35.x86_64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _Q35 + ICH9, 2009_
[root@f35m ~]# hostname --fqdn f35m.greshko.com
Oh the client
[root@f35m ~]# mount f35ser:/home /mnt [root@f35m ~]# ll /mnt total 0 drwx------. 1 djensen users 76 Jan 28 15:42 djensen drwx------. 1 egreshko egreshko 240 Jan 30 12:59 egreshko
And....
[root@f35m ~]# systemctl status nfs-idmapd.service ○ nfs-idmapd.service - NFSv4 ID-name mapping service Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static) Active: inactive (dead)
So, it never ran.
Also,
[root@f35m ~]# cat /sys/module/nfs/parameters/nfs4_disable cat: /sys/module/nfs/parameters/nfs4_disable: No such file or directory
On the server
[root@f35ser ~]# cat /sys/module/nfsd/parameters/nfs4_disable_idmapping Y
● nfs-idmapd.service - NFSv4 ID-name mapping service Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static) Active: active (running) since Sun 2022-01-30 13:15:20 CST; 1h 20min ago Process: 1530 ExecStart=/usr/sbin/rpc.idmapd (code=exited, status=0/SUCCESS) Main PID: 1535 (rpc.idmapd) Tasks: 1 (limit: 2314) Memory: 844.0K CPU: 6ms CGroup: /system.slice/nfs-idmapd.service └─1535 /usr/sbin/rpc.idmapd
Jan 30 13:15:19 f35ser.greshko.com systemd[1]: Starting NFSv4 ID-name mapping sevice
Sio, what hostname and domainname do you want to us/
The server is a CentOS 7 Linux system. [plugh-3g ~]# hostnamectl Static hostname: plugh-3g.local Icon name: computer-desktop Chassis: desktop Machine ID: 21619c9bea8742ac907dd22d3ebb9aef Boot ID: 0866513c82c34909b732fc3cb8d07d54 Operating System: CentOS Linux 7 (Core) CPE OS Name: cpe:/o:centos:centos:7 Kernel: Linux 3.10.0-1160.49.1.el7.x86_64 Architecture: x86-64 [plugh-3g ~]# hostname --fqdn plugh-3g.local
The client is Fedora 35: [fedora ~]# systemctl status nfs-idmapd.service ○ nfs-idmapd.service - NFSv4 ID-name mapping service Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static) Active: inactive (dead) [fedora ~]# mount -t nfs plugh-3g:/srv/shared /Public [fedora ~]# ll /Public ls: cannot open directory '/Public': Permission denied [fedora ~]# ll -d /Public drwxrws--x. 11 nobody nobody 4096 2022-01-30 08:48:27 /Public
As it is for you, the "Domain" line /etc/idmapd.conf is commented out on both server and client.
I don't care what the client's hostname is, "fedora" is fine, and I can set that to anything I want. I have been unable to set the Fedora 35 client's domain name to anything besides "localdomain".
FINALLY!! I can get it all to work by putting "fedora.local" in /etc/hostname _and_ editing /etc/hosts to have "fedora.local" as the _first_ name for 127.0.0.1 .
[fedora ~]# cat /etc/hosts 127.0.0.1 fedora.local localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
With both of those in place, "dnsdomainname" and "nfsidmap -d" both return "local", and the mapping works.
I didn't have to mess with /etc/hosts on my CentOS 7 or CentOS 8 clients. They work fine with the default: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Now, why on Earth did I want to run Fedora anyway? Oh that's right, there was an application I wanted to try that was only available as a flatpak on CentOS 8, and flatpaks have their own level of pain. That's all water over the dam now.
I'm out of here. Thanks to all who offered help.
On 31/01/2022 00:13, Robert Nichols wrote:
FINALLY!! I can get it all to work by putting "fedora.local" in /etc/hostname _and_ editing /etc/hosts to have "fedora.local" as the _first_ name for 127.0.0.1 .
I installed a Centos7 system and during the install process called it fedora.local. By default this was placed in etc/hostname.
I did not add anything in the hosts file. I did make an entry for the host cos7 in the DNS to make it easier to contact. I also did not make a reverse entry.
While yours is:
[fedora ~]# cat /etc/hosts 127.0.0.1 fedora.local localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Mine is
[root@fedora ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
With both of those in place, "dnsdomainname" and "nfsidmap -d" both return "local", and the mapping works.
Same here. No issues.
Now, why on Earth did I want to run Fedora anyway? Oh that's right, there was an application I wanted to try that was only available as a flatpak on CentOS 8, and flatpaks have their own level of pain. That's all water over the dam now.
I'm out of here. Thanks to all who offered help.
Happy all is well. Wondering why on earth you've not upgraded your systems to Centos8 :-) :-)
FWIW, I too stay away from Flatpaks. For me they are more pain than they are worth.
-- Did 황준호 die?
On Mon, 2022-01-31 at 13:24 +0800, Ed Greshko wrote:
I installed a Centos7 system and during the install process called it fedora.local. By default this was placed in etc/hostname.
Wasn't ".local" and Avahi/Bonjour/mDNS/ZeroConf non-traditional DHCP and DNS thing? Does it still require different configuration techniques?
I've always steered clear of it. Like SMB, instead of having a centrol control that you could configure to work how you wanted it, everything has some kind of round-table conference, repeatedly, and might manage to sort things out between themselves. But, like a committee of volunteers, was also likely to mismanage the whole shebang.
Happy all is well. Wondering why on earth you've not upgraded your systems to Centos8 :-) :-)
I have a server on CentOS 7. I looked at 8 by temporarily installing it on another computer, and there was so many problems I'd have to resolve, without improving one particular thing that I actually cared about, that I couldn't see it being worth my while.
Not long ago, 16 Nov 2021, I had one of their email press releases stating that the latest version of 8 had just been released and that it's EOL would be 31 Dec 2021. I had to check that wasn't a typo.
A bit more internet noodling around suggested that if you'd chosen to use CentOS for the usual reasons (a server that you wanted to be stable), then CentOS Stream wasn't going to be what you wanted.
FWIW, I too stay away from Flatpaks. For me they are more pain than they are worth.
Slightly works on most things, only fully works on the same system as the programmer used...
I can't print anything using packages that didn't come from our own repos (whether that be Fedora or CentOS), it just doesn't work. And it ruins one of the chief benefits of having a distro with its own repo (everything from one central place, that usually just works because they've all been tested together).
On 31/01/2022 14:39, Tim via users wrote:
On Mon, 2022-01-31 at 13:24 +0800, Ed Greshko wrote:
I installed a Centos7 system and during the install process called it fedora.local. By default this was placed in etc/hostname.
Wasn't ".local" and Avahi/Bonjour/mDNS/ZeroConf non-traditional DHCP and DNS thing? Does it still require different configuration techniques?
I've always steered clear of it. Like SMB, instead of having a centrol control that you could configure to work how you wanted it, everything has some kind of round-table conference, repeatedly, and might manage to sort things out between themselves. But, like a committee of volunteers, was also likely to mismanage the whole shebang.
I don't know much about Avahi/Bonjour/mDNS/ZeroConf I think it is/was a way to shoehorn Linux into some Windows environments. I hardly had to deal with that.
I also didn't deal much with SMB as only ever had a couple of Windows systems. Now None. And the companies I worked for had staff that dealt with that. Not to toot my horn, I did have to come to their rescue from time to time. It didn't make it any easier with their horrible understanding of networking.
I really just setup Centos7 to see if I could replicate the difficulty the OP was having. Frankly, I had no issues so I can't comment on that.
Happy all is well. Wondering why on earth you've not upgraded your systems to Centos8 :-) :-)
I have a server on CentOS 7. I looked at 8 by temporarily installing it on another computer, and there was so many problems I'd have to resolve, without improving one particular thing that I actually cared about, that I couldn't see it being worth my while.
I don't really use CentOS. I just keep basic installs as VM's in the case they come up as being used by someone else.
Not long ago, 16 Nov 2021, I had one of their email press releases stating that the latest version of 8 had just been released and that it's EOL would be 31 Dec 2021. I had to check that wasn't a typo.
I do need to see what direction CentOS is now talking. If only for "educational" purposes only. I don't intend to become a "subject matter expert" :-)
A bit more internet noodling around suggested that if you'd chosen to use CentOS for the usual reasons (a server that you wanted to be stable), then CentOS Stream wasn't going to be what you wanted.
FWIW, I too stay away from Flatpaks. For me they are more pain than they are worth.
Slightly works on most things, only fully works on the same system as the programmer used...
I can't print anything using packages that didn't come from our own repos (whether that be Fedora or CentOS), it just doesn't work. And it ruins one of the chief benefits of having a distro with its own repo (everything from one central place, that usually just works because they've all been tested together).
Yes, I think some of your comments on this list about Flatpaks assisted in keeping me away from them. :-) :-)
-- Did 황준호 die?
On Mon, 2022-01-31 at 16:59 +0800, Ed Greshko wrote:
I don't know much about Avahi/Bonjour/mDNS/ZeroConf I think it is/was a way to shoehorn Linux into some Windows environments. I hardly had to deal with that.
I also didn't deal much with SMB as only ever had a couple of Windows systems. Now None. And the companies I worked for had staff that dealt with that. Not to toot my horn, I did have to come to their rescue from time to time. It didn't make it any easier with their horrible understanding of networking.
I think we can blame Windows knowledge (hurrumph) with a lot of the internet's woes. :-p
In the past, and probably still now:
Avahi, et al, use a decentralised (lack of) method to let all the clients try and sort things out by themselves, and discover things on the network (like your printer, NAS, etc), it's not just addressing but device and feature discovery. It's a form of self-advertising *and* network probing by each client, and it did this over a different set of ports like DNS and DHCP, it used the ".local" domain, and, it wanted to be in control of it.
i.e. Trying to make use of .local outside of Avahi's self-management can lead to nasty surprises. Take this one bit of advice into long term memory, don't use it with your DHCP server, or manual address naming, ESPECIALLY if Avahi, et al, are on your network.
If everything works, then fine. But if something stuffs it up, you don't have *one* thing to try and configure into submission. You have to go around trying to beat all the clients into submission.
With traditional DHCP and DNS serving, you have one server that everything else is controlled by. You configure the server to do what you want. You configure clients (if you have to) to obey the server, but generally the clients default was to obey a server, and you had to manually intervene to do it some other way.
Linux had an interesting quirk of using ".localdomain" as its LAN domain (at least on the few distros I've played with). Microsoft may have used .mshome or .home (as my router uses, actually it also uses .router, not that it tells you about any of this). And plenty of people have used .lan as their domain. But there's no well-defined LAN domain name to use in lieu of registering a real domain name.
With a mixed system, you're in for a world of pain, because Avahi, DHCP and DNS don't talk to each other.
Individually configuring devices in a business was a complete pain, but used to be not too hard in a home environment. But, now, home environments are possibly more complex than business ones. Modem/router, one or more desktop computers, one or more laptops, several phones and tablets, smart TVs and media players, (allegedly) smart lighting lightbulbs in every room, smart central heating and air conditioning, smart solar and vehicle charging.
And at some stage people are going to stop making devices look for DHCP and fallback on Avahi, they'll decide to simplify things and just follow the latest fad. You'll end up with a gadget that only does Avahi.
In my opinion, Avahi should only be used on a network where nothing else will be doing address management. And my current devices work that way. Quite apart from me turning it off where I can, so far everything will configure themselves using DHCP first, and either ignore Avahi, or use it in addition (e.g. your printer may be discovered, as a printing device, using it).
If you want to do use names, rather than just numerical IP addressing, on your LAN. Thought needs to go into your hostnames and domain names, and keeping an eye on trends that appear outside of your LAN. e.g. It could be that .lan starts getting a defined use that'll clash with yours, and simply calling your PC "fedora" will annoy you if you have more than one PC with fedora installations.
There's some value in registering a real domain name, even if you don't host websites, etc. It's yours to use as you like, you control it. And there are still a few cheap registrars around. A few bucks a year for less networking pain can be well worth it.
On Mon, 2022-01-31 at 20:41 +1030, Tim via users wrote:
Linux had an interesting quirk of using ".localdomain" as its LAN domain (at least on the few distros I've played with). Microsoft may have used .mshome or .home (as my router uses, actually it also uses .router, not that it tells you about any of this). And plenty of people have used .lan as their domain. But there's no well-defined LAN domain name to use in lieu of registering a real domain name.
Ooh, just found an actually sensible suggestion. Apparently home.arpa has been reserved for this kind of special use.
https://datatracker.ietf.org/doc/html/rfc8375
"Reserved" in as much as it shouldn't end up being used on the internet, it shouldn't clash with existing oddball uses of some domain names in home networks (.home, .homenet, .host, .local, .corp, .mail, and various others, where your attempt to manually uses it clashes with some automatic system).
".arpa" is owned, and they're able to set rules about its usage (so home.arpa was possible). Trying to set up a new top level domain, such as .home, would require getting a plethora of organisations to agree to something new, and require getting another plethora of organisations to stop using it.
But it won't give you a unique name. That's usually not a problem, and gives you a kind of "I'm Spartacus" anonymity when one of your hostnames gets written about in public. It might be an issue if you take your computer to a LAN party, but I wonder how often that happens any more (with wider spreading of broadband, so people can play games from home, and the last couple of years of the plague).
There's some advice in https://datatracker.ietf.org/doc/html/rfc6762#appendix-G about some domain names that have been used (in the past) without causing their users problems:
.intranet. .internal. .private. .corp. .home. .lan.
But I have at least one modem/router that uses .home, and you have no control over it, and its not documented (I only found out by debugging a failing network). There's potential for headaches for anything that's not specifically designed for how you might use it.
So, the other advice I mentioned still stands; if you want to use domain names within a network, registering a real one is the best approach. It also helps if you ever want to horse around with security certificates (yes, some people do use SSL, etc., within a LAN).
The trouble with using someone else's domainname, such as .local, or even that .home.arpa one, is that the rules and recommendations can change on you. Years ago, Microsoft recommended people use .local, now you're advised not to use it, because it's used for a specific networking scheme.
I have a domain name, I use it publically. And, I use a .lan. subdomain of it within my lan. Like this set of examples:
www.example.com (a public website) server.lan.example.com (an internal server PC) mail.lan.example.com (an internal mail server) printer.lan.example.com (an internal printer)
There's a Blake's 7 joke in there. ;-)
On 1/30/22 11:24 PM, Ed Greshko wrote:
On 31/01/2022 00:13, Robert Nichols wrote:
FINALLY!! I can get it all to work by putting "fedora.local" in /etc/hostname _and_ editing /etc/hosts to have "fedora.local" as the _first_ name for 127.0.0.1 .
I installed a Centos7 system and during the install process called it fedora.local. By default this was placed in etc/hostname.
I did not add anything in the hosts file. I did make an entry for the host cos7 in the DNS to make it easier to contact. I also did not make a reverse entry.
While yours is:
[fedora ~]# cat /etc/hosts 127.0.0.1 fedora.local localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Mine is
[root@fedora ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
With both of those in place, "dnsdomainname" and "nfsidmap -d" both return "local", and the mapping works.
Same here. No issues.
My problem is _not_ with the CentOS 7 server. That works just fine with an /etc/hosts file like yours. It is the Fedora 35 client that needs the /etc/hosts modification to accept a domain name.
Now, why on Earth did I want to run Fedora anyway? Oh that's right, there was an application I wanted to try that was only available as a flatpak on CentOS 8, and flatpaks have their own level of pain. That's all water over the dam now.
I'm out of here. Thanks to all who offered help.
Happy all is well. Wondering why on earth you've not upgraded your systems to Centos8 :-) :-)
When I upgrade that server, it is _not_ going to be CentOS, probably Rocky Linux or AlmaLinux. I have no idea what I'm going to use as my "daily driver" OS, perhaps something outside of the Red Hat family.
On 31/01/2022 22:19, Robert Nichols wrote:
On 1/30/22 11:24 PM, Ed Greshko wrote:
On 31/01/2022 00:13, Robert Nichols wrote:
FINALLY!! I can get it all to work by putting "fedora.local" in /etc/hostname _and_ editing /etc/hosts to have "fedora.local" as the _first_ name for 127.0.0.1 .
I installed a Centos7 system and during the install process called it fedora.local. By default this was placed in etc/hostname.
I did not add anything in the hosts file. I did make an entry for the host cos7 in the DNS to make it easier to contact. I also did not make a reverse entry.
While yours is:
[fedora ~]# cat /etc/hosts 127.0.0.1 fedora.local localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Mine is
[root@fedora ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
With both of those in place, "dnsdomainname" and "nfsidmap -d" both return "local", and the mapping works.
Same here. No issues.
My problem is _not_ with the CentOS 7 server. That works just fine with an /etc/hosts file like yours. It is the Fedora 35 client that needs the /etc/hosts modification to accept a domain name.
I needed no such change to my F35's host file for it to function properly. Probably will never find out why yours did.
Now, why on Earth did I want to run Fedora anyway? Oh that's right, there was an application I wanted to try that was only available as a flatpak on CentOS 8, and flatpaks have their own level of pain. That's all water over the dam now.
I'm out of here. Thanks to all who offered help.
Happy all is well. Wondering why on earth you've not upgraded your systems to Centos8 :-) :-)
When I upgrade that server, it is _not_ going to be CentOS, probably Rocky Linux or AlmaLinux. I have no idea what I'm going to use as my "daily driver" OS, perhaps something outside of the Red Hat family.
OK. I'm sure you're well aware that no matter what distro you finally choose it will have its own quirks.
-- Did 황준호 die?
Ed Greshko wrote:
On 31/01/2022 14:39, Tim via users wrote:
Not long ago, 16 Nov 2021, I had one of their email press releases stating that the latest version of 8 had just been released and that it's EOL would be 31 Dec 2021. I had to check that wasn't a typo.
I do need to see what direction CentOS is now talking. If only for "educational" purposes only. I don't intend to become a "subject matter expert" :-)
A bit more internet noodling around suggested that if you'd chosen to use CentOS for the usual reasons (a server that you wanted to be stable), then CentOS Stream wasn't going to be what you wanted.
At the risk of going a little off-topic, maybe a few links will be useful for other Fedora folks who haven't followed the changes in the CentOS project.
CentOS Linux 8 as a rebuild of RHEL 8 has now gone EOL. There won't be a CentOS Linux 9.
For folks who want a rebuild of RHEL 8 (and later), there are at least two projects providing it, Rocky Linux and Alma Linux:
https://rockylinux.org/ https://almalinux.org/
CentOS Stream 8 is a new release. It is where the next point release of RHEL 8 will be worked on in the open. More details on how CentOS Stream differs from CentOS Linux:
https://www.centos.org/cl-vs-cs
For folks running a home server, this is very likely a fine solution. If not, there's the rebuilds mentioned above. Or you can use RHEL, as it's (more or less) free to run on up to 16 nodes for things like a home server.
It's trivial to convert a system running CentOS Linux 8 to CentOS Stream 8:
dnf --disablerepo '*' --allowerasing install http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/Packages/centos-st... dnf distro-sync
Per https://www.centos.org/centos-stream/#centos-stream-8
Both Rocky and Alma have scripts to convert an existing CentOS Linux 8 system as well.
On 1/31/22 06:27, Ed Greshko wrote:
I needed no such change to my F35's host file for it to function properly. Probably will never find out why yours did.
Probably because the server configuration was modified. Robert reported:
On the server: [plugh-3g ~]# cat /sys/module/nfsd/parameters/nfs4_disable_idmapping N
The default setting is 'Y' (in which case idmap is disabled for NFSv4 with sec=sys).
If idmapping is enabled for NFSv4 with sec=sys, then there are several ways to match domains, and one of them needs to be used.
On Mon, 2022-01-31 at 21:52 +1030, Tim via users wrote:
".arpa" is owned, and they're able to set rules about its usage (so home.arpa was possible). Trying to set up a new top level domain, such as .home, would require getting a plethora of organisations to agree to something new, and require getting another plethora of organisations to stop using it.
Trying to / hoping to, finally finish my train of thought...
One of the many problems with using domain names within a LAN is how name resolution is handled.
If your client doesn't already know the IP for a hostname, it has to look it up. If you have your own DNS server, or equivalent (*), and it's configured properly, then everything works nicely.
(* You can use hosts files for static addresses. Avahi, et al, use their own systems - it's not DNS, but similar in function.)
If it doesn't already know the IP, then your computer can end up trying to query public servers outside your LAN for the answers. That causes at least two problems: The obvious one to most users is the lack of privacy. The obvious one to admin types is that someone else's servers can get hammered with millions of queries (globally speaking) that they shouldn't do. Not to mention that the query can't be properly answered, so you get a badly behaving network.
Some of the suggested domain-names to use in LANs are also part of this solution. Since .local is supposed to only be used in LANs, every public DNS server can be preconfigured to automatically blacklist such queries. Sure, they still get hammered with badly configured systems, but the damage gets stopped at a border, rather than propagate through entire trees of DNS servers. The same can be said about several other commonly used LAN domain names (the public DNS servers *can* be preconfigured to halt LAN queries at the border, and probably *will* have to be for the foreseeable future, mitigating problems being caused on the internet, and forcing users to properly set up their LANs).
And, your own internal networking can make decisions about how to resolve such addresses. It should know that .local addresses will be internally handled, and not attempt to bother DNS servers in the outside world.
The same cannot be said about other random, unknown, or ill-advised, fake domain names that people may use within their LANs.
On 1 Feb 2022, at 18:59, Tim via users users@lists.fedoraproject.org wrote:
If it doesn't already know the IP, then your computer can end up trying to query public servers outside your LAN for the answers.
I thought that mDNS that Avahi implements only uses multicast on the LAN. You could set up multicast across multiple LAN segments.
How does that end up getting answers from the internet? Especially when all ISPs block multicast it seems.
Barry
On Tue, 2022-02-01 at 22:38 +0000, Barry wrote:
I thought that mDNS that Avahi implements only uses multicast on the LAN. You could set up multicast across multiple LAN segments.
How does that end up getting answers from the internet? Especially when all ISPs block multicast it seems.
It shouldn't (go out on the internet). But what happens when something doesn't get an answer from within the LAN, or, some part of your LAN isn't using mDNS? Is *it*, then, going to try a normal DNS query?
*It* being something on your computer, not specifically Avahi, querying beyond the internal LAN.
On a whim, I've just tried this on my system which doesn't use mDNS:
$ dig router.local
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.8 <<>> router.local ;; global options: +cmd ;; Got answer: ;; WARNING: .local is reserved for Multicast DNS ;; You are currently testing what happens when an mDNS query is leaked to DNS ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41071 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;router.local. IN A
;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2022020101 1800 900 604800 86400
;; Query time: 86 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Feb 02 13:17:02 ACDT 2022 ;; MSG SIZE rcvd: 116
So, the "dig" tool, at least, is prepared to break out of the confines of my LAN. And, so it would seem, is BIND (I have BIND running on this machine), and dig queried it. I suppose I should customise BIND to internally abort .local domain name queries. Though I think I have turned off mDNS/Avahi, et al, in all the devices in the LAN.
On the other hand:
$ nslookup router.local Server: 127.0.0.1 Address: 127.0.0.1#53
** server can't find router.local: NXDOMAIN
Doesn't really tell me how far the query went before it got nixed.
On 1/31/22 02:11, Tim via users wrote:
And at some stage people are going to stop making devices look for DHCP and fallback on Avahi, they'll decide to simplify things and just follow the latest fad. You'll end up with a gadget that only does Avahi.
You have this quite confused. DHCP and mdns are orthogonal. The device still gets an IP normally using DHCP. mdns is a replacement for dynamic dns on a local network. It's so that you can find your device regardless of what IP it ends up getting because it has a fixed name. And it broadcasts that info locally so that other devices know it's there. Whether or not you personally like it, it's very useful and extremely helpful for less technical people.
-
Barry -
Ed Greshko -
Francis.Montagnac＠inria.fr -
Gordon Messmer -
Robert Nichols -
Samuel Sieb -
stan -
Tim -
Todd Zullinger