Organize with page bundles
@@ -48,7 +48,7 @@ Synology's MailPlus seems to be a good candidate for backing up this data. By en
|
||||
|
||||
Installing MailPlus can be done from the Package Center:
|
||||
|
||||

|
||||

|
||||
|
||||
Next, I went into **Synology MailPlus Server** and on the left, clicked on **Account** and ensured my user was marked as active.
|
||||
|
||||
@@ -60,7 +60,7 @@ I made sure to set the `Fetch Range` to `All` in order to get all emails from th
|
||||
|
||||
After this, mail started coming in.
|
||||
|
||||

|
||||

|
||||
|
||||
After fetching 19 years worth of emails, I tried searching for some emails. It only took a few seconds to search through ~50K emails, which is a relief if I ever did have to search for something important.
|
||||
|
After Width: | Height: | Size: 30 KiB |
After Width: | Height: | Size: 52 KiB |
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: "Enhancing Pfsense With Services"
|
||||
date: 2023-03-25T18:37:08-04:00
|
||||
lastmod: 2023-03-25T18:37:08-04:00
|
||||
draft: true
|
||||
keywords: []
|
||||
description: ""
|
||||
tags: []
|
||||
categories: []
|
||||
author: ""
|
||||
|
||||
# You can also close(false) or open(true) something for this content.
|
||||
# P.S. comment can only be closed
|
||||
comment: false
|
||||
toc: false
|
||||
autoCollapseToc: false
|
||||
postMetaInFooter: false
|
||||
hiddenFromHomePage: false
|
||||
# You can also define another contentCopyright. e.g. contentCopyright: "This is another copyright."
|
||||
contentCopyright: false
|
||||
reward: false
|
||||
mathjax: false
|
||||
mathjaxEnableSingleDollar: false
|
||||
|
||||
flowchartDiagrams:
|
||||
enable: false
|
||||
options: ""
|
||||
|
||||
sequenceDiagrams:
|
||||
enable: false
|
||||
options: ""
|
||||
|
||||
---
|
||||
|
||||
<!--more-->
|
After Width: | Height: | Size: 35 KiB |
@@ -43,7 +43,7 @@ In this post I'll go through the process of setting up Gitea Actions and [Tailsc
|
||||
|
||||
[Gitea Actions](https://docs.gitea.com/usage/actions/overview) have made it into the [1.19.0 release](https://blog.gitea.com/release-of-1.19.0/). This feature had been in an experimental state up until [1.21.0](https://blog.gitea.com/release-of-1.21.0/) and is now enabled by default 🎉.
|
||||
|
||||
So what are they? If you've ever used GitHub Actions (and if you're reading this, I imagine you have), they essentially allow you to run github workflows on gitea. Workflows between gitea and github are not completely interopable, but a lot of the same workflow syntax is already compatible on gitea. You can find a list of [unsupported workflows syntax](https://docs.gitea.com/usage/actions/comparison#unsupported-workflows-syntax).
|
||||
So what are they? If you've ever used GitHub Actions (and if you're reading this, I imagine you have), these will look familiar. Gitea Actions essentially enable the ability to run github workflows on gitea. Workflows between gitea and github are not completely interopable, but a lot of the same workflow syntax is already compatible on gitea. You can find a documented list of [unsupported workflows syntax](https://docs.gitea.com/usage/actions/comparison#unsupported-workflows-syntax).
|
||||
|
||||
Actions work by using a [custom fork](https://gitea.com/gitea/act) of [nekos/act](https://github.com/nektos/act). Workflows run in a new container for every job. If you specify an action such as 'actions/checkout@v3', it defaults to downloading the scripts from github.com. To avoid internet egress, you could always clone the required actions to your local gitea instance.
|
||||
|
||||
@@ -136,7 +136,7 @@ http:
|
||||
|
||||
Something to consider is whether or not you want to use ssh with git. One method of getting this to work with containers is to use [ssh container passthrough](https://docs.gitea.com/installation/install-with-docker#ssh-container-passthrough). I decided to keep it simple and not use ssh, since communicating over https is perfectly fine for my use case.
|
||||
|
||||
After adding the above configuration, running `docker compose up -d` should be enough to get your instance up and running. It will be accessible at [https://gitea.my-tailnet-name.ts.net](https://gitea.my-tailnet-name.ts.net) from within your tailnet.
|
||||
After adding the above configuration, running `docker compose up -d` should be enough to get an instance up and running. It will be accessible at [https://gitea.my-tailnet-name.ts.net](https://gitea.my-tailnet-name.ts.net) from within your tailnet.
|
||||
|
||||
## Connecting a Runner
|
||||
|
||||
@@ -144,7 +144,7 @@ I installed the runner by [following the docs](https://docs.gitea.com/usage/acti
|
||||
|
||||
After registering this runner and starting the daemon, it appeared in `/admin/actions/runners`:
|
||||
|
||||

|
||||

|
||||
|
||||
## Running a workflow
|
||||
|
||||
@@ -201,6 +201,6 @@ And voilà:
|
||||
|
||||
## Conclusion
|
||||
|
||||
Gitea Actions are fast and the resource footprint is minimal. My gitea instance is currently using around 250mb of memory and a small fraction of a single cpu core (and the runner is using a similar amount of resources). This is impressive since many alternatives tend to require substantionally more resources (ahem, gitlab). It certainly doesn't hurt that the codebase is largely written in go.
|
||||
Gitea Actions are fast and the resource footprint is minimal. My gitea instance is currently using around 250mb of memory and a small fraction of a single cpu core (and the runner is using a similar amount of resources). This is impressive since many alternatives tend to require substantionally more resources (ahem, gitlab). It likely helps that the codebase is largely written in go.
|
||||
|
||||
By combining gitea with the networking marvel that is tailscale, running workflows becomes simple and fun. Whether you are working on a team or working alone, this setup ensures that your workflows are securely accessible from anywhere with an internet connection.
|
||||
|
@@ -56,7 +56,7 @@ The following configuration will:
|
||||
|
||||
In the switch's web interface, I went to `VLAN` and then `802.1Q`, and then clicked on `VLAN Configuration`. I configured the ports to look like this:
|
||||
|
||||

|
||||

|
||||
|
||||
Note that the `VLAN Identifier Setting` has been setup already with two VLANs (1 and 10). More VLANs can be created (i.e. to isolate IoT devices), but 2 VLANs is all we need for the initial setup of a router.
|
||||
|
||||
@@ -64,15 +64,15 @@ To replicate the above configuration, add a new VLAN ID 10 (1 should exist by de
|
||||
|
||||
Next, go into `VLAN Membership` and configure VLAN 1's port membership to be the following:
|
||||
|
||||

|
||||

|
||||
|
||||
and then configure VLAN 10's port membership to be the following:
|
||||
|
||||

|
||||

|
||||
|
||||
Now, go into `Port PVID` and ensure that port 8 is set to PVID 10.
|
||||
|
||||

|
||||

|
||||
|
||||
This above configuration will dedicate two of the eight ports to WAN and LAN. This will allow the internet to flow into the pfSense from the modem.
|
||||
|
||||
@@ -90,7 +90,7 @@ After going through the rest of the installation, if everything is connected cor
|
||||
|
||||
If all goes well, the web interface should be running at [https://192.168.1.1](https://192.168.1.1).
|
||||
|
||||

|
||||

|
||||
|
||||
And this is where the fun begins. There are many tutorials and blogs about how to setup pfSense and various services and packages that can be installed. I've already installed [pfBlocker-NG](https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html).
|
||||
|
After Width: | Height: | Size: 33 KiB |
After Width: | Height: | Size: 42 KiB |
After Width: | Height: | Size: 36 KiB |
After Width: | Height: | Size: 36 KiB |
After Width: | Height: | Size: 90 KiB |
BIN
content/post/watching-youtube-in-private/computerphile.png
Normal file
After Width: | Height: | Size: 935 KiB |
@@ -5,7 +5,7 @@ lastmod: 2022-12-10T21:46:55-05:00
|
||||
draft: false
|
||||
keywords: []
|
||||
description: ""
|
||||
tags: ['invidious','degoogle', 'youtube', 'yewtu.be', 'tailscale', 'privacy']
|
||||
tags: ["invidious", "degoogle", "youtube", "yewtu.be", "tailscale", "privacy"]
|
||||
categories: []
|
||||
author: ""
|
||||
|
||||
@@ -26,18 +26,16 @@ flowchartDiagrams:
|
||||
enable: false
|
||||
options: ""
|
||||
|
||||
sequenceDiagrams:
|
||||
sequenceDiagrams:
|
||||
enable: false
|
||||
options: ""
|
||||
|
||||
---
|
||||
|
||||
<!--more-->
|
||||
|
||||
I recently stumbled upon [yewtu.be](https://yewtu.be) and found it intriguing. It not only allows you to watch YouTube without *being on YouTube*, but it also allows you to create an account and subscribe to channels without a Google account. What sort of wizardry is going on under the hood? It turns out that it's a hosted instance of [invidious](https://invidious.io/).
|
||||
I recently stumbled upon [yewtu.be](https://yewtu.be) and found it intriguing. It not only allows you to watch YouTube without _being on YouTube_, but it also allows you to create an account and subscribe to channels without a Google account. What sort of wizardry is going on under the hood? It turns out that it's a hosted instance of [invidious](https://invidious.io/).
|
||||
|
||||
|
||||

|
||||

|
||||
|
||||
The layout is simple, and **JavaScript is not required**.
|
||||
|
||||
@@ -54,7 +52,6 @@ I made a few modifications (such as pinning the container's tag), and ended up w
|
||||
```yaml
|
||||
version: "3"
|
||||
services:
|
||||
|
||||
invidious:
|
||||
image: quay.io/invidious/invidious:5160d8bae39dc5cc5d51abee90571a03c08d0f2b
|
||||
restart: unless-stopped
|
||||
@@ -103,7 +100,7 @@ I figured it would be nice to redirect existing YouTube links that others send m
|
||||
|
||||
I went looking for a way to redirect paths at the browser level. I found the lightweight proxy [requestly](https://requestly.io/), which can be used to modify http requests in my browser. I created the following rules:
|
||||
|
||||

|
||||

|
||||
|
||||
Now the link https://www.youtube.com/watch?v=-lz30by8-sU will redirect to [http://invidious:3000/watch?v=-lz30by8-sU](http://invidious:3000/watch?v=-lz30by8-sU)
|
||||
|
BIN
content/post/watching-youtube-in-private/requestly-rules.png
Normal file
After Width: | Height: | Size: 86 KiB |
@@ -23,7 +23,7 @@ Having multiple machines/nodes provides the advantage of increased redundancy, b
|
||||
Virtualizing your hardware is an organized way of dividing up your machine's resources. This can be done with something such as a *Virtual Machine* or something lighter like a container using *LXC* or *runC*.
|
||||
Containers have much less overhead in terms of boot time and storage allocation. This [Stack Overflow answer](https://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-virtual-machine) sums it up nicely.
|
||||
|
||||

|
||||

|
||||
|
||||
A hypervisor such as [Proxmox](https://www.proxmox.com/en/proxmox-ve/get-started) can be installed in minutes on a new machine. It provides a web interface and a straight-forward way to spin up new VMs and containers. Even if your plan is to run mostly docker containers, Proxmox can be a useful abstraction for managing VMs, disks and running scheduled backups. You can even run docker within an LXC container by enabling nested virtualization. You'll want to ensure that VT-d and VT-x are enabled in the BIOS if you decide to install a hypervisor to manage your virtualization.
|
||||
|
||||
@@ -46,7 +46,7 @@ You could certainly setup and manage your own VPN by using something like [OpenV
|
||||
|
||||
## Monitoring
|
||||
|
||||

|
||||

|
||||
|
||||
Monitoring can become an important aspect of your homelab after it starts to become something that is relied upon. One of the simplest ways to setup some monitoring is using [netdata](https://www.netdata.cloud/). It can be installed on individual containers, VMs, and also a hypervisor (such as Proxmox). All of the monitoring works out of the box by detecting disks, memory, network interfaces, etc.
|
||||
|
||||
@@ -54,7 +54,7 @@ Additionally, agents installed on different machines can all be centrally viewed
|
||||
|
||||
As mentioned above, [Uptime Kuma](https://github.com/louislam/uptime-kuma) is a convenient way to track uptime and monitor the availability of your services.
|
||||
|
||||

|
||||

|
||||
|
||||
## In Summary
|
||||
|
BIN
content/post/what-to-do-with-a-homelab/netdata.png
Normal file
After Width: | Height: | Size: 69 KiB |
BIN
content/post/what-to-do-with-a-homelab/proxmox.png
Normal file
After Width: | Height: | Size: 157 KiB |
BIN
content/post/what-to-do-with-a-homelab/uptime-kuma.png
Normal file
After Width: | Height: | Size: 117 KiB |