This should just need ownership of the keytab and compose directories parent changed I think.

There was also code that tweak configuration in boot.iso, which used mount -o loop which required root. However now there should be a code path that uses guestmount if it's available, and that runs with normal user permissions.

What pungi runs are you talking about here? composes for Beta/Final RC and gold?

@kevin - correct - beta/final RC and gold.

Perhaps those could/should be done as 'releng' user? I don't guess it matters too much.

I guess we probibly need to do a test compose and see what issues we run into before we get too close to beta?

@mohanboddu Is anything blocking this now? Perhaps we could do a test compose as yourself or releng user and we can find out what need adjusting?

@kevin Well, I guess we could give it a try and see what happens 🤷‍♂️

So, any news here? Should we just close this and try it and if we hit issues solve them?

So, I guess make a note for the first f32 beta compose to try this so we don't forget?

Yeah, I totally forgot about this, may be we could try it for f32 BEta.

Is it the good time to try this ?

I've ased @mohanboddu to try this with the upcoming rc's for beta...

When we tried to run it as rootless, first we found one issue

PermissionError: [Errno 13] Permission denied: '/mnt/koji/compose/32/Fedora-32-20200311.0

So, we changed the compose dir perms as follows to give sysadmin-releng access:

chgrp sysadmin-releng /mnt/koji/compose/32
chmod 775 /mnt/koji/compose/32

But then failed to access /mnt/koji/packages/...

From https://kojipkgs.fedoraproject.org/compose/32/Fedora-32-20200311.0/logs/global/traceback.global.log

PermissionError: [Errno 1] Operation not permitted: '/mnt/koji/packages/0ad/0.0.23b/11.fc32/data/signed/12c944d0/src/0ad-0.0.23b-11.fc32.src.rpm' -> '/mnt/koji/compose/32/Fedora-32-20200311.0/compose/Everything/source/tree/Packages/0/0ad-0.0.23b-11.fc32.src.rpm'

So, we might have to do the same thing we did above for /mnt/koji/packages as well.

I am not sure if there would be any more problems or not.

Pinging @lsedlar for suggestions.

That looks like fs.protected_hardlinks is set to 1. With that option on the user creating the hardlink either has to own the source file, or must have r+w permissions.

cat /proc/sys/fs/protected_hardlinks should show if it's enabled.

You could either disable that option or switch from hardlinking to copying packages or symlinks.

EDIT: reference: https://sysctl-explorer.net/fs/protected_hardlinks/

I will make side note related to ODCS here. ODCS runs as non-root user and uses symlinks instead of hardlinks. You still want to use hardlinks in the end for any composes which should stay archived forever, otherwise Koji garbage collector could remove the target of your symlink.

We have odcs-promote-compose (https://pagure.io/odcs/blob/master/f/server/contrib/odcs-promote-compose) script which can copy the compose from one location (typically /srv/odcs) to another location (/mnt/koji/composes). This script also replaces symlinks with hardlinks.

The odcs-promote-compose would have the same issue, but it might be easier to trust this small script than full Pungi source-code with more complex configuration.

We sucessfully finished a f32 final rc non root. :)