{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Infrastructure Wiki","text":""},{"location":"#about","title":"About","text":"<p>The Rocky Linux Infrastructure Team dedicates themselves to the management of the infrastructure in the Rocky Enterprise Software Foundation. This group maintains the stability of all components of infrastructure, ensuring the foundation of Rocky Linux and its Special Interest Groups, as well as other projects of the foundation, have a stable platform to use and build upon.</p> <p>Some of the goals of this team are:</p> <ul> <li>To ensure the Rocky Linux build system is operating in a complete and functional manner</li> <li>To ensure the Rocky Linux mirror services are running optimally</li> <li>To ensure Identity Management services are working for applicable applications in the foundation</li> <li>To ensure all Git-related services work optimally</li> <li>To ensure the security and integrity of the overall infrastructure</li> </ul> <p>See the What We Do page for more information on our activities.</p>"},{"location":"#getting-in-touch-contributing","title":"Getting In Touch / Contributing","text":"<p>There are a few ways to get in touch with the Infrastructure Team to ask questions, provide help, assistance, or even ideas that can benefit us.</p> <p>See something in our Git that could use some improvements? Perhaps you have a question on how they work. Please reach out!</p> <ul> <li> <p>Chat</p> <ul> <li>Mattermost: ~infrastructure</li> <li>IRC: #rockylinux and #rockylinux-infra on libera.chat</li> </ul> </li> <li> <p>RESF SIG/Core Issue Tracker</p> </li> <li>Mail List</li> </ul> <p>For a list of our members, see the Members page.</p>"},{"location":"#rocky-related-resources","title":"Rocky-related Resources","text":"<ul> <li>RESF Git Service</li> <li>Rocky Linux GitHub</li> <li>Rocky Linux GitLab</li> <li>Rocky Linux Wiki Section</li> <li>Special Interest Groups.</li> </ul>"},{"location":"#members","title":"Members","text":"<p>For a list of our members, see the Members page.</p>"},{"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 &amp; Release Engineering Louis Abel label@rockylinux.org @nazunalika Sokel/label/Sombra Infrastructure Randolph @meltro N/A Infrastructure Patrick Roberts @preachermanx N/A"},{"location":"what_we_do/","title":"What We Do","text":"<p>Infrastructure was the first team created as part of the Rocky Linux project. As a result, the work that is done benefits not just Rocky Linux, but also the RESF in general. The team consistes of dedicated volunteers and professionals that manage the servers, utilities, and applications that benefit the projects, the RESF community, and the users of Rocky Linux.</p> <p>Some of the things we do in pursuit of our mission:</p> <ul> <li>Deploys and maintains various services for the Rocky Linux project and RESF</li> <li>Ensures systems are hardened in a way that it does not disrupt the build system and services</li> <li>Ensures Identity Management systems are functioning as intended</li> <li>Ensures all Git-related services work optimally as to not disrupt users in and outside of the project and foundation</li> <li>Design, architecture, and development work to integrate Infrastructure components together</li> <li>Maintenance of the infrastructure used to build and maintain Rocky Linux (such as ansible roles and playbooks)</li> <li>Providing resources for Special Interest Groups</li> <li>Providing assistance and resources for users within the community to meet their goals where possible</li> </ul>"},{"location":"documentation/","title":"Documentation","text":"<p>This section goes over various Documentation for the Infrastructure team. Please use the menu items to find the various pages of interest.</p>"},{"location":"documentation/dns/","title":"DNS Zone Standards","text":"<p>Internal DNS zones are, for the most part, simply structured. Majority of systems won't be at the root of the IPA domain (in this case, rockylinux.org). Instead, subdomains are used based on environment (e.g. datacenter) as a starting point, with an additional subdomain that notes the \"type\" of systems or endpoints.</p> <pre><code>{LOCATION}-{ENV}-{NAME}{INCREMENT}.{TYPE}.{DC}.rockylinux.org\n^           ^     ^     ^           ^      ^\n|           |     |     |           |      |---Data Center\n|           |     |     |           |--Node type (like idm, svc)\n|           |     |     |--Node Number\n|           |     |--Node Name\n|           |--prod,dev\n|---Location code\n</code></pre>"},{"location":"documentation/idm/","title":"Identity Management","text":"<p>This section goes over various parts of Identity Management within the Rocky Linux/RESF infrastructure.</p> <p>See the left side to find pages of interest.</p>"},{"location":"guidelines/","title":"Guidelines","text":"<p>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.</p> <p>All guidelines are listed on the left side of this page.</p>"},{"location":"guidelines/awx_scm_guidelines/","title":"AWX / Ansible SCM Guidelines","text":"<p>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.</p> <p>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.</p>"},{"location":"guidelines/awx_scm_guidelines/#contact-information","title":"Contact Information","text":"Owner Infrastructure Team Email Contact infrastructure@rockylinux.org Mattermost Contacts <code>@label</code> Mattermost Contacts <code>@neil</code> Mattermost Contacts <code>@tgo</code> Mattermost Channels <code>~Infrastructure</code>"},{"location":"guidelines/awx_scm_guidelines/#guidelines","title":"Guidelines","text":"<p>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 <code>infrastructure/ansible-awx-template</code> and using that as the starting point, the next few sections will explain the basic structure and basic design principals.</p> <p>You should begin by starting from the Infrastructure Ansible AWX Template.</p>"},{"location":"guidelines/awx_scm_guidelines/#root-structure","title":"Root Structure","text":"<p>The general structure will always start from this:</p> <pre><code>.\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</code></pre> <p>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:</p> <ul> <li>All playbooks should be in the root and import tasks from <code>./tasks</code> if needed</li> <li>Vars should be clearly defined where needed in vars, defaults, and/or playbooks</li> <li>Files and templates should be created with a purpose</li> <li>Handlers should be clearly defined and used</li> <li>There should be wiggle room to add callback_plugins, filter_plugins, libraries</li> </ul> <p>With these basic ideas in mind, we can move into playbook design.</p>"},{"location":"guidelines/awx_scm_guidelines/#designing-playbooks","title":"Designing Playbooks","text":"<p>Generally, your playbooks should be doing the following:</p> <ol> <li>Checking if ansible can be ran on a specific host</li> <li>Asserting if variables are filled and are correctly formed, if applicable</li> <li>Importing tasks from the <code>./tasks</code> directory</li> <li>Importing roles, if necessary</li> <li>Post tasks, if necessary</li> </ol> <p>At no point should you be using <code>./tasks/main.yml</code> under any circumstance.</p>"},{"location":"guidelines/awx_scm_guidelines/#pre-flight-and-post-flight-tasks","title":"Pre-flight and Post-flight Tasks","text":"<p>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.</p> <pre><code>  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</code></pre>"},{"location":"guidelines/awx_scm_guidelines/#tasks-general-information","title":"Tasks General Information","text":"<p>Ensure that your tasks are using FQCN. This means, even for the simple modules such as <code>file</code>, you should be using <code>ansible.builtin.file</code> to be compliant with ansible-lint 6+ and ansible 2.12+.</p>"},{"location":"guidelines/awx_scm_guidelines/#comments","title":"Comments","text":"<p>Each playbook should have comments or a name descriptor that explains what the playbook does or how it is used. If not available, <code>README-...</code> 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.</p>"},{"location":"guidelines/awx_scm_guidelines/#tags","title":"Tags","text":"<p>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.</p>"},{"location":"guidelines/awx_scm_guidelines/#playbook-naming-system","title":"Playbook Naming System","text":"<p>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.</p> <pre><code>init-* -&gt; 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  -&gt; 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 -&gt; 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-* -&gt; These playbooks call roles for potential tasks or even roles in general.\n</code></pre> <p>Using the role prefix without an ansible role</p> <p>It is perfectly fine to use <code>role-</code> as a way to say \"this system will do or be X\" without calling out to an ansible role. You may use <code>role</code> for this case or you can use <code>init</code>. This is not a strict requirement and you should go with what feels right for your project.</p>"},{"location":"guidelines/awx_scm_guidelines/#defining-hosts","title":"Defining Hosts","text":"<p>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:</p> <ul> <li>Use group names where necessary</li> <li>Use localhost if you aren't actually doing anything to a system (e.g., you're calling an API) and you don't have to connect to a system to use said API</li> <li> <p>When filling in the <code>hosts</code> directive, follow these general guidelines:</p> <ul> <li>If it applies to all hosts in an inventory, use <code>all</code></li> <li>If you want the host or a group of hosts to be selectable (via dropdown or manual input), set <code>host: {{ host }}</code> and the host var can be defined as an extra var</li> <li>If the above two are not applicable and you must set a hostname, you may do so. Note that this will require you to be more vigilant in keeping your repository up to date.</li> </ul> </li> </ul>"},{"location":"guidelines/awx_scm_guidelines/#local-inventory-files","title":"Local Inventory Files","text":"<p>Generally local inventory files are not recommended. Some general rules to follow is this:</p> <ul> <li>If your project can be ran in AWX and locally outside of AWX, the inventory file should not be committed as <code>inventory</code> (the current <code>.gitignore</code> prevents this from being committed by default)</li> <li>If your project is local only (meaning it will not be used in AWX, but your team will be using it locally), you may modify <code>.gitignore</code> to include the file</li> </ul> <p>We want to prevent AWX from picking up a random inventory that isn't defined within it.</p>"},{"location":"guidelines/awx_scm_guidelines/#local-ansiblecfg-files","title":"Local ansible.cfg files","text":"<p>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.</p>"},{"location":"guidelines/awx_scm_guidelines/#collections-and-roles","title":"Collections and Roles","text":"<p>Collections and roles should be defined in a <code>requirements.yml</code> 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:</p> <pre><code>ansible-galaxy collection install -r collections/requirements.yml\nansible-galaxy role install -r roles/requirements.yml\n</code></pre> <p>Tools like <code>ansible-navigator</code> and <code>ansible-builder</code> can also help in this area as well.</p>"},{"location":"guidelines/awx_scm_guidelines/#pre-commits-linting","title":"Pre-commits / linting","text":"<p>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.</p> <p>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.</p>"},{"location":"guidelines/awx_scm_guidelines/#tests","title":"Tests","text":"<p>A template generally comes with a <code>tests</code> 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.</p> <p>Complex situations can be tested for as well and is encouraged.</p>"},{"location":"include/resources_bottom/","title":"Resources bottom","text":"Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContacts <p>URL: https://accounts.rockylinux.org</p> <p>Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem</p> <p>Technology: Noggin used by Fedora Infrastructure</p> <p>Contact: <code>~Infrastructure</code> in Mattermost and <code>#rockylinux-infra</code> in Libera IRC</p> <p>URL: https://git.resf.org</p> <p>Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.</p> <p>Technology: Gitea</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://github.com/rocky-linux</p> <p>Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.</p> <p>Technology: GitHub</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://git.rockylinux.org</p> <p>Purpose: Packages and light code for the Rocky Linux distribution</p> <p>Technology: GitLab</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://lists.resf.org</p> <p>Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem</p> <p>Technology: Mailman 3 + Hyper Kitty</p> <p>Contact: <code>~Infrastructure</code> in Mattermost and <code>#rockylinux-infra</code> in Libera IRC</p> 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":"<p>This section goes over the various SOP's for the Infrastructure Team. Please use the menu items to find the various pages of interest.</p>"},{"location":"sop/idm_sop_gdpr/","title":"SOP: Personal Data Request - Deletion","text":"<p>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.</p>"},{"location":"sop/idm_sop_gdpr/#contact-information","title":"Contact Information","text":"Owner Infrastructure Team &amp; Identity Management Team Email Contact infrastructure@rockylinux.org Email Contact identitymanagement@rockylinux.org Mattermost Contacts <code>@label</code> Mattermost Channels <code>~Infrastructure</code>"},{"location":"sop/idm_sop_gdpr/#responding-to-a-deletion-request","title":"Responding to a Deletion Request","text":"<p>This section covers how a system administrator will use our <code>adhoc-ipauser-disable-pdr.yml</code> playbook to respond to a delete request.</p> <p>If a request has been received via email, perform the following steps:</p> <ol> <li> <p>If request was received by email: Open a ticket at the bug tracker under the <code>Account Services</code> product (Click the drop down in the top right corner, click \"Account Services\", select \"Report Issue\")</p> <ul> <li>Set category to <code>Account Requests - Personal Data Request</code></li> <li>Assign to yourself if possible</li> <li>Summary should be set: <code>PDR - Email Delete Request for &lt;USER/EMAIL&gt;</code></li> <li>Description should be set to the snippet <code>PDR Request - Remove Personal Information</code> or copied directly from the email if the template was followed.</li> <li>Use the ID for the ansible playbook</li> </ul> </li> <li> <p>On the ansible host, run the necessary ansible playbook: <code>ansible-playbook -i inventories/production/hosts.ini playbooks/adhoc-ipauser-disable-pdr.yml --extra-vars='ipa_user=&lt;USER&gt; ticket_id=BT&lt;TICKET&gt;'</code></p> </li> <li>Leave a comment on the issue that the disable request was performed.</li> <li>Email the affected user:</li> </ol> <p><pre><code>Hello. We have reviewed your account request and have performed the requested\nchanges. The ticket &lt;ID&gt; 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</code></pre> 4. Set ticket to <code>RESOLVED</code></p> Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContacts <p>URL: https://accounts.rockylinux.org</p> <p>Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem</p> <p>Technology: Noggin used by Fedora Infrastructure</p> <p>Contact: <code>~Infrastructure</code> in Mattermost and <code>#rockylinux-infra</code> in Libera IRC</p> <p>URL: https://git.resf.org</p> <p>Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.</p> <p>Technology: Gitea</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://github.com/rocky-linux</p> <p>Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.</p> <p>Technology: GitHub</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://git.rockylinux.org</p> <p>Purpose: Packages and light code for the Rocky Linux distribution</p> <p>Technology: GitLab</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://lists.resf.org</p> <p>Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem</p> <p>Technology: Mailman 3 + Hyper Kitty</p> <p>Contact: <code>~Infrastructure</code> in Mattermost and <code>#rockylinux-infra</code> in Libera IRC</p> 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":"<p>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.</p> <p>Note: This assumes the user is logging in with their RAS credentials to Mattermost.</p>"},{"location":"sop/idm_sop_mm_ras/#contact-information","title":"Contact Information","text":"Owner Infrastructure Team &amp; Identity Management Team Email Contact infrastructure@rockylinux.org Email Contact identitymanagement@rockylinux.org Mattermost Contacts <code>@label</code> Mattermost Contacts <code>@neil</code> Mattermost Channels <code>~Infrastructure</code>"},{"location":"sop/idm_sop_mm_ras/#creating-the-necessary-group","title":"Creating the necessary group","text":"<p>This section covers how a system administrator will create a group Rocky Account Services using ansible. The playbook utilized will be <code>adhoc-ipagroup.yml</code>.</p> <ol> <li>First, determine where and how the group will be utilized. The starting template will be <code>mm_X_name</code>. <code>mm</code> is for mattermost, <code>X</code> will be for the designated part of Mattermost (e.g., resf, rl, and so on), and <code>name</code> will be the name of the group in question.</li> <li> <p>On the ansible host, run the necessary ansible playbook: <code>ansible-playbook -i inventories/production/hosts.ini ansible-ipa-management/adhoc-ipagroup.yml --extra-vars='ipa_group=&lt;GROUP&gt; ipa_description=\"&lt;DESC&gt;\" ipa_nonposix=false ipa_fas=true ipa_group_manager_user=&lt;OWNER&gt;'</code></p> <ul> <li>Ensure that the description is set in a way that it explains what it is for</li> <li>It is unlikely the group will need to have a GID assigned. Assigning the group as nonposix should be sufficient.</li> <li>Setting the group with <code>ipa_fas=true</code> ensures that the group will appear in Rocky Account Services and can be managed there.</li> <li>Setting <code>ipa_group_manager_user</code> will set a user in RAS that can manage the group without requesting for an administrator to do so.</li> </ul> </li> </ol>"},{"location":"sop/idm_sop_mm_ras/#syncing-in-mattermost","title":"Syncing in Mattermost","text":"<p>Within mattermost's administration console, apply the group to the channel as necessary.</p> Resources Account ServicesGit (RESF Git Service)Git (Rocky Linux GitHub)Git (Rocky Linux GitLab)Mail ListsContacts <p>URL: https://accounts.rockylinux.org</p> <p>Purpose: Account Services maintains the accounts for almost all components of the Rocky ecosystem</p> <p>Technology: Noggin used by Fedora Infrastructure</p> <p>Contact: <code>~Infrastructure</code> in Mattermost and <code>#rockylinux-infra</code> in Libera IRC</p> <p>URL: https://git.resf.org</p> <p>Purpose: General projects, code, and so on for the Rocky Enterprise Software Foundation.</p> <p>Technology: Gitea</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://github.com/rocky-linux</p> <p>Purpose: General purpose code, assets, and so on for Rocky Linux. Some content is mirrored to the RESF Git Service.</p> <p>Technology: GitHub</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://git.rockylinux.org</p> <p>Purpose: Packages and light code for the Rocky Linux distribution</p> <p>Technology: GitLab</p> <p>Contact: <code>~Infrastructure</code>, <code>~Development</code> in Mattermost and <code>#rockylinux-infra</code>, <code>#rockylinux-devel</code> in Libera IRC</p> <p>URL: https://lists.resf.org</p> <p>Purpose: Users can subscribe and interact with various mail lists for the Rocky ecosystem</p> <p>Technology: Mailman 3 + Hyper Kitty</p> <p>Contact: <code>~Infrastructure</code> in Mattermost and <code>#rockylinux-infra</code> in Libera IRC</p> 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"}]}