Infrastructure Apprentice

The 'fi-apprentice' group in the Fedora Account System is one with a lot of read-only access to various Fedora infrastructure machines. This group is used for new folks to look around at the infrastructure setup, check machines and processes and see where they might like to contribute moving forward. This also allows apprentices to examine and gather info on problems, then propose solutions.

Access to many infrastructure machines

Members of the fi-apprentice group have ssh/shell access to many machines, but no sudo rights or ability to commit to ansible (but they do have read-only access). Apprentice can, however, contribute to the infrastructure documentation by sending pull requests to the infra-docs-fpo repository. Access is via the machine and from there to each machine. See the SSH Access Infrastructure SOP for more info. You can see a list of hosts that allow apprentice access by using: ./scripts/hosts_with_var_set -i inventory/ -o ipa_client_shell_groups=fi-apprentice from an ansible repo checkout (see below).

Nagios alerts

This group does NOT get Nagios alerts. If you would like to see them you can join the #fedora-noc channel, adjust your FMN notifications settings or watch the Nagios web interface at: and

Nagios access is now controlled by kerberos, so you will need to do a command with “kinit your_fas_name@@FEDORAPROJECT.ORG”. On the use of the kerberos, you can view the page

Length of membership

Members who have not logged into any machine and/or are not active will be removed. There’s nothing personal in this, and you’re welcome to re-join later when you have more time, we just want to make sure the group only has active members.

Longer term quests

There’s a few items we need help with ongoing and apprentices are encouraged to work on these items and provide patches and ask questions, etc. The current list:

  • Update group variables in ansible for CSI standards for machines that don’t have any listed. See: for information on CSI, and look at the ansible repo under inventory/group_vars/ for groups without CSI information. Patches adding this information for groups can be sent to the infrastructure list to be reviewed and applied. Please refer to standards for documenting CSI variables before submitting patches for ansible.

  • Our docs aren’t all using the same template. See the repo and propose patches to update documents to use the same templates as the rest.

  • Look over our logs on in /var/log/merged/ and track down issues and propose solutions to them. Be sure to discuss in meeting or in a issue whatever you find.

easyfix tickets

There are tickets marked with the 'easyfix' keyword that may be suitable for apprentices to learn how things are setup, and also contribute a fix. See the easyfix report

Working on a ticket workflow

  • Pick a ticket

Look in for a ticket that looks interesting to you. If the ticket is already assigned, but hasn’t had any action in a while, feel free to ask on the ticket if it’s still being worked on, and if there is no reply in a week or so, take it over. Some tickets can be worked on by several people, so feel free to ask in ticket if this is one of those kinds of tasks and what part you can work on. If a ticket seems really old and like it may no longer be needed, please add it to the agenda of the next meeting and we will discuss it there and close it or rework it as needed. You can add to the next meeting agenda in Gobby.

  • Make patch for fix from git ansible repo

Most any task will require changes to ansible. You can check this out on (just "git clone /git/ansible" there) and make edits to your local copy. Then you can create a PR with your changes into

Matrix Tips

The primary way the infrastructure team communicates is Matrix. Here’s a few tips to best communicate with the rest of the team:

  • Feel free to ask questions when you think of them/run into them, but don’t expect everyone to drop what they are doing and answer right then. Please be patient.

  • Try to avoid private messages to specific team members. Instead ask your questions in Fedora Infrastructure Team" and "Fedora Network Operation Center" on Matrix if at all possible. This allows anyone to help you out and also other folks to see the answer and peer review the answers you get.

  • Try and assume best intentions on past decisions. There is often a reason for something being setup the way it is or there’s some history behind it. "Have we considered switching from foo to bar?" is great, "Why are you using foo! bar is better, we should switch to it right now" is not.

  • Keep in mind many of the infrastructure folks are busy, so do try and avoid 'pinging' them unless there’s a specific need or you know they are active in channel. Many people have a matrix 'trigger' that notifies them when someone mentions their nick.

  • Being active in Matrix and asking questions is a great way to find out how things are setup and gain more trust.

  • Watching discussion in Matrix can often lead to some topic or area you might be interested in helping out with. If so, please feel free to chime in in channel that you would be interested in helping out and ask how you could do so.

Further information

For further information on this group, please ask in fedora-admin on, the Fedora Infrastructure Matrix room and/or the fedora infrastructure mailing list.

Ansible documentation is available at