Create and configure a new user for ELNBuildSync #13132

Open
opened 2025-12-12 01:57:03 +00:00 by yselkowitz · 25 comments
Member

Describe the issue

Until now, ELNBuildSync has been using the distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org name in Koji to create and tag builds. However, in order to implement the requested change to create a single side-tag update per batch (or a small number of such in the case of a mass rebuild), our automation would have to also interact with Bodhi, and the keytab we have will not log in to Bodhi.

In discussion tonight in #eln, @kevin stated that because this name is not a real user in FAS, it does not have the capability to log into Bodhi, and that services that need to do so need to be real users, e.g. like packit. Therefore, we apparently need to do the same for ELNBuildSync in order to implement this change.

  1. Is there a preferred naming scheme for such accounts?
  2. Should the account be named to be specific for ELNBuildSync, or more general to (possibly) be used by other ELN automation?
  3. Once created, can you create a keytab for the service(s) to use without interactive logins?
  4. Also, https://pagure.io/fedora-infra/ansible will need to be adapted:
    a. roles/bodhi2/base/templates/production.ini.j2: include the new user in stats_blacklist
    b. roles/openshift-apps/badges/templates/fm-fedbadges.toml: include the new user in skip_users
  5. Is there anywhere else that may need to be adapted similarly?

More information on this change:

https://github.com/fedora-eln/eln/issues/200
#12869
https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync/-/merge_requests/98
https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync/-/merge_requests/100

When do you need this? (YYYY/MM/DD)

ASAP (although we haven't created such a user yet)

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

N/A

If we cannot complete this, what is the impact? [Dependencies/Blocker]

ELN cannot implement batching of updates.

/cc @sgallagh


Checklist

  • I have checked existing issues for duplicates
  • I have filled out all the fields above
  • I have provided relevant links or references (if applicable)
## Describe the issue Until now, ELNBuildSync has been using the `distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org` name in Koji to create and tag builds. However, in order to implement the requested change to create a single side-tag update per batch (or a small number of such in the case of a mass rebuild), our automation would have to also interact with Bodhi, and the keytab we have will not log in to Bodhi. In discussion tonight in #eln, @kevin stated that because this name is not a real user in FAS, it does not have the capability to log into Bodhi, and that services that need to do so need to be real users, e.g. like `packit`. Therefore, we apparently need to do the same for ELNBuildSync in order to implement this change. 1. Is there a preferred naming scheme for such accounts? 2. Should the account be named to be specific for ELNBuildSync, or more general to (possibly) be used by other ELN automation? 3. Once created, can you create a keytab for the service(s) to use without interactive logins? 4. Also, https://pagure.io/fedora-infra/ansible will need to be adapted: a. roles/bodhi2/base/templates/production.ini.j2: include the new user in `stats_blacklist` b. roles/openshift-apps/badges/templates/fm-fedbadges.toml: include the new user in `skip_users` 5. Is there anywhere else that may need to be adapted similarly? More information on this change: https://github.com/fedora-eln/eln/issues/200 https://forge.fedoraproject.org/releng/tickets/issues/12869 https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync/-/merge_requests/98 https://gitlab.com/redhat/centos-stream/ci-cd/distrosync/distrobuildsync/-/merge_requests/100 ## When do you need this? (YYYY/MM/DD) ASAP (although we haven't created such a user yet) ## When is this no longer needed or useful? (YYYY/MM/DD) N/A ## If we cannot complete this, what is the impact? [Dependencies/Blocker] ELN cannot implement batching of updates. /cc @sgallagh --- ## Checklist - [x] I have checked existing issues for duplicates - [x] I have filled out all the fields above - [x] I have provided relevant links or references (if applicable)
Member

Also, if this means we will be changing the user in Koji, we need to make sure that this new user has the same privileges as the existing distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org. Among other things, this means the new user needs to have privilege to rebuild the secure boot packages.

Also, if this means we will be changing the user in Koji, we need to make sure that this new user has the same privileges as the existing `distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org`. Among other things, this means the new user needs to have privilege to rebuild the secure boot packages.
Member

Do we need to create the user, or will releng generate one. It's unclear if "service account" users differ in FAS, so I don't want to jump the gun and create one manually.

Do we need to create the user, or will releng generate one. It's unclear if "service account" users differ in FAS, so I don't want to jump the gun and create one manually.
Owner

As a step 1 to it, I created eln-buildsync user, and gave it a signed-fpca for Fedora.

As a step 1 to it, I created `eln-buildsync` user, and gave it a signed-fpca for Fedora.
Member

@jnsamyak The eln-buildsync user will need to be a provenpackager and also be granted privileges to build secure boot packages. Put another way, it needs the same privileges afforded to the distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org currently on Koji, plus the ability to submit updates to Bodhi.

@jnsamyak The `eln-buildsync` user will need to be a provenpackager and also be granted privileges to build secure boot packages. Put another way, it needs the same privileges afforded to the `distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org` currently on Koji, plus the ability to submit updates to Bodhi.
Owner

The previous user on koji only had secure-boot permission:

amedvede@fedora:~$ koji list-permissions --user=distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org
Permission name   
------------------
secure-boot  
The previous user on koji only had `secure-boot` permission: ``` amedvede@fedora:~$ koji list-permissions --user=distrobuildsync-eln/jenkins-continuous-infra.apps.ci.centos.org Permission name ------------------ secure-boot ```
Owner

I'm not sure what group giving ability to submit updates on Bodhi, perhaps bodhi-admin?

I'm not sure what group giving ability to submit updates on Bodhi, perhaps `bodhi-admin`?
Owner

yeah bodhiadmin should be the one, there is sysadmin-bodhi too but I'll check.

yeah `bodhiadmin` should be the one, there is `sysadmin-bodhi` too but I'll check.
Owner
koji list-permissions --user=eln-buildsync     
Permission name   
------------------
secure-boot       
``` koji list-permissions --user=eln-buildsync Permission name ------------------ secure-boot ```
Owner

@jnsamyak can you please later document the steps you did, because I will need releng-bot user in the future and this knowledge will be really valuable

@jnsamyak can you please later document the steps you did, because I will need `releng-bot` user in the future and this knowledge will be really valuable
Owner

So Ansible changes are merged, perms are given, sgallagh created the keytab also.

CC: @yselkowitz @sgallagh

So Ansible changes are merged, perms are given, sgallagh created the keytab also. CC: @yselkowitz @sgallagh
Author
Member

The changes have been deployed on our end, and everything looks good so far. Presumably there will be a kernel build in the next few days which will allow us to verify the secure-boot permissions.

The changes have been deployed on our end, and everything looks good so far. Presumably there will be a kernel build in the next few days which will allow us to verify the secure-boot permissions.
Author
Member

Finally got a kernel build, and it was correctly sent to secure-boot channel. So looks like the user is working fine.

One question, does this account still have login credentials (aside from the keytab), and if so are we responsible for keeping those or releng?

Finally got a kernel build, and it was correctly sent to secure-boot channel. So looks like the user is working fine. One question, does this account still have login credentials (aside from the keytab), and if so are we responsible for keeping those or releng?
Owner

A couple of things here:

  1. We should have a wiki page for it since it's a bot account... https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_bot_accounts
  2. The email address here is just 'eln-buildsync@fedoraproject.org'... so it is collecting all it's email in /var/spool/mail/eln-buildsync on bastion01, which is not very ideal. ;( Can we set it's email to go somewhere where someone might look at it?
A couple of things here: 1. We should have a wiki page for it since it's a bot account... https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_bot_accounts 2. The email address here is just 'eln-buildsync@fedoraproject.org'... so it is collecting all it's email in /var/spool/mail/eln-buildsync on bastion01, which is not very ideal. ;( Can we set it's email to go somewhere where someone might look at it?
Member

@kevin wrote in #13132 (comment):

A couple of things here:

1. We should have a wiki page for it since it's a bot account... https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_bot_accounts

I'll look into writing this up as part of the work I'm doing with the Ansible deployment.

2. The email address here is just 'eln-buildsync@fedoraproject.org'... so it is collecting all it's email in /var/spool/mail/eln-buildsync on bastion01, which is not very ideal. ;( Can we set it's email to go somewhere where someone might look at it?

Can you point it at sgallagh+elnbuildsync@redhat.com for now? That will at least get it to me (and be easily filterable).

@kevin wrote in https://forge.fedoraproject.org/releng/tickets/issues/13132#issuecomment-866867: > A couple of things here: > > 1. We should have a wiki page for it since it's a bot account... https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_bot_accounts I'll look into writing this up as part of the work I'm doing with the Ansible deployment. > 2. The email address here is just 'eln-buildsync@fedoraproject.org'... so it is collecting all it's email in /var/spool/mail/eln-buildsync on bastion01, which is not very ideal. ;( Can we set it's email to go somewhere where someone might look at it? Can you point it at `sgallagh+elnbuildsync@redhat.com` for now? That will at least get it to me (and be easily filterable).
Owner

Done. (should be active in a bit, get your filters ready. ;)

Also, I think we can drop this from provenpackager and instead add it to the bodhi_update_bots group (which is where we have packit now).

Done. (should be active in a bit, get your filters ready. ;) Also, I think we can drop this from provenpackager and instead add it to the bodhi_update_bots group (which is where we have packit now).
Member

@kevin wrote in #13132 (comment):

Done. (should be active in a bit, get your filters ready. ;)

Also, I think we can drop this from provenpackager and instead add it to the bodhi_update_bots group (which is where we have packit now).

As long as we are sure that won't impact our ability to build in Koji, that's fine with me.

@kevin wrote in https://forge.fedoraproject.org/releng/tickets/issues/13132#issuecomment-867093: > Done. (should be active in a bit, get your filters ready. ;) > > Also, I think we can drop this from provenpackager and instead add it to the bodhi_update_bots group (which is where we have packit now). As long as we are sure that won't impact our ability to build in Koji, that's fine with me.
Owner

It shouldn't.

I have removed it from provenpackager and bodhiadmin and added it to bodhi_update_bots

I think that makes it more clear it's a bot, and I don't think it needs bodhiadmin (which also sends all the bodhi admin emails to it).

Please let me know if any of that breaks something.

It shouldn't. I have removed it from provenpackager and bodhiadmin and added it to bodhi_update_bots I think that makes it more clear it's a bot, and I don't think it needs bodhiadmin (which also sends all the bodhi admin emails to it). Please let me know if any of that breaks something.
Member

I think you may have just added it to Bodhi STG admins, because I am suddenly flooded with emails.

I think you may have just _added_ it to Bodhi STG admins, because I am suddenly flooded with emails.
Owner

I... only adjusted the production one.

Are the emails from prod or stg?

It may be that bodhi still thinks it's in the group right now?

I... only adjusted the production one. Are the emails from prod or stg? It may be that bodhi still thinks it's in the group right now?
Member

They're coming from stg, it looks like.

They're coming from stg, it looks like.
Owner

ok, I adjusted stg to the same groups now.

ok, I adjusted stg to the same groups now.
Owner

I don't get why you would get staging emails tho. It wasn't in any groups in stg before I added it.
I guess if you can forward one of those to me to look at?

I don't get why you would get staging emails tho. It wasn't in any groups in stg before I added it. I guess if you can forward one of those to me to look at?
Member

Forwarded one

Forwarded one
Author
Member

Ping?

Ping?
Owner

Sorry, this dropped off my radar. You are still getting them?
Can you send a more recent one?

Sorry, this dropped off my radar. You are still getting them? Can you send a more recent one?
Sign in to join this conversation.
No milestone
No project
No assignees
5 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
releng/tickets#13132
No description provided.