I don’t think much needs to be said. This is just an amazing watch!
KVM is a powerful tool for creating virtual machines but one of the issues that seem to be haunting people is; how the hell do you connect to the VM from another point on your network. Furthermore, with the development of Cockpit advancing so rapidly, Cockpit is becoming an amazing tool for home server management. Sure, there are a lot of images where direct port management to localhost is perfectly fine, and the “containerized” VM serves its purpose well where no other access is required. But, in my case, what if you need a development environment, and you don’t want to have an entirely new machine.
My initial setup wasn’t successful as the VM was isolated behind the virtual bridge and because the gateway/router couldn’t explicitly define routes, it was impossible for other computers to see the bridge or the VM. Below is a simple network diagram that depicts my issue.
The behavior of this configuration was secure, but not what I needed. There were a few things I observed:
- PC to virbr0 ping was not successful
- PC to VM ping was not successful
- Server to virbr0 ping was successful
- Server to VM ping was not successful (I believe this was because of the Windows 10 firewall)
- VM to PC ping was successful
- VM to Gateway ping was successful
- VM to virbr0 ping was successful
- VM to Google ping was successful
I also noticed that when running nmap on the server, port’s 5900 and 5901 were only open to localhost. When I ran nmap on the ethernet device IP, these ports were closed. I assumed that without proper routing configured, the ports would only ever be accessible from the host machine. (Again, this is a great security feature that could be useful for certain containerized virtual machines)
First, I decided to ditch the idea of using VNC and went with RDP instead. The responsiveness is way better and it seemed like a more clean approach for a development/coding environment. This option requires that you enable remote connections in the. Windows 10 settings.
The network bridge features that KVM and Cockpit deploy is very secure and utilizes good firewall protocols to protect your equipment. The one method I found that allowed me to get bypass these limitations was a direct attachment to a secondary NIC. I know this probably isn’t the first choice that everyone has, but after about a week of iptables, ebtables, and other various firewall management, this was the easiest configuration and allowed the VM to tap directly into the host network making it accessible from anywhere.
There are a few Windows 10 firewall features that will also need to be disabled so that your host machine and other devices on the Network will be able to see your VM. (Here will help you turn off the Windows Defender firewall)
Once Cockpit, libvirt, virt-install, bridge-utils and ebtables are installed properly, then you should be able to proceed with the setup.
I had two devices configured on my network; the first is the primary ethernet card. The secondary device is the one I configured for the direct attachment. Once your VM is installed and running, you can disable the default bridge network.
Navigate to the Virtual Machine’s Network Interface settings tab. I deleted the initial network device and created a new one. The new device interface type is Direct Attachment. The Source was the secondary ethernet card and the model was the e1000e. After you restart your virtual machine the changes will take effect.
To confirm everything is working properly, just open cmd in your Windows VM, and check the IP address to make sure that the gateway is your router on the host network and not a bridge IP address.
Static IP addresses are very useful on networks where a lot of devices are managed and/or you need to track specific devices for any reason. In my specific case, I have a multi-purpose server where I manage specific rules related to port management. The easiest application for port management is to assign a static IP.
In linux, there are various different network management tools available. In my opinion, the most intuitive tool for local system IP address management for a server is dhcpcd as it is very simple to use and gets the job done.
I appended the following snippet to the bottom of /etc/dhcpcd.conf which allowed for static assignment.
static domain_name_servers=22.214.171.124 126.96.36.199
podman run -dt -v /srv/hassio:/config:Z -v /etc/localtime:/etc/localtime:ro --net=host -d docker.io/homeassistant/home-assistant:latest --name=home-assistant
When most pods are configured, I would recommend using specific port management instead of the host network. However, since Home Assistant is exclusive to port 8123, this would be one of those exceptions that shouldn’t matter.
There has been a substantial amount of progress made on the Envoi Project. The setup page is now completely functional and requires users to complete the setup prior to using the platform. Other things included are:
- Password encryption using Argon2i (requires PHP 7.2)
- Proper password verification for sessions
- Upgrade to Bootstrap 5 (alpha)
- User settings manipulation
- Dynamic HTML class for page creation (work in progress, but functional)
- Admin panel functionality
- CRUD model for posts (Create, Remove, Update, and Delete)
- All posts are sorted and posted on the main page
While there is a long road ahead, the baseline is coming together very nicely. My goal is to clean up the backend, get the admin panel completed, and begin the API integration very soon.
Add posts page
View posts page
I have started working on something that I think is interesting. There aren’t enough flat-file blogging platforms around that support full integration with social media. I have decided to create my own version of this with the Envoi Project. This project is currently hosted on GitHub, but will soon have its own website.
The idea is to focus on centralized content sharing. No matter what type of team or group you are trying to share, you will be able to reach everyone with a single post.
Another huge topic I want to focus on is security. Since you will be syncing your social media with Envoi, securely storing your credentials is very important.
The project is in an infancy stage at the moment, but I am hoping to gain some traction soon and get a working project released before the end of the year.
If you are interested, follow the project at GitHub.
Let’s Encrypt offers a great service of offering self-signed SSL certificates for your self-hosted websites. Using these certificates are fairly easy, and when you add cron jobs into the mix, you don’t have to worry about completely stopping your web services to renew your certs.
If you don’t have ‘certbot’ installed yet, install through your distribution of choice. Then run the following commands (pay attention to the parts that require your actual information).
$ sudo systemctl stop [INSERT WEBSERVICE HERE]
$ sudo certbot certonly --standalone --email [EMAIL-ADDRESS] -d thebytes.net,www.thebytes.net,[ALL OTHER SUBDOMAINS]
If all goes according to plan, then all of your certificates will be generated under the first name in the run. You will get a congratulations message and you can check if they exist by looking in
/etc/letsencrypt/live/ for a folder named after the site.
The last thing you need to do is create a small script that your cron jobs can execute to automatically update the certificates. I created a file in the monthly cron folder for this exact requirement.
$ sudo nano /etc/cron.monthly/update-certbot
$ sudo nano /etc/cron.monthly/update-certbot
$ sudo chmod +x /etc/cron.monthly/update-certbot
certbot renew --force-renew
Save the file with the above lines, and restart your web service. Your certbot SSL certificates will now renew monthly.
Yeah, a Minecraft server… Probably one of the most annoying games that most children are completely addicted to. The issue I have with this game is the requirement for an Xbox Live account in order to play on a server. Not the traditional online server, but rather the local server. Like most parents, I’d like to have a little control over what my kids do on the internet, and playing a game with strangers at their age isn’t something I’m ready for. And, since they both enjoy playing together but still want to play in the same world when each other aren’t around, having to self-host a local game doesn’t seem to solve their problem.
So, I set out on a mission to find the best way to solve this. The solution seemed simple, host a server and bypass the Microsoft requirement so I don’t have to give them an Xbox account. This wasn’t as much of a problem as I had anticipated based on what options are provided from the Bedrock Server edition.
Simply switching ‘online-mode’ to false in the server.properties allowed local server connections. The benefit is that no outsiders can join because I control port forwarding.
My choice for server was the Bedrock edition because of the simplicity and ease of setup coupled with the basic configuration. Another great benefit was the ability to take on of the save files from their tablets and upload it as a server world (so they didn’t have to “start over”).
Installing on Arch Linux was pretty intuitive. I downloaded the server files from Mojang’s website, unzipped it to my /srv folder and launched the server (from within ‘screen’).
In the default folder is the properties file, that was easy to configure as well. I changed all of the game settings for the server to match one of the world’s they created (seed, name, difficulty, etc)and FTPed the files to the ‘worlds’ folder. The last thing I did was change the settings to disable online mode. This allowed them both to join without having an Xbox account.