Make the pidfile accessible by everyone

[mcasquer]

Creates the pidfile at an accessible location
for every user, this way the manage pidfile
warning is avoided.

Pull Request Checklist

• implement the feature
• write the documentation
• extend the test coverage
• update the specification
• mention the version
• include a release note

[mcasquer]

To discuss here which of the added # noqa could be avoided

[mcasquer]

@happz one question, in the related issue with the patch it's used tmt -a provision -h local which IIUC it's the local host already executing tmt, in this case the code raises again permissions issues when doing the chmod

[happz]

@happz one question, in the related issue with the patch it's used tmt -a provision -h local which IIUC it's the local host already executing tmt, in this case the code raises again permissions issues when doing the chmod

Is your change here causing a regression? Or is your change here just making no difference WRT #2877?

[mcasquer]

That should resolve the test finally :)

Updated !

[psss]

Summary from the chat discussion: /tests/provision/facts/guest should be adjusted to use the container image with password-less sudo that is localhost/tmt/tests/container/fedora/39/unprivileged and we will explicitly document that one of the following is needed on the guest:

• root user (with all permissions)
• regular user (with password-less sudo configured)

[happz]

--user would need to change as well, to fedora, and the main image shouldn't be the unprivileged one. Together, I think something like this should be the outcome:

provision_options="--image $TEST_IMAGE_PREFIX/fedora/39:latest"
bfu_provision_options="--image $TEST_IMAGE_PREFIX/fedora/39/unprivileged:latest --user=fedora"

[mcasquer]

It seems now there's an issue when setting the ACLs, the user doesn't have permissions

cmd:
            mkdir -p /var/tmp/tmt;
            setfacl -d -m o:rX /var/tmp/tmt
            err: setfacl: /var/tmp/tmt: Operation not permitted

Also I see some extra error about an rsync command along with the following message
fail: Failed to push workdir to the guest. This usually means that login as 'fedora' to the guest does not work.

[martinhoyer]

lgtm, thanks!

[mcasquer]

I see now the failed tests are
/tests/core/environment-file

:: [ 10:30:11 ] :: [   FAIL   ] :: Command 'tmt run --environment STR=bad_str -rvvvddd plan --name /plan/good 2>&1             | tee output' (Expected 1, got 2)
:: [ 10:30:11 ] :: [   FAIL   ] :: File 'output' should contain 'AssertionError: assert 'bad_str' == 'O'' 

/tests/prepare/ansible

:: [ 10:54:20 ] :: [   FAIL   ] :: Command 'tmt run -i /tmp/tmp.7zaDNljweN --scratch -av provision -h container -i localhost/tmt/tests/container/alpine:latest plan -n /remote' (Expected 0, got 2)
:: [ 10:54:20 ] :: [   FAIL   ] :: File '/tmp/tmp.7zaDNljweN/log.txt' should contain 'ansible-playbook -vvv' 

Sorry I don't see how is this related with the patch... 😕 @happz @psss could you shed some light here?

[psss]

Hmmm, these seem to be caused by GitHub randomly refusing to serve the raw content:

fail: Failed to fetch remote playbook 'https://raw.githubusercontent.com/teemtee/tmt/main/tests/prepare/ansible/data/playbook.yml'.
403 Client Error: Forbidden for url: https://raw.githubusercontent.com/teemtee/tmt/22a46a4a6760517e3eadbbff0c9bebdb95442760/tests/core/env/data/vars.yaml

Sounds like they enabled some rate limiting, or we hit the limit:

• https://stackoverflow.com/questions/66522261/does-github-rate-limit-access-to-public-raw-files

Any suggestions?

[mcasquer]

I see this test case is also failing:

Command '
mkdir -p /var/tmp/tmt;
setfacl -d -m o:rX /var/tmp/tmt
' returned 1.

# stderr (1 lines)
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
setfacl: /var/tmp/tmt: Operation not permitted
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I think the same approach for the pidfile can be used?, something like:

sudo = 'sudo' if not self.facts.is_superuser else ''
...
    {sudo} setfacl -d -m o:rX {workdir_root}
    """))

what do you think? @psss @happz

[psss]

I think the same approach for the pidfile can be used?, something like:

sudo = 'sudo' if not self.facts.is_superuser else ''
...
    {sudo} setfacl -d -m o:rX {workdir_root}
    """))

what do you think? @psss @happz

Yes, I think sudo should be used here as well. This part of code is under the following condition:

if not self.facts.is_superuser and self.become

Meaning that we should probably use it here always. @happz, any thoughts?

@carlosrodfern, as this setfacl code was submitted by you, do you have any additional recommendations here?

[psss]

Anyway, this is too late for 1.39. Let's merge this as one of the first changes in 1.40 in order to give it some testing.

[carlosrodfern]

For what I can understand, when the sudo mkdir -p is run with the pid directory, which goes pass /var/tmp/tmt/, then the whole structure is created owned by root. So, when it gets to the setfacl part, it fails. I would be also surprised that the chmod ugo+rwx is enough in a umask 0027 scenario. Wouldn't it better to create /var/tmp/tmt first with the corresponding acl to avoid issues with umask 0027, and then do the nested dirs?

I may be missing something too...