added package for adapting to remote kitty-based terminal sessions

README.md

@@ -89,7 +89,7 @@ Other common ones, especially for services, are `port` (which can be an integer
 
 ## Essential Usage
 
-Before running any Ansible playbooks in either development or production mode, make sure to specify the username and the home directory path of the user on the system you are currently using in `{ANSIBLE_PROJECT_ROOT}/vars/local_facts.yml`.
+Before running any Ansible [playbooks](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_intro.html) in either development or production mode, make sure to specify the username and the home directory path of the user on the system you are currently using in `{ANSIBLE_PROJECT_ROOT}/vars/local_facts.yml`.
 
 ### Development Mode
 
@@ -184,7 +184,7 @@ ansible-playbook -Kk -i hosts.yml --extra-vars "chosen_host=staging1.test" --ext
 
 As long as you are matching the appropriate set of [playbook variable files](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_variables.html#defining-variables-in-included-files-and-roles) or settings files with the [playbook](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_intro.html) according to its need of those variable definitions/declarations, mostly determined by [the intended targeted hosts' own variables](https://docs.ansible.com/projects/ansible/latest/inventory_guide/intro_inventory.html#host-variables) together with role [handlers](https://docs.ansible.com/projects/ansible/latest/inventory_guide/intro_inventory.html#host-variables), and as long as you have appropriately set up software installations, (see [Software Management](#software-management)) creating new/custom [playbooks](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_intro.html) should be relatively easy.
 
-Depending on what you are trying to do with a new playbook, the best approach may be to just copy/duplicate the extant playbook files and then edit them, as this allows one to mitigate errors as well as have a reliable reference point for changes.
+Depending on what you are trying to do with a new [playbook](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_intro.html), the best approach may be to just copy/duplicate the extant [playbook files](https://docs.ansible.com/projects/ansible/latest/playbook_guide/playbooks_intro.html) and then edit them, as this allows one to mitigate errors as well as have a reliable reference point for changes.
 
 ### CLI Tool
 
@@ -215,14 +215,14 @@ set -euo pipefail
 INVENTORY_HOSTNAMES=(web1 web2)
 FQDN=web.site
 
-./skato-ansible.sh init vps -v 3 -n "${INVENTORY_HOSTNAME[0]}" -d "$FQDN"
+./skato-ansible.sh init vps -v 3 -n "${INVENTORY_HOSTNAMES[0]}" -d "$FQDN"
 ./skato-ansible.sh populate-agent staging
-./skato-ansible.sh bootstrap vps -s 1 -v 3 -n "${INVENTORY_HOSTNAME[0]}" -d "$FQDN"
+./skato-ansible.sh bootstrap vps -s 1 -v 3 -n "${INVENTORY_HOSTNAMES[0]}" -d "$FQDN"
 
-./skato-ansible.sh init homeserver -v 3 -n "${INVENTORY_HOSTNAME[1]}" -d "$FQDN"
+./skato-ansible.sh init homeserver -v 3 -n "${INVENTORY_HOSTNAMES[1]}" -d "$FQDN"
 # BELOW ONLY IF $SKANSIBLE_SSH_KEY ALTERED IN THE SHELL SCRIPT
 # ./skato-ansible.sh populate-agent staging
-./skato-ansible.sh bootstrap vps -s 1 -v 3 -n "${INVENTORY_HOSTNAME[1]}" -d "$FQDN"
+./skato-ansible.sh bootstrap vps -s 1 -v 3 -n "${INVENTORY_HOSTNAMES[1]}" -d "$FQDN"
 ```
 
 > [!IMPORTANT]

host_vars/staging0.test.yml

@@ -195,6 +195,14 @@ pkgs:
         suites: ~
         comps: ~
         handler: default
+      - name: "kitty-terminfo"
+        uri: ~
+        sigkey: ~
+        sources: ~
+        types: ~
+        suites: ~
+        comps: ~
+        handler: default
       - name: "git-doc"
         uri: ~
         sigkey: ~

host_vars/staging1.test.yml

@@ -409,6 +409,14 @@ pkgs:
         suites: ~
         comps: ~
         handler: default
+      - name: minidlna
+        uri: ~
+        sigkey: ~
+        sources: ~
+        types: ~
+        suites: ~
+        comps: ~
+        handler: default
     userspace:
       - name: aria2
         uri: ~