I created this server because I wanted a server to fuck around with. It was created on 20250211.

It runs Debian Stable, on a VPS hosted on the Moon. It's primary functionality are the few public services that run on it. This includes HTTP, Email, IRC, XMPP, Git, & Mumble. I'll start with HTTP first, as it was the most painful.

I set HTTP up pretty quickly, with certbot as the certificate manager, and one daemon: Caddy. Later on I set up Mediawiki and a sevice requiring FastCGI. Caddy does support CGI, however I wasn't willing to install a source package for such a thing, hence I used NGINX. Apache way used for Mediawiki. This means I now had 3 HTTPDs. I had also installed lighttpd, for something I don't remember. Eventually I broke mediawiki when trying to install a different version of PHP, this resulted in all the images on the Mediawiki to be wiped. I eventually gave up on mediawiki and uninstalled Apache. PHP remained, but downgraded from the supposedly "better" version. PHP is still used in a file uploading script which I found on a random Gunthub page. All the actually "formal" PHP projects I couldn't figure out how to install any of them and went with the simple one.

Apache was nightmarish to interact with, but with the information I had at my disposal, my method was to simply just poke at the evil daemon inside of my server until it worked close enough to how I wanted. Dealing with NGINX was fine, as it is my current and only HTTPD, however I kept insisting on HTTP/3 because I considered it a decently valuable upgrade. Newer versions of NGINX support it via an option, however this version of Debian does not have such a thing. I used caddy to talk to NGINX only when I needed its decent set of feature.

NGINX was relatively painless minus some "fuck around and find out" testing with try_files.

The next one was Email, which was fun because I had no idea what I was doing. I used Luke Smith's Email Wizard script because I remembered watching a video from him about setting up a self-hosted mail server - and that script seemed very easy in my memory. Anyhow, it didn't work at first. Dealing with Dovecot's configuration was a pain because I tried everything to get databasing working, and ended up with passwd-file. Dealing with mbox vs. Maildir was lots of fun because it didn't make any sense, but eventually I got the system to use the correct sendmail from Postfix and my mail system could then curry local mail to external peers & vice versa. Setting up Spamd was actually very easy, the hardest part was testing and dealing with the minor configuration bugs along the way - doing the necessary parts of domain configuration was really easy. Luke Smith's script got me close enough to functionality that I fucked with Dovecot and Postfix enough to permit myself to send emails - from any address unrestrictly.

This enabled me to not have that simple issue anymore. I couldn't figure out a way to set up databasing, and considering my scale for this mail server was <10 people, and likely only 1-2 active users at any given time. The mail server functions, the only gripe I have currently is the authentication system, and the fact that it cannot be transported to FreeBSD. After making a temporary snapshot, I wiped and rebooted the server to play with and see if I could get FreeBSD as my server OS. It did not work out for mail especially, as using OpenSMTPd demostrated to me that I had no idea what I was doing. While trying to setup dovecot I nearly had a conniption because there was no way to install ARGON2I which was my choice of password hashing, meaning I had to reset everyone's password or have a copy - I had a copy of most user's randomly generated passwords in my personal KeePassXC DB as for their recovery. The idea of storing passwords in such a way is disgusting, however better than leaving them in plaintext on the server. I eventually got to the point where I switched to Postfix and had the ability to recieve mail, but not send it. Which I had experienced before setting up mail on linux, but I couldn't debug it before I simply decided to revert the snapshot.

Regarding IRC, it was decent, but I made some severe mistakes. I wanted an IRC server that was powerful in the way that it had everything melted together, including IRCv3 features, & a bouncer. This did not go well in the long term. While my server daemon, Ergo, does work, it has some issues such as being an experimental version rather than a stable upgradable release, and an database format that stores Nickserv data that I haven't recovered. While ergo works great and does what I want, I realize that it is archaic in the fact that I can't migrate away from it without causing serious issues. If I violently remove the database and upgrade many users will need to intervene with a setting like set sasl_fail = continue (weechat) to even automatically reconnect. This means everything is fine as long as I don't touch it, however I will eventually have to either do a breaking upgrade or recover the data and hope that it is infact compatible with a newer database or plaintext.

Restarting has bricked two VPSs for me, one was one I gave up on under Vultr, and the other was this server during an upgrade. I was trying to setup iptables as a firewall and I foolishly trusted a configuration detail added to /etc/network/interfaces. This was fine, however, because of something I initially disliked, VNC. Which is a video sharing(?) protocol that let me access the video console of the remote server and fix the issue that way. Redundancy aiding my stupidity. This issue was fixed within an hour and was harmless as my server isn't exactly in need of high uptime. Uptime, apart from those choosen periods of downtime is relatively high, minus me forgetting to enable a service at boot & test it or simply not have restarted a service correctly after making a configuration change. More than half of this server has been guess and check, which is unproductive but it has gotten it to the point of this page delivering correctly.

Mumble and XMPP were completely opposing experiences. Mumble was click and go, install it, run it, connect this way and do that and this, done. XMPP, as in Prosody, was utterly confusing at times and still doesn't work how I want. I started off with installing it, running and getting connected, that part was easy, but I couldn't figure at first how to setup voice/video calls, filesharing, and a IRC bridge called Biboumi. The voice calls were actually relatively easy and only took two attempts, with the second being added by Someodd's Gopher blog entry here (HTTP link). The same is true for audio calls, see here (HTTP link). I've yet to verify the existence of video call functionality due to the lack of a (virtual) webcam. The file server was annoying because how it iteracts with files and my file server - the lack thereof. Prosody, the XMPP daemon, fails to commit to UNIX and treat an uploaded JPG as a file in a directory, a directory that I could mount over the network, locally, or symlink to, achieving a file server that provides the file that I could then specify the nature of the URL to Prosody and be done with it. No, this was not the case. Instead, the default configuration routes through port 5281, and shares links through there via my specific link, which cannot be the apex domain for *some reason*. The only method to have a "normal" port is to do some HTTPD routing magic with it through NGINX, which Someodd provided some information on however I couldn't get it to work on my system. I got the IRC gateway, Biboumi working to a percentage of 99%. Which means it doesn't work at all. I'm currently hoping to have the expert webshitter Someodd look at it and hopefully tell me what configuration detail to change by one character to make the thing go 1% further.

Gitea, sitting ontop of the reverse proxy, is a system to manage Git repositories from a browser and provide basic CRUD & authentication to users. This wasn't my first choice. At first I just wanted SSH keys, un/restricted user accounts, and Git repositories at a publicly accessible HTTP address. However, this quickly showed itself unused, so I decided to provide the more generally usable Gitea, which was very painful to actually import Git repos into. My initial format was this: names/repo.git which I handsorted. However, Gitea did not automatically import these into those existing users. It did however provide information for them existing in the admin UI. I eventually found that and I had to write a script to say "YES" to all of them, because of the webpage's shittiness, it would send the POST and reload the page at incredibly slow speeds and there was no way to select several at once or a "yes to import everything." Gitea has very poor tooling. The CLI is utterly shit, and offers no useful features in the general sense. Gitea isn't the worst from the commandline as you can basically pretend it doesn't exist past your initial setup. In the past I've met others with issues involving GPG setup and SSH setup - to be fair this was over TOR - which was exceptionally annoying to deal with as a user and an admin. It's not the best interface by far, but it loads without Javascript and is relatively unassuming. One feature it arguably could use and does infact lack is its inability to mirror a repo to a local directory, so you cannot turn the Gitea into it's own description. Additionally, if you use such a post-recieve Git hook script as:

Above is stolen from some Stackoverflow, and provides the ability to mirror from a server side bare Git repo to a directory. Very useful. Ideally this would a feature into the crud, but it hardly matters as it is strictly to git that this is important. You have to chattr +i this file to protect it.

Overall setting this server up hasn't been the most painful thing ever, but it was an interesting experience and I enjoyed what I've done with it so far. It can't possibly get worse than this, unless I start using Windows or very old versions of Linux. This document wasn't meant to be very well written, it was not written over a long period of time - I just wanted to put what I generally remember about the last 2 1/2 months on a page.