[
https://issues.apache.org/jira/browse/SOLR-15543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris M. Hostetter updated SOLR-15543:
--------------------------------------
Attachment: SOLR-15543.patch
Assignee: Chris M. Hostetter
Status: Open (was: Open)
> docker tests should fail more transparently if 'setfacl' is not available
> -------------------------------------------------------------------------
>
> Key: SOLR-15543
> URL: https://issues.apache.org/jira/browse/SOLR-15543
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Chris M. Hostetter
> Assignee: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-15543.patch
>
>
> a handful of docker cases depend on {{prepare_dir_to_mount}} in {{shared.sh}}
> which ends with...
> {code:java}
> # The /var/solr mountpoint is owned by solr, so when we bind mount there
> our directory,
> # owned by the current user in the host, will show as owned by solr, and
> our attempts
> # to write to it as the user will fail. To deal with that, set the ACL to
> allow that.
> # If you can't use setfacl (eg on macOS), you'll have to chown the
> directory to 8983, or apply world
> # write permissions.
> if command -v setfacl &> /dev/null; then
> setfacl -m "u:$userid:rwx" "$folder"
> fi
> }
> {code}
> I don't really understand that comment (is setfacl not available on macs? do
> docker tests currently not work on macs?) but more concerning is that if
> setfacl isn't available on the host OS, then the necessary ACLs just aren't
> added – which means these tests fail down the road when the code being tested
> tries to use these directories with the specified userid.
> ----
> I think we should change this logic such that if {{setfacl}} isn't available,
> or if it exits with non zero status, then the test fails with a clear error
> about the need for {{setfacl}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
