Page Comparison

...

• If you are not a member of ESCP, document what you’re doing however you document things.

  • If you are a member of ESCP, document in the node.yaml file:

    Code Block
    # See https://tuftswork.atlassian.net/wiki/spaces/ESPTS/pages/499220519/Making+a+private+Github+Runner # Git Runner installed as user 'foobaruser' connected to repo [URL of github repo] # Note: This runner will die after the OS is EOL. For RHEL 8 this is May 31, 2029 # Note: This runner will die after the OS is EOL. For RHEL 9 this is May 31, 2032

• In your web browser, browse to your repository.

• Go to Settings > Actions > Runners > New Self-Hosted Runner.

• It will give you a series of commands to paste into the terminal. Instead of pasting them into the terminal, do this:

  • Find the line that says "./config.sh --url=..."

  • Get the URL and the token.

  • Read the URL to ensure it's a specific repository, not the organization or whatever.

  • Run this script as root. The script installs the runner, creates the service, and launches the service as the service account. It records the URL of which repository it's working for, in the service account's home directory under "actions-runner-url.txt":

    Code Block
    # Optionally, if you need your runner to have any custom label, you may specify --labels= /root/bin/create-gitrunner.sh username GithubRepositoryURL token [--labels=foobarlabel]

• Browse back to Actions > Runners, and confirm the new runner appears there, with a green Status, and Idle.

GHA Runner service and systemd+selinux

The OOTB experience when installing the runner in a separate user’s home directory is that the runner will not operate correctly on any system with selinux enabled, such as onprem RHEL9 builds.

For generic notes on selinux, see: SELinux

While the runner installer does attempt to set things properly:

Creating launch runner in /etc/systemd/system/actions.runner.Tufts-Technology-Services-runner-name.service
Run as user: username
Run as uid: nnn
gid: nnn
Relabeled /etc/systemd/system/actions.runner.Tufts-Technology-Services-runner-name.service from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:systemd_unit_file_t:s0
Created symlink /etc/systemd/system/multi-user.target.wants/actions.runner.Tufts-Technology-Services-runner-name.service → /etc/systemd/system/actions.runner.Tufts-Technology-Services-runner-name.service.
Finished. Service is running.

this only changes the context of the service itself. The service will try to run a shell script inside the user directory and this will fail:

# example outputs from systemctl/journalctl
date hostname systemd[1092642]: actions.runner.Tufts-Technology-Services-runner-name.service: Failed at step EXEC spawning /home/username/actions-runner/runsvc.sh: P>
date hostname systemd[1]: actions.runner.Tufts-Technology-Services-runner-name.service: Main process exited, code=exited, status=203/EXEC

# error if you look at selinux messages
type=AVC msg=audit(1724335071.274:92964): avc:  denied  { execute } for  pid=242535 comm="(unsvc.sh)" name="runsvc.sh" dev="dm-5" ino=407846 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclas
s=file permissive=0

The fix is to update the selinux context:

# note that this change is not persistent across relabels
chcon -R -t bin_t /home/username/actions-runner

# this change preserves the context
semanage fcontext -a -t bin_t "/home/username/actions-runner(/.*)"

Note that you could probably skip the chron command, run the 
semanage command, and then use restorecon to reapply the new changes.

Removing a private runner

...