@puiterwijk helped with making mass-rebuilds work without sudo/root. @lsedlar and I had a discussion this morning and we are confident Pungi could have the same treatment and would like to open the discussion with Fedora Infra team.
No hard date, this is nice-to-have and needs more discussion.
Not applicable.
We keep using sudo for the script that invokes pungi-koji.
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.
mount -o loop
guestmount
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?
Metadata Update from @kevin: - Issue priority set to: Waiting on Assignee (was: Needs Review)
@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.
/mnt/koji/packages
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.
fs.protected_hardlinks
cat /proc/sys/fs/protected_hardlinks should show if it's enabled.
cat /proc/sys/fs/protected_hardlinks
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.
odcs-promote-compose
/srv/odcs
/mnt/koji/composes
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. :)
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.