ansible-powerscale
ansible-powerscale copied to clipboard
dell
[BUG]: dellemc.powerscale.filesystem does not set SETGID bit correctly on directory creation
Describe the bug When specifying permissions including a SETGID bit for a new directory, the SETGID bit seems to be stripped. It is only applied on second invocation of the same playbook. See the example below
To Reproduce Steps to reproduce the behavior:
- Run the following playbook:
---
- name: "===== CREATE A DIRECTORY ====="
hosts: localhost
gather_facts: no
tasks:
- name: "DELL PowerScale : Create directory"
dellemc.powerscale.filesystem:
onefs_host: "XXXXX"
api_user: "XXXXX"
api_password: "XXXXX"
verify_ssl: False
path: "/path/to/directory"
state: "present"
owner:
name: "root"
provider_type: "file"
group:
name: "XXXXX"
provider_type: "ads"
access_control: 2357
- The directory is created with the following - wrong - permissions (no SETGID):
d-wxr-xrwx 2 root AD\XXXXX 0 Jun 13 18:28 /path/to/directory
- Rerun the playbook above
- The correct permissions are applied (SETGID set):
d-wxr-srwx 2 root AD\XXXX 0 Jun 13 18:28 /path/to/directory
Expected behavior The SETGID bit should be set from the beginning
Logs
ansible_powerscale.log entries after first run:
2024-06-13 19:23:14,651 filesystem.py INFO : Got python SDK instance for provisioning on PowerScale
2024-06-13 19:23:14,797 filesystem.py INFO : Filesystem path/to/directory status is 404
2024-06-13 19:23:14,968 filesystem.py INFO : Unable to get Quota details on path path/to/directory
2024-06-13 19:23:14,968 filesystem.py INFO : Creating Filesystem...
2024-06-13 19:23:15,301 filesystem.py INFO : Attempting to create new FS path/to/directory
2024-06-13 19:23:15,316 filesystem.py INFO : Getting filesystem details..
ansible_powerscale.log entries after second run:
2024-06-13 19:25:15,207 filesystem.py INFO : Got python SDK instance for provisioning on PowerScale
2024-06-13 19:25:15,443 filesystem.py INFO : Determining if the ACLs are modified..
2024-06-13 19:25:15,450 filesystem.py INFO : ACL of the filesystem on the array is [{'accessrights': ['dir_gen_write', 'dir_gen_execute', 'std_write_dac', 'delete_child', 'dir_read_attr'], 'accesstype': 'allow', 'inherit_flags': [], 'op': None, 'trustee': {'id': 'UID:0', 'name': 'root', 'type': 'user'}}, {'accessrights': ['dir_gen_read', 'dir_gen_execute'], 'accesstype': 'allow', 'inherit_flags': [], 'op': None, 'trustee': {'id': 'GID:XXXXX', 'name': 'AD\\XXXXX', 'type': 'group'}}, {'accessrights': ['dir_gen_read', 'dir_gen_write', 'dir_gen_execute', 'delete_child'], 'accesstype': 'allow', 'inherit_flags': [], 'op': None, 'trustee': {'id': 'SID:S-1-1-0', 'name': 'Everyone', 'type': 'wellknown'}}]
2024-06-13 19:25:15,450 filesystem.py INFO : ACL provided in the playbook is 2357
2024-06-13 19:25:15,450 filesystem.py INFO : Determining if Quota is modified...
2024-06-13 19:25:15,450 filesystem.py INFO : Determining if owner is modified..
2024-06-13 19:25:15,621 filesystem.py INFO : The user ID fetched from playbook is UID:0 and the user ID on the file is UID:0
2024-06-13 19:25:15,622 filesystem.py INFO : Determining if group is modified..
2024-06-13 19:25:15,832 filesystem.py INFO : The group ID fetched from playbook is GID:XXXXX and the group ID on the file is GID:34005
2024-06-13 19:25:15,832 filesystem.py INFO : Modifying group..
2024-06-13 19:25:15,837 filesystem.py INFO : Modifying ACL..
2024-06-13 19:25:15,842 filesystem.py INFO : Getting filesystem details..
System Information (please complete the following information):
- OS/Version: [e.g. RHEL 7.6]: CentOS 7.9
- Ansible Version [e.g. 2.12]: core 2.16.3
- Python Version [e.g. 3.9]: 3.12.1
- Additional Information...
Additional context It doesn't make a difference, when the permission is quoted in the playbook
@fthommen, thank you for reporting this issue. Let us have a look internally and get back to you at the earliest.
@fthommen, we tried the below playbook to reproduce the issue on both PowerScale 9.5 and 9.4, but every time it created the directory with the STEGID bit set. Could you let us know the version of PowerScale against which you are running the ansible playbook? Also, it would be good to know the version of the dellemc.powerscale collection and isilon-sdk python SDK.
- name: Create directory with SETGID bit set
dellemc.powerscale.filesystem:
onefs_host: "XX.XX.XX.XX"
api_user: "root"
api_password: "***********"
verify_ssl: false
path: "/ifs/test_three"
owner:
name: "root"
provider_type: "file"
group:
name: "Guests"
provider_type: "local"
access_control: 2357
state: "present"
access_zone: System
Output:
That is very interesting @anupamaloke . I tried with a slightly different playbook, adapted to the user we are using to access the Isilons:
- name: "===== CREATE A NEW ISILON DIRECTORY ====="
hosts: localhost
gather_facts: no
tasks:
- name: Create directory with SETGID bit set
dellemc.powerscale.filesystem:
onefs_host: "ISILON_HOSTNAME"
api_user: "OUR_API_USER"
api_password: "PASSWORD"
verify_ssl: false
path: "/ifs/test_here"
owner:
name: "root"
provider_type: "file"
group:
name: "Guests"
provider_type: "local"
access_control: 2357
state: "present"
access_zone: System
After one run I get
ISILON_HOSTNAME% ls -ld /ifs/test_here
d-wxr-xrwx 2 root Guests 0 Jul 9 17:38 test_here
ISILON_HOSTNAME%
and after I've run it a second time, I get
ISILON_HOSTNAME% ls -ld /ifs/test_here
d-wxr-srwx 2 root Guests 0 Jul 9 17:38 /ifs/test_here
ISILON_HOSTNAME%
When creating files locally, it works immediately:
ISILON_HOSTNAME% mkdir -m 2357 /ifs/test_there
ISILON_HOSTNAME% ls -ld /ifs/test_there
d-wxr-srwx 2 OUR_API_USER Isilon Users 0 Jul 9 17:44 /ifs/test_there
ISILON_HOSTNAME%
On login the system tells me PowerScale OneFS 9.4.0.11. In the Ansible collection directory there is a file dellemc.powerscale-3.0.0.info and dellemc/powerscale/MANIFEST.json also has "version": "3.0.0".
@fthommen, that's interesting. Could you also please let me know what version of the isilon-sdk is installed in your environment?
$ pip freeze | grep isilon-sdk
isilon-sdk==0.3.0.1
@fthommen, it seems that we have not been able to get this issue reproduced in our environment. Could you also please let us know that api_user and the privileges associated with it?
@anupamaloke the account has been assigned to us by our central IT. I will inquire and get back to you as soon as I got the required information.
Hello @anupamaloke , these are the privileges of the account, which we are using:
XXXXXX# isi auth roles view XXXXXX
Name: XXXXXX
Description: XXXXXX
Members: XXXXXX
Privileges
ID: ISI_PRIV_LOGIN_CONSOLE
Permission: r
ID: ISI_PRIV_LOGIN_PAPI
Permission: r
ID: ISI_PRIV_LOGIN_SSH
Permission: r
ID: ISI_PRIV_AUTH
Permission: r
ID: ISI_PRIV_ROLE
Permission: r
ID: ISI_PRIV_DEVICES
Permission: r
ID: ISI_PRIV_EVENT
Permission: r
ID: ISI_PRIV_JOB_ENGINE
Permission: r
ID: ISI_PRIV_NETWORK
Permission: r
ID: ISI_PRIV_NFS
Permission: w
ID: ISI_PRIV_NFS_SETTINGS
Permission: r
ID: ISI_PRIV_PAPI_CONFIG
Permission: r
ID: ISI_PRIV_PERFORMANCE
Permission: r
ID: ISI_PRIV_QUOTA
Permission: w
ID: ISI_PRIV_QUOTA_SETTINGS
Permission: w
ID: ISI_PRIV_QUOTA_SUMMARY
Permission: w
ID: ISI_PRIV_SMARTPOOLS
Permission: r
ID: ISI_PRIV_SMB
Permission: r
ID: ISI_PRIV_SNAPSHOT
Permission: r
ID: ISI_PRIV_STATISTICS
Permission: r
ID: ISI_PRIV_IFS_BACKUP
Permission: r
ID: ISI_PRIV_IFS_RESTORE
Permission: r
ID: ISI_PRIV_NS_TRAVERSE
Permission: r
ID: ISI_PRIV_NS_IFS_ACCESS
Permission: r
XXXXXX#
Hi @anupamaloke we decided not to use the Powerscale Ansible modules any more. We will instead switch to isi scripts, which give us the full power of the functionalities w/o the limitations of the Powerscale modules. I will therefore close this issue. Of course you are free to continue on your own if you think, that this is a general issue, but I'd rather not be involved with it any more.