Is it possible to find the "creator"/"owner" of a deployed file?

Transferring my issue from https://github.com/ostreedev/ostree/issues/2433

Hi Silverbluers,

On one of my systems I have a /usr/etc/authselect/user-nsswitch.conf.bak file which I can’t make sense of. Is there a tool or log available that could help me pinpoint the creator/owner/source of it?

1 Like

On Silverblue & Kinoite, 99% of the content in /usr comes from an RPM. Running:

rpm -qf /path/to/file

will give you the corresponding package.

Everything else that does not explicitly come from an RPM can come from:

  • A file included or created from the config. See workstation-ostree-config.
  • A file generated, modified or created by RPM scriptlets that are run during the image build.
  • A file from /etc (and some other special places) moved by rpm-ostree to /usr.

For your particular case, this is a probably a mix of a file generated by a scriptlet and then moved by rpm-ostree into /usr/etc which is a pristine copy of /etc as installed during the image build.

1 Like

Thank you very much for the explanation @Siosm

  • A file generated, modified or created by RPM scriptlets that are run during the image build.

Let’s take the mysterious /usr/etc/authselect/user-nsswitch.conf.bak as an example.

~ ❯❯❯ rpm -qf /usr/etc/authselect/user-nsswitch.conf.bak
file /usr/etc/authselect/user-nsswitch.conf.bak is not owned by any package

If I get it right: A layered package can include/trigger a scriptlet which generates, modifies or creates a file that has no relation visible through rpm -qf. This brings up a follow-up question: Is a log of the image build available which would show the creation of this file?

A file from /etc (and some other special places) moved by rpm-ostree to /usr .

Don’t wanna diverge from the initial question too much. This is a mechanism I’ve seen in practice a lot but that I have not fully understood yet. Is there documentation available to better understand when and for which files rpm-ostree is doing this transfer?

Yes. This is another case where we would very much appreciate to have a few scriptlets as possible doing weird things :slight_smile:.

The local layering case should produce local logs in the journal (have not fully checked yet).

For the base image, logs for failed composes are available at: Issues - releng/failed-composes - Pagure.io. I don’t know where the logs from successful composes are :confused:.

Existing documentation that I know of: