fedora-infrastructure

Clone
Source Code
GIT

#7194 Some files in /mnt/koji/compose/updates/ are becoming root-owned, which will break Bodhi 3.9.0's composer
Closed: Upstream 5 years ago Opened 5 years ago by bowlofeggs.

Closed: Upstream
Reopen Issue
  • Describe what you need us to do:
    Bodhi 3.9.0 has a new feature where it will trim old composes from /mnt/koji/compose/updates/ at the end of each compose. Prior to 3.9.0, I would periodically run bodhi-clean-old-mashes (well, I haven't run it in a few months, but I used to run it regularly) to do this, so the idea was to get Bodhi to do this at the end of each compose instead.

Unfortunately I noticed today that there seems to be some recent change that is causing files to become root owned in /mnt/koji/compose/updates/, specifically ostree related. Due to this, Bodhi's composes are going to fail.

What I need in this ticket is help solving the problem, or help with thinking of a good solution to the problem. A few things we could do:

  1. I could just remove this feature from Bodhi and we could clean the old mashes some other way (either going back to manual, or maybe cron).
  2. We could identify what is making these root owned files and see if there's a way to make them apache owned. It seems like a recent change as it didn't affect older f27 composes but does affect more recent ones, and seems to be ostree related.
  3. I welcome other ideas.

  • When do you need this? (YYYY/MM/DD)
    ASAP, because composes will fail the way things are now.

  • When is this no longer needed or useful? (YYYY/MM/DD)
    N/A

  • If we cannot complete your request, what is the impact?
    Composes will fail. For now I am manually running bodhi-clean-old-mashes as root to try to clear out the composes.

Does anybody know what is creating the root owned ostree related files in /mnt/koji/compose/updates/? This caused last night's compose to fail:

================================================================================
      F28-stable     :   0 updates (failed)
================================================================================
Content Type: None
     Started: 2018-08-27 23:02:09
     Updated: 2018-08-29 00:56:56
       Error: [Errno 13] Permission denied: '/mnt/koji/compose/updates/Fedora-28-updates-20180818.0/work/aarch64/Atomi
cHost/ostree_installer/.discinfo'

The file is created by lorax running in koji runroot task. This is not a recent change, the only recent change in this area was to make the files readable for every user (there used to be some with 600 permissions).

So I am wondering if the directory permissions were affected by this. If not we need to find a different culprit.

Since this was working in the past, my best assumption is that the group permissions on these directories were group owned by apache and group +wS so that the script would work previously. [An another assumption was that the directories were 777 but I am going to guess no :smile:]

Since there doesn't seem to be a readily available solution to this problem, I'm going to just make the auto-cleanup an opt-out setting in Bodhi's config file in Bodhi 3.10.0 and we'll just turn it off for Fedora.

3.10.0 is planned for post-freeze.

Metadata Update from @bowlofeggs:
- Issue close_status updated to: Upstream
- Issue status updated to: Closed (was: Open)
5 years ago

Since there doesn't seem to be a readily available solution to this problem, I'm going to just make the auto-cleanup an opt-out setting in Bodhi's config file in Bodhi 3.10.0 and we'll just turn it off for Fedora.

we should probably still pursue a long term solution, right ?

Login to comment on this ticket.

Metadata
None

bodhi

None
None
Waiting on Assignee
Powered by Pagure 5.13.3
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.