The following applications are being ported to fedora-messaging, and would require a set of certificates for staging and prod.
releng-tools
When do you need this? (YYYY/MM/DD) When you can.
When is this no longer needed or useful? (YYYY/MM/DD) When we finally decide to replace our messaging system by Twitter posts.
If we cannot complete your request, what is the impact? I can't test the ported apps on staging (nor on prod).
Metadata Update from @kevin: - Issue priority set to: Waiting on Assignee (was: Needs Review)
I've got a bodhi beta in staging that I would like to use fedora-messaging with. Ideally I'd test it next week, though I understand if it can't be done by then. Bodhi can work with either messaging system until Bodhi 4, so this does not block me from testing and releasing my beta, but I would love to switch to fedora-messaging as soon as I am able.
I want to move the-new-hotness to openshift and deploy the version with fedora-messaging directly. So it will be nice to have it.
I'm also missing release-monitoring in the list.
I can make these.
So, with fedmsg our convention was to make these named the FQDN of each host. However, in the openshift world that doesn't make too much sense, so is there another convention we should use here?
Can multiple hosts use the same cert if we just issue one per service, but that service has multiple hosts?
Metadata Update from @kevin: - Issue assigned to kevin
From a security point of view, do we want this? For openshift-based instance this may be fine but for VMs, having 1 cert / host may be nice to track down issues if we run into unexpected behaviours.
The Distinguished Name or Common Name in the certificate maps to a user account in RabbitMQ[0]. We have RabbitMQ configured to use the Common Name, so you can make 1 cert or 100, but they all need to have the CN set to the user in RabbitMQ.
I'm not sure what security issues having 1 cert per host solves, can you expand on this?
Since you're probably not generating the CSR on the host, the key is getting copied around anyway, and revoking 1 certificate is easier and faster than revoking 100. Getting hold of any one of those certificates also gives you all the permissions of any other so I don't see much point.
If you're thinking about how to identify individual hosts as mis-behaving (in a non-security way) there's other ways to do that. Connections and all resources associated with them can be easily browsed from the web UI or CLI.
[0] https://github.com/rabbitmq/rabbitmq-auth-mechanism-ssl#username-extraction-from-certificate
That's what I had in mind, easily find out which is not behaving as expected on the bus.
Metadata Update from @smooge: - Issue priority set to: Next Meeting (was: Waiting on Assignee)
anitya basset bodhi bugzilla2fedmsg copr datagrepper datanommer elections fedbadges fedocal fedora-messaging fedora-search fm-orchestrator github2fedmsg koji koschei mailman3-fedmsg-plugin mdapi mirrormanager2 nuancier odcs pagure pungi releng-tools robosignatory sse2fedmsg supybot-fedmsg tag2distrepo tahrir tahrir-api the-new-hotness zanata2fedmsg
Additionally, I looked at all our existing fedmsg certs and:
These we should also port I think:
ftpsync - used in scripts about updates/rawhide being synced to master kerneltest librariesio lookaside - when people upload sources mediawiki - wiki page edits nagios - on alerts fpdc - ? planet - when people post to the planet releng - used for start/end of composes and such resultsdb - this is used by ci too? scm - lockbox and pkgs for when commits happen, etc. supybot - for zodbot twoweekatomic - when 2 week atomic releases happen
These are likely going away / we don't care:
autocloud fas fedimg fmn pdc
We should ask upstreams/owners about these:
openqa faf freshmaker greenwave mbs odcs retrace waiverdb
These I have no idea off hand:
magazine - do we even use this anywhere? happinesspackets - commops might be still using it?
not sure we want to track all those here off hand? Should we discuss on list? or would someone want to file issues on the ones we want to know about?
:eyeglasses:
Metadata Update from @kevin: - Issue priority set to: Waiting on Assignee (was: Next Meeting)
I'm not sure if we want to use librariesio anymore. I want to make it part of Anitya and I don't think anybody else is using it. It didn't even worked till I wanted to use it with Anitya.
@zlopez ok, shall I remove that pod/project in stg then?
@kevin Yes, I think you can.
To be clear, the list at the top of https://pagure.io/fedora-infrastructure/issue/7523#comment-555366 is the list of certs that have been created :)
The files are located for prod at:
{{private}}/files/rabbitmq/{{env}}/pki/ca.crt
{{private}}/files/rabbitmq/{{env}}/pki/issued/<app>.crt
{{private}}/files/rabbitmq/{{env}}/pki/private/<app>.key
For staging:
{{private}}/files/rabbitmq/{{env}}/pki/issued/<app>.stg.crt
{{private}}/files/rabbitmq/{{env}}/pki/private/<app>.stg.key
@kevin I'm seeing some app.stg.crt in the production tree, is that expected?
@pingou With fedmsg I used volumes in OpenShift. See https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/openshift-apps/release-monitoring/files/deploymentconfig.yml
fedmsg
Is something like this possible with fedora messaging?
@zlopez I think you need to do something similar to https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/playbooks/openshift-apps/the-new-hotness.yml#n18
To create the secret files and use them as a volume later
@cverna:
Thanks, I didn't noticed the logic is in playbook itself.
I have issue with {{private}} var.
{{private}}
I'm getting:
ERROR! Syntax Error while loading YAML. did not find expected key The error appears to have been in '/srv/web/infra/ansible/playbooks/openshift-apps/release-monitoring.yml': line 21, column 29, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: key: fedora-messaging-release-monitoring.ca privatefile: {{private}}/files/rabbitmq/{{env}}/pki/ca.crt ^ here We could be wrong, but this one looks like it might be an issue with missing quotes. Always quote template expression brackets when they start a value. For instance: with_items: - {{ foo }} Should be written as: with_items: - "{{ foo }}"
I fixed this issue by looking at the messaging-bridges playbook.
You actually need this in the OpenShift playbook: privatefile: "rabbitmq/{{ env }}/pki/private/release-monitoring.key"
privatefile: "rabbitmq/{{ env }}/pki/private/release-monitoring.key"
Something is not right. I'm getting this when I execute the playbook.
"Could not find or access '/srv/private/ansible/files/rabbitmq/staging/pki/private/release-monitoring.stg.key' on the Ansible Controller.
@zlopez try with anitya instead of the release-monitoring this is the name of the app from @kevin's comment
anitya
release-monitoring
@cverna Tried right now and it works. It's sometimes confusing.
\o/
yes not having the visibility of what is in the private repo makes it hard
As requested, I wrote up some documentation on how to make a user/queues/bindings in the infra-docs: https://pagure.io/infra-docs/pull-request/143
Together with @jcline and @abompard we managed to make the-new-hotness and Anitya work with fedora-messaging.
If anybody wants to see, how this is done, you can look at Anitya as publisher example and the-new-hotness as consumer example.
I deleted the librariesio2fedmsg stg app. I'll clean up the one stg cert that somehow was in prod.
I'm going to close this now, reopen or file new ticket if you need anything further.
Metadata Update from @kevin: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Thanks @kevin
Login to comment on this ticket.