Stage composes are run as compose/koji.stg.fedoraproject.org@STG.FEDORAPROJECT.ORG user. Recent sync seems to have caused a loss of permissions though, as now I'm getting failures about not being able to start a runroot task.
compose/koji.stg.fedoraproject.org@STG.FEDORAPROJECT.ORG
Could you update the sync script so that the user above has permissions to do necessary tasks? Ideally it should have the same permissions that releng has in production (at least runroot, appliance, image and livemedia).
releng
runroot
appliance
image
livemedia
Yeah. :person_frowning:
https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/playbooks/manual/staging-sync/templates/koji-reset-staging.sql
is the script we run. We need to fix it up some more not only for this, but it didn't setup builders right either. I'll try and fix this when I fix those, but patches welcome of course.
Also, FYI, I want to do another sync at the end of this week after the f26 branching (so stg stays close to prod there with tags, etc).
Hum, so this user doesn't exist in prod, only stg?
What user do we use in prod for this? Can we use the same one in stg? or it has to be the above?
I believe production is using releng user. If I recall correctly, stage had the same name until flag day. The keytab that's configured with compose_koji profile gives the current username. Nothing in the composing process cares about the user, so as far as testing Pungi is concerned, renaming would be perfectly fine.
compose_koji
@puiterwijk Is my assumption about the similar users valid? Is there any risk in making the compose_koji profile appear as releng user?
The user is now fixed in staging.
And this should now be fixed for future syncs: http://infrastructure.fedoraproject.org/cgit/ansible.git/commit/?id=395ca24
Metadata Update from @puiterwijk: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open) - Issue tagged with: authentication
@kevin I already fixed the krb principal code for builders since we found that out, so that part should be fixed. We should extend this tuple list though.
Login to comment on this ticket.