You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Notice: /Stage[main]/Stunnel/Posix_acl/permission: current_value ["group::r--", "other::---", "user::rw-","user:phil:r--", "user:bob:r--"], should be ["user:2001:r--", "user:2002:r--"]
phil is user 2001, bob is user 2002. Puppet wants to re-apply this every time the code is run. (I know, silly example, why would you do that? but I have a use case for which this would be useful.)
The check will always fail because the check is made against the resolved usernames not the userIDs (and as an aside the check seems to be made against the complete getfacl output not the specific lines, but that's the gist of the other Issue linked). The code should check if a line match is found based on /either/ numerical id /or/ username.
This is a side-issue from the add this is linked to, and seems to be a separate case worthy of separate consideration, IMO.
I think a switch to using getfacl in numeric output mode ("-n" option), all the time, would be an approach and would make the module more robust. I do feel like a lower level approach might be much better though, given the limitations of the getfacl/setfacl tools.
My example:
Results in:
Notice: /Stage[main]/Stunnel/Posix_acl/permission: current_value ["group::r--", "other::---", "user::rw-","user:phil:r--", "user:bob:r--"], should be ["user:2001:r--", "user:2002:r--"]
phil is user 2001, bob is user 2002. Puppet wants to re-apply this every time the code is run. (I know, silly example, why would you do that? but I have a use case for which this would be useful.)
The check will always fail because the check is made against the resolved usernames not the userIDs (and as an aside the check seems to be made against the complete getfacl output not the specific lines, but that's the gist of the other Issue linked). The code should check if a line match is found based on /either/ numerical id /or/ username.
This is a side-issue from the add this is linked to, and seems to be a separate case worthy of separate consideration, IMO.
Originally posted by @matt-matt2 in #58 (comment)
The text was updated successfully, but these errors were encountered: