Compare commits
31 Commits
052de21dd0
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
| de4757b0c7 | |||
| 9e566f4c86 | |||
| 0b4e6ced95 | |||
| d71189db1f | |||
| ca9606ea23 | |||
| bf464c1f34 | |||
| 51cdd1fdb6 | |||
| 554c04aa32 | |||
| 52e6f83418 | |||
| 39ffb700f0 | |||
| 3fdbfbd3c3 | |||
| 8b56b6bb71 | |||
| 91875cd475 | |||
| af8ec84ece | |||
| 417321150b | |||
| 54b41b1fdf | |||
| 7342cb64bc | |||
| daf24d7480 | |||
| 2b82ef254d | |||
| f85e77dcba | |||
| 328ccc1d09 | |||
| ed88b2d0f9 | |||
| 0f0036809a | |||
| 1e374ec423 | |||
| 6a1de1a436 | |||
| b0a094e6fa | |||
| e6e8f489ae | |||
| d682e0b54f | |||
| 6921fd4b3f | |||
| 1f5b2c89e0 | |||
| fb67ebe7f5 |
37
.gitea/workflows/automatic-deployment.yml
Normal file
37
.gitea/workflows/automatic-deployment.yml
Normal file
@@ -0,0 +1,37 @@
|
||||
name: Automatic Documentation Deployment
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ main ]
|
||||
|
||||
jobs:
|
||||
zensical_deploy:
|
||||
name: Sync Docs to https://kb.bunny-lab.io
|
||||
runs-on: zensical-host
|
||||
|
||||
steps:
|
||||
- name: Checkout Repository
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- name: Stop Zensical Service
|
||||
run: sudo /usr/bin/systemctl stop zensical-watchdog.service
|
||||
|
||||
- name: Sync repository into /srv/zensical/docs
|
||||
run: |
|
||||
rsync -rlD --delete \
|
||||
--exclude='.git/' \
|
||||
--exclude='.gitea/' \
|
||||
--exclude='assets/' \
|
||||
--exclude='schema/' \
|
||||
--exclude='stylesheets/' \
|
||||
--exclude='schema.json' \
|
||||
--chmod=D2775,F664 \
|
||||
. /srv/zensical/docs/
|
||||
|
||||
- name: Start Zensical Service
|
||||
run: sudo /usr/bin/systemctl start zensical-watchdog.service
|
||||
|
||||
- name: Notify via NTFY
|
||||
if: always()
|
||||
run: |
|
||||
curl -d "https://kb.bunny-lab.io - Zensical job status: ${{ job.status }}" https://ntfy.bunny-lab.io/gitea-runners
|
||||
@@ -1,65 +0,0 @@
|
||||
name: GitOps Automatic Documentation Deployment
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [ main ]
|
||||
|
||||
jobs:
|
||||
mkdocs_deploy:
|
||||
name: Sync Docs to https://docs.bunny-lab.io
|
||||
runs-on: gitea-runner-mkdocs
|
||||
|
||||
steps:
|
||||
- name: Install Node.js, git, rsync, and curl
|
||||
run: |
|
||||
apk add --no-cache nodejs npm git rsync curl
|
||||
|
||||
- name: Checkout Repository
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- name: Copy Repository Data to Production Server
|
||||
run: |
|
||||
rsync -a --delete \
|
||||
--exclude='.git/' \
|
||||
--exclude='.gitea/' \
|
||||
--exclude='assets/' \
|
||||
--exclude='schema/' \
|
||||
--exclude='stylesheets/' \
|
||||
--exclude='schema.json' \
|
||||
. /Gitops_Destination/
|
||||
|
||||
- name: Trigger Material MKDocs Container Re-Deployment
|
||||
run: |
|
||||
curl --fail --show-error --silent --insecure \
|
||||
-X POST \
|
||||
"https://192.168.3.48:9443/api/stacks/webhooks/c891d2b5-7eca-42ef-8c3f-896bffbae803"
|
||||
|
||||
- name: Notify via NTFY
|
||||
if: always()
|
||||
run: |
|
||||
curl -d "https://docs.bunny-lab.io - MKDocs job status: ${{ job.status }}" https://ntfy.bunny-lab.io/gitea-runners
|
||||
|
||||
zensical_deploy:
|
||||
name: Sync Docs to https://kb.bunny-lab.io
|
||||
runs-on: zensical-host
|
||||
|
||||
steps:
|
||||
- name: Checkout Repository
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- name: Sync repository into /srv/zensical/docs
|
||||
run: |
|
||||
rsync -rlD --delete \
|
||||
--exclude='.git/' \
|
||||
--exclude='.gitea/' \
|
||||
--exclude='assets/' \
|
||||
--exclude='schema/' \
|
||||
--exclude='stylesheets/' \
|
||||
--exclude='schema.json' \
|
||||
--chmod=D2775,F664 \
|
||||
. /srv/zensical/docs/
|
||||
|
||||
- name: Notify via NTFY
|
||||
if: always()
|
||||
run: |
|
||||
curl -d "https://kb.bunny-lab.io - Zensical job status: ${{ job.status }}" https://ntfy.bunny-lab.io/gitea-runners
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Blog
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Blog
|
||||
## Purpose
|
||||
Narrative posts for lessons learned, experiments, and updates.
|
||||
|
||||
@@ -7,10 +7,11 @@ authors:
|
||||
categories:
|
||||
- General
|
||||
tags:
|
||||
- Windows Server
|
||||
- Power Profiles
|
||||
- Virtualization
|
||||
- Blog
|
||||
- Hyper-V
|
||||
- Veeam
|
||||
- Windows
|
||||
- Backup
|
||||
---
|
||||
|
||||
# Windows Power Profiles Causing Notable CPU Performance Loss
|
||||
@@ -7,15 +7,15 @@ authors:
|
||||
categories:
|
||||
- General
|
||||
tags:
|
||||
- Infrastructure as Code
|
||||
- Gitea Act Runners
|
||||
- Blog
|
||||
- Containers
|
||||
- Docker
|
||||
- GitOps
|
||||
- CI/CD
|
||||
- Portainer
|
||||
- Ansible
|
||||
---
|
||||
|
||||
# Learning to Leverage Gitea Runners
|
||||
When I first started my journey with a GitOps mentality to transition a portion of my homelab's infrastructure to an "**Intrastructure-as-Code**" structure, I had made my own self-made Docker container that I called the [Git-Repo-Updater](../../platforms/containerization/docker/custom-containers/git-repo-updater.md). This self-made tool was useful to me because it copied the contents of Gitea repositories into bind-mounted container folders on my Portainer servers. This allowed me to set up configurations for Homepage-Docker, Material MkDocs, Traefik Reverse Proxy, and others to pull configuration changes from Gitea directly into the production servers, causing them to hot-load the changes instantly. (within 10 seconds, give or take).
|
||||
When I first started my journey with a GitOps mentality to transition a portion of my homelab's infrastructure to an "**Intrastructure-as-Code**" structure, I had made my own self-made Docker container that I called the [Git-Repo-Updater](../../deployments/platforms/containerization/docker/custom-containers/git-repo-updater.md). This self-made tool was useful to me because it copied the contents of Gitea repositories into bind-mounted container folders on my Portainer servers. This allowed me to set up configurations for Homepage-Docker, Material MkDocs, Traefik Reverse Proxy, and others to pull configuration changes from Gitea directly into the production servers, causing them to hot-load the changes instantly. (within 10 seconds, give or take).
|
||||
|
||||
## Criticisms of Git-Repo-Updater
|
||||
When I made the [Git-Repo-Updater docker container stack](https://git.bunny-lab.io/container-registry/git-repo-updater), I ran into the issue of having made something I knew existing solutions existed for but simply did not understand well-enough to use yet. This caused me to basically delegate the GitOps workflow to a bash script with a few environment variables, running inside of an Alpine Linux container. While the container did it's job, it would occassionally have hiccups, caching issues, or repository branch errors that made no sense. This lack of transparency and the need to build an entire VSCode development environment to push new docker package updates to Gitea's [package repository for Git-Repo-Updater](https://git.bunny-lab.io/container-registry/-/packages/container/git-repo-updater/latest) caused a lot of development headaches.
|
||||
@@ -115,3 +115,4 @@ Gitea Act Runners are a beautiful thing, and it's a damn shame it took me this l
|
||||
|
||||

|
||||
|
||||
|
||||
@@ -8,7 +8,9 @@ categories:
|
||||
- General
|
||||
- Documentation
|
||||
tags:
|
||||
- MKDocs
|
||||
- Blog
|
||||
- Rocket.Chat
|
||||
- MkDocs
|
||||
- Material MkDocs
|
||||
- Documentation
|
||||
---
|
||||
@@ -11,7 +11,10 @@ categories:
|
||||
- Virtualization
|
||||
- Containers
|
||||
tags:
|
||||
- Blog
|
||||
- OpenStack
|
||||
- Hyper-V
|
||||
- Containers
|
||||
- Ansible
|
||||
---
|
||||
|
||||
@@ -19,7 +22,7 @@ tags:
|
||||
So, I want to start with a little context. As part of a long-standing project I have been working on, I have tried to deploy OpenStack. OpenStack is sort of envisioned as "Infrastructure as a Service (IAAS)". Basically you deploy an OpenStack cluster, which can run its own KVM for virtual machine and containers, or it can interface with an existing Hypervisor infrastructure, such as Hyper-V. In most cases, people branch out the "Control", "Compute", and "Storage" roles into different physical servers, but in my homelab, I have been attempting to deploy it via a "Converged" model, of having Control, Compute, and Storage on each node, spanning a high-availability cluster of 3 nodes.
|
||||
|
||||
## The Problem
|
||||
The problems come into the overall documentation provided for deploying either [Canonical Openstack](https://ubuntu.com/openstack/install) which I have detailed my frustrations of the system in my own attempted re-write of the documentation [here](../../platforms/virtualization/openstack/canonical-openstack.md). I have also attempted to deploy it via [Ansible OpenStack](https://docs.openstack.org/project-deploy-guide/openstack-ansible/2024.1/), whereas my documentation thus far in my homelab is visible [here](../../platforms/virtualization/openstack/ansible-openstack.md).
|
||||
The problems come into the overall documentation provided for deploying either [Canonical Openstack](https://ubuntu.com/openstack/install) which I have detailed my frustrations of the system in my own attempted re-write of the documentation [here](../../deployments/platforms/virtualization/openstack/canonical-openstack.md). I have also attempted to deploy it via [Ansible OpenStack](https://docs.openstack.org/project-deploy-guide/openstack-ansible/2024.1/), whereas my documentation thus far in my homelab is visible [here](../../deployments/platforms/virtualization/openstack/ansible-openstack.md).
|
||||
|
||||
You see, OpenStack is like icecream, it has many different ways to deploy it, and it can be as simple, or as overtly-complex as you need it to be, and it scales *really well* across a fleet of servers in a datacenter. My problems come in where the Canonical deployment has never worked fully / properly, and their own development team is hesitant to recommend the current documentation, and the Ansible OpenStack deployment process, while relatively simple, requires a base of existing knowledge that makes translating the instructions into more user-friendly instructions in my homelab documentation a difficult task. Eventually I want to automate much of the process as much as I can, but that will take time.
|
||||
|
||||
@@ -27,3 +30,4 @@ The common issue I've seen while trying to deploy OpenStack is understanding the
|
||||
|
||||
I will post an update later if I figure things out!
|
||||
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- AWX
|
||||
- Automation
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Deploying a Rancher RKE2 Cluster-based Ansible AWX Operator server. This can scale to a larger more enterprise environment if needed.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- AWX
|
||||
- Automation
|
||||
---
|
||||
|
||||
# Deploy AWX on Minikube Cluster
|
||||
Minikube Cluster based deployment of Ansible AWX. (Ansible Tower)
|
||||
!!! note Prerequisites
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Ansible
|
||||
- AWX
|
||||
- Automation
|
||||
---
|
||||
|
||||
## Upgrading from 2.10.0 to 2.19.1+
|
||||
There is a known issue with upgrading / install AWX Operator beyond version 2.10.0, because of how the PostgreSQL database upgrades from 13.0 to 15.0, and has changed permissions. The following workflow will help get past that and adjust the permissions in such a way that allows the upgrade to proceed successfully. If this is a clean installation, you can also perform this step if the fresh install of 2.19.1 is not working yet. (It wont work out of the box because of this bug). `The developers of AWX seem to just not care about this issue, and have not implemented an official fix themselves at this time).
|
||||
|
||||
|
Before Width: | Height: | Size: 122 KiB After Width: | Height: | Size: 122 KiB |
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Operations
|
||||
- Automation
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Automation
|
||||
## Purpose
|
||||
Infrastructure automation, orchestration, and workflow tooling.
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Puppet
|
||||
- Automation
|
||||
---
|
||||
|
||||
**Purpose**: Puppet Bolt can be leveraged in an Ansible-esque manner to connect to and enroll devices such as Windows Servers, Linux Servers, and various workstations. To this end, it could be used to run ad-hoc tasks or enroll devices into a centralized Puppet server. (e.g. `LAB-PUPPET-01.bunny-lab.io`)
|
||||
|
||||
!!! note "Assumptions"
|
||||
@@ -176,7 +182,7 @@ klist
|
||||
### Prepare Windows Devices
|
||||
Windows devices need to be prepared ahead-of-time in order for WinRM functionality to work as-expected. I have prepared a powershell script that you can run on each device that needs remote management functionality. You can port this script based on your needs, and deploy it via whatever methods you have available to you. (e.g. Ansible, Group Policies, existing RMM software, manually via remote desktop, etc).
|
||||
|
||||
You can find the [WinRM Enablement Script](../../ansible/enable-winrm-on-windows-devices.md) in the Bunny Lab documentation.
|
||||
You can find the [WinRM Enablement Script](../../../../workflows/operations/automation/ansible/enable-winrm-on-windows-devices.md) in the Bunny Lab documentation.
|
||||
|
||||
## Ad-Hoc Command Examples
|
||||
At this point, you should finally be ready to connect to Windows and Linux devices and run commands on them ad-hoc. Puppet Bolt Modules and Plans will be discussed further down the road.
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Puppet
|
||||
- Automation
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Puppet is another declarative configuration management tool that excels in system configuration and enforcement. Like Ansible, it's designed to maintain the desired state of a system's configuration but uses a client-server (master-agent) architecture by default.
|
||||
|
||||
15
deployments/index.md
Normal file
15
deployments/index.md
Normal file
@@ -0,0 +1,15 @@
|
||||
---
|
||||
tags:
|
||||
- Deployments
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Deployments
|
||||
## Purpose
|
||||
Build and deployment documentation for platforms, services, and automation stacks.
|
||||
|
||||
## Includes
|
||||
- Platform deployments (virtualization and containerization)
|
||||
- Service deployments and integration patterns
|
||||
- Automation stack deployment guides
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Containers
|
||||
- Docker
|
||||
- Containerization
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This document will outline the general workflow of using Visual Studio Code to author and update custom containers and push them to a container registry hosted in Gitea. This will be referencing the `git-repo-updater` project throughout.
|
||||
|
||||
@@ -1,4 +1,11 @@
|
||||
**Purpose**: Docker container running Alpine Linux that automates and improves upon much of the script mentioned in the [Git Repo Updater](../../../../reference/bash/git-repo-updater.md) document. It offers the additional benefits of checking for updates every 5 seconds instead of every 60 seconds. It also accepts environment variables to provide credentials and notification settings, and can have an infinite number of monitored repositories.
|
||||
---
|
||||
tags:
|
||||
- Containers
|
||||
- Docker
|
||||
- Containerization
|
||||
---
|
||||
|
||||
**Purpose**: Docker container running Alpine Linux that automates and improves upon much of the script mentioned in the [Git Repo Updater](../../../../../scripts/bash/git-repo-updater.md) document. It offers the additional benefits of checking for updates every 5 seconds instead of every 60 seconds. It also accepts environment variables to provide credentials and notification settings, and can have an infinite number of monitored repositories.
|
||||
|
||||
### Deployment
|
||||
You can find the current up-to-date Gitea repository that includes the `docker-compose.yml` and `.env` files that you need to deploy everything [here](https://git.bunny-lab.io/container-registry/-/packages/container/git-repo-updater/latest)
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Docker
|
||||
- Portainer
|
||||
- Containerization
|
||||
---
|
||||
|
||||
### Update The Package Manager
|
||||
We need to update the server before installing Docker
|
||||
|
||||
@@ -47,7 +54,7 @@ Alternative Methods:
|
||||
2. Be sure to set the `-v /srv/containers/portainer:/data` value to a safe place that gets backed up regularily.
|
||||
|
||||
### Configure Docker Network
|
||||
I highly recomment setting up a [Dedicated Docker MACVLAN Network](../../../networking/docker-networking/docker-networking.md). You can use it to keep your containers on their own subnet.
|
||||
I highly recomment setting up a [Dedicated Docker MACVLAN Network](../../../../reference/infrastructure/networking/docker-networking/docker-networking.md). You can use it to keep your containers on their own subnet.
|
||||
|
||||
### Access Portainer WebUI
|
||||
You will be able to access the Portainer WebUI at the following address: `https://<IP Address>:9443`
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Kubernetes
|
||||
- RKE2
|
||||
- Rancher
|
||||
- Containerization
|
||||
---
|
||||
|
||||
# Deploy RKE2 Cluster
|
||||
Deploying a Rancher RKE2 Cluster is fairly straightforward. Just run the commands in-order and pay attention to which steps apply to all machines in the cluster, the controlplanes, and the workers.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Kubernetes
|
||||
- Containerization
|
||||
---
|
||||
|
||||
# Deploy Generic Kubernetes
|
||||
The instructions outlined below assume you are deploying the environment using Ansible Playbooks either via Ansible's CLI or AWX.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Platforms
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Platforms
|
||||
## Purpose
|
||||
Virtualization and containerization platforms, cluster builds, and base OS images.
|
||||
@@ -1,3 +1,8 @@
|
||||
---
|
||||
tags:
|
||||
- Documentation
|
||||
---
|
||||
|
||||
**Purpose**: Deploying a Windows Server Node into the Hyper-V Failover Cluster is an essential part of rebuilding and expanding the backbone of my homelab. The documentation below goes over the process of setting up a bare-metal host from scratch and integrating it into the Hyper-V Failover Cluster.
|
||||
|
||||
!!! note "Prerequisites & Assumptions"
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- OpenStack
|
||||
- Ansible
|
||||
---
|
||||
|
||||
!!! warning "Document Under Construction"
|
||||
This document is very unfinished and should **NOT** be followed by anyone for deployment at this time.
|
||||
|
||||
@@ -1,3 +1,8 @@
|
||||
---
|
||||
tags:
|
||||
- OpenStack
|
||||
---
|
||||
|
||||
# OpenStack
|
||||
OpenStack is basically a virtual machine hypervisor that is HA and cluster-friendly. This particular variant is deployed via Canonical's MiniStack environment using SNAP. It will deploy OpenStack onto a single node, which can later be expanded to additional nodes. You can also use something like OpenShift to deploy a Kubernetes Cluster onto OpenStack automatically via its various APIs.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Rancher
|
||||
- Harvester
|
||||
---
|
||||
|
||||
**Purpose**: Rancher Harvester is an awesome tool that acts like a self-hosted cloud VDI provider, similar to AWS, Linode, and other online cloud compute platforms. In most scenarios, you will deploy "Rancher" in addition to Harvester to orchestrate the deployment, management, and rolling upgrades of a Kubernetes Cluster. You can also just run standalone Virtual Machines, similar to Hyper-V, RHEV, oVirt, Bhyve, XenServer, XCP-NG, and VMware ESXi.
|
||||
|
||||
:::note Prerequisites
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Proxmox
|
||||
- Ubuntu
|
||||
---
|
||||
|
||||
## Purpose
|
||||
You may need to deploy many copies of a virtual machine rapidly, and don't want to go through the hassle of setting up everything ad-hoc as the needs arise for each VM workload. Creating a cloud-init template allows you to more rapidly deploy production-ready copies of a template VM (that you create below) into a ProxmoxVE environment.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Proxmox
|
||||
- iSCSI
|
||||
- Storage
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document describes the **end-to-end procedure** for creating a **thick-provisioned iSCSI-backed shared storage target** on **TrueNAS CORE**, and consuming it from a **Proxmox VE cluster** using **shared LVM**.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Proxmox
|
||||
- ZFS
|
||||
- iSCSI
|
||||
---
|
||||
|
||||
**Purpose**: There is a way to incorporate ProxmoxVE and TrueNAS more deeply using SSH, simplifying the deployment of virtual disks/volumes passed into GuestVMs in ProxmoxVE. Using ZFS over iSCSI will give you the following non-exhaustive list of benefits:
|
||||
|
||||
- Automatically make Zvols in a ZFS Storage Pool
|
||||
@@ -1,3 +1,8 @@
|
||||
---
|
||||
tags:
|
||||
- Proxmox
|
||||
---
|
||||
|
||||
## Initial Installation / Configuration
|
||||
Proxmox Virtual Environment is an open source server virtualization management solution based on QEMU/KVM and LXC. You can manage virtual machines, containers, highly available clusters, storage and networks with an integrated, easy-to-use web interface or via CLI.
|
||||
|
||||
@@ -15,7 +20,7 @@ You will need to download the [Proxmox VE 8.1 ISO Installer](https://www.proxmox
|
||||
```
|
||||
|
||||
1. This tells Hyper-V to allow the GuestVM to behave as a hypervisor, nested under Hyper-V, allowing the virtualization functionality of the Hypervisor's CPU to be passed-through to the GuestVM.
|
||||
2. This tells Hyper-V to allow your GuestVM to have multiple nested virtual machines with their own independant MAC addresses. This is useful when using nested Virtual Machines, but is also a requirement when you set up a [Docker Network](../../../networking/docker-networking/docker-networking.md) leveraging MACVLAN technology.
|
||||
2. This tells Hyper-V to allow your GuestVM to have multiple nested virtual machines with their own independant MAC addresses. This is useful when using nested Virtual Machines, but is also a requirement when you set up a [Docker Network](../../../../reference/infrastructure/networking/docker-networking/docker-networking.md) leveraging MACVLAN technology.
|
||||
|
||||
### Networking
|
||||
You will need to set a static IP address, in this case, it will be an address within the 20GbE network. You will be prompted to enter these during the ProxmoxVE installation. Be sure to set the hostname to something that matches the following FQDN: `proxmox-node-01.MOONGATE.local`.
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Homebox
|
||||
- Asset Management
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Homebox is the inventory and organization system built for the Home User! With a focus on simplicity and ease of use, Homebox is the perfect solution for your home inventory, organization, and management needs.
|
||||
|
||||
[Reference Documentation](https://hay-kot.github.io/homebox/quick-start/)
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Snipe-IT
|
||||
- Asset Management
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: A free open source IT asset/license management system.
|
||||
|
||||
!!! warning
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Activepieces
|
||||
- Automation
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Self-hosted open-source no-code business automation tool.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Node-RED
|
||||
- Automation
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Semaphore
|
||||
- Automation
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: User friendly web interface for executing Ansible playbooks, Terraform, OpenTofu code and Bash scripts. It is designed to make your automation tasks easier and more enjoyable.
|
||||
|
||||
[Website Details](https://semaphoreui.com/)
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- AdGuard Home
|
||||
- DNS
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: AdGuard Home is a network-wide software for blocking ads & tracking. After you set it up, it will cover ALL your home devices, and you don’t need any client-side software for that. With the rise of Internet-Of-Things and connected devices, it becomes more and more important to be able to control your whole network.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Pi-hole
|
||||
- DNS
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Pi-hole is a Linux network-level advertisement and Internet tracker blocking application which acts as a DNS sinkhole and optionally a DHCP server, intended for use on a private network.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- DNS
|
||||
- Windows Server
|
||||
- Windows
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document outlines best practices for DNS server configuration in Active Directory environments, focusing on both performance and security considerations. The goal is to enhance the stability, efficiency, and security of DNS infrastructure within enterprise networks.
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- DFS
|
||||
- Windows Server
|
||||
- Windows
|
||||
- File Services
|
||||
---
|
||||
|
||||
## Purpose
|
||||
If you want data available from a single, consistent UNC path while hosting it on multiple file servers, use **DFS Namespaces (DFSN)**. A namespace presents a *virtual* folder tree (for example, `\\bunny-lab.io\Projects`) whose folders point to one or more **folder targets** (actual SMB shares on your servers).
|
||||
**DFS Replication (DFSR)** is a *separate* feature you configure to keep the contents of those targets in sync.
|
||||
@@ -121,7 +129,8 @@ In the Replication wizard that appears after about a minute, you can configure t
|
||||
- ✅Update folder properties
|
||||
- ✅Create connections
|
||||
|
||||
### Checking DFS Status
|
||||
### Troubleshooting / Diagnostics
|
||||
#### Checking DFS Status
|
||||
You may want to put together a simple table report of the DFS namespaces, replication info, and target folders. You can run the following powershell script to generate a nice table-based report of the current structure of the DFS namespaces in your domain.
|
||||
|
||||
??? example "Powershell Reporting Script"
|
||||
@@ -387,3 +396,147 @@ You may want to put together a simple table report of the DFS namespaces, replic
|
||||
|
||||
Write-DfsGrid -Data $rows
|
||||
```
|
||||
|
||||
#### Fixing Inconsistent DFS Management GUI
|
||||
Sometimes the GUI for managing DFS becomes "inconsistent" whereas the namespaces and replication groups are different between member servers, and may be missing namspaces or missing replication groups. DFS Management is an MMC snap-in. MMC persists per-user console state under `%APPDATA%\Microsoft\MMC\`. If that state gets out of sync (common after service hiccups or server crashes), the snap-in can render partial/incorrect namespace/replication trees even when DFS itself is fine. Deleting the cached dfsmgmt* console forces a fresh enumeration. We will also include a few extra commands for extra thouroughness.
|
||||
|
||||
Before anything, we want to make sure that active directory itself is not having replication issues, as this would be a deeper, more complicated issue. Run the following command on one of your domain controllers:
|
||||
```powershell
|
||||
repadmin /syncall /AdeP
|
||||
repadmin /replsummary
|
||||
```
|
||||
|
||||
If AD-level replication is successful and timely, you can proceed to run the commands below (one-line-at-a-time):
|
||||
```sh
|
||||
# Pull-Down DFS Configuration from Active Directory & Restart DFS
|
||||
dfsrdiag pollad
|
||||
net stop dfsr
|
||||
net start dfsr
|
||||
|
||||
# Clear DFS Management Snap-In Cache
|
||||
taskkill /im mmc.exe /f
|
||||
del "%appdata%\Microsoft\MMC\dfsmgmt*"
|
||||
dfsmgmt.msc
|
||||
```
|
||||
|
||||
!!! success "DFS Management GUI Restored"
|
||||
At this point, the DFS Management snap-in (should) be successfully showing all of the DFS namespaces and replication groups when you re-open "DFS Management".
|
||||
|
||||
#### Check Replication Progress
|
||||
You may want to check that replication is occurring bi-directionally between every member server in your DFS deployment. I wrote a script below that effectively shows you every replication group and each directional backlog status.
|
||||
|
||||
```powershell
|
||||
# --- CONFIG ---
|
||||
$Members = @("LAB-FPS-01","LAB-FPS-02")
|
||||
$SummarizeAcrossFolders = $true # $true = one line per direction per RG; $false = per-folder lines
|
||||
|
||||
function Invoke-DfsrBacklogStatus {
|
||||
param(
|
||||
[Parameter(Mandatory)] [string] $RG,
|
||||
[Parameter(Mandatory)] [string] $RF,
|
||||
[Parameter(Mandatory)] [string] $Send,
|
||||
[Parameter(Mandatory)] [string] $Recv
|
||||
)
|
||||
|
||||
$out = & dfsrdiag backlog /rgname:"$RG" /rfname:"$RF" /sendingmember:"$Send" /receivingmember:"$Recv" 2>&1 | Out-String
|
||||
$outTrim = ($out -split "`r?`n" | ForEach-Object { $_.Trim() }) | Where-Object { $_ -ne "" }
|
||||
|
||||
if ($out -match 'No Backlog') {
|
||||
return [pscustomobject]@{ Status="No Backlog"; Count=0; Detail=$null }
|
||||
}
|
||||
|
||||
$count = $null
|
||||
$countLine = $outTrim | Where-Object { $_ -match '(?i)backlog' } | Select-Object -First 1
|
||||
if ($countLine -and ($countLine -match '(\d+)')) { $count = [int]$matches[1] }
|
||||
|
||||
$detail = ($outTrim | Select-Object -First 8) -join " | "
|
||||
|
||||
return [pscustomobject]@{
|
||||
Status = if ($count -ne $null) { "Backlog: $count" } else { "Backlog/Check Output" }
|
||||
Count = $count
|
||||
Detail = $detail
|
||||
}
|
||||
}
|
||||
|
||||
$groups = Get-DfsReplicationGroup | Sort-Object GroupName
|
||||
|
||||
foreach ($g in $groups) {
|
||||
$rg = $g.GroupName
|
||||
$rfs = Get-DfsReplicatedFolder -GroupName $rg | Sort-Object FolderName
|
||||
|
||||
Write-Host ""
|
||||
Write-Host ("== Replication Group: {0} ==" -f $rg)
|
||||
|
||||
foreach ($send in $Members) {
|
||||
foreach ($recv in $Members) {
|
||||
if ($send -eq $recv) { continue }
|
||||
|
||||
if ($SummarizeAcrossFolders) {
|
||||
$worstCount = 0
|
||||
$nonZero = @()
|
||||
$errorsOrDetails = @()
|
||||
|
||||
foreach ($rfObj in $rfs) {
|
||||
$rf = $rfObj.FolderName
|
||||
$res = Invoke-DfsrBacklogStatus -RG $rg -RF $rf -Send $send -Recv $recv
|
||||
|
||||
if ($res.Status -ne "No Backlog") {
|
||||
$nonZero += [pscustomobject]@{ RF=$rf; Status=$res.Status; Count=$res.Count; Detail=$res.Detail }
|
||||
if ($res.Count -ne $null -and $res.Count -gt $worstCount) { $worstCount = $res.Count }
|
||||
|
||||
# ✅ FIX: ${rf} avoids the ':' parsing issue
|
||||
if ($res.Detail) { $errorsOrDetails += "RF=${rf}: $($res.Detail)" }
|
||||
}
|
||||
}
|
||||
|
||||
if ($nonZero.Count -eq 0) {
|
||||
Write-Host ("{0} -> {1}: No Backlog" -f $send, $recv)
|
||||
} else {
|
||||
if ($worstCount -gt 0) {
|
||||
Write-Host ("{0} -> {1}: Backlog (max {2} across RFs)" -f $send, $recv, $worstCount)
|
||||
} else {
|
||||
Write-Host ("{0} -> {1}: Backlog/Errors (see details)" -f $send, $recv)
|
||||
}
|
||||
|
||||
$errorsOrDetails | Select-Object -First 5 | ForEach-Object { Write-Host (" - {0}" -f $_) }
|
||||
if ($errorsOrDetails.Count -gt 5) { Write-Host " - ... (more omitted)" }
|
||||
}
|
||||
}
|
||||
else {
|
||||
foreach ($rfObj in $rfs) {
|
||||
$rf = $rfObj.FolderName
|
||||
$res = Invoke-DfsrBacklogStatus -RG $rg -RF $rf -Send $send -Recv $recv
|
||||
|
||||
if ($res.Status -eq "No Backlog") {
|
||||
Write-Host ("{0} -> {1} [{2}]: No Backlog" -f $send, $recv, $rf)
|
||||
} else {
|
||||
Write-Host ("{0} -> {1} [{2}]: {3}" -f $send, $recv, $rf, $res.Status)
|
||||
if ($res.Detail) { Write-Host (" - {0}" -f $res.Detail) }
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
!!! example "Example Output"
|
||||
You will see output like the following when you run the script.
|
||||
|
||||
```powershell
|
||||
== Replication Group: bunny-lab.io\music\fl studio plugins ==
|
||||
LAB-FPS-01 -> LAB-FPS-02: No Backlog
|
||||
LAB-FPS-02 -> LAB-FPS-01: No Backlog
|
||||
|
||||
== Replication Group: bunny-lab.io\music\personal music ==
|
||||
LAB-FPS-01 -> LAB-FPS-02: No Backlog
|
||||
LAB-FPS-02 -> LAB-FPS-01: No Backlog
|
||||
|
||||
== Replication Group: bunny-lab.io\music\shared music ==
|
||||
LAB-FPS-01 -> LAB-FPS-02: No Backlog
|
||||
LAB-FPS-02 -> LAB-FPS-01: No Backlog
|
||||
|
||||
== Replication Group: bunny-lab.io\projects\coding ==
|
||||
LAB-FPS-01 -> LAB-FPS-02: No Backlog
|
||||
LAB-FPS-02 -> LAB-FPS-01: No Backlog
|
||||
```
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Frigate
|
||||
- IoT
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: A complete and local NVR designed for Home Assistant with AI object detection. Uses OpenCV and Tensorflow to perform realtime object detection locally for IP cameras.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Home Assistant
|
||||
- IoT
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- EmulatorJS
|
||||
- Media
|
||||
- Gaming
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Emulatorjs is a browser web based emulation portable to nearly any device for many retro consoles. A mix of emulators is used between Libretro and EmulatorJS.
|
||||
|
||||
## Docker Configuration
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Pyload
|
||||
- Media
|
||||
- Gaming
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: pyLoad-ng is a Free and Open Source download manager written in Python and designed to be extremely lightweight, easily extensible and fully manageable via web.
|
||||
|
||||
[Detailed LinuxServer.io Deployment Info](https://docs.linuxserver.io/images/docker-pyload-ng/)
|
||||
@@ -1,3 +1,8 @@
|
||||
---
|
||||
tags:
|
||||
- MFA
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Sometimes you may need to change the MFA on an account, by adding a new email or phone number for SMS-based MFA. This can be done fairly quickly and only involves a few steps:
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Apache Guacamole
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: HTML5-based Remote Access Broker for SSH, RDP, and VNC. Useful for remote access into an environment.
|
||||
|
||||
### Docker Compose Stack
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Firefox
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Sometimes you just want an instance of Firefox running on an Alpine Linux container, that has persistence (Extensions, bookmarks, history, etc) outside of the container (with bind-mapped folders). This is useful for a number of reasons, but insecure by default, so you have to protect it behind something like a [Keycloak Server](../authentication/keycloak/deployment.md) so it is not misused.
|
||||
|
||||
## Keycloak Authentication Sequence
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- ChangeDetection
|
||||
- Security
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Detect website content changes and perform meaningful actions - trigger notifications via Discord, Email, Slack, Telegram, API calls and many more.
|
||||
|
||||
## Docker Configuration
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- CyberChef
|
||||
- Security
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: The Cyber Swiss Army Knife - a web app for encryption, encoding, compression and data analysis.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- IT-Tools
|
||||
- Security
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Collection of handy online tools for developers, with great UX.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Password Pusher
|
||||
- Security
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: An application to securely communicate passwords over the web. Passwords automatically expire after a certain number of views and/or time has passed. Track who, what and when.
|
||||
|
||||
## Docker Configuration
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Searx
|
||||
- Security
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Deploys a SearX Meta Search Engine Server
|
||||
|
||||
## Docker Configuration
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Vaultwarden
|
||||
- Security
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Active Directory
|
||||
- Certificate Services
|
||||
- Authentication
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This document outlines the Microsoft-recommended best practices for deploying a secure, internal-use-only, two-tier Public Key Infrastructure (PKI) using Windows Server 2022 or newer. The PKI supports securing S/MIME email, 802.1X Wi-Fi with NPS, and LDAP over SSL (LDAPS).
|
||||
|
||||
@@ -9,9 +16,9 @@ This document outlines the Microsoft-recommended best practices for deploying a
|
||||
!!! note "Certificate Authority Server Provisioning Assumptions"
|
||||
- OS = Windows Server 2022/2025 bare-metal or as a VM
|
||||
- You should give it at least 4GB of RAM.
|
||||
- [Change the edition of Windows Server from "**Evaluation**" to "**Standard**" via DISM](../../../operations/windows/change-windows-edition.md)
|
||||
- [Change the edition of Windows Server from "**Evaluation**" to "**Standard**" via DISM](../../../../workflows/operations/windows/change-windows-edition.md)
|
||||
- Ensure the server is fully updated
|
||||
- [Ensure the server is activated](../../../operations/windows/change-windows-edition.md#force-activation-edition-switcher)
|
||||
- [Ensure the server is activated](../../../../workflows/operations/windows/change-windows-edition.md#force-activation-edition-switcher)
|
||||
- Ensure the timezone is correctly configured
|
||||
- Ensure the hostname is correctly configured
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Active Directory
|
||||
- Group Policy
|
||||
- Authentication
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
To deploy a shortcut to the desktop pointing to a network share's root path. (e.g. `\\storage.bunny-lab.io`). There is a quirk with how Windows handles network shares and shortcuts and doesn't like when you point the shortcut to a root UNC path.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Active Directory
|
||||
- LDAP
|
||||
- Authentication
|
||||
---
|
||||
|
||||
**Purpose**: LDAP settings are used in various services from privacyIDEA to Nextcloud. This will outline the basic parameters in my homelab that are necessary to make it function.
|
||||
|
||||
| **Field** | **Value** | **Description** |
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Active Directory
|
||||
- Authentication
|
||||
---
|
||||
|
||||
## Purpose
|
||||
If you have a device that lost trust in the domain for some reason, and won't let you login using domain credentials, run the following command as a local administrator on the device to repair trust.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Authelia
|
||||
- Authentication
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Authelia is an open-source authentication and authorization server and portal fulfilling the identity and access management (IAM) role of information security in providing multi-factor authentication and single sign-on (SSO) for your applications via a web portal. It acts as a companion for common reverse proxies.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Authentik
|
||||
- Authentication
|
||||
- Docker
|
||||
---
|
||||
|
||||
!!! bug
|
||||
The docker-compose version of the deployment appears bugged and has known issues, deployment via Kubernetes is required to stability and support.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Keycloak
|
||||
- Authentication
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Keycloak is an open source identity and access management system for modern applications and services.
|
||||
|
||||
- [Original Reference Compose File](https://github.com/JamesTurland/JimsGarage/blob/main/Keycloak/docker-compose.yaml)
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Gitea
|
||||
- Keycloak
|
||||
- OAuth2
|
||||
- Authentication
|
||||
---
|
||||
|
||||
### OAuth2 Configuration
|
||||
These are variables referenced by the associated service to connect its authentication system to [Keycloak](../deployment.md).
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Portainer
|
||||
- Keycloak
|
||||
- OAuth2
|
||||
- Authentication
|
||||
---
|
||||
|
||||
### OAuth2 Configuration
|
||||
These are variables referenced by the associated service to connect its authentication system to [Keycloak](../deployment.md).
|
||||
|
||||
@@ -1,2 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Keycloak
|
||||
- OAuth2
|
||||
- Authentication
|
||||
- Docker
|
||||
---
|
||||
|
||||
You can deploy Keycloak via a [docker-compose stack](../deployment.md) found within the "Containerization" section of the documentation.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- PrivacyIDEA
|
||||
- Authentication
|
||||
---
|
||||
|
||||
**Purpose**: privacyIDEA is a modular authentication system. Using privacyIDEA you can enhance your existing applications like local login, VPN, remote access, SSH connections, access to web sites or web portals with a second factor during authentication.
|
||||
|
||||
!!! info "Assumptions"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Kopia
|
||||
- Backup
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Cross-platform backup tool for Windows, macOS & Linux with fast, incremental backups, client-side end-to-end encryption, compression and data deduplication. CLI and GUI included.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- cPanel
|
||||
- Email
|
||||
---
|
||||
|
||||
## Purpose
|
||||
This documentation helps you deploy an email server within a cPanel hosted environment.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Niltalk
|
||||
- Communication
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Niltalk is a web based disposable chat server. It allows users to create password protected disposable, ephemeral chatrooms and invite peers to chat rooms.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Rocket.Chat
|
||||
- Communication
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
When someone types a message that includes a ticket number (e.g. `T00000000.0000`) we want to replace that text with an API-friendly URL that leverages Markdown language as well.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Rocket.Chat
|
||||
- Communication
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Deploy a RocketChat and MongoDB database together.
|
||||
|
||||
!!! caution Folder Pre-Creation
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Docker
|
||||
- Homepage
|
||||
- Dashboards
|
||||
---
|
||||
|
||||
**Purpose**: A highly customizable homepage (or startpage / application dashboard) with Docker and service API integrations.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Dashy
|
||||
- Dashboards
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: A self-hostable personal dashboard built for you. Includes status-checking, widgets, themes, icon packs, a UI editor and tons more!
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Gitea
|
||||
- DevOps
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Gitea is a painless self-hosted all-in-one software development service, it includes Git hosting, code review, team collaboration, package registry and CI/CD. It is similar to GitHub, Bitbucket and GitLab. Gitea was forked from Gogs originally and almost all the code has been changed.
|
||||
|
||||
[Detailed SMTP Configuration Reference](https://docs.gitea.com/administration/config-cheat-sheet)
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- MkDocs
|
||||
- Material MkDocs
|
||||
- Documentation
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Documentation that simply works. Write your documentation in Markdown and create a professional static site for your Open Source or commercial project in minutes – searchable, customizable, more than 60 languages, for all devices.
|
||||
|
||||
## Deploy Material MKDocs
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Docusaurus
|
||||
- Documentation
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: An optimized site generator in React. Docusaurus helps you to move fast and write content. Build documentation websites, blogs, marketing pages, and more.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Zensical
|
||||
- Documentation
|
||||
---
|
||||
|
||||
## Purpose
|
||||
After many years of using Material for MKDocs and it being updated with new features and security updates, it finally reached EOL around the end of 2025. The project maintainers started pivoting to a new successor called [Zensical](https://zensical.org/docs/get-started/). This document outlines my particular process for setting up a standalone documentation server within a virtual machine.
|
||||
|
||||
@@ -208,6 +214,14 @@ sudo useradd --system --create-home --home /var/lib/gitea_runner --shell /usr/sb
|
||||
# Allow the runner to write documentation changes
|
||||
sudo usermod -aG zensical gitearunner
|
||||
|
||||
# Allow the runner to start and stop Zensical Watchdog Service
|
||||
sudo tee /etc/sudoers.d/gitearunner-systemctl > /dev/null <<'EOF'
|
||||
gitearunner ALL=NOPASSWD: /usr/bin/systemctl start zensical-watchdog.service, /usr/bin/systemctl stop zensical-watchdog.service
|
||||
EOF
|
||||
sudo chmod 440 /etc/sudoers.d/gitearunner-systemctl
|
||||
sudo chown root:root /etc/sudoers.d/gitearunner-systemctl
|
||||
sudo visudo -c
|
||||
|
||||
# Download Newest Gitea Runner Binary (https://gitea.com/gitea/act_runner/releases)
|
||||
cd /tmp
|
||||
wget https://gitea.com/gitea/act_runner/releases/download/v0.2.13/act_runner-0.2.13-linux-amd64
|
||||
@@ -280,8 +294,8 @@ sudo systemctl enable --now gitea-runner.service
|
||||
### Repository Workflow
|
||||
Place the following file into your documentation repository at the given location and this will enable the runner to execute when changes happen to the repository data.
|
||||
|
||||
```yaml title="gitea/workflows/gitops-automatic-deployment.yml"
|
||||
name: GitOps Automatic Documentation Deployment
|
||||
```yaml title="gitea/workflows/automatic-deployment.yml"
|
||||
name: Automatic Documentation Deployment
|
||||
|
||||
on:
|
||||
push:
|
||||
@@ -296,6 +310,9 @@ jobs:
|
||||
- name: Checkout Repository
|
||||
uses: actions/checkout@v3
|
||||
|
||||
- name: Stop Zensical Service
|
||||
run: sudo /usr/bin/systemctl stop zensical-watchdog.service
|
||||
|
||||
- name: Sync repository into /srv/zensical/docs
|
||||
run: |
|
||||
rsync -rlD --delete \
|
||||
@@ -308,10 +325,14 @@ jobs:
|
||||
--chmod=D2775,F664 \
|
||||
. /srv/zensical/docs/
|
||||
|
||||
- name: Start Zensical Service
|
||||
run: sudo /usr/bin/systemctl start zensical-watchdog.service
|
||||
|
||||
- name: Notify via NTFY
|
||||
if: always()
|
||||
run: |
|
||||
curl -d "https://kb.bunny-lab.io - Zensical job status: ${{ job.status }}" https://ntfy.bunny-lab.io/gitea-runners
|
||||
|
||||
```
|
||||
|
||||
## Traefik Reverse Proxy
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Nginx
|
||||
- Reverse Proxy
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: NGINX is open source software for web serving, reverse proxying, caching, load balancing, media streaming, and more.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Traefik
|
||||
- Reverse Proxy
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: A traefik reverse proxy is a server that sits between your network firewall and servers hosting various web services on your private network(s). Traefik automatically handles the creation of Let's Encrypt SSL certificates if you have a domain registrar that is supported by Traefik such as CloudFlare; by leveraging API keys, Traefik can automatically make the DNS records for Let's Encrypt's DNS "challenges" whenever you add a service behind the Traefik reverse proxy.
|
||||
|
||||
!!! info "Assumptions"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Microsoft Exchange
|
||||
- Lets Encrypt
|
||||
- Email
|
||||
---
|
||||
|
||||
**Purpose**: If you want to set up automatic Let's Encrypt SSL certificates on a Microsoft Exchange server, you have to go through a few steps to install the WinACME bot, and configure it to automatically renew certificates.
|
||||
|
||||
!!! note "ACME Bot Provisioning Considerations"
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Microsoft Exchange
|
||||
- Email
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This document is meant to be an abstract guide on what to do before installing Cumulative Updates on Microsoft Exchange Server. There are a few considerations that need to be made ahead of time. This list was put together through shere brute-force while troubleshooting an update issue for a server on 12/16/2024.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- IredMail
|
||||
- Email
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Self-Hosted Open-Source email server that can be setup in minutes, and is enterprise-grade if upgraded with an iRedAdmin-Pro license.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- IredMail
|
||||
- SMTP
|
||||
- Email
|
||||
---
|
||||
|
||||
## Purpose
|
||||
You may need to troubleshoot the outgoing SMTP email queue / active sessions in iRedMail for one reason or another. This can provide useful insight into the reason why emails are not being delivered, etc.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- IredMail
|
||||
- Email
|
||||
---
|
||||
|
||||
| Server | Port(s) | Security | Auth Method | Username |
|
||||
|:------------------|:----------------------------------------------|:----------|:----------------|:-------------------|
|
||||
| `mail.bunny-lab.io` | **IMAP:** 143 `Internal`, 993 `External`<br>**SMTP:** 587, 25 `Fallback` | STARTTLS | Normal Password | user@bunny-lab.io |
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Mailcow
|
||||
- Email
|
||||
- Docker
|
||||
---
|
||||
|
||||
!!! warning "Under Construction"
|
||||
The deployment of Mailcow is mostly correct here, but with the exception that we dont point DNS records to the reverse proxy (internally) because it's currently not functioning as expected. So for the time being, you would open all of the ports up to the Mailcow server's internal IP address via port forwarding on your firewall.
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- ARK
|
||||
- Gaming
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This document outlines some of the prerequisites as well as deployment process for an ARK: Survival Ascended Server
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Pterodactyl
|
||||
- Gaming
|
||||
---
|
||||
|
||||
**Purpose**: Pterodactyl is the open-source game server management panel built with PHP, React, and Go. Designed with security in mind, Pterodactyl runs all game servers in isolated Docker containers while exposing a beautiful and intuitive UI to administrators and users.
|
||||
[Official Website](https://pterodactyl.io/panel/1.0/getting_started.html)
|
||||
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Valheim
|
||||
- Gaming
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
This document outlines some of the prerequisites as well as deployment process for an dedicated Valheim server.
|
||||
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Services
|
||||
- Index
|
||||
- Documentation
|
||||
---
|
||||
|
||||
# Services
|
||||
## Purpose
|
||||
Deployable services and applications in the lab (auth, email, monitoring, etc).
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Speedtest Tracker
|
||||
- Monitoring
|
||||
- Docker
|
||||
---
|
||||
|
||||
## Purpose:
|
||||
Speedtest Tracker is a self-hosted application that monitors the performance and uptime of your internet connection over time.
|
||||
[Detailed Configuration Reference](https://docs.speedtest-tracker.dev/getting-started/installation)
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Gatus
|
||||
- Monitoring
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Gatus Service Status Server.
|
||||
|
||||
## Docker Configuration
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Uptime Kuma
|
||||
- Monitoring
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Deploy Uptime Kuma uptime monitor to monitor services in the homelab and send notifications to various services.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- ntfy
|
||||
- Notifications
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: ntfy (pronounced notify) is a simple HTTP-based pub-sub notification service. It allows you to send notifications to your phone or desktop via scripts from any computer, and/or using a REST API. It's infinitely flexible, and 100% free software.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Collabora
|
||||
- Productivity
|
||||
- Docker
|
||||
---
|
||||
|
||||
## Purpose:
|
||||
The Collabora CODE Server is used by Nextcloud Office to open and edit documents and spreadsheets collaboratively. When Nextcloud is not deployed in a [Nextcloud AIO](./nextcloud-aio.md) way, and is instead installed not as a container, you (may) run into stability issues with Collabora CODE Server just randomly breaking and not allowing users to edit documents. If this happens, you can follow this document to stand-up a dedicated Collabora CODE Server on the same host as your Nextcloud server.
|
||||
|
||||
@@ -1,3 +1,11 @@
|
||||
---
|
||||
tags:
|
||||
- Nextcloud AIO
|
||||
- Nextcloud
|
||||
- Productivity
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Deploy a Nextcloud AIO Server. [Official Nextcloud All-in-One Documentation](https://github.com/nextcloud/all-in-one).
|
||||
This version of Nextcloud consists of 12 containers that are centrally managed by a single "master" container. It is more orchestrated and automates the implementation of Nextcloud Office, Nextcloud Talk, and other integrations / apps.
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- OnlyOffice
|
||||
- Productivity
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: ONLYOFFICE offers a secure online office suite highly compatible with MS Office formats. Generally used with Nextcloud to edit documents directly within the web browser.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Stirling PDF
|
||||
- Productivity
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: This is a powerful locally hosted web based PDF manipulation tool using docker that allows you to perform various operations on PDF files, such as splitting merging, converting, reorganizing, adding images, rotating, compressing, and more. This locally hosted web application started as a 100% ChatGPT-made application and has evolved to include a wide range of features to handle all your PDF needs.
|
||||
|
||||
## Docker Configuration
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Nextcloud
|
||||
- Productivity
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Deploy a Nextcloud and PostgreSQL database together.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- Trilium
|
||||
- Productivity
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: Build your personal knowledge base with [Trilium Notes](https://github.com/zadam/trilium/tree/master).
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,10 @@
|
||||
---
|
||||
tags:
|
||||
- WordPress
|
||||
- Productivity
|
||||
- Docker
|
||||
---
|
||||
|
||||
**Purpose**: At its core, WordPress is the simplest, most popular way to create your own website or blog. In fact, WordPress powers over 43.3% of all the websites on the Internet. Yes – more than one in four websites that you visit are likely powered by WordPress.
|
||||
|
||||
```yaml title="docker-compose.yml"
|
||||
@@ -1,3 +1,9 @@
|
||||
---
|
||||
tags:
|
||||
- Tactical RMM
|
||||
- RMM
|
||||
---
|
||||
|
||||
**Purpose**:
|
||||
Tactical RMM is a remote monitoring & management tool built with Django, Vue and Golang. [Official Documentation](https://docs.tacticalrmm.com/install_server/).
|
||||
|
||||
31
index.md
31
index.md
@@ -1,33 +1,21 @@
|
||||
# Home
|
||||
## Homelab Documentation Structure
|
||||
This documentation details the design, setup, and day-to-day management of my homelab environment. The goal is to keep it deterministic, CLI-first, and easy to audit or reproduce.
|
||||
This documentation details the design, setup, and day-to-day management of my homelab environment. The goal is to keep it deterministic, CLI-first, and easy to audit or reproduce. Some of the decisions made may not involve using the best security practices. Use your own discretion when following this documentation.
|
||||
|
||||
---
|
||||
|
||||
## Top-Level Sections
|
||||
**Foundations**
|
||||
- Conventions, templates, glossary, and shared standards
|
||||
**Deployments**
|
||||
- Platform, service, and automation deployment guides
|
||||
|
||||
**Hardware**
|
||||
- Node build sheets, storage layouts, and physical inventory
|
||||
**Workflows**
|
||||
- Day-2 runbooks, maintenance procedures, and troubleshooting flows
|
||||
|
||||
**Networking**
|
||||
- Addressing plans, firewall rules, VPNs, and network services
|
||||
|
||||
**Platforms**
|
||||
- Virtualization and containerization stacks (hypervisors, Kubernetes, Docker)
|
||||
|
||||
**Services**
|
||||
- Deployable apps and services (auth, docs, email, monitoring, etc.)
|
||||
|
||||
**Automation**
|
||||
- Ansible, Puppet, and workflow automation notes
|
||||
|
||||
**Operations**
|
||||
- Runbooks for maintenance, backups, and troubleshooting
|
||||
**Scripts**
|
||||
- Quick-use Bash, PowerShell, and Batch scripts/snippets
|
||||
|
||||
**Reference**
|
||||
- Quick scripts and snippets for day-to-day tasks
|
||||
- Foundations, hardware inventory, and networking reference material
|
||||
|
||||
**Blog**
|
||||
- Narrative posts and lessons learned
|
||||
@@ -40,7 +28,7 @@ This documentation details the design, setup, and day-to-day management of my ho
|
||||
- **Personal Environment:** These docs reflect my own environment, goals, and risk tolerance.
|
||||
- **Security & Scale:** Approaches described here are suited to homelab or SMB use, and may need adjustments for enterprise-scale, regulatory compliance, or higher security standards.
|
||||
- **No Credentials:** All sensitive info is redacted or generalized.
|
||||
- **Assumptions:** Some guides assume specific tools, e.g. [Portainer](./platforms/containerization/docker/deploy-portainer.md), [AWX](./automation/ansible/awx/deployment/awx-operator.md), etc. Substitute with your preferred tools as needed.
|
||||
- **Assumptions:** Some guides assume specific tools, e.g. [Portainer](deployments/platforms/containerization/docker/deploy-portainer.md), [AWX](./deployments/automation/ansible/awx/deployment/awx-operator.md), etc. Substitute with your preferred tools as needed.
|
||||
|
||||
---
|
||||
|
||||
@@ -52,3 +40,4 @@ This documentation details the design, setup, and day-to-day management of my ho
|
||||
---
|
||||
|
||||
> _“Homelabs are for learning, breaking things, and sharing the journey. Hope you find something helpful here!”_
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user