semaphore, or rather ansible is how i manage and automate my local infrastructure. heck even my cloud infrastructure. this service is essentially a nice gui for ansible automation playbooks. it has the option to add inventory files, passwords, ssh keys, and playbooks from github. right now i am using it to enforce patch management. the setup was a bit confusing, but it is worth it after setting it all up.

first things first, i installed this as an lxc container in proxmox. this installed on the debian lxc template. once i installed it, i accessed the web site of the service and setup a user. once logged in, i removed defaults like the semaphore repo, and other items. i wanted a clean interface so that i can add my own inventories and hosts.

i first began by creating my static inventory files, which follow this format:

[servers]
server1.domain.com
server2.domain.com
server3.domain.com

i use “domain.com” as i have my own domain name and i have a dns server managing all of those entries. since i have a reverse proxy, i had to add another section to the fqdn, so it looks like this:
“server1.local.domain.com”

this is because the “main” subdomain for a web server like jellyfin.domain.com is pointed to my reverse proxy ip address. by adding a “.local” to the fqdn, i can simply create a secondary dns record that points to the ip address of the actual server. this increases complexity for management and number of dns records, but it has to be done “for the sake of security”.

if you do not have a domain name, that is fine, if you have decent ip address management, you can jot those down. otherwise you can find the ip address’ of your servers from your router.

adding credentials is fairly simple as well. this is done through the key store tab. this has options of ssh keys and passwords. i recommend you use a standard linux user and add that user to sudoers group. that way you are not using root user for ssh access. in a secure infrastructure, please use ssh key based authentication. as this is just a home lab, i stick with ssh passwords, which is fine since i make them complex, but for best practice, use ssh keys. essentially, you just add the user and the password with the login type.

if you are using user with sudo do this:

create the user and the password.

create a second key store that is named “user – sudo”, and create the user with no username, and the same user password.

if you are using ssh keys do this:

create the user and paste in the private key.

so this process is very easy, and now you can create your playbooks. semaphore has the option to pull the yaml files from your github repo, whether it is private or public. you can do this in the repositories tab and paste in the repo from github. it should look like this:

“https://github.com/username/semaphore.git”

this will pop up in your repo if it is public. if it is not you have to go through the steps of getting a key for your private repo.

but this is just pulling the repo, there is no actual playbooks. to do this, you have to obviously add the yaml files into the main branch of the repo. the file extension can either be “.yaml” or “.yml”.

here a link to the yaml syntax from ansible.

anyways, after reading that, you can create your playbooks. here are some playbooks that i have created that i use right now. these are mainly for patch management for debian servers.

—
– name: Update Debian Servers
hosts: servers
gather_facts: yes
become: yes
tasks:
– name: Update package list
apt:
update_cache: yes
– name: Upgrade all packages
apt:
ugprade: full
– name: Remove dependencies that are no longer required
apt:
autoremove: yes

this is a simple automation playbook that will:

run ssh on the host(s) defined

gather facts from the server(s)

elevate privilege rights (sudo)

run the task to update cache (apt update)

run the task to upgrade packages (apt upgrade)

run the task to remove dependencies (apt autoremove)

there is more to this playbook between upgrade and autoremove and that is the option to restart the server when it is an option by looking at the reboot-required file. i have it in my original playbook, but it is commented out as i do not want my servers restarting if they can restart after upgrades.

which brings us to the schedule section. you can set schedules for when you want the playbooks to run, this is done through cron jobs. very easy to setup, just name the schedule and select the template playbook. from there you can configure it to run whenever you want. for me i do weekly upgrades on sunday night. do whatever you think meets your requirements for proper patch management.

i do plan to create another playbook dedicated to the server restarts, so that my servers can auto restart by scanning that file. keep in mind that this is for debian, as it might be different for other distros. i will keep it in the back burner for now, but possible server restarts every quarter at the beginning of the month.