Fedora - Home Server (Application Dashboard)

Our home server can host a couple of applications now. But, remembering the different addresses, ports, and services seems somewhat wrong. In this article, we will solve this situation by deploying a dashboard, that provides links to all our applications.

Fedora - Home Server (Application Dashboard)
Screenshot - Homer Dashboard

Our home server can host a couple of applications now. But, remembering the different addresses, ports, and services seems somewhat wrong. In this article, we will solve this situation by deploying a dashboard, that provides links to all our applications.

For this tutorial, I will use the Homer dashboard, but will link some alternatives at the end.

Intro

This series is explaining how we are setting up a home server from scratch. You can find links to the previous articles below.

  1. Intro & Concept
  2. Hardware & OS
  3. Automation
  4. Management
  5. Virtualization
  6. Container
  7. Time, DHCP, DNS Server
  8. Git Server
  9. File, Calendar, Contact Sync
  10. Application Dashboard

This time, we will automate the last deployment, an application dashboard. This way, we don't need to remember all the deployments.

Homer Dashboard

Homer is a pretty simple dashboard application. It is developed in JavaScript, and it is Open Source. It can provide bookmarks with customizable icons and descriptions. Furthermore, it is configured in YAML, which makes it super easy to adjust.

Screenshot - Homer Dashboard

There are also some more powerful features, that are meant to integrate status notifications and additional information or messages. For now, we will not use this. Please feel free to play around with it afterward.

For our home server, we will use the dashboard to display our applications from the previous articles of this series.

Homer with Ansible and Podman

In the last articles about Gitea and Nextcloud, we build the playbooks, including the tasks and templates, on our own. This time, I want to show you something else.

As you may be aware, I have started an Ansible collection that holds a couple of roles for container deployments. Recently, I added the Homer role to it.

GitHub - whiletruedoio/whiletruedoio.container: Ansible collection to provide container setups and prepared container deployments.
Ansible collection to provide container setups and prepared container deployments. - GitHub - whiletruedoio/whiletruedoio.container: Ansible collection to provide container setups and prepared cont...

The collection is still under heavy development, and not published to Ansible Galaxy. But, we can use the content anyway.

Let's use some code from there, shall we?

The code

The first thing, we should ensure, that the desired collection is installed. Therefore, we need to adjust the requirements.yml.

---
# ansible/requirements.yml

collections:

  - name: "ansible.posix"
  - name: "community.general"
  - name: "community.libvirt"
  - name: "containers.podman"
  - name: "https://github.com/whiletruedoio/whiletruedoio.container.git"
    type: "git"
...
ansible/requirements.yml

As you can see, we can install Ansible collections directly from a Git repository. Since this will pull in the latest commit on the main branch, we might limit it to desired tags or commits.

---
# ansible/requirements.yml

collections:

  - name: "ansible.posix"
  - name: "community.general"
  - name: "community.libvirt"
  - name: "containers.podman"
  - name: "https://github.com/whiletruedoio/whiletruedoio.container.git"
    type: "git"
    version: "a5926340b467ecd8f5c172c448bb198fb7c618db"
...

The next part is our playbook. The collection has an Ansible playbook included, but let's create our own. This way, everything will work the same way as the other deployments.

Just create a new YAML file and use the role of the collection. This is done by referencing the fully-qualified role name, similar to modules from a collection.

---
# ansible/playbooks/deploy_homer_container.yml

- name: "Deploy homer Container"
  hosts: "all"

  tasks:

    - name: "Import homer Role"
      ansible.builtin.import_role:
        name: "whiletruedoio.container.homer"
...
ansible/playbooks/deploy_homer_container.yml

This will deploy a pretty standard dashboard without our custom links. That's not exactly what we want.

Fortunately, we can provide our own configuration file. Let's create this one. In case you want to adjust everything to your linking, please have a look at the Homer documentation.

For now, the below example will take care of our already existing deployments.

---
# ansible/playbooks/templates/homer_config.yml.j2

title: "Home Server"
subtitle: "My Fedora homeserver"
icon: "fas fa-home-heart"

header: true

defaults:
  layout: "list"
  colorTheme: "auto"

theme: "default"

links:
  - name: "Blog"
    icon: "fas fa-newspaper"
    url: "https://while-true-do.io"
    target: "_blank"
  - name: "Code"
    icon: "fab fa-github"
    url: "https://github.com/dschier-wtd/fedora-homeserver/"
    target: "_blank"

services:
  - name: "Applications"
    icon: "fas fa-cloud"
    items:
      - name: "Nextcloud"
        icon: "fas fa-cloud"
        subtitle: "Sync files, calendar, contacts and more"
        keywords: "files calendar contacts tasks"
        url: "http://{{ ansible_default_ipv4.address }}:8080"
        target: "_blank"
      - name: "Gitea"
        icon: "fas fa-code"
        subtitle: "Platform for projects, code and issues"
        keywords: "code issues projects"
        url: "http://{{ ansible_default_ipv4.address }}:3000"
        target: "_blank"
      - name: "PiHole"
        icon: "fas fa-network-wired"
        subtitle: "Ad Block and DNS"
        keywords: "adds dns filter"
        url: "http://{{ ansible_default_ipv4.address }}"
        target: "_blank"

  - name: "Admin"
    icon: "fas fa-cloud"
    items:
      - name: "Cockpit"
        icon: "fas fa-tachometer-alt"
        subtitle: "Administer the home server"
        keywords: "linux podman updates"
        url: "https://{{ ansible_default_ipv4.address }}:9090"
        target: "_blank"
...
ansible/playbooks/templates/homer_config.yml.j2

In addition, we need to edit the playbook for two more things. First, we need to let Ansible know, that we want to have a different configuration file, and we also need to adjust the default port for homer, since it is conflicting with our Nextcloud deployment.

---
# ansible/playbooks/deploy_homer_container.yml

- name: "Deploy homer Container"
  hosts: "all"

  tasks:

    - name: "Import homer Role"
      ansible.builtin.import_role:
        name: "whiletruedoio.container.homer"
      vars:
        homer_config_src: "templates/homer_config.yml.j2"
        homer_publish_http: "5000"
...
ansible/playbooks/deploy_homer_container.yml

For your convenience, I have added the complete code in the repository, too.

GitHub - dschier-wtd/fedora-homeserver: Kickstart and Ansible setup of my homeserver.
Kickstart and Ansible setup of my homeserver. Contribute to dschier-wtd/fedora-homeserver development by creating an account on GitHub.

The deployment

The deployment is straight forward. First, we need to install the dependencies from the above requirements.yml file.

# Install dependency collections
$ ansible-galaxy collection install -r ansible/requirements.yml

Afterward, we can run the playbook to get Homer installed.

# Install Homer container
ansible-playbook -i IP_ADDRESS, -u USER -k -K ansible/playbooks/deploy_homer_container.yml

That's already it. Just point your browser to http://IP_ADDRESS:5000, and you will be greeted with our brand-new dashboard.

Screenshot - Homer dashboard

In case you want to add, remove or change a button, you just need to adapt the config file and re-run the playbook. That's already it.

Further improvements

In case, you want to improve this setup even more, I would suggest the following things:

  • change the default HTTP port of the Pi-hole deployment to a different port
  • change the homer default HTTP port to port 80
  • adapt the Homer configuration accordingly

This way, the dashboard will be the default gateway to your home server, and you don't need to remember a single port.

Alternatives

In this article, I have chosen Homer. For me, it is looking okay, feels simple enough and is easy to configure. But, there is a vast amount of alternatives available. If you are looking for a different behavior, more features or just something else, let me suggest some tools to look into.

Dashy

Dashy has a much more "folder'ish" look to it. For me, it looks a bit too technical. It features on-demand themes, layouts and is configurable via YAML, too.

Screenshot - Dashy

Heimdall

Heimdall is maybe the most well-known application dashboard for home servers. In addition to a simple dashboard functionality, it provides enhanced application integration. Meaning, you can add information like your Pi-hole status to the bookmarks.

The configuration is done on the page itself interactively.

Heimdall - Demo Video

Dashboard

Dashboard is another application dashboard. The name might be a bit boring, and this also accounts for their design philosophy. It is simple, yet very pleasing. If you are looking for a super sleek, JSON configured dashboard, this might be for you.

Screenshot - Dashboard (from GitHub)

More

The "awesome-selfhosted" list might be an inspiration for you. It is a collection for many self-hosted services, and you can find a couple of dashboards there, too.

GitHub - awesome-selfhosted/awesome-selfhosted: A list of Free Software network services and web applications which can be hosted on your own servers
A list of Free Software network services and web applications which can be hosted on your own servers - GitHub - awesome-selfhosted/awesome-selfhosted: A list of Free Software network services and ...

Conclusion

This already wraps it up. Our container deployments to make the home server useful are done. I would like to know if you are using this home server and how the articles helped or inspired you.

If you find another application, that should be tackled, I would like to hear from you. I might not put it into this series, but there is a couple of room for more articles about Ansible and Podman. ;)

Update

There is something I want to address here. I removed the "Kubernetes testing ground" from the list. This is mostly related to recent updates in Fedora, which make it hard to run k3s directly on our home server. It is still possible to run Kubernetes in a VM, and I will tackle this in one of the next articles. But it does not really fit into the series anymore.

Therefore, this is the last article for this series. I really hope you enjoyed it and got some inspiration for your home lab. Please let me know what you are doing and how it is working for you.