[PATCH] Doc: add work around to handle NFS root squash problem
From: Royce Lv <lvroyce@linux.vnet.ibm.com> Tested: 1. make 2. nfs pool and vm creation Default NFS server export path is configured as root squash, mapping root user to nobody. This results: 1. Root user cannot step into mount point if export path does not allow other to read/execute. So create volume will fail. 2. Even with other permission open, owner/group of volume created by root is still nobody/nogrp, and qemu permission is denied on such img. This work around instruct user to enable squash to given libvirt user to address the above problems. Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- docs/README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/docs/README.md b/docs/README.md index 5721878..17abe78 100644 --- a/docs/README.md +++ b/docs/README.md @@ -146,8 +146,15 @@ new template using the "+" button in the upper right corner. Known Issues ------------ -Kimchi is still experimental and should not be used in a production +1. Kimchi is still experimental and should not be used in a production environment. +2. When you are using NFS as storage pool, check the nfs export path permission +is configured as: + (1) export path need to be squashed as kvm gid and libvirt uid: + /my_export_path *(all_squash,anongid=<kvm-gid>, anonuid=<libvirt-uid>,rw,sync) + So that root user can create volume with right user/group. + (2) Chown of export path user as libvirt user, group as kvm group, + In order to make sure all mapped user can get into the mount point. Participating ------------- -- 1.8.1.2
On 03/11/2014 07:05 AM, lvroyce@linux.vnet.ibm.com wrote:
From: Royce Lv <lvroyce@linux.vnet.ibm.com>
Tested: 1. make 2. nfs pool and vm creation Default NFS server export path is configured as root squash, mapping root user to nobody. This results: 1. Root user cannot step into mount point if export path does not allow other to read/execute. So create volume will fail. 2. Even with other permission open, owner/group of volume created by root is still nobody/nogrp, and qemu permission is denied on such img. This work around instruct user to enable squash to given libvirt user to address the above problems.
Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- docs/README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/docs/README.md b/docs/README.md index 5721878..17abe78 100644 --- a/docs/README.md +++ b/docs/README.md @@ -146,8 +146,15 @@ new template using the "+" button in the upper right corner. Known Issues ------------
-Kimchi is still experimental and should not be used in a production +1. Kimchi is still experimental and should not be used in a production environment. +2. When you are using NFS as storage pool, check the nfs export path permission +is configured as: + (1) export path need to be squashed as kvm gid and libvirt uid: + /my_export_path *(all_squash,anongid=<kvm-gid>, anonuid=<libvirt-uid>,rw,sync) + So that root user can create volume with right user/group. + (2) Chown of export path user as libvirt user, group as kvm group,
There is an extra "user" word ^ "Chown of export path as libvirt..." I can update it before applying if anyone has more comments
+ In order to make sure all mapped user can get into the mount point.
Participating -------------
Was this ever applied? I'm seeing an issue with selinux and am wondering if we need to also make some additional changes for NFS. I'll send out an RFC shortly with more info. Regards, - Christy On Wed, 2014-03-12 at 13:50 -0300, Aline Manera wrote:
On 03/11/2014 07:05 AM, lvroyce@linux.vnet.ibm.com wrote:
From: Royce Lv <lvroyce@linux.vnet.ibm.com>
Tested: 1. make 2. nfs pool and vm creation Default NFS server export path is configured as root squash, mapping root user to nobody. This results: 1. Root user cannot step into mount point if export path does not allow other to read/execute. So create volume will fail. 2. Even with other permission open, owner/group of volume created by root is still nobody/nogrp, and qemu permission is denied on such img. This work around instruct user to enable squash to given libvirt user to address the above problems.
Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- docs/README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/docs/README.md b/docs/README.md index 5721878..17abe78 100644 --- a/docs/README.md +++ b/docs/README.md @@ -146,8 +146,15 @@ new template using the "+" button in the upper right corner. Known Issues ------------
-Kimchi is still experimental and should not be used in a production +1. Kimchi is still experimental and should not be used in a production environment. +2. When you are using NFS as storage pool, check the nfs export path permission +is configured as: + (1) export path need to be squashed as kvm gid and libvirt uid: + /my_export_path *(all_squash,anongid=<kvm-gid>, anonuid=<libvirt-uid>,rw,sync) + So that root user can create volume with right user/group. + (2) Chown of export path user as libvirt user, group as kvm group,
There is an extra "user" word ^
"Chown of export path as libvirt..."
I can update it before applying if anyone has more comments
+ In order to make sure all mapped user can get into the mount point.
Participating -------------
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On 03/18/2014 02:16 PM, Christy Perez wrote:
Was this ever applied? I'm seeing an issue with selinux and am wondering if we need to also make some additional changes for NFS. I'll send out an RFC shortly with more info.
This was not applied yet, Christy! Are you going to send a separated patch to the selinux config?
Regards,
- Christy
On Wed, 2014-03-12 at 13:50 -0300, Aline Manera wrote:
On 03/11/2014 07:05 AM, lvroyce@linux.vnet.ibm.com wrote:
From: Royce Lv <lvroyce@linux.vnet.ibm.com>
Tested: 1. make 2. nfs pool and vm creation Default NFS server export path is configured as root squash, mapping root user to nobody. This results: 1. Root user cannot step into mount point if export path does not allow other to read/execute. So create volume will fail. 2. Even with other permission open, owner/group of volume created by root is still nobody/nogrp, and qemu permission is denied on such img. This work around instruct user to enable squash to given libvirt user to address the above problems.
Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- docs/README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/docs/README.md b/docs/README.md index 5721878..17abe78 100644 --- a/docs/README.md +++ b/docs/README.md @@ -146,8 +146,15 @@ new template using the "+" button in the upper right corner. Known Issues ------------
-Kimchi is still experimental and should not be used in a production +1. Kimchi is still experimental and should not be used in a production environment. +2. When you are using NFS as storage pool, check the nfs export path permission +is configured as: + (1) export path need to be squashed as kvm gid and libvirt uid: + /my_export_path *(all_squash,anongid=<kvm-gid>, anonuid=<libvirt-uid>,rw,sync) + So that root user can create volume with right user/group. + (2) Chown of export path user as libvirt user, group as kvm group, There is an extra "user" word ^
"Chown of export path as libvirt..."
I can update it before applying if anyone has more comments
+ In order to make sure all mapped user can get into the mount point.
Participating -------------
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
On Tue, 2014-03-18 at 15:20 -0300, Aline Manera wrote:
On 03/18/2014 02:16 PM, Christy Perez wrote:
Was this ever applied? I'm seeing an issue with selinux and am wondering if we need to also make some additional changes for NFS. I'll send out an RFC shortly with more info.
This was not applied yet, Christy! Are you going to send a separated patch to the selinux config? I don't have a patch in progress yet, nope.
Regards,
- Christy
On Wed, 2014-03-12 at 13:50 -0300, Aline Manera wrote:
On 03/11/2014 07:05 AM, lvroyce@linux.vnet.ibm.com wrote:
From: Royce Lv <lvroyce@linux.vnet.ibm.com>
Tested: 1. make 2. nfs pool and vm creation Default NFS server export path is configured as root squash, mapping root user to nobody. This results: 1. Root user cannot step into mount point if export path does not allow other to read/execute. So create volume will fail. 2. Even with other permission open, owner/group of volume created by root is still nobody/nogrp, and qemu permission is denied on such img. This work around instruct user to enable squash to given libvirt user to address the above problems.
Signed-off-by: Royce Lv <lvroyce@linux.vnet.ibm.com> --- docs/README.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/docs/README.md b/docs/README.md index 5721878..17abe78 100644 --- a/docs/README.md +++ b/docs/README.md @@ -146,8 +146,15 @@ new template using the "+" button in the upper right corner. Known Issues ------------
-Kimchi is still experimental and should not be used in a production +1. Kimchi is still experimental and should not be used in a production environment. +2. When you are using NFS as storage pool, check the nfs export path permission +is configured as: + (1) export path need to be squashed as kvm gid and libvirt uid: + /my_export_path *(all_squash,anongid=<kvm-gid>, anonuid=<libvirt-uid>,rw,sync) + So that root user can create volume with right user/group. + (2) Chown of export path user as libvirt user, group as kvm group, There is an extra "user" word ^
"Chown of export path as libvirt..."
I can update it before applying if anyone has more comments
+ In order to make sure all mapped user can get into the mount point.
Participating -------------
Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (3)
-
Aline Manera -
Christy Perez -
lvroyce＠linux.vnet.ibm.com