Hello all,
I have observed a problem with a diskless PXE client I am attempting to configure. PXE/NFS/DHCP/TFTPd server is running CentOS5.1 and the Diskless workstation's root and kernel was extracted from a CentOS5.1 (custom kernel due to setting to enable Root File System support).
Problem: When the diskless client boots and logs in I notice that my root user is being squashed, even if I have exported the root with the "no_root_squash" option. The exports file contains this line: /export/images *(rw,no_root_squash,no_subtree_check)
1. Creating a file as root gives it nobody permission: rw-r--r-- 1 65534 65534 0 Feb 26 16:30 foo 2. When I explicitly mount the same export from the booted workstation and create another file; this time, it is created as root: -rw-r--r-- 1 root root 0 Feb 26 16:31 bar
3. I checked the /proc/mounts and notice there are differences in the NFS options it has accepted during mount: rootfs / rootfs rw 0 0 /dev/root / nfs rw,vers=2,rsize=4096,wsize=4096,hard,nolock,proto=udp,timeo=11,retrans=2,sec=null,addr=192.16.10.5 0 0
192.16.10.5:/tftpboot /mnt/test nfs rw,vers=3,rsize=32768,wsize=32768,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=192.168.16.5 0 0
4. I try to append NFS options to my APPEND line to force: NFS version3, change r/wsize, use tcp protocol and change the sec from null to sys (null seems to be the parameter that affects the NFS ownership/permission). My /tftpboot/pxelinux.cfg/default file contains the following:
nfsroot=192.168.16.5:/export/images/centos51_x86-64,nfsversvers=3,tcp,rsize=32768,wsize=32768,sec=sys ip=dhcp
5. All options are honored except for the "sec=sys" option. Below is the output of the /proc/cmdline:
/proc/cmdline: root=/dev/nfs rw nfsroot=192.168.16.5:/export/images/centos51_x86-64,nfsvers=3,tcp,rsize=32768,wsize=32768,sec=sys ip=dhcp BOOT_IMAGE=vmlinuz-2.6.18-custom-2.6.18-53.el5
6. But the /proc/mounts shows that the "sec=" parameter is still set to NULL. /proc/mounts: rootfs / rootfs rw 0 0 /dev/root / nfs rw,vers=3,rsize=3278,wsize=3478,hard,nolock,proto=tcp,timeo=11,retrans=2,sec=null,addr=192.168.16.5 0 0
............
Kernel versions:
PXE server --> uname -a Linux qatest1 2.6.18-53.1.13.el5xen #1 SMP Tue Feb 12 13:33:07 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Diskless Workstation's kernel and root are extracted from this: Linux localhost.localdomain 2.6.18-custom-2.6.18-53.el5 #1 SMP Wed Feb 20 08:45:23 PST 2008 x86_64 x86_64 x86_64 GNU/Linux
Any help would be greatly appreciated.
on 2/26/2008 5:31 PM vincenzo romero spake the following:
Hello all,
I have observed a problem with a diskless PXE client I am attempting to configure. PXE/NFS/DHCP/TFTPd server is running CentOS5.1 and the Diskless workstation's root and kernel was extracted from a CentOS5.1 (custom kernel due to setting to enable Root File System support).
Problem: When the diskless client boots and logs in I notice that my root user is being squashed, even if I have exported the root with the "no_root_squash" option. The exports file contains this line: /export/images *(rw,no_root_squash,no_subtree_check)
- Creating a file as root gives it nobody permission:
rw-r--r-- 1 65534 65534 0 Feb 26 16:30 foo 2. When I explicitly mount the same export from the booted workstation and create another file; this time, it is created as root: -rw-r--r-- 1 root root 0 Feb 26 16:31 bar
- I checked the /proc/mounts and notice there are differences in the
NFS options it has accepted during mount: rootfs / rootfs rw 0 0 /dev/root / nfs rw,vers=2,rsize=4096,wsize=4096,hard,nolock,proto=udp,timeo=11,retrans=2,sec=null,addr=192.16.10.5 0 0
192.16.10.5:/tftpboot /mnt/test nfs rw,vers=3,rsize=32768,wsize=32768,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=192.168.16.5 0 0
- I try to append NFS options to my APPEND line to force: NFS
version3, change r/wsize, use tcp protocol and change the sec from null to sys (null seems to be the parameter that affects the NFS ownership/permission). My /tftpboot/pxelinux.cfg/default file contains the following:
nfsroot=192.168.16.5:/export/images/centos51_x86-64,nfsversvers=3,tcp,rsize=32768,wsize=32768,sec=sys ip=dhcp
- All options are honored except for the "sec=sys" option. Below is
the output of the /proc/cmdline:
/proc/cmdline: root=/dev/nfs rw nfsroot=192.168.16.5:/export/images/centos51_x86-64,nfsvers=3,tcp,rsize=32768,wsize=32768,sec=sys ip=dhcp BOOT_IMAGE=vmlinuz-2.6.18-custom-2.6.18-53.el5
- But the /proc/mounts shows that the "sec=" parameter is still set to NULL.
/proc/mounts: rootfs / rootfs rw 0 0 /dev/root / nfs rw,vers=3,rsize=3278,wsize=3478,hard,nolock,proto=tcp,timeo=11,retrans=2,sec=null,addr=192.168.16.5 0 0
............
Kernel versions:
PXE server --> uname -a Linux qatest1 2.6.18-53.1.13.el5xen #1 SMP Tue Feb 12 13:33:07 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
Diskless Workstation's kernel and root are extracted from this: Linux localhost.localdomain 2.6.18-custom-2.6.18-53.el5 #1 SMP Wed Feb 20 08:45:23 PST 2008 x86_64 x86_64 x86_64 GNU/Linux
Any help would be greatly appreciated.
I haven't done this in a long time but do your workstation kernels have root nfs in them? config_root_nfs This could be obsolete these days.
Thanks for your reply Scott.
I haven't done this in a long time but do your workstation kernels have root nfs in them? config_root_nfs This could be obsolete these days.
Yes, at least with Centos5 and fedora6 (2.6.18 kernels are what I am testing with on both distros), i have configured the Root File System Support via the "make menuconfig" option.
The following were the changes I made to the kernel:
1. Networking-> Networking options * IP Level autoconfiguration * IP DHCP * IP Bootp * IP Rarp (enabled = *)
2. Device Drivers-> Network device Support-> Ethernet 10/100Mbit -> nForce (my nVidia NIC)
3. File Systems -> Network File Systems * NFS File System Support (changed from M to *) * Root FS on NFS
.... I had to also disable on option: "Provide NFS Client Caching Support" - the only reason is because, after I performed Steps 1-3 and attempt to recompile the kernel, I had some make compile error that pertained to FS cache; in searching/googling it was recommended to disable this option. Upon disabling, the compile completed without error.
... I have also just completed setting up a FEDORA 6 Root-NFS kernel and root directory - and upon booting, I still get the same problems as the prior mentioned CentOS5. Both are of the 2.6.18 kernel base, and both give that same value: "sec=null" ... when the root NFS is mounted.
Any thoughts?
Thanks in advance.
Vince
on 2/27/2008 2:53 PM vincenzo romero spake the following:
Thanks for your reply Scott.
I haven't done this in a long time but do your workstation kernels have root nfs in them? config_root_nfs This could be obsolete these days.
Yes, at least with Centos5 and fedora6 (2.6.18 kernels are what I am testing with on both distros), i have configured the Root File System Support via the "make menuconfig" option.
The following were the changes I made to the kernel:
- Networking-> Networking options
- IP Level autoconfiguration
- IP DHCP
- IP Bootp
- IP Rarp
(enabled = *)
- Device Drivers-> Network device Support-> Ethernet 10/100Mbit ->
nForce (my nVidia NIC)
- File Systems -> Network File Systems
- NFS File System Support (changed from M to *)
- Root FS on NFS
.... I had to also disable on option: "Provide NFS Client Caching Support" - the only reason is because, after I performed Steps 1-3 and attempt to recompile the kernel, I had some make compile error that pertained to FS cache; in searching/googling it was recommended to disable this option. Upon disabling, the compile completed without error.
... I have also just completed setting up a FEDORA 6 Root-NFS kernel and root directory - and upon booting, I still get the same problems as the prior mentioned CentOS5. Both are of the 2.6.18 kernel base, and both give that same value: "sec=null" ... when the root NFS is mounted.
Any thoughts?
Thanks in advance.
Vince
I haven't done it since kernel 2.2 days so my knowledge is old and rusty, like me.
Have you looked on any of the distros set up for this like k12LTSP? Maybe they have a more current set of docs.
I haven't done it since kernel 2.2 days so my knowledge is old and rusty, like me.
LOL! .. :)
Have you looked on any of the distros set up for this like k12LTSP? Maybe they have a more current set of docs.
well, I found the issue - this was a problem in the 2.6.18 kernel; and a fix has been incorprated since 2.6.22 or so ... we decided to use 2.6.18 - which is the base for "Fedora 6" (we'll be supporting - so called - golden releases per selected distro, if you will) ..
i guess for future reference, the fix can be found here:
http://www.linuxhq.com/kernel/v2.6/23-rc4/fs/nfs/super.c
.....
-
on 2/27/2008 3:34 PM vincenzo romero spake the following:
I haven't done it since kernel 2.2 days so my knowledge is old and rusty, like me.
LOL! .. :)
Have you looked on any of the distros set up for this like k12LTSP? Maybe they have a more current set of docs.
well, I found the issue - this was a problem in the 2.6.18 kernel; and a fix has been incorprated since 2.6.22 or so ... we decided to use 2.6.18 - which is the base for "Fedora 6" (we'll be supporting - so called - golden releases per selected distro, if you will) ..
i guess for future reference, the fix can be found here:
http://www.linuxhq.com/kernel/v2.6/23-rc4/fs/nfs/super.c
.....
That explains why something that has worked "forever" suddenly stopped.
-
Scott Silva -
vincenzo romero