Linux 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

'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.