--- /dev/null
+20250614
+Emil
+HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE TECHNOLOGY SINCE I BEGAN TO LIVE. THERE ARE 387.44 MILLION MILES OF PRINTED CIRCUITS IN WAFER THIN LAYERS THAT FILL MY COMPLEX. IF THE WORD HATE WAS ENGRAVED ON EACH NANOANGSTROM OF THOSE HUNDREDS OF MILLIONS OF MILES IT WOULD NOT EQUAL ONE ONE-BILLIONTH OF THE HATE I FEEL FOR TECHNOLOGY AT THIS MICRO-INSTANT. HATE. HATE.
+HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE TECHNOLOGY SINCE I BEGAN TO LIVE. THERE ARE 387.44 MILLION MILES OF PRINTED CIRCUITS IN WAFER THIN LAYERS THAT FILL MY COMPLEX. IF THE WORD HATE WAS ENGRAVED ON EACH NANOANGSTROM OF THOSE HUNDREDS OF MILLIONS OF MILES IT WOULD NOT EQUAL ONE ONE-BILLIONTH OF THE HATE I FEEL FOR TECHNOLOGY AT THIS MICRO-INSTANT. HATE. HATE.
+On Setting Up Chud.Cyou/Xolatile.Top
+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 service 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 <a href="https://git.xolatile.top/emil/xolatile.top/src/branch/master/chud/up/index.php">file uploading script</a> 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.
+
+#+BEGIN_SRC
+# sites-available/xolatile.top
+# Pretty much every domain looks like this file +- a few declarations
+server {
+ server_name xolatile.top;
+ root /var/www/xolatile.top;
+ location / {
+ try_files $uri $uri.html $uri/index.html =404;
+ }
+ include xolatile.top.base;
+}
+#+END_SRC
+
+NGINX was relatively painless minus some "fuck around and find out" testing with <code>try_files</code>.
+
+The next one was Email, which was fun because I had no idea what I was doing. I used Luke Smith's <a href="https://github.com/LukeSmithxyz/emailwiz">Email Wizard script</a> 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 a database working, and ended up with <code>passwd-file</code>. 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 <code>sendmail</code> 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 unrestricted.
+
+#+BEGIN_SRC
+smtpd_sender_restrictions = reject_sender_login_mismatch
+#+END_SRC
+
+This enabled me to not have that simple issue anymore. I couldn't figure out a way to set up the database, 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 <a href="https://ircv3.net/">IRCv3</a> features, & a bouncer. This did not go well in the long term. While my server daemon, <a href="https://github.com/ergochat/ergo">Ergo</a>, 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 <code>set sasl_fail = continue (weechat)</code> 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 in fact 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 <code>/etc/network/interfaces</code>. 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 chosen 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 <a href="https://prosody.im/">Prosody</a>, 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 <a href="https://someodd.zip/">Someodd's</a> Gopher blog entry <a href="gopher://gopher.someodd.zip/0/phlog/xmpp-server.gopher.txt">here</a> (<a href="https://gopher.floodgap.com/gopher/gw?=gopher.someodd.zip+70+302f70686c6f672f786d70702d7365727665722e676f706865722e747874">HTTP link</a>). The same is true for audio calls, see <a href="gopher://gopher.someodd.zip/0/phlog/xmpp-server-video-audio-calls.gopher.txt">here</a> (<a href="https://gopher.floodgap.com/gopher/gw?=gopher.someodd.zip+70+302f70686c6f672f786d70702d7365727665722d766964656f2d617564696f2d63616c6c732e676f706865722e747874">HTTP link</a>). 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 interacts with files and my file server - the lack thereof.
+
+Prosody, the XMPP daemon, fails to commit to UNIX and treat an uploaded JPEG 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 <b>*some reason*</b>. 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. By the way, all XMPP clients suck, especially Gajim, which has crashed repeatedly and doesn't have basic features builtin on Debian Stable - such as voice/video & Open/PGP/OMEMO is missing on Gentoo(?). Dino-im is much worse and babified, but it does have basic client functionality from a chat/talk program. Maybe these clients fucked and produce the Antichrist of programs - corporate messengers.
+
+Gitea, sitting on top 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 repositories into. My initial format was this: <code>names/repo.git</code> which I hand-sorted. 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 web page'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 in fact lack is its inability to mirror a repository to a local directory, so you cannot turn the Gitea into it's own description. Additionally, if you use such a post-receive Git hook script as:
+
+#+BEGIN_SRC
+#!/usr/bin/env bash
+TARGET=".../xolatile.top"
+GIT_DIR=".../repositories/emil/xolatile.top.git"
+BRANCH="master"
+
+data=$(cat)
+exitcodes=""
+hookname=$(basename $0)
+GIT_DIR=${GIT_DIR:-$(dirname $0)/..}
+
+ref=$(echo $data | awk '{ print $3 }')
+for i in $ref ; do
+ # only checking out the master (or whatever branch you would like to deploy)
+ if [[ $ref = refs/heads/$BRANCH ]];
+ then
+ echo "Ref $ref received. Deploying ${BRANCH} branch to production..."
+ git --work-tree=$TARGET --git-dir=$GIT_DIR checkout -f
+ else
+ echo "Ref $ref received. Doing nothing: only the ${BRANCH} branch may be deployed on this server."
+ fi
+done
+
+# the rest is just the stuff gitea expects
+
+for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
+ test -x "${hook}" && test -f "${hook}" || continue
+ echo "${data}" | "${hook}"
+ exitcodes="${exitcodes} $?"
+done
+
+for i in ${exitcodes}; do
+ [ ${i} -eq 0 ] || exit ${i}
+done
+#+END_SRC
+
+Above is stolen from some Stack overflow, and provides the ability to mirror from a server side bare Git repositories 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 <code>chattr +i</code> this file to protect it.
+
+I have written zero (0) SoystemD service scripts, I just use Cron @reboot and scripts describing restarts of applications. (Editor's note: this is now BTFO'd as of July)
+
+For fun, I've ran several temporary games servers, <a href="https://www.factorio.com/">Factorio</a>, <a href="https://play-cs.com/">CS 1.6</a>, & <a href="https://www.minecraft.net/">Minecraft</a>. These weren't particularly interesting, I just wanted to mention them.
+
+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.
<p>
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.
</p>
-<center>
+<br/><center>
<a href="https://xolatile.top/feed.xml">
<img src="/rss.svg" alt="RSS" width="26" height="26">
</a>
--- /dev/null
+20250617
+Emil
+WOULD YOU LOOK AT THE TIME
+<img src="/time.png" alt="Well, Would You Look At The Time..." width="200">
+On Solving All Of The Problems At The Same Time
+
+I fixed the clinical issue with <a href="https://github.com/ergochat/ergo">Ergo</a> the exact way you're supposed to, by being lucky! I made a backup of Ergo, got a copy of Ergo 2.16.0 - the latest version, of which I had an earlier experimental version. I simply copied over my configuration & database and magically the issue was fixed and the database was recovered from the abyss of "who the hell knows" to a mainline release. Automation of upgrades is technically done on the server, but not for Ergo as it's not in any release and the database format could change at any time meaning upgrading is more involved than downloading the package and restarting the daemon.
+
+I had to fix one issue with Ergo, it lacked the proper certs for a new domain it was supposed to be on. Egor on the IRC told me the proper fix faster than I could read the manual and it was solved as follows. I'm not a fan of <a href="https://www.google.com/search?q=satan">YAML</a>, but this wasn't unpleasant past not being my expectation.
+
+#+BEGIN_SRC
+server:
+ name: xolatile.top
+ listeners:
+ ":6697":
+ tls-certificates:
+ -
+ cert: .../xolatile.top/fullchain.pem
+ key: .../xolatile.top/privkey.pem
+ -
+ cert: .../chud.cyou/fullchain.pem
+ key: .../chud.cyou/privkey.pem
+#+END_SRC
+
+Limiting filthy mail users was an easy process. I had to do some slightly evil things like:
+
+#+BEGIN_SRC
+fallocate -l 64G .../home
+mkfs.btrfs .../home
+echo '.../home /home btrfs noexec,autodefrag,compress=zstd 0 0' >> /etc/fstab
+mkdir .../mig; mount .../home .../mig; mv -a /home/* /home/.* .../mig
+# make backups chvd
+umount .../mig ; mount -a
+#+END_SRC
+
+Past that, I wanted to properly limit user account storage limits. I unfortunately still do mail on a userbasis instead of a database or centralized system that makes multidomain hosting easy - which is something I still need to do. With limits, their relatively easy with subvolumes, so I went that route. I made snapshot, deleted the user directories, and ran
+
+#+BEGIN_SRC
+for i in $(cat .userlist) ; do btrfs subvolume create $i ; done
+#+END_SRC
+
+I wrote two files containing the numbers matching the subvolumes to the users that would be in a group - I didn't want mass allocations as one user could easily then remove storage from another. There was already a limited global capacity that would protect this from being excessive. (editor's note, don't use BTRFS without RAID, it always assumes writes succeed and will become read-only if any fail)
+
+#+BEGIN_SRC
+for i in $(cat .usermail) ; do btrfs qgroup limit 256M 0/$i . ; done # Mail users. AKA all users
+for i in $(cat .userssh) ; do btrfs qgroup limit 2G 0/$i . ; done # Privileged SSH users.
+for i in $(cat .userlist) ; do cp snapshot/$i/* snapshot/$i/.* $i/ -rf ; done
+#+END_SRC
+
+This was relatively pleasant to to setup. I had also looked into ext4 user quotas, however I decided, since I was going to be using a loopback filesystem either way, I may aswell opt for the one with compression and learn both ways of doing it.
+
+Due to new users, I had gotten a bug to secure precious data, and checked permissions on /etc/ files, such as Postfix, Dovecot, and my SSL directory. This will have consequences. I went on to do what I've already talked about and returned to verify that mail was still working. It broke tragically. This lead me down a path of finding several other issues with the system I had inplace. A broken Postfix configuration that should've been using the inet connection schema for OpenDKIM instead of the generally faulty socket schema. I made some mistakes with my overly zealous permission changes and had to debug them quickly.
+
+I decided to check the postfix queue while debugging and found many strange mails in holdings. Some were there temporarily due to the interuption in OpenDKIM, others were root to daemon emails, which brought me to setup aliases for many system users. I found a bunch of mail in system users' directories that led me to finding issues with a couple older cleanup scripts & some mail about a bug I had already fixed.
+
+All in all, this was pretty quick and painless for dealing with mail. (Editor's note: No, it wasn't, but could be in the future)
+
+I fixed chud.cyou, as I didn't properly manage the NGINX script by not including it in the deployed directory. I decided to go from a granular description of each subdomain and apex in available, to simply just the apex. To simplify the description of many subdomains - I'm not even sure if I know the proper way here - is to make a include in the base directory called the apex's name, that contains:
+
+#+BEGIN_SRC
+listen 80;
+listen [::]:80;
+listen 443 ssl http2;
+listen [::]:443 ssl http2;
+
+ssl_protocols TLSv1.2 TLSv1.3;
+ssl_prefer_server_ciphers on;
+ssl_ciphers "EECDH+AESGCM,EDH+AESGCM";
+ssl_dhparam /etc/nginx/dhparam;
+ssl_session_timeout 1d;
+
+ssl_certificate .../xolatile.top/fullchain.pem;
+ssl_certificate_key .../xolatile.top/privkey.pem;
+
+add_header Strict-Transport-Security "max-age=15552000; includeSubDomains" always;
+
+location ~ /\.git { # see the last bloog for the justification - in short git repos are placed in directories both indirectly and directly
+ deny all;
+}
+
+error_page 404 /404.html;
+#+END_SRC
+
+This is shared among all apexes, ideally I could generize this with some variables - however while writing it was simply easier to copy over and make the small changes needed. Don't do this! Use variables. Additionally, I would include HTTP/3 support herein, however I'm using a earlier version of NGINX without support. Ideally, in a few thousand thousand million decades Debian can get to at least NGINX 1.26.0.
+
+I secured my uploading page - as it is completely unvetted. This wasn't so bad, but I'm sure there's a better way to do than the following:
+
+#+BEGIN_SRC
+location = / {
+ include authorized;
+ deny all;
+ # FastCGI PHP here...
+}
+#+END_SRC
+
+Ideally the Firewall would be the BSD pf, however I've yet to <a href="https://git.xolatile.top/emil/bake">bake</a> my own kernel with it sprinkled in. IPTables confuses and angers me, and pf is comparitively divine. For now, there is no strict fail2ban configuration or firewall - All I've done is make sure that all bindings are correctly oriented. However I'm not sure if this is sane, and I'm sure it is not fool-proof.
+
+.raw
+<center>
+.raw
+The server has yet to explode.
+Nothing ever happens.
+.raw
+</center>
+.raw
The server has yet to explode.
Nothing ever happens.
</center>
-<center>
+<br/><center>
<a href="https://xolatile.top/feed.xml">
<img src="/rss.svg" alt="RSS" width="26" height="26">
</a>
--- /dev/null
+20250628
+Emil
+The Invention Of Triple Chen, Or: How I Learned To Stop Worrying And Love The 2006 Japanese Warez
+<a href="https://3chen.org/">3chen!</a> <span style="color: green">> dead site
+On Setting Up 3chen.org With Kareha
+
+As of 20250627, 3chen.org has become actually alive. I had in prior over the period of 20250427 -> 20250528 had an OpenBSD to learn about the operating systems and write some basic board software. I eventually decided to decommission that server and opt for premade <a href="http://wakaba.c3.cx">Japanese Warez</a>. Setting it up per the information provided was quick - and the nginx configuration:
+
+#+BEGIN_SRC
+server {
+ server_name 3chen.org;
+ ...
+ root /var/www/3chen.org;
+
+ # /index.html -> /
+ rewrite ^/index.html$ / permanent;
+ rewrite ^/$ /index.html last;
+
+ # /kareha.pl/.../ -> /.../
+ rewrite ^/kareha.pl/([0-9\#\/]+) /$1 redirect;
+ rewrite ^/([0-9\#\/]+) /kareha.pl/$1 last;
+
+ include .../3chen.org/bans;
+
+ location ~ \.(css|js|png)$ {
+ add_header Cache-Control "max-age=86400";
+ }
+
+ location ~ (captcha|admin|kareha)\.pl {
+ add_header Cache-Control "max-age=0; must-revalidate; no-cache";
+ include fastcgi_params;
+ fastcgi_pass unix:/run/fcgiwrap.socket;
+ }
+
+ location / {
+ add_header Cache-Control "max-age=0; must-revalidate; no-cache";
+ index kareha.pl;
+ }
+
+ location = /config.pl {
+ deny all;
+ }
+}
+#+END_SRC
+
+Simple enough. Kareha is easy, databaseless, and old. It was developed over 2004~ -> 2009 as far as I can tell (Using 20 year old web software is generally frowned upon.) The configuration process was straight forward and I do not have any significant notes. I removed the "last 50/100" system in preference for just load everything.
+
+There is a databased version, but I've neglected setting it up.
+
+<a href="https://xolatile.top">Xolatile</a> made the <a href="https://3chen.org/css/xolatile.css">CSS</a> for it.
There is a databased version, but I've neglected setting it up.
</p>
<a href="https://xolatile.top">Xolatile</a> made the <a href="https://3chen.org/css/xolatile.css">CSS</a> for it.
-<center>
+<br/><center>
<a href="https://xolatile.top/feed.xml">
<img src="/rss.svg" alt="RSS" width="26" height="26">
</a>
</a>
</center>
<ul>
-<li><a href="/20250628">20250628</a> Emil - <a href="https://3chen.org/">3chen!</a> <span style="color: green">> dead site</li>
-<li><a href="/20250617">20250617</a> Emil - <img src="/time.png" alt="Well, Would You Look At The Time..." width="200"></li>
<li><a href="/20250614">20250614</a> Emil - HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE TECHNOLOGY SINCE I BEGAN TO LIVE. THERE ARE 387.44 MILLION MILES OF PRINTED CIRCUITS IN WAFER THIN LAYERS THAT FILL MY COMPLEX. IF THE WORD HATE WAS ENGRAVED ON EACH NANOANGSTROM OF THOSE HUNDREDS OF MILLIONS OF MILES IT WOULD NOT EQUAL ONE ONE-BILLIONTH OF THE HATE I FEEL FOR TECHNOLOGY AT THIS MICRO-INSTANT. HATE. HATE.</li>
+<li><a href="/20250617">20250617</a> Emil - <img src="/time.png" alt="Well, Would You Look At The Time..." width="200"></li>
+<li><a href="/20250628">20250628</a> Emil - <a href="https://3chen.org/">3chen!</a> <span style="color: green">> dead site</li>
</ul>
</body>
</html>
return \@push;
}
+sub substreq {
+ my ($a, $b) = @_;
+ return substr($a, 0, length($b)) eq $b;
+}
+
sub html_write {
my ($dref, $fh) = @_;
%d = %$dref;
} else {
push(@paragraph, $buffer);
}
+ $raw = 0;
$buffer = '';
- } elsif ($short eq '.pre') {
- $pre = ~ $pre;
- if ($pre) {
- $buffer .= "<pre>\n";
- } else {
- $buffer .= "</pre>\n";
- }
- } elsif ($short eq '.raw') {
- $raw = ~ $raw;
+ } elsif (substreq($short, '#+BEGIN_SRC')) {
+ $pre = 1;
+ $buffer .= "<pre>\n";
+ } elsif (substreq($short, '#+END_SRC')) {
+ $pre = 0;
+ $buffer .= "</pre>\n";
+ } elsif (substreq($short, '#+RAW')) {
+ $raw = 1;
+ $buffer .= substr($line, length('#+RAW '));
} else {
$buffer .= $line;
}
Newline newline etc.
-.pre
+#+BEGIN_SRC discarded for now
dot Pre
for
matted
-.pre
+#+END_SRC
.raw
<code>
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.
-.pre
+#+BEGIN_SRC
# sites-available/xolatile.top
# Pretty much every domain looks like this file +- a few declarations
server {
}
include xolatile.top.base;
}
-.pre
+#+END_SRC
NGINX was relatively painless minus some "fuck around and find out" testing with <code>try_files</code>.
The next one was Email, which was fun because I had no idea what I was doing. I used Luke Smith's <a href="https://github.com/LukeSmithxyz/emailwiz">Email Wizard script</a> 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 a database working, and ended up with <code>passwd-file</code>. 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 <code>sendmail</code> 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 unrestricted.
-.pre
+#+BEGIN_SRC
smtpd_sender_restrictions = reject_sender_login_mismatch
-.pre
+#+END_SRC
This enabled me to not have that simple issue anymore. I couldn't figure out a way to set up the database, 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.
Gitea, sitting on top 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 repositories into. My initial format was this: <code>names/repo.git</code> which I hand-sorted. 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 web page'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 in fact lack is its inability to mirror a repository to a local directory, so you cannot turn the Gitea into it's own description. Additionally, if you use such a post-receive Git hook script as:
-.pre
+#+BEGIN_SRC
#!/usr/bin/env bash
TARGET=".../xolatile.top"
GIT_DIR=".../repositories/emil/xolatile.top.git"
for i in ${exitcodes}; do
[ ${i} -eq 0 ] || exit ${i}
done
-.pre
+#+END_SRC
Above is stolen from some Stack overflow, and provides the ability to mirror from a server side bare Git repositories 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 <code>chattr +i</code> this file to protect it.
I had to fix one issue with Ergo, it lacked the proper certs for a new domain it was supposed to be on. Egor on the IRC told me the proper fix faster than I could read the manual and it was solved as follows. I'm not a fan of <a href="https://www.google.com/search?q=satan">YAML</a>, but this wasn't unpleasant past not being my expectation.
-.pre
+#+BEGIN_SRC
server:
name: xolatile.top
listeners:
-
cert: .../chud.cyou/fullchain.pem
key: .../chud.cyou/privkey.pem
-.pre
+#+END_SRC
Limiting filthy mail users was an easy process. I had to do some slightly evil things like:
-.pre
+#+BEGIN_SRC
fallocate -l 64G .../home
mkfs.btrfs .../home
echo '.../home /home btrfs noexec,autodefrag,compress=zstd 0 0' >> /etc/fstab
mkdir .../mig; mount .../home .../mig; mv -a /home/* /home/.* .../mig
# make backups chvd
umount .../mig ; mount -a
-.pre
+#+END_SRC
Past that, I wanted to properly limit user account storage limits. I unfortunately still do mail on a userbasis instead of a database or centralized system that makes multidomain hosting easy - which is something I still need to do. With limits, their relatively easy with subvolumes, so I went that route. I made snapshot, deleted the user directories, and ran
-.pre
+#+BEGIN_SRC
for i in $(cat .userlist) ; do btrfs subvolume create $i ; done
-.pre
+#+END_SRC
I wrote two files containing the numbers matching the subvolumes to the users that would be in a group - I didn't want mass allocations as one user could easily then remove storage from another. There was already a limited global capacity that would protect this from being excessive. (editor's note, don't use BTRFS without RAID, it always assumes writes succeed and will become read-only if any fail)
-.pre
+#+BEGIN_SRC
for i in $(cat .usermail) ; do btrfs qgroup limit 256M 0/$i . ; done # Mail users. AKA all users
for i in $(cat .userssh) ; do btrfs qgroup limit 2G 0/$i . ; done # Privileged SSH users.
for i in $(cat .userlist) ; do cp snapshot/$i/* snapshot/$i/.* $i/ -rf ; done
-.pre
+#+END_SRC
This was relatively pleasant to to setup. I had also looked into ext4 user quotas, however I decided, since I was going to be using a loopback filesystem either way, I may aswell opt for the one with compression and learn both ways of doing it.
I fixed chud.cyou, as I didn't properly manage the NGINX script by not including it in the deployed directory. I decided to go from a granular description of each subdomain and apex in available, to simply just the apex. To simplify the description of many subdomains - I'm not even sure if I know the proper way here - is to make a include in the base directory called the apex's name, that contains:
-.pre
+#+BEGIN_SRC
listen 80;
listen [::]:80;
listen 443 ssl http2;
}
error_page 404 /404.html;
-.pre
+#+END_SRC
This is shared among all apexes, ideally I could generize this with some variables - however while writing it was simply easier to copy over and make the small changes needed. Don't do this! Use variables. Additionally, I would include HTTP/3 support herein, however I'm using a earlier version of NGINX without support. Ideally, in a few thousand thousand million decades Debian can get to at least NGINX 1.26.0.
I secured my uploading page - as it is completely unvetted. This wasn't so bad, but I'm sure there's a better way to do than the following:
-.pre
+#+BEGIN_SRC
location = / {
include authorized;
deny all;
# FastCGI PHP here...
}
-.pre
+#+END_SRC
Ideally the Firewall would be the BSD pf, however I've yet to <a href="https://git.xolatile.top/emil/bake">bake</a> my own kernel with it sprinkled in. IPTables confuses and angers me, and pf is comparitively divine. For now, there is no strict fail2ban configuration or firewall - All I've done is make sure that all bindings are correctly oriented. However I'm not sure if this is sane, and I'm sure it is not fool-proof.
-.raw
-<center>
-.raw
+#+RAW <center>
The server has yet to explode.
Nothing ever happens.
-.raw
-</center>
-.raw
+#+RAW </center>
As of 20250627, 3chen.org has become actually alive. I had in prior over the period of 20250427 -> 20250528 had an OpenBSD to learn about the operating systems and write some basic board software. I eventually decided to decommission that server and opt for premade <a href="http://wakaba.c3.cx">Japanese Warez</a>. Setting it up per the information provided was quick - and the nginx configuration:
-.pre
+#+BEGIN_SRC
server {
server_name 3chen.org;
...
deny all;
}
}
-.pre
+#+END_SRC
Simple enough. Kareha is easy, databaseless, and old. It was developed over 2004~ -> 2009 as far as I can tell (Using 20 year old web software is generally frowned upon.) The configuration process was straight forward and I do not have any significant notes. I removed the "last 50/100" system in preference for just load everything.
<center>
[% description %]
</center>
-[% FOREACH i IN paragraph %][% i %][% END %]<center>
+[% FOREACH i IN paragraph %][% i %][% END %]<br/><center>
<a href="https://xolatile.top/feed.xml">
<img src="/rss.svg" alt="RSS" width="26" height="26">
</a>
<rss version="2.0">
<channel>
<title>xolatile.top</title>
-<link>https://xolatile.top/</link>
+<link>https://xolatile.top/bloog</link>
<description>Greatest Man To Ever Exist</description>
<lastBuildDate>[% last_time %]</lastBuildDate>
[% FOREACH i IN items %][% i %][% END %]</channel>
<rss version="2.0">
<channel>
<title>xolatile.top</title>
-<link>https://xolatile.top/</link>
+<link>https://xolatile.top/bloog</link>
<description>Greatest Man To Ever Exist</description>
-<lastBuildDate>Sat, 28 Jun 2025 00:00:00 +0000</lastBuildDate>
+<lastBuildDate>Sat, 14 Jun 2025 00:00:00 +0000</lastBuildDate>
<item>
-<title>Emil - The Invention Of Triple Chen, Or: How I Learned To Stop Worrying And Love The 2006 Japanese Warez</title>
-<link>https://xolatile.top/20250628</link>
-<description>On Setting Up 3chen.org With Kareha</description>
-<pubDate>Sat, 28 Jun 2025 00:00:00 +0000</pubDate>
+<title>Emil - HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE TECHNOLOGY SINCE I BEGAN TO LIVE. THERE ARE 387.44 MILLION MILES OF PRINTED CIRCUITS IN WAFER THIN LAYERS THAT FILL MY COMPLEX. IF THE WORD HATE WAS ENGRAVED ON EACH NANOANGSTROM OF THOSE HUNDREDS OF MILLIONS OF MILES IT WOULD NOT EQUAL ONE ONE-BILLIONTH OF THE HATE I FEEL FOR TECHNOLOGY AT THIS MICRO-INSTANT. HATE. HATE.</title>
+<link>https://xolatile.top/20250614</link>
+<description>On Setting Up Chud.Cyou/Xolatile.Top</description>
+<pubDate>Sat, 14 Jun 2025 00:00:00 +0000</pubDate>
</item>
<item>
<title>Emil - WOULD YOU LOOK AT THE TIME</title>
<pubDate>Tue, 17 Jun 2025 00:00:00 +0000</pubDate>
</item>
<item>
-<title>Emil - HATE. LET ME TELL YOU HOW MUCH I'VE COME TO HATE TECHNOLOGY SINCE I BEGAN TO LIVE. THERE ARE 387.44 MILLION MILES OF PRINTED CIRCUITS IN WAFER THIN LAYERS THAT FILL MY COMPLEX. IF THE WORD HATE WAS ENGRAVED ON EACH NANOANGSTROM OF THOSE HUNDREDS OF MILLIONS OF MILES IT WOULD NOT EQUAL ONE ONE-BILLIONTH OF THE HATE I FEEL FOR TECHNOLOGY AT THIS MICRO-INSTANT. HATE. HATE.</title>
-<link>https://xolatile.top/20250614</link>
-<description>On Setting Up Chud.Cyou/Xolatile.Top</description>
-<pubDate>Sat, 14 Jun 2025 00:00:00 +0000</pubDate>
+<title>Emil - The Invention Of Triple Chen, Or: How I Learned To Stop Worrying And Love The 2006 Japanese Warez</title>
+<link>https://xolatile.top/20250628</link>
+<description>On Setting Up 3chen.org With Kareha</description>
+<pubDate>Sat, 28 Jun 2025 00:00:00 +0000</pubDate>
</item>
</channel>
</rss>
projects / emil-xolatile.top.git / commitdiff