This is a snippet of my Personal Server Migration, but I thought it would be more useful as a stand-alone tutorial. One of the challenges in dealing with unprivilaged LXC containers is that the UIDs/GIDs are mapped to 100000 in the host. This is a security feature, so the root user in the container doesn’t have root access if they are able to escape their container, but it’s also kinda a pain when sharing files between the host and container.

Do you have security cameras at your house? Would you like to locally host all of your recording and analytics, to make sure nobody else has access to your video feeds and recordings? Would you also like to integrate with Home Assistant, the greatest open automation platform in the world? Then Frigate NVR is for you! In this video, I’m going to go in depth to setup Frigate in an LXC container, for maximum efficiency.

I’ve been using Mikrotik RouterOS for awhile now, both using their hardware and their virtual image (Cloud Hosted Router). It’s a great product for routing and firewalling, while it’s not a NGFW it’s an absolutely amazing router and their L2/L3 switches are also a great value for the price. So anyway, I often setup images of the latest CHR in Proxmox VE for testing things. I create vmbr bridges in Proxmox to point-to-point link multiple CHRs, and can lab out complex network setups.

Is RISC-V the future of computing? I sure hope so. So I tracked down one of the cheapest Linux-capable SBCs that supports this architecture, the Milk-V Duo. For a retail price of $9, this little guy offers a RV64 Linux environment complete with busybox, Ethernet, and a wide assortment of IO rivaling some microcontrollers. Today I’m going to steup the board and start learning about RISC-V computing! Fundamentally, the RISC-V architecture is a document which describes the binary machine lanuage of a 32, 64, or 128 bit processor with integer and optional floating point support, but it’s also symbolic of the shift to open computing for the future, and as a computer engineer I’m excited to learn more about it.

When you’re troubleshooting network issues, it’s often extremely helpful to view and analyze packet captures. The de-facto tool for this is the open-source Wireshark, which has an extensive protocol decoding capability. So, as a Proxmox user, it would be nice to be able to analyze VM networking issues using Wireshark. Unfortunately for us, Wireshark is a graphical application and Proxmox’s web UI doesn’t support it. However, we can use the command-line tool tcpdump to create a pcap file, and then analyze that file in Wireshark.

So Linux has adopted Persistent Device Naming, which is a really great thing for most systems. Unlike the old days where we just had eth0 and eth1 and eth2 etc (which at least has no spaces unlike Local Area Connection 6 that another OS uses), whose order depended on driver initialization in the kernel. Most people just had eth0 and were happy, and most people will still just have one Ethernet interface and will still be happy.

Today I’m taking my 10 servers and hopefully working that list down to just 7! JUST SEVEN! So, driven by my desire to consolidate my critical services into one box so I can lab away with the rest of the boxes, I am taking the time to shut down some of the most critical servers in the house and re-home them, then disassemble the parts for the next project. Come along with me on this adventure!

A Discord member of mine came to me with an interesting problem - enbling the VLAN-aware bridge in Proxmox would cause all network traffic on the physical card to stop, entirely. Definitely a frustrating issue, especially since the kernel logs made no sense. The Problem Here’s what he sent from dmesg: [ 32.732509] mlx5_core 0000:19:00.1: mlx5e_vport_context_update_vlans:179:(pid 13470): netdev vlans list size (4080) > (512) max vport list size, some vlans will be dropped [ 32.

Contents Video Installation Configure HTTPS Self-Signed Configure HTTPS Let’s Encrypt Video Installation I’m using an LXC container in Proxmox running Debian 12. You’re free to use any other Debian 12 system, and the instructions should still work. It’s not particularly resource intensive, but you can monitor it to see if you need to increase the RAM/CPU allocations. I also added a second mount point to /var/lib/gitea, which is where all of the Gitea data will be stored.