Home on juni's blog ٩(◕‿◕｡)۶

Tracking & Syncing my dotfiles!

Sun, 22 Jun 2025 00:00:00 +0000

.dotfiles or… (.)²files?

- Using Git + Github, & tracking dotfiles with an alias.

… as mentioned on the ever-wise Arch Wiki.

# 1. Create a bare Git repo to track dotfiles
git init --bare ~/.dotfiles

# 2. Create an alias to simplify dotfiles management.
# Tells (/usr/bin/git) to link the git alias directory you just created to your real .config/
alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'

# 3. Hide untracked files in ~/ from cluttering "git status"
dotfiles config status.showUntrackedFiles no

Setup & communicate with this repo via ssh, authenticating with a local private key.

# 4. Generate SSH key for GitHub auth (if you haven't got one already)
ssh-keygen -t ed25519 -C "you@example.com"
ssh-add ~/.ssh/id_ed25519

# Add the value of ~/.ssh/id_ed25519.pub as an entry in your Github --> Settings --> SSH & GPG Keys, via cat + copy-pasting, or however you'd like.

# 5. Force git on your machine to always push to github with SSH instead of HTTPS
git config --global url."git@github.com:".insteadOf "https://github.com/"

# 6. Set upstream branch as origin main & push via ssh!
dotfiles push --set-upstream origin main

then, upon changing my dotfiles, can push to github with:

dotfiles status
dotfiles add XXXXX
dotfiles commit -m "Update shell and Hyprland config"
dotfiles push (to remote, via SSH)

- or… using a dotfiles manager, comme `chezmoi`.

… which is a tool that essentially creates a copy of your dotfiles folder outside of your /home directory (e.g. in ~/.local/share/chezmoi/private_dot_config/) to act as a place to stage, synchronise (with git) & manage changes to your local dotfiles.

I think of it as a remotely-connected playground for your dotfiles, to mess with them, pull them from remote repos etc., before applying the changes (via symlinks, copying, or templating) into your local home directory (e.g. ~/.config).

- To install:

sudo pacman -S chezmoi
chezmoi init
Check what is & isn’t managed by chezmoi with chezmoi managed/chezmoi unmanaged.
… then follow steps on this tutorial to connect to your repository & get your first commit. I’m using chezmoi to push to the same remote dotfiles repo created above, and so just rebased my changes (overwriting the old, chezmoi-less dotfiles from above) to keep it nice and clean.

- Editing your dotfiles & using `chezmoi`:

You can edit your dotfiles in multiple ways with chezmoi.

(`RECOMMENDED`) You can work and make changes within the locally-created `chezmoi` copy of your `dotfiles`, apply them locally, and push them to remote repo once done.

Navigate to your chezmoi dotfiles copy with chezmoi cd (you should be able to tell that it’s the chezmoi-managed copy - e.g. it’s called private_dot_config for me).
Then, once you’ve made changes and are ready to see them/apply them to your real dotfiles (e.g to see changes live made to your desktop GUI), use chezmoi status to list all changed files, chezmoi diff to check any changes, and chezmoi apply to copy the chezmoi-managed files over to your local dotfiles. Now, you should see any changes made reflected on your live system (after reloading the given services, if applicable)
Then², once you’re ready to update your remote repo with your changes, go through the usual git commit process within the chezmoi-managed directory.
git status to see all changed files (within the chezmoi-managed copy)
git add . (or whatever files you want to add)
git commit -m "cool changes
git push origin main

However, you also have the option of…

…making changes to your dotfiles normally (i.e. not within the `chezmoi`-managed copy of your `dotfiles`)

So, after you’re finished a particularly spicy ricing session, you can run:

chezmoi status - to see what’s changed between your local dotfiles and chezmoi’s copy.
chezmoi add ~/.config/path/to/file.config - to add any locally-changed files to chezmoi’s tracked & git-managed copy.
chezmoi apply -v to write these local changes to chezmoi's working copy of your dotfiles.
Then switch to the chezmoi-managed copy with cd chezmoi, and go through the usual git commit process to update your remote repo if desired.

chezmoi, importantly, allows you to do some of the following cool things:

Set up your dotfiles on a new machine with a single command: chezmoi init --apply https://github.com/$GITHUB_USERNAME/dotfiles.git (public repo - private requires other methods)
Using templates to manage dotfiles between different machines/distros.
Encrypting your dotfiles using secrets from your password manager

Git CLI Basics - branching & stashing!

Tue, 22 Apr 2025 00:00:00 +0000

Smol Objective: Revisiting branching, checkout’s, and stashing!

Via: creating a new local branch to save recent experimental changes on, publishing the branch to a remote Github repository, and then switching back to the functional, remote main branch locally. Oh, and stashing changes as I switch between the two to compare.

- Branching & Checkouts

# Check the current status (ensure connected to remote origin)
git status                      

# checkout - create (argument -b) and switch to a new branch.
git checkout -b branch-name 

# Stage all changes at the HEAD of this new branch (or select specific files/changes by specifying them, instead of '.')
git add .

# Commit changes
git commit -m "Describe changes here" 

# Publish changes to upstream branch on Github
git push origin branch-name

- in the wild:

To switch back to the remote main branch locally (which will also change your working file tree in VSCode to match what’s on main), use:


# Switch back to the main branch
git checkout main

# Verify you're on the main branch
git branch                      
# or
git status

- Stashing

To briefly save your working changes, you can “stash” them. Useful when you’re switching between branches or pulling from a remote repository, and don’t want to commit your current changes yet.

## saves your modified tracked files and reverts the working directory to match the HEAD commit (a pointer indicating the current commit your directory is based on).
git stash 

## stashing, with a message:
git stash save "message here"

## list current stashes with:
git stash list

## apply them to your current working directory with:
git stash apply stash@{index}

## "pop" them - aka, apply the stash & then remove it from the list
git stash pop 

## "drop" them - aka, remove them from the stash list
git stash drop stash@{index}

## clears all stashed changes
git stash clear

Minecraft Server From Scratch (Proxmox LXC, Docker Compose + itzg)

Sun, 13 Apr 2025 00:00:00 +0000

Just a smol lil guide for myself to set up a minecraft server from scratch, as I cannot count the number of times I’ve had to re-learn this when I migrate from server to server.

I’ve opted for services that should (for the most part) be supported long-term and are relatively secure & lightweight. However, as any good netizen should do, please take my advice with a granule of sugar…

- Set up `LXC` Container in Proxmox

Create new container in proxmox using the Ubuntu 24.04 LXC image (or your desired flavour, noting commands may differ slightly depending on package managers) - allocating at least 4GB RAM & 2-4 CPU cores to the machine.
Once logged in, create a sudo-enabled user with: adduser myuser Set the password, then: usermod -aG sudo myuser su myuser
Harden SSH - ensuring the following values are changed & set within /etc/sshd_config.

Port 22
PermitRootLogin no
MaxAuthTries 4
MaxSessions 2

PubkeyAuthentication yes

PasswordAuthentication no
PermitEmptyPasswords no

KbdInteractiveAuthentication no

UsePAM no

X11Forwarding no
PrintMotd no
ClientAliveInterval 600
ClientAliveCountMax 2

Add your local machine’s ed25519_pub key to the ~/.ssh/authorized_keys file (creating it, if it doesn’t exist). This will allow key-based login for user myuser.

Be careful not to lock yourself out here, test with password based login first! For example, by setting PasswordAuthentication yes and logging in, before changing it to PasswordAuthentication no.

Ensure DNS is setup properly - check /etc/resolv.conf. Basic internet functionality can be tested & achieved by having the line nameserver 8.8.8.8, but configure to your use case.
Login from local machine with ssh myuser@XXX.XXX.XXX.XXX. Test your sudo privileges with sudo ls /root.
Lock root account with sudo passwd root -l.
Run sudo apt update && sudo apt upgrade -y.
Find the current IP with ip -a (typically on the eth interface) and set it as static (in proxmox and/or on your router).

- Install Docker (Compose) & itzg Minecraft Server

Install Docker Engine - follow steps (distro-specific) here, as you will need to configure your package repository properly.
Install Docker Compose - following steps here. sudo apt install docker-compose worked for me.
Make a new directory for the Minecraft server to sit in: ~/minecraft.
Inside, create a docker-compose.yml, generated with something like setupmc.com to specify server version, plugins, etc.

My example docker-compose.yml file is below (for a 1.18 server, replacing Timezone (TZ) accordingly):

services:
	mc:    
		image: itzg/minecraft-server:java17    
		tty: true    
		stdin_open: true    
		ports:       
			- "25565:25565"     
		environment:       
			EULA: "TRUE"       
			TYPE: "PAPER"       
			VERSION: "1.18"       
			PAPER_CHANNEL: "experimental"       
			MEMORY: "4096M"       
			MOTD: "welcome, traveller, to an older time...
			USE_AIKAR_FLAGS: "true"       
			TZ: "[YOUR-TIMEZONE]"     
		volumes:       
			- "./data:/data"

Start the container from within the same directory as docker-compose.yml with sudo docker compose up -d. After the image is finished being pulled from the itzg minecraft server repo, watch the logs as the server starts with sudo docker compose logs -f.
If you get an error message about the “class file version” after starting the server, check this table to see which Java version corresponds to the respective class file version. Then adjust the Docker image tag in the setupmc.com](https://setupmc.com/java-server/) configurator accordingly.
To stop the server, run sudo docker compose down.
To migrate a world save file over (if applicable), copy the following files (at minimum) over from your old server (using something like scp, or via a GUI if you install something like webmin):
- server.properties
- /world
- /world_the_nether (if exists)
- /world_the_end (if exists)
- whitelist.json (if applicable)

Ensure to tweak server-specific configurations within server.properties if needed!

As you’re running through docker, it should handle the local network ports on the lxc for you nicely (if on a fresh linux install). Also, before I continue, it would be remiss of me to exclude the obligatory ***do this so at your own risk, and please consider the below server hardening methods:
- not running the server as root! (not a problem if you followed the guide above)
- general server tips & links to hardening methodology
With that out of the way, now time to open up a port on your local router/modem. For me, I’ve opted for a little “security through obscurity” (a contentious topic, but given my threat model) by mapping my router’s external port, 43456 to the default minecraft listening port (25565 - specified in server.properties) on my lxc machine:

Additionally, I’ve set up a DNS A record for the domain I own to point at my router’s public IP, so I can access my server (and share it) with my-domain:43456.

Now, you should be all up and running! :3

- For any further troubleshooting

Authentication Methods - A Deep(ish) Dive

Thu, 27 Feb 2025 00:00:00 +0000

Here lies the ramblings of a madwoman; bumbling her way around in the darkness in an attempt to understand the wide world of websec…

… in the absolute broadest of strokes:

Token-based (JWT):
- Authentication state is stored on the client (local/session storage) in the form of a token.
Session-based:
- Authentication state is stored on the server’s database.

Now, let’s go a little deeper, shall we?

- JSON Web Tokens (JWT)

- How it works:

Client sends credentials to sever
Sever generates a JWT based on credentials, and provides it to user (following below structure).
- For example, using the RS256 algorithm, the generated JWT is signed with the server’s private key, and verified by the client with the server’s public key. (JWT structure - https://jwt.io/)
The client receives theJWT, which is stored in the client’s local storage/session storage/as a cookie. AKA, the state lives as a token on the client, instead of on the server (as is with typical session-based authentication).
- Note: the client also verifies the JWT with the server’s public key, if using the RS256 algorithm.

- JWT-based Authentication Drawbacks

State is stored client side & can thus be dissected & manipulated
Vulnerable to being accessed/stolen via XSS attacks
Can be vulnerable to CSRF based on how the JWT is stored & sent.
- Vulnerable to CSRF: if the JWT is stored as an HTTP-only cookie that is passed to the server with every request.
  - to mitigate this, use SameSite=Strict & additional CSRF tokens with each request.
- NOT (as) vulnerable to CSRF: if the JWT is stored in the local/session storage, meaning it’s not sent with every request. Instead, it must be manually passed into the request header (e.g. Authorization: Bearer <token>) when authorising.
No server-side revocation - token is valid until it expires.
Token expiration management can be complex
Data is base64 encoded, not encrypted - so sensitive data should never be stored in JWTs, as anyone with the token can decode and read its contents.

- How it works:

Client provides credentials to the server
Server generates a unique session ID for the client and stores the session details & state in its local database.
Server sends the session ID back within an HTTP-only cookie, which is stored in the client browser’s cookie jar (a storage for key-value pairs - how cool is this name though-)
The client sends this cookie back with subsequent requests, & each time, the server has to check the session against the value in the server’s database.
Upon logout, session ID is cleared from both the client side and server database.

- Session-based Authentication Drawbacks:*

Vulnerable to CSRF (attackers using session IDs to perform actions on behalf of the user) as cookies are sent automatically with every request.
Processing power & complexity that increases with scale: as sessions have to be generated, stored & managed on the server’s database.
Domain Restriction: Cookies are domain-specific, making cross-domain authentication difficult without additional configurations like CORS (Cross Origin Resource Sharing) or third-party cookies.
- CORS: when a web app makes a cross-origin request (e.g. example.com to api.example.com), the browser sends an additional CORS preflight request to check if the server (api.example.com) allows the cross-origin request. If it does, it needs to respond with the appropriate CORS headers.

A brief comparison…

credit where credit is due, this is from ChatGPT, but it was used as a sanity check after I did the bulk of the manual research to build a basis of understanding. so, what am i saying by this? take… all of it with a grain of salt lol-

Helpful Resources:

Branching out with a previous commit in a GitHub project

Sun, 12 Jan 2025 00:00:00 +0000

just a lil guide for my future self when i inevitably forget this again (and it’s probably still wrong oops-)

- Steps:

- Find the commit you want to revert to & copy its hash:

- Return to your open project:

for me, i was working with a locally-cloned copy in VScode, connected to the remote repo’s main branch, and was up to date with all of the changes made.

- Create new remote branch:

open the terminal and run git checkout -b <new-remote-branch> <old-commit-hash>. This will create a new remote branch populated with the project at the time of the commit hash you specified, and switch you to it.

E.g., git checkout -b names-update 4853ecf5765b7174465e604e8fd8bdd5430ea84f.

- Push this new remote branch:

then, simply push this new remote branch with git push origin <new-remote-branch>, and check that it appears on github!

Now you can operate off this new branch, containing the project in a previous commit’s state.

yes… i know this is a very simple thing to do that i only just kinda grasped >.<

building & deploying this blog with hugo!

Wed, 08 Jan 2025 00:00:00 +0000

and now - to the story of how this blog was born!

(it’s nothing special, but I thought I’d document it for myself when i inevitably forget how i did it in the future, as well as any other wandering lost souls out there!)

i’ve been meaning to re-jig my tech blog for a while now. for the last year and a bit, I experimented with the static site generator (SSG) jekyll. jekyll is essentially a tool built in ruby that combines blog posts (typically written in markdown, .md files) with themes/config files to generate browser-renderable code (HTML, CSS and JS).

this way, you can streamline your workflow, embed all sorts of cool features (comments, reactions, reading times, table of contents, automatic rss feeds, post dating etc.), and most importantly avoid the horror of writing blog posts in raw HTML… but still being able to dabble in it when you please (providing your markdown-to-html renderer permits that).

…and all of this within a static site (all files pre-built on web-server, no databases) that is lightweight, responsive, maintainable and (relatively) quick to spin up.

- why did i move away from jekyll?

for three simple reasons:

i’d been meaning to try the SSG hugo.
hugo is built in golang, and i’d been wanting to poke around with go for a while now.
i found (and confirmed, after trying hugo) ruby & jekyll to be a bit more onerous to work with & overly-verbose in both site layout & base code. also - i noticed that jekyll had much slower build times.

- getting up and running with hugo:

there are endless tutorials for this, and my pipeline is probably most similar to that of NetworkChuck in the recent video he released (not even a week before I went in on my own build, after sitting on the idea for ages haha - twas kinda spoopy :3).

- setting up the hugo site:

Hugo has two simple dependencies: git (for code version control), and the go compiler toolchain. (here are where you can install git and go, if needed)
after installing these, using the package manager of your choice (for me, homebrew), install hugo with brew install hugo.
choose a directory for your site, and open it in your code editor. ensure hugo is in your system PATH so you can access it via the command line, and run hugo -v to ensure you’re on the latest.
then simply run hugo new site [SITENAME], replacing [SITENAME] with whatever you’d like to call the site (& folder it lives in). hugo will then spinup the basic bones of your site, and navigate into the folder it creates with cd.
initialise an empty git repository in this new folder with git init.
to install a theme, browse them here, and follow the instructions in the theme’s description (as some methods vary). however, the most common is installation is via a git submodule - which essentially will just pull down an existing git repo containing a pre-built hugo theme, and populate your site’s themes folder with it. this way, when building your site, hugo will use it as a base layout, and add any changes made to your site on top of it. for me, i ran: git submodule add https://github.com/michaelneuper/hugo-texify3.git themes/hugo-texify3
now, your site’s directory tree should look something like the following:

Folders & files are fairly self-explanatory, with the main ones being:
- hugo.toml - your site’s configuration variables.
- /content - where you create folders to store blog posts (.md) & site pages
- /assets - ideally where media is stored & linked (although you can place them anywhere, theoretically, providing you link back to it correctly)
- /public (only created when website is built, see step 8.) - where your raw website (raw HTML, CSS, JS) will be built to and live. you shouldn’t need to touch this folder.
- /themes - where all of your sites themes are installed (and specified/switched between in hugo.toml)
sometimes, themes require installing other tools as part of their custom build process. this should be specified in the theme’s documentation. for me, that required needing to install the following with npm: npm install postcss-cli autoprefixer postcss-import
to build your site locally, ensure you’re in your site’s base directory and run hugo server -t [THEME-NAME] (if using a theme). for me: hugo server -t hugo-texify3
now, navigate to the local address to see your site in action! it should live-reload as you make changes in your code editor.
[EXTRA] after analysing my specific theme’s layout & directory structure, I mirrored elements of it (thus overwriting what was contained in the /themes folder) to create the below folder structure, allowing me to: - add dedicated website pages in /pages - use /posts to hold my site post, with each in its own folder alongside any assets (images, media, etc.). this was done due to my particular workflow (writing in obsidian, see below). - split site configuration into two files for readability in /config: one for parameters (enabling/disabling certain features like social links, metadata etc.), and one for overall config & layout.

- pushing to remote git repository & deploying via cloudflare pages

(aka my weird custom workflow):

after running git init, ensure you are authenticated locally with gh auth login (requires use of Github CLI, install with brew install gh or similar)
create a new repository on GitHub with: gh repo create juni-blog --public --source=. --remote=origin
- --public: sets repo as public, as cloudflare will need to monitor it for changes
- --source=.: initialises the remote repository with your current local directory’s contents
- --remote=origin: sets up the remote URL for the repository
now, just push the local branch to the remote with git push -u origin main.

The -u (or --set-upstream) option in git push links your local branch (main) to the remote branch (origin) by default, allowing you to run git push and git pull commands in the future without adding origin main at the end (AKA specifying which remote branch to interact with by default).
navigate to your remote repository on github to check whether the changes have been propagated!
setup, login to and open cloudflare pages and navigate to your Workers & Pages section, then Create to deploy a new “site”. The click Connect to Git and follow the prompts to authenticate, and link to the repository that you just pushed to.

After that, you can specify which branch Cloudflare should look for changes on, as any frameworks that you’re using to build & deploy the site, and where the built assets & HTML files are stored. I selected Hugo (for obvious reasons), and it populated the build command with a simple hugo.

However, if your site requires other tools as part of the build process like mine (specified in step 8 in the previous section), be sure to install them on the remote server this site is running off with the relevant commands. for me, these are: npm install postcss-cli autoprefixer postcss-import && hugo Cloudflare should provide logs from the remote server should your build fail, making troubleshooting fairly simple.
then you’re all set! cloudflare will now watch for any changes made to the specified branch of this repo (for me, main), and if detected, it will automatically run npm install postcss-cli autoprefixer postcss-import && hugo on its remote server(s) to build the updated version of my site, and then serve only the created HTML, CSS & JS files in the specified output directory (for me, public). you should be able to access your site from the default URL created and provided to you, like https://b3ce9f44.juni-blog.pages.dev/.
[extra] to change this URL to a custom domain that you own, go to the Custom Domain section of the page you just created, click Set up a custom domain.

Then, follow the prompts. In my case, I associated the myblog CNAME with this “Page” (juni-blog.pages.dev).

Then, simply navigate to your domain’s (juni-mp4.com) DNS records (for me, also managed via Cloudflare) and add a record for the CNAME you just specified.

This means that when someone visits myblog.juni-mp4.com, they will functionally be visiting juni-blog.pages.dev.

this combination of github & cloudflare pages allows me to easily host & deploy sites from different github repos, each built with all kinds of different build methods (from hand-coding raw HTML/CSS/JS to using various SSGs like jekyll, hugo etc.), as subdomains of my primary domain juni-mp4.com and all served securely & quickly from Cloudflare’s worldwide array of web servers. (not sponsored haha - the only thing you monetarily pay for is your domain registration fee, and even that is optional.)

Side note: yes, whilst you could argue that you “pay” in the form of you & your content being technically in the hands of cloudflare, outside of hosting file files yourself on a VPS or a home server - which comes with a slew of additional overhead, maintenance and security configuration concerns - this is a fairly reasonable compensation to make for the uptime, security & responsiveness that Cloudflare’s network of servers provides, at least imho and for my use case.

this very particular workflow & need for flexibility is why i chose to use cloudflare instead of just deploying straight from Github Pages.

- my final note-taking process: an overview

open my Obsidian “blog” vault, and create a new note within a folder in posts:

the Templater plugin auto-generates the hugo-formatted frontmatter you see above in every new note, using the code block below inside the template file.
```
---
title: ""
date: <% tp.file.creation_date("YYYY-MM-DD") %>
description: ""
toc: true
math: true
draft: true
categories: 
tags:
---
```
write the post :3. drag & drop / copy-paste images as needed, after making sure the Absolute path in vault option is selected in your vault’s Files and links settings. This may need to be tweaked depending on your site’s layout later, but it worked for me, and is easily changed in bulk in VSCode or a similar editor via find & replace.
once I’m finished writing, I switch to my full website directory tree in VSCode (my Obsidian “blog” vault is just the website’s content folder, hence the .obsidian folder inside it).

i run the build command hugo server -t [theme-name-here] in the VScode terminal to start a live server, and visit http://localhost:1313/ to double check that the changes have been formatted properly.
then a simple git commit -m "new blog post: hugo site build" -a && git push origin main pushes the changes to my site where it’s rebuilt & served as new HTML pages!

'securely' setting up web server with nginx @ home & self hosting

Thu, 26 Dec 2024 00:00:00 +0000

debian 12 container install inside proxmox
`sudo apt update && sudo apt upgrade -y
network settings: If your router supports subnets/VLANs, connect this to the isolated VLAN. within proxmox, assign static IP not in use and point to your router’s gateway.![[Screenshot 2024-07-08 at 8.40.32 PM.png]]
install nginx on debian - sudo apt install nginx -y
create a file for website settings: `nano /etc/nginx/sites-available/mywebsite

server {
        listen 80 ; 
        listen [::]:80 ;
        server_name juni-mp4.org ;
        root /var/www/juni-web ;
        index.html index.htm index.nginx-debian.html ;
        location / {
                try_files $uri $uri/ =404 ;
        }
}

The listen lines tell nginx to listen for connections on both IPv4 and IPv6. The server_name is the website that we are looking for. By putting landchad.net here, that means whenever someone connects to this server and is looking for that address, they will be directed to the content in this block. root specifies the directory we’re going to put our website files in.

This can theoretically be wherever, but it is conventional to have them in /var/www/. Name the directory in that whatever you want. index determine what the “default” file is; normally when you go to a website, say landchad.net, you are actually going to a file at landchad.net/index.html. That’s all that is. Note that that this in concert with the line above mean that /var/www/landchad/index.html, a file on our computer that we’ll create, will be the main page of our website.

Lastly, the location block is really just telling the server how to look up files, otherwise throw a 404 error. Location settings are very powerful, but this is all we need them for now. 7. create directory for your website’s contents/files using: mkdir /var/www/juni-web (can be located wherever but standard to store in /var/www/[X] ) where you can place website files like index.html etc.) 8. enable the site by making a link between the config file in you just created in sites-available and the sites-enabled directory: ln -s /etc/nginx/sites-available/juni-web /etc/nginx/sites-enabled/ 9. restart nginx systemctl restart nginx`

make sure the “default” file doesn’t remain in /etc/nginx/sites-enabled/ otherwise will serve the default config page for nginx!!

Main Nginx Files & Explanation:

The idea is that you can make a site configuration file in sites-available (that links to where your website is stored locally, e.g. /var/www/sitestorage), then make a link to this configuration file in sites-enabled, which will activate it.

Config Files:

/etc/nginx/sites-available/ - directory containing any site configuration files. Points to directory containing main website content, e.g. /var/www/juni-web

server {
        listen 80 ;
        listen [::]:80 ;
        server_name juni-mp4.org ;
        root /var/www/juni-web ;
        index.html index.htm index.nginx-debian.html ;
        location / {
                try_files $uri $uri/ =404 ;
        }
}

/etc/nginx/sites-enabled/ - directory containing links to site configuration files make links via: `ln -s [link-source-path] [link-destination-path]

Main website location:

/var/www/[site-name]' e.g. /var/www/juni-web contains files like index.html, etc.

Securing it:

UFW:

sudo apt install ufw

# Limit SSH access to port 22 
sudo ufw limit 22/tcp 

# Allow HTT![[Screenshot 2024-07-19 at 9.04.25 PM.png]]P traffic on port 80 
sudo ufw allow 80 

# Allow HTTPS traffic on port 443 
sudo ufw allow 443 

# Limit SSH access to port 22 for IPv6 
sudo ufw limit 22/tcp6 

# Allow HTTP traffic on port 80 for IPv6 
sudo ufw allow 80/tcp6 

# Allow HTTPS traffic on port 443 for IPv6 
sudo ufw allow 443/tcp6

ufw enable

ufw logging on

ufw status

![[Screenshot 2024-07-09 at 11.51.31 PM.png]] https://www.linode.com/docs/guides/configure-firewall-with-ufw/

docker install (debian):

Run the following command to uninstall all conflicting packages:

 for pkg in docker.io docker-doc docker-compose podman-docker containerd runc; do sudo apt-get remove $pkg; done

install dependencies:

sudo apt -y install apt-transport-https ca-certificates curl gnupg2 software-properties-common

Set up Docker’s apt repository.

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/debian \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

install latest docker version

 sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Verify that the installation is successful by running the hello-world image:

 sudo docker run hello-world

docker compose install

why install it? manage all containers & deployments from a single yaml file

sudo apt-get update

sudo apt-get install docker-compose-plugin

docker compose version

![[Screenshot 2024-07-10 at 12.12.09 AM.png]]

create compose file near website data for ease of management

## if website located in mkdir /var/www/juni-web
mkdir /var/www/docker-compose
nano docker-compose.yml

we can use this to install…

nginx proxy manager (NPM) install

(not to be confused with node package manager npm lol)

note: make sure to set ports for managing nginx proxy manager (NPM) to 8080 & 4443 (or whatever custom ones you’d like) and NOT 80 & 443, as the latter will likely be in use by nginx to serve & access your website at.

in the docker-compose.yml…


cd /var/www/docker-compose
nano docker-compose.yml

## then add into file:
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      # These ports are in format <host-port>:<container-port>
      - '8080:80' # Port for HTTP access to NPM
      - '4443:443' # Port for HTTS access to NPM
      - '81:81' # Admin Web Port
      # Add any other Stream port you want to expose
      # - '21:21' # FTP

    # Uncomment the next line if you uncomment anything in the section
    # environment:
      # Uncomment this if you want to change the location of
      # the SQLite DB file within the container
      # DB_SQLITE_FILE: "/data/database.sqlite"

      # Uncomment this if IPv6 is not enabled on your host
      # DISABLE_IPV6: 'true'

    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt


## then run

docker compose up -d

access nginx via http://[server-ip]:81 & login with admin@example.com and changeme (changed upon entry)

cloudflare setup

autoscan for any DNS records you changed with your registrar (* domains, subdomains etc.) so cloudflare is aware of them

![[Screenshot 2024-07-19 at 9.05.00 PM.png]] ![[Screenshot 2024-07-19 at 9.09.40 PM.png]]

navigate to your domain registrar and set the custom DNS servers to the ones provided to you by cloudflare.

![[Screenshot 2024-07-19 at 9.08.37 PM.png]]

cloudflare setup guide here - https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/ ![[Screenshot 2024-07-19 at 9.17.23 PM.png]] ![[Screenshot 2024-07-19 at 9.17.34 PM.png]] ![[Screenshot 2024-07-19 at 9.18.03 PM.png]]

API token: HRWvk067sLPv_RMGDPhS1y0lj5XDcLErat5nY18m verify with cul command: curl -X GET "https://api.cloudflare.com/client/v4/user/tokens/verify" \ -H "Authorization: Bearer [YOUR TOKEN]" \ -H "Content-Type:application/json"

Cloudflare & SSL issues (certbot)

if you’ve setup certbot or something similar to manage ssl certificates on your nginx server, MAKE SURE to go to cloudflare and select Full (strict) SSL/TLS encryption mode so it doesn’t have an SSL mismatch and make your site inaccessible via the browser - ![[Screenshot 2024-07-19 at 10.00.00 PM.png]]

The Why: as with ‘flexible’ ticked, cloudflare will (by default) try and make requests to your server via HTTP and the server will throw an error if it’s using SSL due to a cipher mismatch, then browsers interpret this as a potential MiTM attack. see below: ![[Screenshot 2024-07-19 at 10.03.20 PM.png]] ![[Screenshot 2024-07-19 at 10.03.46 PM.png]]

you can also check your site’s nginx config file to see that certs are set up properly:

![[Screenshot 2024-07-19 at 10.07.33 PM.png]]

OPENING the ports

External port: what port is used by external users to access, like: pu.bl.ic.ip:[external-port] e.g. 182.46.382.83:443

Internal port: what port on the specified Device (the one identified by the Device IP Address field) that the traffic will be forwarded to.

![[Screenshot 2024-07-19 at 10.24.08 PM.png]]

![[Screenshot 2024-07-19 at 10.23.53 PM.png]]

set up static IP for container in proxmox on router

OR just change the DHCP pool to not include the IP address you want statically added on the proxmox

(e.g. setting DNS pool to 192.168.0.20 -> 192.168.0.200 and then assigning static IP for your container in proxmox outside of the pool range but on the same subnet, e.g. 192.168.0.5 ) ![[Screenshot 2024-07-19 at 10.19.57 PM.png]]

![[Screenshot 2024-07-19 at 10.19.45 PM.png]]

adding SSL cert to nginx proxy manager

![[Screenshot 2024-07-19 at 10.40.02 PM.png]]

certs on web server: ![[Screenshot 2024-07-19 at 10.43.38 PM.png]]

setup proxy host on NPM

![[Screenshot 2024-07-19 at 11.37.22 PM.png]] ![[Screenshot 2024-07-19 at 11.38.09 PM.png]]

setup NPM & dynamic DNS

to do:

https://anebula.io/how-to-set-up-nginx-proxy-manager-using-docker-compose/
https://www.youtube.com/watch?v=GarMdDTAZJo
https://notthebe.ee/blog/easy-ssl-in-homelab-dns01/
set up nginx reverse proxy, cloudflare etc. https://blog.prutser.net/2021/01/20/how-to-securely-self-host-a-website-or-web-app/
install certbot & auto renewal & setup https
setup firewall around docker - https://docs.docker.com/network/packet-filtering-firewalls/#docker-and-ufw
ssh harden copy config files & replace keys
install auto updates for all respective software (docker, docker compose, nginx, nginx proxy manager, ufw, anything else used)
port forward website to internet to make accessible
update domain registrar to point to local public IP
write scp command that writes locally-edited files to website remotely scp -r user@[remoteTargetComputerIP]: [RemoteFilesPath] [localDestinationPath] e.g. scp -r root@45.77.26.67:/var/www/mysite ~

DISCLAIMER: I would consider this a LEGACY POST of mine, written a long time ago. Please excuse any typos, errors or lapses in memory/judgement - as it was added to the site from the archives, just to put everything in one place. Thankq for your understanding 🙇‍♀️

Backing up linux .config & apps to move to a new device/distro

Wed, 25 Dec 2024 00:00:00 +0000

burn it all down… or?

Ahh, a tale born from the first time that I dipped my toes into the weird, wide and wonderful world of distro-hopping. Because sometimes, instead of building it all from scratch again (like so many of us are fond of doing), bringing your old config, notes of a previous home, with you is desirable. Because don’t lie - we won’t get those hours spent tweaking shell configs to look just how we like it back.

In any case - the following (somewhat high-level) overview should get you up and running on a new system/distro fairly quickly, in an environment

Basically, most user settings (from my research - some may be hidden in other corners, but this got me back to a similar place) are stored in `/home/[user-name]/.config/.

So, for me, this was at /home/juni/.config/. So, simply copy that folder to an external drive or over the network, and paste it in the corresponding place on your new system.

- Copying over .config

cd /home/[user]/
- navigate to the user’s directory where the .config folder is stored.
`sudo tar cvzf configs-backup.tgz .config/
- creates a compressed archive (configs-backup.tgz) of the .config folder with tar, and passing cvzf as parameters:
  - c - create a new archive
  - v - enable verbose output, to monitor the progress
  - z - compress with the gzip algorithm
  - f - specifies the name of the created archive file (in this case, configs-backup.tgz) Alternatively, you could use a tool like rsync to copy the entire /home/ folder to an external ssd, although this can take a long time depending on its size. I’d recommend rsync over just copying with cp, as rsync copies all files whilst retaining owner/group/other file permissions.
If connecting an external SSD to copy to: `sudo fdisk -l
- lists the connected disk drives and their corresponding filesystem location - like `/dev/sda1)
`sudo mkdir -p /mnt/externalssd
- creates a folder on your computer’s filesystem to act as a mount point: i.e. a place where you can access files stored on a mounted external SSD.
`sudo mount -t exfat /dev/sda1 /mnt/externalssd
- Mounting the SSD (the device we found at /dev/sda1) ‘in’ this new folder created in the previous step, allowing all the files on it to appear in /mnt/externalssd.
You should now be able to navigate there with cd /mnt/externalssd and run a ls to show the SSD’s existing contents. Then, copy the compressed .config file with cp /home/[user]/configs-backup.tgz /mnt/externalssd (may require prepending sudo depending on user permissions) - and you’re done!.

If you opted for rsync instead above:

sudo rsync -avh --progress /home/[user]/ /mnt/externalssd/home-backup - a - preserves file attributes & ensures a mirror copy is created, including permissions, symlinks, etc. - v - enable verbose output, to monitor the progress - h - ensures output is human-readable - --progress - displays real-time progress for troubleshooting purposes.

Now just unmount the drive with sudo umount /mnt/externalssd (or don’t - live on the edge ;), plug it into new machine/distro, and copy the file you created over into /home/[new-user]/ with cp.

Make sure to de-compress the file (if you used tar) with tar xvzf configs-backup.tgz, so it can be read by the system!

Then reboot, and your settings should be re-applied! :3

- BONUS: Grabbing a list of installed packages to re-install

Optionally, if you want to grab a list of all packages/apps installed on your current distro to bring over and auto-install on your new one, run the following:

Debian-based distros (e.g. Ubuntu, Kali, etc.):

dpkg --get-selections > installed-packages.txt
- saves a list of all packages to installed-packages.txt. Save this on an external SSD or transfer to the new machine via the network. On the New Machine/Distro:
sudo apt update
Navigate to where installed-packages.txt is stored (on the local machine), and run sudo dpkg --set-selections < installed-packages.txt
Run sudo apt-get dselect-upgrade

The process is similar for distributions using different package managers like yum, pacman, or rpm, the concept is the same but the commands will differ slightly. A little net/manual searching will fix you up :P.

second post wahoo

Tue, 24 Dec 2024 00:00:00 +0000

a single breath echoes into the abyss

hello, world. it’s been a while.

PACK files in .git - a rabbit hole

Mon, 23 Dec 2024 00:00:00 +0000

- so, how did we get here? 🙈

git stores all historical changes to a repo in a PACK file inside the hidden .git folder. This allows restoration of previous repo states in the future.

However, if you upload files like binaries, photos or videos, this file gets VERY large, even if you delete them in a future commit.

- enter: `git-filter-repo`

Luckily a tool exists called git-filter-repo that you can download and use (python script) to analyse your PACK file, and filter out any unwanted bits (e.g. file extensions, paths, etc.). This can dramatically reduce the size of the PACK file.

It works in a single command (with the option to point the command to a file defining what to keep/exclude, if preferred). Just download the python script, move it to your working directory (MUST have .git folder, as it will analyze this), and run:

python git-filter-repo.py --analyze

(the use of “python” or similar, and giving the script a .py extension, is necessary sometimes on windows, depending on what shell you’re running the above command in, your PATH configuration etc. - but just think of it as running a script file and passing the “analyze” argument to it)

It then produces a folder with text files showing files/repo paths (historical) and their relative sizes. From here, you can search through and figure out how to filter what you’d like to remove.

When you’ve decided what you’re going to remove and how (path/extension/date etc.), I recommend doing a –dry-run, which will produce two files (the original version and the modified version) and comparing what elements were removed with your filter. For me, using the following command, I went from 6473 lines of committed files to 1428.

python git-filter-repo.py --path 'old-site/audio/' --path 'old-site/photos/' --invert-paths --dry-run --force

(I used –force as I had one untracked change - being moving the git-filter-repo script file itself into the directory - that I didn’t want to push to git)

And to make “the changes” [PERMANENTLY!! CAUTION!!!] remove the --dry-run component of the above command, resulting the following:

python git-filter-repo.py --path 'old-site/audio/' --path 'old-site/photos/' --invert-paths

Run that, and then there you go - it should make the changes to the .git folder in your repo, stripping out the components of the file you filtered and producing a new, (hopefully) smaller PACK file.

Now, it just needs to be pushed to the remote repository with:

git push --all [remote-repo-URL]

- and then…

well, if all things went well, you should have shaved a few KBs/MBs/GBs off your PACK file - well done! grab yourself a cookie, you’ve well and truly earnt it :3

Home on juni's blog ٩(◕‿◕｡)۶

Tracking & Syncing my dotfiles!

- Using Git + Github, & tracking dotfiles with an alias.

- or… using a dotfiles manager, comme chezmoi.

- To install:

- Editing your dotfiles & using chezmoi:

(RECOMMENDED) You can work and make changes within the locally-created chezmoi copy of your dotfiles, apply them locally, and push them to remote repo once done.

…making changes to your dotfiles normally (i.e. not within the chezmoi-managed copy of your dotfiles)

Git CLI Basics - branching & stashing!

- Branching & Checkouts

- in the wild:

- Stashing

Minecraft Server From Scratch (Proxmox LXC, Docker Compose + itzg)

- Set up LXC Container in Proxmox

- Install Docker (Compose) & itzg Minecraft Server

- For any further troubleshooting

Authentication Methods - A Deep(ish) Dive

… in the absolute broadest of strokes:

- JSON Web Tokens (JWT)

- How it works:

- JWT-based Authentication Drawbacks

- Session-based (cookie) authentication:

- How it works:

- Session-based Authentication Drawbacks:*

A brief comparison…

Branching out with a previous commit in a GitHub project

- Steps:

- Find the commit you want to revert to & copy its hash:

- Return to your open project:

- Create new remote branch:

- Push this new remote branch:

building & deploying this blog with hugo!

and now - to the story of how this blog was born!

- why did i move away from jekyll?

- getting up and running with hugo:

- setting up the hugo site:

- pushing to remote git repository & deploying via cloudflare pages

- my final note-taking process: an overview

'securely' setting up web server with nginx @ home & self hosting

Main Nginx Files & Explanation:

Config Files:

Main website location:

Securing it:

UFW:

docker install (debian):

docker compose install

nginx proxy manager (NPM) install

cloudflare setup

Cloudflare & SSL issues (certbot)

OPENING the ports

set up static IP for container in proxmox on router

adding SSL cert to nginx proxy manager

setup proxy host on NPM

setup NPM & dynamic DNS

Backing up linux .config & apps to move to a new device/distro

burn it all down… or?

- Copying over .config

- BONUS: Grabbing a list of installed packages to re-install

- Related helpful articles:

second post wahoo

a single breath echoes into the abyss

PACK files in .git - a rabbit hole

- so, how did we get here? 🙈

- enter: git-filter-repo

- and then…

- other helpful links:

- or… using a dotfiles manager, comme `chezmoi`.

- Editing your dotfiles & using `chezmoi`:

(`RECOMMENDED`) You can work and make changes within the locally-created `chezmoi` copy of your `dotfiles`, apply them locally, and push them to remote repo once done.

…making changes to your dotfiles normally (i.e. not within the `chezmoi`-managed copy of your `dotfiles`)

- Set up `LXC` Container in Proxmox

- enter: `git-filter-repo`