+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ This section goes over various Documentation for the Infrastructure team. Please +use the menu items to find the various pages of interest.
+URL: https://accounts.rockylinux.org
+Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem
+Technology: Noggin used by Fedora Infrastructure
+Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
URL: https://git.resf.org
+Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.
+Technology: Gitea
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://github.com/rocky-linux
+Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.
+Technology: GitHub
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://git.rockylinux.org
+Purpose: Packages and light code for the Rocky Linux distribution
+Technology: GitLab
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem
+Technology: Mailman 3 + Hyper Kitty
+Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
| Name | +Mattermost Name | +IRC Name | +|
|---|---|---|---|
| Neil Hanlon | +neil@resf.org | +@neil | +neil | +
| Taylor Goodwill | +tg@resf.org | +@tgo | +tg | +
| Louis Abel | +label@rockylinux.org | +@nazunalika | +Sokel/label/Sombra | +
This document covers the guidelines as set out by the Infrastructure/Core group for designing modular repositories that may be used in the Rocky AWX instance or local execution based on team needs. This is meant to supersede the guidelines in the ansible-awx-template repository.
+This does not cover detailed examples, but is meant to get teams and their contributors started in designing or improving upon all ansible related activities for their group.
+| + | + |
|---|---|
| Owner | +Infrastructure Team | +
| Email Contact | +infrastructure@rockylinux.org | +
| Mattermost Contacts | +@label |
+
| Mattermost Contacts | +@neil |
+
| Mattermost Contacts | +@tgo |
+
| Mattermost Channels | +~Infrastructure |
+
This section covers the basics for your AWX project. It is absolutely important that you start with these as an absolute bare minimum. While you will be forking/cloning off of infrastructure/ansible-awx-template and using that as the starting point, the next few sections will explain the basic structure and basic design principals.
You should begin by starting from the Infrastructure Ansible AWX Template.
+The general structure will always start from this:
+.
+├── somePlaybook.yml
+├── defaults
+│ └── main.yml
+├── files
+├── handlers
+│ └── main.yml
+├── tasks
+│ └── main.yml
+├── templates
+├── tests
+│ ├── inventory
+│ └── test.yml
+└── vars
+ └── main.yml
+This structure follows the basic expected structure for ansible (this means ignoring AWX/Tower). If you are familiar with ansible already, you may already know how these files and directories work at an operational level. The gist of it is:
+./tasks if neededWith these basic ideas in mind, we can move into playbook design.
+Generally, your playbooks should be doing the following:
+./tasks directoryAt no point should you be using ./tasks/main.yml under any circumstance.
In majority of cases, you will need to have pre-flight and post-flight tasks. These aren't needed in all cases, but they should be used as a starting point.
+ pre_tasks:
+ - name: Check if ansible cannot be run here
+ ansible.builtin.stat:
+ path: /etc/no-ansible
+ register: no_ansible
+
+ - name: Verify if we can run ansible
+ ansible.builtin.assert:
+ that:
+ - "not no_ansible.stat.exists"
+ success_msg: "We are able to run on this node"
+ fail_msg: "/etc/no-ansible exists - skipping run on this node"
+
+ # Assertions and other checks here
+
+ # Import roles/tasks here
+
+ post_tasks:
+ - name: Touching run file that ansible has ran here
+ ansible.builtin.file:
+ path: /var/log/ansible.run
+ state: touch
+ mode: '0644'
+ owner: root
+ group: root
+Ensure that your tasks are using FQCN. This means, even for the simple modules such as file, you should be using ansible.builtin.file to be compliant with ansible-lint 6+ and ansible 2.12+.
Each playbook should have comments or a name descriptor that explains what the playbook does or how it is used. If not available, README-... can be used in place, especially in the case of adhoc playbooks that take or require input. Documentation for each playbook/role does not have to be on a wiki. Comments or README's should be perfectly sufficient.
Ensure that you are using relevant tags where necessary for your tasks. This will allow you or the deployers to have deeper control of what is ran or called in AWX.
+When making playbooks, there is a set of predefined prefixes you will need to set. It is highly discouraged to step outside of these prefixes.
+init-* -> Starting playbooks that run solo or import other playbooks that start
+ with import-. Can also be used to run updates or repetive tasks that
+ adhoc may not suffice and running a role playbook is too much overhead.
+
+adhoc -> These playbooks are one-off playbooks that can be used on the CLI or
+ in AWX. These are typically for basic tasks.
+
+import -> Playbooks that should be imported from the top level playbooks or
+ used to "import" or "add" data somewhere (e.g., a database or LDAP)
+
+role-* -> These playbooks call roles for potential tasks or even roles in general.
+Using the role prefix without an ansible role
+It is perfectly fine to use role- as a way to say "this system will do or be X" without calling out to an ansible role. You may use role for this case or you can use init. This is not a strict requirement and you should go with what feels right for your project.
There will likely be multiple dynamic inventory sources used for hosts managed by AWX, and as a result, there will be a lot of groups defined with one or more hosts at a time. As this is the case, here are some things to keep in mind:
+When filling in the hosts directive, follow these general guidelines:
allhost: {{ host }} and the host var can be defined as an extra varGenerally local inventory files are not recommended. Some general rules to follow is this:
+inventory (the current .gitignore prevents this from being committed by default).gitignore to include the fileWe want to prevent AWX from picking up a random inventory that isn't defined within it.
+General ansible.cfg files are not recommended as they would be picked up during normal operation. These should be provided only for special cases. Optionally, you may provide it under another name that a user can reference for local execution outside of AWX.
+Collections and roles should be defined in a requirements.yml in their respective directories. AWX will pick them up. Optionally, you can provide a playbook or script to install roles and collections locally. Example commands that could be in a script or playbook:
ansible-galaxy collection install -r collections/requirements.yml
+ansible-galaxy role install -r roles/requirements.yml
+Tools like ansible-navigator and ansible-builder can also help in this area as well.
When committing, pre-commit must run to verify your changes. They must be passing to be pushed up. This is an absolute requirement, even for roles. There are very rare exceptions to this rule and they may be granted depending on what it is.
+When the linter passes, a push can be performed. After that, if a PR is necessary, open one. Otherwise, it should be free to use locally or in AWX.
+A template generally comes with a tests directory. While not strictly required, it is recommended to create a suite of tests to ensure most, if not all of your playbooks are in working order. This is similar to providing tests to ansible collections, in that they should test at least basic functionality.
Complex situations can be tested for as well and is encouraged.
+ +This section goes over guidelines that the Infrastructure team has set out for +anything related to the infrastructure managed for the RESF and Rocky Linux.
+All guidelines are listed on the left side of this page.
+URL: https://accounts.rockylinux.org
+Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem
+Technology: Noggin used by Fedora Infrastructure
+Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
URL: https://git.resf.org
+Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.
+Technology: Gitea
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://github.com/rocky-linux
+Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.
+Technology: GitHub
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://git.rockylinux.org
+Purpose: Packages and light code for the Rocky Linux distribution
+Technology: GitLab
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem
+Technology: Mailman 3 + Hyper Kitty
+Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
| Name | +Mattermost Name | +IRC Name | +|
|---|---|---|---|
| Neil Hanlon | +neil@resf.org | +@neil | +neil | +
| Taylor Goodwill | +tg@resf.org | +@tgo | +tg | +
| Louis Abel | +label@rockylinux.org | +@nazunalika | +Sokel/label/Sombra | +
URL: https://accounts.rockylinux.org
+Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem
+Technology: Noggin used by Fedora Infrastructure
+Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
URL: https://git.resf.org
+Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.
+Technology: Gitea
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://github.com/rocky-linux
+Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.
+Technology: GitHub
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://git.rockylinux.org
+Purpose: Packages and light code for the Rocky Linux distribution
+Technology: GitLab
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem
+Technology: Mailman 3 + Hyper Kitty
+Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
| Name | +Mattermost Name | +IRC Name | +|
|---|---|---|---|
| Neil Hanlon | +neil@resf.org | +@neil | +neil | +
| Taylor Goodwill | +tg@resf.org | +@tgo | +tg | +
| Louis Abel | +label@rockylinux.org | +@nazunalika | +Sokel/label/Sombra | +
| Role | +Name | +Mattermost Name | +IRC Name | +|
|---|---|---|---|---|
| Infrastructure Lead | +Neil Hanlon | +neil@resf.org | +@neil | +neil | +
| Infrastructure Lead | +Taylor Goodwill | +tg@resf.org | +@tgo | +tg | +
| Infrastructure, IdM & Release Engineering | +Louis Abel | +label@rockylinux.org | +@nazunalika | +Sokel/label/Sombra | +
| Infrastructure | +Randolph | ++ | @meltro | +N/A | +
| Infrastructure | +Patrick Roberts | ++ | @preachermanx | +N/A | +
This section goes over various Documentation for the Infrastructure team. Please use the menu items to find the various pages of interest.
Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContactsURL: https://accounts.rockylinux.org
Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem
Technology: Noggin used by Fedora Infrastructure
Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
URL: https://git.resf.org
Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.
Technology: Gitea
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://github.com/rocky-linux
Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.
Technology: GitHub
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://git.rockylinux.org
Purpose: Packages and light code for the Rocky Linux distribution
Technology: GitLab
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://lists.resf.org
Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem
Technology: Mailman 3 + Hyper Kitty
Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
This section goes over guidelines that the Infrastructure team has set out for anything related to the infrastructure managed for the RESF and Rocky Linux.
All guidelines are listed on the left side of this page.
Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContactsURL: https://accounts.rockylinux.org
Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem
Technology: Noggin used by Fedora Infrastructure
Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
URL: https://git.resf.org
Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.
Technology: Gitea
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://github.com/rocky-linux
Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.
Technology: GitHub
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://git.rockylinux.org
Purpose: Packages and light code for the Rocky Linux distribution
Technology: GitLab
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://lists.resf.org
Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem
Technology: Mailman 3 + Hyper Kitty
Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
This document covers the guidelines as set out by the Infrastructure/Core group for designing modular repositories that may be used in the Rocky AWX instance or local execution based on team needs. This is meant to supersede the guidelines in the ansible-awx-template repository.
This does not cover detailed examples, but is meant to get teams and their contributors started in designing or improving upon all ansible related activities for their group.
"},{"location":"guidelines/awx_scm_guidelines/#contact-information","title":"Contact Information","text":"Owner Infrastructure Team Email Contact infrastructure@rockylinux.org Mattermost Contacts@label Mattermost Contacts @neil Mattermost Contacts @tgo Mattermost Channels ~Infrastructure"},{"location":"guidelines/awx_scm_guidelines/#guidelines","title":"Guidelines","text":"This section covers the basics for your AWX project. It is absolutely important that you start with these as an absolute bare minimum. While you will be forking/cloning off of infrastructure/ansible-awx-template and using that as the starting point, the next few sections will explain the basic structure and basic design principals.
You should begin by starting from the Infrastructure Ansible AWX Template.
"},{"location":"guidelines/awx_scm_guidelines/#root-structure","title":"Root Structure","text":"The general structure will always start from this:
.\n\u251c\u2500\u2500 somePlaybook.yml\n\u251c\u2500\u2500 defaults\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\n\u251c\u2500\u2500 files\n\u251c\u2500\u2500 handlers\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\n\u251c\u2500\u2500 tasks\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 main.yml\n\u251c\u2500\u2500 templates\n\u251c\u2500\u2500 tests\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 inventory\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 test.yml\n\u2514\u2500\u2500 vars\n \u2514\u2500\u2500 main.yml\nThis structure follows the basic expected structure for ansible (this means ignoring AWX/Tower). If you are familiar with ansible already, you may already know how these files and directories work at an operational level. The gist of it is:
./tasks if neededWith these basic ideas in mind, we can move into playbook design.
"},{"location":"guidelines/awx_scm_guidelines/#designing-playbooks","title":"Designing Playbooks","text":"Generally, your playbooks should be doing the following:
./tasks directoryAt no point should you be using ./tasks/main.yml under any circumstance.
In majority of cases, you will need to have pre-flight and post-flight tasks. These aren't needed in all cases, but they should be used as a starting point.
pre_tasks:\n - name: Check if ansible cannot be run here\n ansible.builtin.stat:\n path: /etc/no-ansible\n register: no_ansible\n\n - name: Verify if we can run ansible\n ansible.builtin.assert:\n that:\n - \"not no_ansible.stat.exists\"\n success_msg: \"We are able to run on this node\"\n fail_msg: \"/etc/no-ansible exists - skipping run on this node\"\n\n # Assertions and other checks here\n\n # Import roles/tasks here\n\n post_tasks:\n - name: Touching run file that ansible has ran here\n ansible.builtin.file:\n path: /var/log/ansible.run\n state: touch\n mode: '0644'\n owner: root\n group: root\nEnsure that your tasks are using FQCN. This means, even for the simple modules such as file, you should be using ansible.builtin.file to be compliant with ansible-lint 6+ and ansible 2.12+.
Each playbook should have comments or a name descriptor that explains what the playbook does or how it is used. If not available, README-... can be used in place, especially in the case of adhoc playbooks that take or require input. Documentation for each playbook/role does not have to be on a wiki. Comments or README's should be perfectly sufficient.
Ensure that you are using relevant tags where necessary for your tasks. This will allow you or the deployers to have deeper control of what is ran or called in AWX.
"},{"location":"guidelines/awx_scm_guidelines/#playbook-naming-system","title":"Playbook Naming System","text":"When making playbooks, there is a set of predefined prefixes you will need to set. It is highly discouraged to step outside of these prefixes.
init-* -> Starting playbooks that run solo or import other playbooks that start\n with import-. Can also be used to run updates or repetive tasks that\n adhoc may not suffice and running a role playbook is too much overhead.\n\nadhoc -> These playbooks are one-off playbooks that can be used on the CLI or\n in AWX. These are typically for basic tasks.\n\nimport -> Playbooks that should be imported from the top level playbooks or\n used to \"import\" or \"add\" data somewhere (e.g., a database or LDAP)\n\nrole-* -> These playbooks call roles for potential tasks or even roles in general.\nUsing the role prefix without an ansible role
It is perfectly fine to use role- as a way to say \"this system will do or be X\" without calling out to an ansible role. You may use role for this case or you can use init. This is not a strict requirement and you should go with what feels right for your project.
There will likely be multiple dynamic inventory sources used for hosts managed by AWX, and as a result, there will be a lot of groups defined with one or more hosts at a time. As this is the case, here are some things to keep in mind:
When filling in the hosts directive, follow these general guidelines:
allhost: {{ host }} and the host var can be defined as an extra varGenerally local inventory files are not recommended. Some general rules to follow is this:
inventory (the current .gitignore prevents this from being committed by default).gitignore to include the fileWe want to prevent AWX from picking up a random inventory that isn't defined within it.
"},{"location":"guidelines/awx_scm_guidelines/#local-ansiblecfg-files","title":"Local ansible.cfg files","text":"General ansible.cfg files are not recommended as they would be picked up during normal operation. These should be provided only for special cases. Optionally, you may provide it under another name that a user can reference for local execution outside of AWX.
"},{"location":"guidelines/awx_scm_guidelines/#collections-and-roles","title":"Collections and Roles","text":"Collections and roles should be defined in a requirements.yml in their respective directories. AWX will pick them up. Optionally, you can provide a playbook or script to install roles and collections locally. Example commands that could be in a script or playbook:
ansible-galaxy collection install -r collections/requirements.yml\nansible-galaxy role install -r roles/requirements.yml\nTools like ansible-navigator and ansible-builder can also help in this area as well.
When committing, pre-commit must run to verify your changes. They must be passing to be pushed up. This is an absolute requirement, even for roles. There are very rare exceptions to this rule and they may be granted depending on what it is.
When the linter passes, a push can be performed. After that, if a PR is necessary, open one. Otherwise, it should be free to use locally or in AWX.
"},{"location":"guidelines/awx_scm_guidelines/#tests","title":"Tests","text":"A template generally comes with a tests directory. While not strictly required, it is recommended to create a suite of tests to ensure most, if not all of your playbooks are in working order. This is similar to providing tests to ansible collections, in that they should test at least basic functionality.
Complex situations can be tested for as well and is encouraged.
"},{"location":"include/resources_bottom/","title":"Resources bottom","text":"Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContactsURL: https://accounts.rockylinux.org
Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem
Technology: Noggin used by Fedora Infrastructure
Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
URL: https://git.resf.org
Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.
Technology: Gitea
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://github.com/rocky-linux
Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.
Technology: GitHub
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://git.rockylinux.org
Purpose: Packages and light code for the Rocky Linux distribution
Technology: GitLab
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://lists.resf.org
Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem
Technology: Mailman 3 + Hyper Kitty
Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
This section goes over the various SOP's for the Infrastructure Team. Please use the menu items to find the various pages of interest.
Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContactsURL: https://accounts.rockylinux.org
Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem
Technology: Noggin used by Fedora Infrastructure
Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
URL: https://git.resf.org
Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.
Technology: Gitea
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://github.com/rocky-linux
Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.
Technology: GitHub
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://git.rockylinux.org
Purpose: Packages and light code for the Rocky Linux distribution
Technology: GitLab
Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://lists.resf.org
Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem
Technology: Mailman 3 + Hyper Kitty
Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
This SOP covers how the Rocky Enterprise Software Foundation (RESF) and Rocky Linux Infrastructure Team handles GDRP (General Data Protection Regulation) data delete requests. It contains information about how System Administrators will use Ansible and other tooling to respond to delete requests.
"},{"location":"sop/idm_sop_gdpr/#contact-information","title":"Contact Information","text":"Owner Infrastructure Team & Identity Management Team Email Contact infrastructure@rockylinux.org Email Contact identitymanagement@rockylinux.org Mattermost Contacts@label Mattermost Channels ~Infrastructure"},{"location":"sop/idm_sop_gdpr/#responding-to-a-deletion-request","title":"Responding to a Deletion Request","text":"This section covers how a system administrator will use our adhoc-ipauser-disable-pdr.yml playbook to respond to a delete request.
If a request has been received via email, perform the following steps:
If request was received by email: Open a ticket at the bug tracker under the Account Services product (Click the drop down in the top right corner, click \"Account Services\", select \"Report Issue\")
Account Requests - Personal Data RequestPDR - Email Delete Request for <USER/EMAIL>PDR Request - Remove Personal Information or copied directly from the email if the template was followed.On the ansible host, run the necessary ansible playbook: ansible-playbook -i inventories/production/hosts.ini playbooks/adhoc-ipauser-disable-pdr.yml --extra-vars='ipa_user=<USER> ticket_id=BT<TICKET>'
Hello. We have reviewed your account request and have performed the requested\nchanges. The ticket <ID> has been closed and set to private.\n\nPlease note that some public content such as mailing lists cannot be deleted\nsince some information is meant to serve the RESF legitimate business\ninterests, the public interest, and the interest of the open source community.\n\nThank you, please let us know if you have any further questions.\nRESOLVED"},{"location":"sop/idm_sop_mm_ras/","title":"SOP: Mattermost and RAS Group Sync","text":"This SOP covers how the Rocky Enterprise Software Foundation (RESF) and Rocky Linux Infrastructure handles group syncing between the Rocky Account Services and Mattermost Channels. It contains information about how System Administrators will create groups, the templates, and how to setup syncing within Mattermost.
Note: This assumes the user is logging in with their RAS credentials to Mattermost.
"},{"location":"sop/idm_sop_mm_ras/#contact-information","title":"Contact Information","text":"Owner Infrastructure Team & Identity Management Team Email Contact infrastructure@rockylinux.org Email Contact identitymanagement@rockylinux.org Mattermost Contacts@label Mattermost Contacts @neil Mattermost Channels ~Infrastructure"},{"location":"sop/idm_sop_mm_ras/#creating-the-necessary-group","title":"Creating the necessary group","text":"This section covers how a system administrator will create a group Rocky Account Services using ansible. The playbook utilized will be adhoc-ipagroup.yml.
mm_X_name. mm is for mattermost, X will be for the designated part of Mattermost (e.g., resf, rl, and so on), and name will be the name of the group in question.On the ansible host, run the necessary ansible playbook: ansible-playbook -i inventories/production/hosts.ini ansible-ipa-management/adhoc-ipagroup.yml --extra-vars='ipa_group=<GROUP> ipa_description=\"<DESC>\" ipa_nonposix=false ipa_fas=true ipa_group_manager_user=<OWNER>'
ipa_fas=true ensures that the group will appear in Rocky Account Services and can be managed there.ipa_group_manager_user will set a user in RAS that can manage the group without requesting for an administrator to do so.Within mattermost's administration console, apply the group to the channel as necessary.
"}]} \ No newline at end of file diff --git a/sitemap.xml b/sitemap.xml new file mode 100644 index 0000000..12329dc --- /dev/null +++ b/sitemap.xml @@ -0,0 +1,43 @@ + +This SOP covers how the Rocky Enterprise Software Foundation (RESF) and Rocky Linux Infrastructure Team handles GDRP (General Data Protection Regulation) data delete requests. It contains information about how System Administrators will use Ansible and other tooling to respond to delete requests.
+| + | + |
|---|---|
| Owner | +Infrastructure Team & Identity Management Team | +
| Email Contact | +infrastructure@rockylinux.org | +
| Email Contact | +identitymanagement@rockylinux.org | +
| Mattermost Contacts | +@label |
+
| Mattermost Channels | +~Infrastructure |
+
This section covers how a system administrator will use our adhoc-ipauser-disable-pdr.yml playbook to respond to a delete request.
If a request has been received via email, perform the following steps:
+If request was received by email: Open a ticket at the bug tracker under the Account Services product (Click the drop down in the top right corner, click "Account Services", select "Report Issue")
Account Requests - Personal Data RequestPDR - Email Delete Request for <USER/EMAIL>PDR Request - Remove Personal Information or copied directly from the email if the template was followed.On the ansible host, run the necessary ansible playbook: ansible-playbook -i inventories/production/hosts.ini playbooks/adhoc-ipauser-disable-pdr.yml --extra-vars='ipa_user=<USER> ticket_id=BT<TICKET>'
Hello. We have reviewed your account request and have performed the requested
+changes. The ticket <ID> has been closed and set to private.
+
+Please note that some public content such as mailing lists cannot be deleted
+since some information is meant to serve the RESF legitimate business
+interests, the public interest, and the interest of the open source community.
+
+Thank you, please let us know if you have any further questions.
+RESOLVED
+
+ This SOP covers how the Rocky Enterprise Software Foundation (RESF) and Rocky Linux Infrastructure handles group syncing between the Rocky Account Services and Mattermost Channels. It contains information about how System Administrators will create groups, the templates, and how to setup syncing within Mattermost.
+Note: This assumes the user is logging in with their RAS credentials to Mattermost.
+| + | + |
|---|---|
| Owner | +Infrastructure Team & Identity Management Team | +
| Email Contact | +infrastructure@rockylinux.org | +
| Email Contact | +identitymanagement@rockylinux.org | +
| Mattermost Contacts | +@label |
+
| Mattermost Contacts | +@neil |
+
| Mattermost Channels | +~Infrastructure |
+
This section covers how a system administrator will create a group Rocky Account Services using ansible. The playbook utilized will be adhoc-ipagroup.yml.
mm_X_name. mm is for mattermost, X will be for the designated part of Mattermost (e.g., resf, rl, and so on), and name will be the name of the group in question.On the ansible host, run the necessary ansible playbook: ansible-playbook -i inventories/production/hosts.ini ansible-ipa-management/adhoc-ipagroup.yml --extra-vars='ipa_group=<GROUP> ipa_description="<DESC>" ipa_nonposix=false ipa_fas=true ipa_group_manager_user=<OWNER>'
ipa_fas=true ensures that the group will appear in Rocky Account Services and can be managed there.ipa_group_manager_user will set a user in RAS that can manage the group without requesting for an administrator to do so.Within mattermost's administration console, apply the group to the channel as necessary.
+ +This section goes over the various SOP's for the Infrastructure Team. Please use the menu items +to find the various pages of interest.
+URL: https://accounts.rockylinux.org
+Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem
+Technology: Noggin used by Fedora Infrastructure
+Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
URL: https://git.resf.org
+Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.
+Technology: Gitea
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://github.com/rocky-linux
+Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.
+Technology: GitHub
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
URL: https://git.rockylinux.org
+Purpose: Packages and light code for the Rocky Linux distribution
+Technology: GitLab
+Contact: ~Infrastructure, ~Development in Mattermost and #rockylinux-infra, #rockylinux-devel in Libera IRC
Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem
+Technology: Mailman 3 + Hyper Kitty
+Contact: ~Infrastructure in Mattermost and #rockylinux-infra in Libera IRC
| Name | +Mattermost Name | +IRC Name | +|
|---|---|---|---|
| Neil Hanlon | +neil@resf.org | +@neil | +neil | +
| Taylor Goodwill | +tg@resf.org | +@tgo | +tg | +
| Louis Abel | +label@rockylinux.org | +@nazunalika | +Sokel/label/Sombra | +