From 6153b33649212b8e855bf756ee50da6c346c5165 Mon Sep 17 00:00:00 2001 From: <> Date: Thu, 13 Apr 2023 21:18:42 +0000 Subject: [PATCH] Deployed d5e1199 with MkDocs version: 1.4.2 --- documentation/index.html | 70 +--------------------------------- guidelines/index.html | 70 +--------------------------------- search/search_index.json | 2 +- sitemap.xml.gz | Bin 281 -> 281 bytes sop/idm_sop_gdpr/index.html | 70 +++++++++++++++++++++++++++++++++- sop/idm_sop_mm_ras/index.html | 70 +++++++++++++++++++++++++++++++++- sop/index.html | 70 +--------------------------------- 7 files changed, 142 insertions(+), 210 deletions(-) diff --git a/documentation/index.html b/documentation/index.html index cd41d5a..22338ca 100644 --- a/documentation/index.html +++ b/documentation/index.html @@ -474,81 +474,13 @@

This section goes over various Documentation for the Infrastructure team. Please use the menu items to find the various pages of interest.

-

Resources

- -
-
-
-

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

-
-
-

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

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameEmailMattermost NameIRC Name
Neil Hanlonneil@resf.org@neilneil
Taylor Goodwilltg@resf.org@tgotg
Louis Abellabel@rockylinux.org@nazunalikaSokel/label/Sombra
-
-
-
Last update: - April 12, 2023 + April 13, 2023 diff --git a/guidelines/index.html b/guidelines/index.html index a726651..9ef274e 100644 --- a/guidelines/index.html +++ b/guidelines/index.html @@ -475,81 +475,13 @@

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

- -
-
-
-

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

-
-
-

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

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameEmailMattermost NameIRC Name
Neil Hanlonneil@resf.org@neilneil
Taylor Goodwilltg@resf.org@tgotg
Louis Abellabel@rockylinux.org@nazunalikaSokel/label/Sombra
-
-
-
Last update: - April 12, 2023 + April 13, 2023 diff --git a/search/search_index.json b/search/search_index.json index ce079b8..faaf1aa 100644 --- a/search/search_index.json +++ b/search/search_index.json @@ -1 +1 @@ -{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Infrastructure Wiki","text":""},{"location":"#links","title":"Links","text":""},{"location":"#responsibilities","title":"Responsibilities","text":""},{"location":"#meetings-communications","title":"Meetings / Communications","text":""},{"location":"#members","title":"Members","text":"Role Name Email 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"},{"location":"documentation/","title":"Documentation","text":"

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 ListsContacts

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

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

Name Email 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"},{"location":"guidelines/","title":"Guidelines","text":"

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 ListsContacts

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

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

Name Email 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"},{"location":"guidelines/awx_scm_guidelines/","title":"AWX / Ansible SCM Guidelines","text":"

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\n

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:

With 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:

  1. Checking if ansible can be ran on a specific host
  2. Asserting if variables are filled and are correctly formed, if applicable
  3. Importing tasks from the ./tasks directory
  4. Importing roles, if necessary
  5. Post tasks, if necessary

At no point should you be using ./tasks/main.yml under any circumstance.

"},{"location":"guidelines/awx_scm_guidelines/#pre-flight-and-post-flight-tasks","title":"Pre-flight and Post-flight Tasks","text":"

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\n
"},{"location":"guidelines/awx_scm_guidelines/#tasks-general-information","title":"Tasks General Information","text":"

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+.

"},{"location":"guidelines/awx_scm_guidelines/#comments","title":"Comments","text":"

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.

"},{"location":"guidelines/awx_scm_guidelines/#tags","title":"Tags","text":"

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.\n

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.

"},{"location":"guidelines/awx_scm_guidelines/#defining-hosts","title":"Defining Hosts","text":"

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:

"},{"location":"guidelines/awx_scm_guidelines/#local-inventory-files","title":"Local Inventory Files","text":"

Generally local inventory files are not recommended. Some general rules to follow is this:

We 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\n

Tools like ansible-navigator and ansible-builder can also help in this area as well.

"},{"location":"guidelines/awx_scm_guidelines/#pre-commits-linting","title":"Pre-commits / linting","text":"

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 ListsContacts

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

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

Name Email 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"},{"location":"sop/","title":"SOP (Standard Operationg Procedures)","text":"

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 ListsContacts

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

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

Name Email 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"},{"location":"sop/idm_sop_gdpr/","title":"SOP: Personal Data Request - Deletion","text":"

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:

  1. 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\")

    • Set category to Account Requests - Personal Data Request
    • Assign to yourself if possible
    • Summary should be set: PDR - Email Delete Request for <USER/EMAIL>
    • Description should be set to the snippet PDR Request - Remove Personal Information or copied directly from the email if the template was followed.
    • Use the ID for the ansible playbook

  2. 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>'

  3. Leave a comment on the issue that the disable request was performed.
  4. Email the affected user:

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.\n
4. Set ticket to RESOLVED

"},{"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.

  1. First, determine where and how the group will be utilized. The starting template will be 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.

  2. 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>'

    • Ensure that the description is set in a way that it explains what it is for
    • It is unlikely the group will need to have a GID assigned. Assigning the group as nonposix should be sufficient.
    • Setting the group with ipa_fas=true ensures that the group will appear in Rocky Account Services and can be managed there.
    • Setting ipa_group_manager_user will set a user in RAS that can manage the group without requesting for an administrator to do so.
"},{"location":"sop/idm_sop_mm_ras/#syncing-in-mattermost","title":"Syncing in Mattermost","text":"

Within mattermost's administration console, apply the group to the channel as necessary.

"}]} \ No newline at end of file +{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Infrastructure Wiki","text":""},{"location":"#links","title":"Links","text":""},{"location":"#responsibilities","title":"Responsibilities","text":""},{"location":"#meetings-communications","title":"Meetings / Communications","text":""},{"location":"#members","title":"Members","text":"Role Name Email 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"},{"location":"documentation/","title":"Documentation","text":"

This section goes over various Documentation for the Infrastructure team. Please use the menu items to find the various pages of interest.

"},{"location":"guidelines/","title":"Guidelines","text":"

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.

"},{"location":"guidelines/awx_scm_guidelines/","title":"AWX / Ansible SCM Guidelines","text":"

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\n

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:

With 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:

  1. Checking if ansible can be ran on a specific host
  2. Asserting if variables are filled and are correctly formed, if applicable
  3. Importing tasks from the ./tasks directory
  4. Importing roles, if necessary
  5. Post tasks, if necessary

At no point should you be using ./tasks/main.yml under any circumstance.

"},{"location":"guidelines/awx_scm_guidelines/#pre-flight-and-post-flight-tasks","title":"Pre-flight and Post-flight Tasks","text":"

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\n
"},{"location":"guidelines/awx_scm_guidelines/#tasks-general-information","title":"Tasks General Information","text":"

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+.

"},{"location":"guidelines/awx_scm_guidelines/#comments","title":"Comments","text":"

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.

"},{"location":"guidelines/awx_scm_guidelines/#tags","title":"Tags","text":"

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.\n

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.

"},{"location":"guidelines/awx_scm_guidelines/#defining-hosts","title":"Defining Hosts","text":"

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:

"},{"location":"guidelines/awx_scm_guidelines/#local-inventory-files","title":"Local Inventory Files","text":"

Generally local inventory files are not recommended. Some general rules to follow is this:

We 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\n

Tools like ansible-navigator and ansible-builder can also help in this area as well.

"},{"location":"guidelines/awx_scm_guidelines/#pre-commits-linting","title":"Pre-commits / linting","text":"

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 ListsContacts

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

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

Name Email 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"},{"location":"sop/","title":"SOP (Standard Operationg Procedures)","text":"

This section goes over the various SOP's for the Infrastructure Team. Please use the menu items to find the various pages of interest.

"},{"location":"sop/idm_sop_gdpr/","title":"SOP: Personal Data Request - Deletion","text":"

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:

  1. 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\")

    • Set category to Account Requests - Personal Data Request
    • Assign to yourself if possible
    • Summary should be set: PDR - Email Delete Request for <USER/EMAIL>
    • Description should be set to the snippet PDR Request - Remove Personal Information or copied directly from the email if the template was followed.
    • Use the ID for the ansible playbook

  2. 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>'

  3. Leave a comment on the issue that the disable request was performed.
  4. Email the affected user:

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.\n
4. Set ticket to RESOLVED

Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContacts

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

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

Name Email 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"},{"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.

  1. First, determine where and how the group will be utilized. The starting template will be 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.

  2. 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>'

    • Ensure that the description is set in a way that it explains what it is for
    • It is unlikely the group will need to have a GID assigned. Assigning the group as nonposix should be sufficient.
    • Setting the group with ipa_fas=true ensures that the group will appear in Rocky Account Services and can be managed there.
    • Setting ipa_group_manager_user will set a user in RAS that can manage the group without requesting for an administrator to do so.
"},{"location":"sop/idm_sop_mm_ras/#syncing-in-mattermost","title":"Syncing in Mattermost","text":"

Within mattermost's administration console, apply the group to the channel as necessary.

Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContacts

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

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

Name Email 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"}]} \ No newline at end of file diff --git a/sitemap.xml.gz b/sitemap.xml.gz index d376f662fe43e90ad3a78c5eea0f067091dab4a6..fa6a690c750a8a0f2bb23af057641de3fbceebe2 100644 GIT binary patch delta 15 WcmbQqG?R%
4. Set ticket to RESOLVED

+

Resources

+ +
+
+
+

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

+
+
+

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

+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameEmailMattermost NameIRC Name
Neil Hanlonneil@resf.org@neilneil
Taylor Goodwilltg@resf.org@tgotg
Louis Abellabel@rockylinux.org@nazunalikaSokel/label/Sombra
+
+
+
Last update: - April 11, 2023 + April 13, 2023 diff --git a/sop/idm_sop_mm_ras/index.html b/sop/idm_sop_mm_ras/index.html index c5f2634..72bac0f 100644 --- a/sop/idm_sop_mm_ras/index.html +++ b/sop/idm_sop_mm_ras/index.html @@ -579,13 +579,81 @@

Syncing in Mattermost

Within mattermost's administration console, apply the group to the channel as necessary.

+

Resources

+ +
+
+
+

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

+
+
+

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

+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
NameEmailMattermost NameIRC Name
Neil Hanlonneil@resf.org@neilneil
Taylor Goodwilltg@resf.org@tgotg
Louis Abellabel@rockylinux.org@nazunalikaSokel/label/Sombra
+
+
+
Last update: - April 11, 2023 + April 13, 2023 diff --git a/sop/index.html b/sop/index.html index 9095001..8714907 100644 --- a/sop/index.html +++ b/sop/index.html @@ -474,81 +474,13 @@

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

- -
-
-
-

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

-
-
-

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

-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NameEmailMattermost NameIRC Name
Neil Hanlonneil@resf.org@neilneil
Taylor Goodwilltg@resf.org@tgotg
Louis Abellabel@rockylinux.org@nazunalikaSokel/label/Sombra
-
-
-
Last update: - April 11, 2023 + April 13, 2023