dbbf94a411
Almost global anyway, i.e. inside the VPN. The ipa/client-based shell access and sudo rules are only effective for staging right now, the respective playbook bits are masked out for prod. - Assign Ansible host groups to IPA host groups, the latter don't care about 'stg' in the name and use dashes rather than underscores. - Distill shell access groups from fas_client_groups in group and host vars. - Let all `sysadmin-*` groups in the previous list run anything via sudo in the host group (except bastion & batcave). - Remove `fas_client_groups` from staging host and group vars. - Remove sudoers from staging host and group vars if only `sysadmin-*` groups have shell access. - Set up `ipa_client_shell_groups` on bastion to be a super set of the same on batcave. Newly created IPA host groups: - autosign - badges - basset - bastion - batcave - blockerbugs - bodhi - bugzilla2fedmsg - busgateway - datagrepper - dbserver - dns - fedimg - github2fedmsg - ipa - kernel-qa - kerneltest - kojibuilder - kojihub - kojipkgs - logging - mailman - memcached - mirrormanager - nagios - notifs - oci-registry - odcs - openqa - openqa-workers - osbs - packages - pdc-web - pkgs - proxies - rabbitmq - releng-compose - resultsdb - secondary - sign-bridge - sundries - value - wiki Signed-off-by: Nils Philippsen <nils@redhat.com>
66 lines
2.2 KiB
Text
66 lines
2.2 KiB
Text
---
|
|
lvm_size: 20000
|
|
mem_size: 6144
|
|
num_cpus: 2
|
|
freezes: false
|
|
|
|
# for systems that do not match the above - specify the same parameter in
|
|
# the host_vars/$hostname file
|
|
|
|
tcp_ports: [ 3000, 3001, 3002, 3003 ]
|
|
|
|
fas_client_groups: sysadmin-noc,sysadmin-datanommer,sysadmin-veteran
|
|
sudoers: "{{ private }}/files/sudo/bugzilla2fedmsg-sudoers"
|
|
|
|
ipa_host_group: bugzilla2fedmsg
|
|
ipa_host_group_desc: Service to bridge Bugzilla events into fedmsg
|
|
ipa_client_shell_groups:
|
|
- sysadmin-datanommer
|
|
- sysadmin-noc
|
|
- sysadmin-veteran
|
|
ipa_client_sudo_groups:
|
|
- sysadmin-datanommer
|
|
- sysadmin-noc
|
|
- sysadmin-veteran
|
|
|
|
# These are consumed by a task in roles/fedmsg/base/main.yml
|
|
fedmsg_certs:
|
|
- service: shell
|
|
owner: root
|
|
group: sysadmin
|
|
can_send:
|
|
- logger.log
|
|
- service: bugzilla2fedmsg
|
|
owner: root
|
|
group: fedmsg
|
|
can_send:
|
|
- bugzilla.bug.new
|
|
- bugzilla.bug.update
|
|
|
|
# for fedora-messaging
|
|
username: "bugzilla2fedmsg{{ env_suffix }}"
|
|
|
|
# For the MOTD
|
|
csi_security_category: Low
|
|
csi_primary_contact: Fedmsg admins - sysadmin-datanommer-members@fedoraproject.org
|
|
csi_purpose: Run the bugzilla2fedmsg bridge to forward RH messages onto fedmsg
|
|
csi_relationship: |
|
|
A 'moksha-hub' daemon is the only thing really running here. (Don't confuse
|
|
that with the 'fedmsg-hub' running on most of our other backend machines.)
|
|
|
|
The bugzilla2fedmsg package provides a plugin to the moksha-hub that
|
|
connects out over the STOMP protocol to a 'fabric' of JBOSS FUSE brokers
|
|
living in the Red Hat DMZ. We authenticate with a cert/key pair that is
|
|
kept in /etc/pki/fedmsg/. Those brokers should push bugzilla events over
|
|
STOMP to our moksha-hub daemon. When a message arrives, we query bugzilla
|
|
about the change to get some 'more interesting' data to stuff in our
|
|
payload, then we sign the message using a fedmsg cert and fire it off to the
|
|
rest of our bus.
|
|
|
|
This service has no database, no memcached usage. It depends on those STOMP
|
|
brokers and being able to query bugzilla.rh.com.
|
|
|
|
STOMP config: /etc/moksha/production.ini
|
|
fedmsg config: /etc/fedmsg.d/
|
|
certs: /etc/pki/fedmsg
|
|
code: /usr/lib/python2.7/site-packages/bugzilla2fedmsg.py
|