标签：#Linux

There is a line in almost every Python web tutorial that nobody explains: uvicorn main:app --host 0.0.0.0 --port 8000 I copied it for weeks without thinking about it. Then I deployed the same application three times — to a local VM, to a production server, and into a container — and the correct value was different every time. Twice it was 0.0.0.0 . Once, in the place that mattered most, it was not. That gap is worth writing about, because the setting itself is trivial and the reasoning behind it is not. What the Flag Actually Controls A server process doesn't "open a port." It creates a socket and binds it to an address. The bind address answers one question: which network interfaces should this socket accept connections from? A machine has more than one interface: lo (loopback) — reachable only from inside the machine ( 127.0.0.1 ). Packets addressed there never reach a physical network card; the kernel loops them straight back. 0.0.0.0 — a wildcard meaning every interface this machine has , including ones added later. So the flag isn't about security or convenience. It's about reachability — and reachability depends entirely on what sits in front of the process. Case 1: The Local VM — 0.0.0.0 I was running the service inside a Multipass VM and wanted to hit it from the browser on my laptop. The laptop is outside the VM, so binding to loopback would have made the service invisible to it. curl inside the VM would work; the browser outside would get connection refused. Decision: wildcard bind. Nothing sits in front of the process, and nothing needs protecting. Case 2: Production — 127.0.0.1 Here I copied the same line at first, and it was wrong. The production box has a public IP. Binding to 0.0.0.0 there means the application is directly exposed to the internet: no TLS, no rate limiting, no authentication. Within hours of provisioning that server, its SSH logs showed hundreds of automated login attempts against usernames like admin and oracle . The same scanners try

Hard debugging is rarely defeated by a lack of tools. It is defeated by three quiet habits: assuming the fault is where the symptom appears, clinging to the first explanation, and hoping a tool will do the thinking. A difficult fault is usually lost to those habits before you read a line of code. The engineers who resolve hard faults are the ones who notice these defaults and replace them with a patient, evidence-first mindset. Most hard bugs are lost before we touch them, in the attitude we bring to the session. When something breaks, the average person rushes in with three quiet habits: they assume the fault lives exactly where it shows up, they cling to the first explanation their mind offers, and they hope a tool or a smarter person will tell them what to do next. Those habits feel natural, but on hard faults they are exactly what keep us stuck. Put two engineers on the same failing board. One finds a way through in an afternoon; the other is still going three days later. The difference is rarely raw intelligence or how many commands they know. It is the mental posture each brings to the work before the first step. Handling a hard debug session is less about knowing every tool and more about managing your own assumptions, reactions, and impatience. A tough problem is usually lost in your mindset before it is lost in your methods. Habit one: starting too narrow The first habit is to fix on the most visible symptom and refuse to look anywhere else. Something breaks, so we stare at the last thing we changed, and we return to it because it is familiar and close at hand. When the answer is not there, we look harder in the same place instead of stepping back. Here is what that looks like on real hardware. A device keeps dropping off the bus. You are a kernel person, so you open the driver and read it, carefully, for three days: the probe path, the error handling, the power-management callbacks. Every line is correct, and the device still fails. The fault was a layer b

I needed a VPS to run CyberPanel. Simple enough: 1 vCPU, 1 GB RAM, 10 GB SSD, IPv6 only. CyberPanel...

Most Linux problems aren't actually difficult. They're difficult because they're often debugged in the wrong order. Many beginners immediately: Restart services randomly Run commands without a plan Change configurations before understanding the problem Guess instead of observing Experienced engineers do something different. They follow a structured troubleshooting process. This article isn't about learning new Linux commands. It's about knowing when and why to use the commands you've already learned throughout this Linux Beginner Series. Think of it as putting everything together into one practical troubleshooting workflow that's used in real Linux and DevOps environments. Quick Troubleshooting Workflow Observe ↓ Check System Health ↓ Identify Problem Type ↓ Read Logs ↓ Verify Service ↓ Check Network ↓ Check Disk ↓ Recent Changes ↓ Find the Root Cause ↓ Apply the Fix Keep this workflow in mind as you read through the guide. Step 0: Observe Before You Change Anything Before running a single command, pause for a moment. Ask yourself: What exactly is broken? When did the issue start? Is everyone affected or only some users? Is the problem constant or intermittent? What changed recently? Many troubleshooting sessions become longer because people try to fix the problem before they understand it. Good troubleshooting begins with observation, not commands. Step 1: Check Overall System Health Your first goal is to understand the overall health of the system—not to fix anything yet. Useful commands: uptime free -h top Look for: High load average High CPU usage Low available memory Signs that the server is under heavy load At this stage, you're only gathering evidence. A quick system health check often tells you where to investigate next. Step 2: Identify the Type of Problem Before diving deeper, classify the issue. Problem Type Common Symptoms First Commands to Check CPU Slow system, high CPU usage top , htop Memory Applications crashing, OOM kills free -h Disk "No space lef

A Month With Bash — Part 3: Building Projects After all the expansions and syntax, I moved on to regex in bash. It wasn't too hard since I'd already worked with regex in Python, but alongside it I learned grep , sed , and awk — tools that turned out to be extremely useful for automation. I built a few mini projects and started automating some of my small day-to-day tasks. I won't go too deep into that here, but you can check out my learning-bash GitHub repo, which has all my learning scripts. From there I covered conditionals, loops, and repetitive tasks. Finally I learned about array variables in bash and shell options, went even further testing different ways of looping, and that's when I started actual project building(I am still building ) #!/usr/bin/env bash ## looping with range functions -- somehow # python style looping {start..end} for i in { 1..10 } ; do # this uses brace expansion so using vars wont work becase of execution sequencing echo $i done clear ## c - slyle looping for (( i = 0 ; i < 10 ; i++ )) ; do # variables works here well echo "hello $i " done ## using variables to loop clear start = 1 stop = 10 step = 2 for i in $( seq $start $stop ) ; do # this uses the seq command echo "hello world" done Conclusion Spending so much time on bash wasn't a waste. Not only did it force me to learn a huge number of commands, it changed how I think about my own machine — most of what I used to do manually, I can now automate. That shift alone made the month worth it. i am still learning and trying to get the best practices and things not to do THANK YOU FOR READING THIS FAR. That is a rough summary of me writing bash for a month there is really a lot left unsaid here but still building and learning. If you are just starting out with bash or if you haven't tried it hope this helps feel free to drop questions advice and corrections

A Month With Bash — Part 2: Expansions Continuing from where I left off, the next thing I learned was special parameters in bash: "$*" $# $? $@ $N $- $0 Another important concept I picked up is how bash executes shell scripts. Bash is one of those languages that interprets each line as it goes — but it doesn't stop if a line fails. It continues on unless you explicitly set set -o pipefail (or -e , depending on what you want it to catch). Generally, the procedure looks like this: Tokenizing : splitting the line into tokens, usually split using the IFS value. Brace expansion : a mechanism by which arbitrary strings can be generated. echo file { 1,2,3 } .txt ## output: file1.txt file2.txt file3.txt Bash preserves the order from left to right. Tilde expansion : this is where expansion of special symbols takes place. ~ represents the HOME built-in variable ~+ represents PWD , the current working directory and others DIR = ~/Desktop # this is $HOME/Desktop echo " $DIR " Parameter expansion : introduced with the $ symbol. # ${} — the braces can be omitted for normal variables but not for array-type variables Command substitution : very important — it lets you assign the output of a command to a variable, and use commands inside if and for statements. Done with $(command to execute) . week_name = " $( date +%A ) " # gets the current day of the week echo " $week_name " Generally, $() spawns a new shell instance, so it's advisable to avoid it where possible, for latency reasons. Arithmetic expansion : just from the name, this allows evaluation of arithmetic expressions and substitution of the result. It starts with $(( expression )) . There are some rules — bash doesn't support floating point arithmetic natively, so you'd reach for bc if you need it. I won't go deep into that here since this isn't a full bash tutorial. Here's a simple BMI calculator I wrote while practicing this: #!/usr/bin/env bash # script calculates user's BMI and gives a recommendation set -euo pipefail #

Also Published On trever.cloud Medium LinkedIn Most of us who get into self-hosting start the same way: start with linux, throw a few apps into Docker, get them running and connectable outside the home network, and call it good for months, maybe even years. Nothing wrong with that approach. A compose file and a spare mini PC gets you further than you think, and if it works and you don't have to think about it, that's a perfectly fine place to stop. Then there's the rest of us. The people who get that first setup running, feel the little spark of "wait, I built this", and immediately start wondering what else is possible. More services. Less babysitting. A real answer to "what happens if this box dies at 2am". If any of that sounds familiar, this one's for you. If you keep going, you'll eventually run into the question every self-hosted setup faces sooner or later, whether you notice it happening or not, "how much should live together, and how much should be kept apart?". Put everything on one box and you quickly feel the fragility when one bad update takes everything down with it. Or when nightly backups put services on hold longer and longer. Split everything into its own isolated piece and you've gained resiliency but now manage a lot of moving parts. Most of the actual learning in running infrastructure happens in the space between those two answers. Where you draw that line is where most of the real infrastructure lessons live. Over the years, I've lived through a few different answers to that question in my own homelab, and each one taught me something the previous one couldn't. It started with a large VM, Docker installed, and every service I wanted to self-host running as a container inside. It was the fastest path to "it's actually working", and at the time that was the whole goal. I didn't know yet what I'd eventually want out of this thing, so keeping the infrastructure simple while I figured that out made sense. That setup carried me a long way, and I don

Mainline-friendly products are designed so their board support lives in upstream Linux, U-Boot, and standard build systems instead of a vendor fork. The decision is architectural, not aspirational: it is made when you choose the SoC, design the add-on connectors, and write the device tree — not when the product is already shipping. This article gives the strategic case, the product design rules that follow from current kernel work on hot-pluggable add-on boards, a vendor checklist for tech leads, and the concrete steps to upstream your own board support. We have covered why silicon vendors are moving to upstream-first BSPs . This article covers the product team's side of that shift: what you should do about it. Building mainline-friendly products means making a set of design decisions — SoC selection, connector design, device tree structure, and an upstreaming plan — so that mainline Linux and U-Boot treat your board as a normally supported board rather than as a permanent private port. Each section below turns one of those decisions into rules you can apply on your next board. Why mainline-friendly products are a strategic decision The cost of a vendor-fork BSP is not paid at bring-up; it is paid for the life of the product. Every kernel upgrade becomes a forward-port of private patches. Every security fix arrives on the vendor's schedule, not the kernel's — and for devices in scope of regulations such as the EU Cyber Resilience Act, patch latency is now a compliance question, not just an engineering one. Hiring is harder, because engineers must learn your fork before they can touch it, and the knowledge they build does not transfer in either direction. Board support that lives in mainline inverts each of these. New kernels are more likely to boot your board without forward-porting private support patches, because your board is part of the kernel's own build-and-test surface; LTS security fixes are easier to consume because the code paths you depend on are already

Here is the whole method: get access to a real Linux machine, type commands on it for 30 to 60 minutes every day, and follow a plan that builds from navigating the filesystem up to running your own web server. Do that and you will be comfortable in four weeks and genuinely fluent in about eight. No experience required, no money required. The rest of this article is the specific plan: what to type each week, where to get a free machine you can safely break, what the three scariest errors mean, and how to tell you are actually improving. Why most people fail at Linux The pattern is nearly universal. Someone decides to learn Linux, finds a nine-hour video course, watches it at 1.5x speed, takes beautiful notes, and three weeks later cannot list the contents of a directory without checking those notes. Watching someone else type is not practice. It feels like learning because the explanation makes sense while you hear it. But command line skill is muscle memory wrapped around a mental model, and both are built one way: typing, failing, reading the error, trying again. An hour of reading about ls teaches you less than typing ls twenty times in twenty directories. Videos are fine as a preview. They are just not the workout. So flip the ratio: for every minute reading or watching, spend five with your hands on a keyboard. This article included. Read a section, then go type it. Two smaller failure modes show up almost as often. Trying to memorize everything Linux has thousands of commands. Working engineers lean hard on a core of about 25 and look up the rest without shame. The plan below teaches that core and nothing else. Fear of breaking things On a practice machine, breaking things is the goal, not the risk. A system you broke and fixed teaches more than ten flawless tutorials. Every option in the practice section makes the worst case "start over," which costs a minute. The four-week plan First, get a machine from the free options below (one minute to one afternoon, dep

How to Verify a SHA-256 Checksum on Windows, macOS, and Linux You download an ISO, installer, archive, or release binary. The publisher provides a long value such as: 9f86d081884c7d659a2feaa0c55ad015 a3bf4f1b2b0b822cd15d6c15b0f00a08 That value is a checksum, usually generated with SHA-256. Verifying it answers one practical question: Does the file you downloaded have exactly the same contents as the file the publisher hashed? A checksum mismatch can indicate a damaged download, an incomplete transfer, the wrong file version, or modified contents. Before verifying anything Get the expected checksum from a source you trust. Ideally, use the software publisher’s official website, release page, package repository, or signed checksum file. A matching checksum confirms that your file matches the data represented by the expected hash. It does not prove that the original publisher or website was trustworthy. If an attacker can replace both the download and the displayed checksum, they can make the two values match. For stronger authenticity verification, use a signed release when the publisher provides one. Verify SHA-256 on Windows Open PowerShell in the folder containing the downloaded file. Run: Get-FileHash ".\filename.iso" -Algorithm SHA256 Example: Get-FileHash ".\ubuntu.iso" -Algorithm SHA256 PowerShell returns something similar to: Algorithm : SHA256 Hash : 4A1F... Path : C:\Users\You\Downloads\ubuntu.iso Compare the value beside Hash with the checksum published by the download provider. Uppercase and lowercase letters do not matter in hexadecimal hashes. The characters themselves must otherwise match exactly. Compare automatically in PowerShell Instead of comparing two 64-character values manually, store the expected checksum and let PowerShell compare them: $expected = "PASTE_EXPECTED_SHA256_HERE" $actual = ( Get-FileHash ".\filename.iso" -Algorithm SHA256 ) . Hash if ( $actual -eq $expected ) { Write-Host "Checksum matches" } else { Write-Host "Checksum does not

Last week I was doing a routine check on a CyberPanel server and noticed something that didn't add...

moin, ich möchte euch mein aktuelles Projekt vorstellen: Die Wiederbelebung eines Alienware m17x (Baujahr 2008) als dedizierte DJ-Workstation unter Linux. Ziel war es, alte Hardware nachhaltig zu nutzen und eine stabile Umgebung für Mixxx zu schaffen. Die Hardware: Notebook: Alienware m17x (Core 2 Duo, 4GB RAM, SSD) OS: KDE Neon mit Low-Latency-Kernel (6.8.0) Software: Mixxx 2.4 Audio-Interface: Günstiges USB-Audio-Device für den Master-Ausgang Das Problem: Mixxx verweigerte unter ALSA den Dienst mit der Fehlermeldung: Error opening "USB Audio Device (hw:1,0)" - Invalid sample rate Die Analyse über /proc/asound/card1/stream0 zeigte die Ursache: Das USB-Gerät unterstützt ausschließlich 46875 Hz – eine für Audio-Interfaces sehr unübliche Rate, die weder 44100 Hz noch 48000 Hz entspricht. Der direkte Zugriff über hw:CARD=Device,DEV=0 schlug fehl. Die Lösung: Die Rettung war die Aktivierung der ALSA-Plug-Erweiterung über PipeWire/ALSA, die eine automatische Sample-Rate-Konvertierung erlaubt. Starten Sie Mixxx nicht direkt, sondern setzen Sie zuvor die Umgebungsvariable: export PA_ALSA_PLUGHW=1 mixxx Damit Mixxx auch dauerhaft korrekt startet (z.B. über das KDE-Menü), habe ich den Starter wie folgt angepasst: bash -c "export PA_ALSA_PLUGHW=1; mixxx" Ergebnis: ✅ Master-Ausgabe über das USB-Device funktioniert stabil. ✅ Kopfhörer-Vorhören (C-Media USB Headphone Set) läuft parallel. ✅ Das System läuft trotz des Alters der Hardware (2008) flüssig und mit geringer Latenz. Die vollständige Dokumentation inklusive Fotos des Umbaus, der genauen Kernel-Einstellungen und der Konfiguration findet ihr in meinem Open-Source-Repository: 👉 [ https://github.com/qrishii/DJ-Installationen ] Ich hoffe, diese Lösung hilft anderen, die ähnliche Probleme mit exotischen USB-Audio-Raten unter Linux haben! das Leben ist lustig

ImgProxy is an open-source image-processing server — resize, convert, and transform images on the fly via URL parameters, ideal as a caching layer in front of a CDN or web app. This guide builds ImgProxy from source on Ubuntu, runs it as a systemd service behind Nginx with TLS, walks through its URL processing options, and secures it with signed URLs. Prerequisites: an Ubuntu server, a domain A record (e.g. imgproxy.example.com ), non-root sudo user. Install ImgProxy ImgProxy uses libvips for image processing; this builds it from source with Go. $ sudo add-apt-repository ppa:dhor/myway $ sudo apt update $ sudo apt install libvips-dev -y $ sudo snap install --classic --channel = latest/stable go $ git clone https://github.com/imgproxy/imgproxy.git $ cd imgproxy $ sudo CGO_LDFLAGS_ALLOW = "-s|-w" go build -o /usr/local/bin/imgproxy Create the environment config: $ sudo touch /usr/local/bin/imgproxy.env $ sudo nano /usr/local/bin/imgproxy.env IMGPROXY_BIND = :8080 IMGPROXY_NETWORK = tcp IMGPROXY_READ_TIMEOUT = 10 IMGPROXY_WRITE_TIMEOUT = 10 IMGPROXY_WORKERS = 2 IMGPROXY_REQUESTS_QUEUE_SIZE = 0 IMGPROXY_QUALITY = 100 IMGPROXY_PREFERRED_FORMATS = webp,jpeg,png,gif,avif IMGPROXY_LOG_FORMAT = "pretty" IMGPROXY_LOG_LEVEL = "INFO" IMGPROXY_WATERMARK_URL = https://example.com/watermark.png IMGPROXY_WATERMARK_OPACITY = 1 Key settings: IMGPROXY_WORKERS should be ~2× your vCPU count; IMGPROXY_REQUESTS_QUEUE_SIZE=0 means unlimited queueing; IMGPROXY_WATERMARK_URL points at whatever image you want overlaid when watermarking is enabled. Point ImgProxy at the config and test: $ export IMGPROXY_ENV_LOCAL_FILE_PATH = /usr/local/bin/imgproxy.env $ cd $ imgproxy WARNING [2024-05-28T00:40:42Z] No keys defined, so signature checking is disabled WARNING [2024-05-28T00:40:42Z] No salts defined, so signature checking is disabled INFO [2024-05-28T00:40:42Z] Starting server at :8080 Stop it with Ctrl+C once verified, then set it up as a service. Run ImgProxy as a systemd Service $ sudo useradd

code-server is the open-source project that runs full VS Code including extensions, integrated terminal, Git, IntelliSense — on a remote server, accessible from any browser. This guide deploys it on Ubuntu 24.04 with Docker Compose, fronted by Traefik for automatic HTTPS. Prerequisites: an Ubuntu 24.04 server (1GB RAM / 2 vCPU minimum), a domain A record (e.g. code.example.com ), Docker and Docker Compose installed. Set Up the Project $ mkdir -p ~/vscode-server/ { project,config,local,letsencrypt } $ cd ~/vscode-server project — your editable workspace config — code-server settings/extensions local — user-specific data letsencrypt — Traefik's ACME certificate storage Find your UID/GID and add yourself to the docker group: $ id $USER $ sudo usermod -aG docker $USER Write the Compose File $ nano docker-compose.yml services : code-server : image : codercom/code-server:latest container_name : code-server user : " UID:GID" # Replace with your user's UID and GID environment : - PASSWORD=SECURE_PASSWORD # Replace with a strong password - DOCKER_USER=LINUXUSER # Replace with your username volumes : - ./project:/home/coder/project - ./config:/home/coder/.config - ./local:/home/coder/.local networks : - internal restart : unless-stopped labels : - " traefik.enable=true" - " traefik.http.routers.code-server.rule=Host(`CODE.EXAMPLE.COM`)" # Replace with your domain name - " traefik.http.routers.code-server.entrypoints=websecure" - " traefik.http.routers.code-server.tls.certresolver=myresolver" - " traefik.http.services.code-server.loadbalancer.server.port=8080" traefik : image : traefik:latest container_name : traefik ports : - " 80:80" - " 443:443" volumes : - /var/run/docker.sock:/var/run/docker.sock:ro - ./letsencrypt:/letsencrypt command : - " --providers.docker=true" - " --providers.docker.exposedbydefault=false" - " --providers.docker.network=internal" - " --entrypoints.web.address=:80" - " --entrypoints.websecure.address=:443" - " --entrypoints.web.http.redirections.entr

Gradio is a Python library for wrapping any ML model in a web interface, ready to deploy and scale as an app. This guide builds a GFPGAN-powered face-restoration demo with Gradio on Ubuntu 22.04, runs it as a systemd service, and exposes it through Nginx with TLS. Prerequisites: a GPU-enabled Ubuntu 22.04 server, a domain A record (e.g. gradio.example.com ), non-root sudo access, Nginx installed. Set Up the Server 1. Install dependencies: $ pip3 install realesrgan gfpgan basicsr gradio realesrgan — background restoration gfpgan — face restoration basicsr — provides RRDBNet , the super-resolution architecture GFPGAN relies on gradio — the web interface 2. GFPGAN's pandas dependency needs jinja2 >= 3.1.2: $ pip show jinja2 Upgrade if it's older: $ pip install --upgrade jinja2 3. Create the project directory: $ sudo mkdir -p /opt/gradio-webapp/ $ sudo chown -R : $( id -gn ) /opt/gradio-webapp/ $ sudo chmod -R 775 /opt/gradio-webapp/ Build the Gradio App Uploads a face image and returns two enhanced outputs. $ cd /opt/gradio-webapp/ $ nano app.py import gradio as gr from gfpgan import GFPGANer from basicsr.archs.rrdbnet_arch import RRDBNet from realesrgan import RealESRGANer import numpy as np import cv2 import requests def enhance_image ( input_image ): arch = ' clean ' model_name = ' GFPGANv1.4 ' gfpgan_checkpoint = ' https://github.com/TencentARC/GFPGAN/releases/download/v1.3.4/GFPGANv1.4.pth ' realersgan_checkpoint = ' https://github.com/xinntao/Real-ESRGAN/releases/download/v0.2.1/RealESRGAN_x2plus.pth ' rrdbnet = RRDBNet ( num_in_ch = 3 , num_out_ch = 3 , num_feat = 64 , num_block = 23 , num_grow_ch = 32 , scale = 2 ) bg_upsampler = RealESRGANer ( scale = 2 , model_path = realersgan_checkpoint , model = rrdbnet , tile = 400 , tile_pad = 10 , pre_pad = 0 , half = True ) restorer = GFPGANer ( model_path = gfpgan_checkpoint , upscale = 2 , arch = arch , channel_multiplier = 2 , bg_upsampler = bg_upsampler ) input_image = input_image . astype ( np . uint8 ) cropped_fa

Nginx UI is an open-source web GUI for managing Nginx, single-node or clustered, with real-time stats, automatic Let's Encrypt TLS, performance monitoring, and even LLM-assisted config editing. This guide installs it on Ubuntu 24.04, puts it behind a reverse proxy with TLS, sets up ACME certificate management, and creates a virtual host through the dashboard. Prerequisites: an Ubuntu 24.04 server, non-root sudo user, a domain A record (e.g. nginx-ui.example.com ), Docker installed if you choose that install path. $ sudo apt update $ sudo apt install nginx -y Pick one of the two install methods below. Option A: Install via Script Runs Nginx UI as a system service, managing the host's Nginx directly. $ curl -O https://cloud.nginxui.com/install.sh $ sudo bash install.sh install $ nginx-ui --version $ sudo systemctl start nginx-ui $ sudo systemctl status nginx-ui Option B: Install via Docker Runs as a container — you won't be able to edit the host's Nginx configs directly through it. $ mkdir -p ~/nginx-ui-docker $ cd ~/nginx-ui-docker $ sudo mkdir -p /opt/nginx-ui/nginx $ sudo mkdir -p /opt/nginx-ui/config $ sudo mkdir -p /opt/nginx-ui/www $ nano docker-compose.yml version : ' 3.8' services : nginx-ui : image : uozi/nginx-ui:latest container_name : nginx-ui restart : always environment : - TZ=UTC volumes : - /opt/nginx-ui/nginx:/etc/nginx - /opt/nginx-ui/config:/etc/nginx-ui - /opt/nginx-ui/www:/var/www ports : - " 127.0.0.1:9000:80" networks : - nginx-ui-net networks : nginx-ui-net : driver : bridge $ sudo docker compose up -d $ sudo docker compose ps $ curl -X GET http://localhost:9000 Configure the Reverse Proxy Nginx UI listens on localhost:9000 . Put it behind a public vhost with WebSocket support (needed for live stats/terminal): $ cd /etc/nginx/sites-available $ sudo nano nginx-ui.conf map $http_upgrade $connection_upgrade { default upgrade ; '' close ; } server { listen 80 ; listen [::]:80 ; server_name nginx-ui.example.com ; location / { proxy_set_header Host $

Ghost is an open-source publishing platform with built-in newsletters, memberships, subscriptions, ActivityPub federation, and Tinybird-powered web analytics. This guide covers two install paths on Ubuntu 24.04: Ghost-CLI for a traditional host install, and Docker Compose for a containerized deployment with analytics. Prerequisites: an Ubuntu 24.04 server, non-root sudo user, a domain A record (e.g. ghost.example.com ). Option A: Install with Ghost-CLI Install Node.js Ghost requires Node v22 LTS — check compatible versions before installing elsewhere. $ curl -fsSL https://deb.nodesource.com/setup_22.x -o nodesource_setup.sh $ sudo -E bash nodesource_setup.sh $ sudo apt install -y nodejs $ node -v Install and Configure MySQL $ sudo apt install -y mysql-server $ mysql --version $ sudo mysql_secure_installation Walk through the prompts: enable password validation ( y ), pick strong policy ( 2 ), remove anonymous users ( y ), restrict root to localhost ( y ), drop the test database ( y ), reload privileges ( y ). $ sudo mysql mysql > CREATE DATABASE ghost_db ; mysql > CREATE USER 'ghostuser' @ 'localhost' IDENTIFIED BY 'Your_password2!' ; mysql > GRANT ALL PRIVILEGES ON ghost_db . * TO 'ghostuser' @ 'localhost' ; mysql > FLUSH PRIVILEGES ; mysql > EXIT ; Install Nginx $ sudo apt install -y nginx $ sudo ufw allow 'Nginx Full' $ sudo systemctl status nginx Install Ghost $ sudo npm install ghost-cli@latest -g $ sudo mkdir -p /var/www/html/ghost $ sudo chown $USER : $USER /var/www/html/ghost $ sudo chmod 775 /var/www/html/ghost $ cd /var/www/html/ghost $ ghost install The installer prompts for: Blog URL : https://ghost.example.com MySQL hostname : localhost MySQL username/password/database : from the setup above Set up Nginx? : y Set up SSL? : y (installs acme.sh ) Email for SSL : your address Set up Systemd? : y Start Ghost? : y Manage the Config $ nano /var/www/html/ghost/config.production.json $ cd /var/www/html/ghost $ ghost restart Or via systemd (replace ghost-example

phpBB is an open-source forum application for building discussion communities — user registration, moderation, permissions, and multiple boards in one interface. This guide deploys phpBB on Ubuntu 22.04 with an external MySQL database, an Apache virtual host, and Let's Encrypt TLS. Prerequisites: an Ubuntu 22.04 server with the LAMP stack installed, non-root sudo user, an external MySQL database, a subdomain A record (e.g. phpbb.example.com ). Create the Database $ mysql -h your-db-host -P 3306 -u dbadmin -p mysql > CREATE DATABASE phpbbdb ; mysql > USE phpbbdb ; mysql > CREATE USER 'phpbbuser' @ 'localhost' IDENTIFIED BY 'securepassword' ; mysql > GRANT ALL ON phpbbdb . * to 'phpbbuser' @ 'localhost' ; mysql > FLUSH PRIVILEGES ; mysql > EXIT ; Install phpBB 1. Install PHP modules: $ sudo apt install php-mysql php-xml php-mbstring -y 2. Download and extract — check the releases page for the current version: $ wget -O phpbb.zip https://download.phpbb.com/pub/release/3.3/3.3.11/phpBB-3.3.11.zip $ unzip phpbb.zip $ sudo mv phpBB3 /var/www/html/phpbb 3. Set ownership and permissions: $ sudo chown -R www-data:www-data /var/www/html/phpbb $ sudo find /var/www/html/phpbb -type d -exec chmod 755 {} \; $ sudo find /var/www/html/phpbb -type f -exec chmod 644 {} \; Configure Apache $ sudo nano /etc/apache2/sites-available/phpbb.conf < VirtualHost *:80 > ServerAdmin admin@example.com DocumentRoot /var/www/html/phpbb ServerName phpbb.example.com < Directory /var/www/html/phpbb > Options FollowSymlinks AllowOverride All Require all granted </ Directory > ErrorLog ${APACHE_LOG_DIR}/phpbb_error.log CustomLog ${APACHE_LOG_DIR}/phpbb_access.log combined </ VirtualHost > $ sudo a2ensite phpbb $ sudo a2enmod rewrite $ sudo systemctl restart apache2 Secure phpBB 1. Firewall: $ sudo ufw status $ sudo ufw allow 22 && sudo ufw enable $ sudo ufw allow 80/tcp $ sudo ufw allow 443/tcp $ sudo ufw reload 2. TLS via Let's Encrypt: $ sudo apt install snapd -y $ sudo snap install --classic certbot

A Patroni cluster needs an odd number of nodes to maintain quorum — with 3 nodes, losing 1 still leaves a majority, so the cluster keeps running. This guide builds a 3-node PostgreSQL cluster on Ubuntu 24.04 with Patroni handling replication and automatic failover, etcd as the coordination store, and HAProxy load-balancing client connections — all secured with TLS. Prerequisites: three Ubuntu 24.04 servers (2 vCPU / 4GB RAM minimum) with PostgreSQL installed, non-root sudo access, and a domain with three A records: node1.example.com , node2.example.com , node3.example.com . Replace these placeholders with your actual subdomains throughout. Install Dependencies Run on all three nodes unless noted otherwise. 1. Install packages: $ sudo apt update $ sudo apt install haproxy certbot pipx -y $ sudo pip3 install --break-system-packages 'patroni[etcd3]' psycopg2-binary psycopg 2. Install etcd: $ wget https://github.com/etcd-io/etcd/releases/download/v3.6.4/etcd-v3.6.4-linux-amd64.tar.gz $ tar -xvf etcd-v3.6.4-linux-amd64.tar.gz $ sudo mv etcd-v3.6.4-linux-amd64/etcd etcd-v3.6.4-linux-amd64/etcdctl /usr/local/bin/ 3. Open firewall ports — 80 (Certbot), 2379/2380 (etcd), 5432/5433 (PostgreSQL + Patroni-managed PostgreSQL), 8008/8009 (Patroni REST API): $ sudo ufw allow 80,2379,2380,5432,5433,8008,8009/tcp $ sudo ufw reload $ sudo ufw status Configure SSL Certificates 1. Request a certificate per node (run on each node for its own subdomain): $ sudo certbot certonly --standalone -d node1.example.com -m admin@example.com --agree-tos --no-eff 2. Create a cert-prep script on each node (set HOSTNAME to that node's subdomain): $ sudo nano /usr/local/bin/prepare-ssl-certs.sh #!/bin/bash HOSTNAME = "node1.example.com" # Update for each node CERT_DIR = "/etc/letsencrypt/live/ $HOSTNAME " ARCHIVE_DIR = "/etc/letsencrypt/archive/ $HOSTNAME " getent group ssl-users > /dev/null || sudo groupadd ssl-users for user in etcd patroni haproxy postgres ; do if ! id " $user " > /dev/null 2>&1 &&

Laravel is a popular PHP framework with routing, authentication, and database management built in. This guide deploys a Laravel app behind Nginx on Ubuntu 24.04, wires it to MySQL, secures it with Let's Encrypt, and builds a small dashboard that queries live data. Prerequisites: Ubuntu 24.04 with Nginx and MySQL installed, a non-root sudo user, a domain A record (e.g. app.example.com ). Create the Database $ sudo mysql mysql > CREATE DATABASE laravel_demo ; mysql > CREATE USER 'laravel_user' @ 'localhost' IDENTIFIED WITH mysql_native_password BY 'secure_password' ; mysql > GRANT ALL ON laravel_demo . * TO 'laravel_user' @ 'localhost' ; mysql > FLUSH PRIVILEGES ; mysql > EXIT ; Seed a demo table to query later: $ mysql -u laravel_user -p mysql > USE laravel_demo ; mysql > CREATE TABLE server_stats ( id INT AUTO_INCREMENT , server_name VARCHAR ( 255 ), region VARCHAR ( 255 ), cpu_usage DECIMAL ( 5 , 2 ), memory_usage DECIMAL ( 5 , 2 ), status ENUM ( 'active' , 'maintenance' , 'offline' ), last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP , PRIMARY KEY ( id ) ); mysql > INSERT INTO server_stats ( server_name , region , cpu_usage , memory_usage , status ) VALUES ( 'app-01' , 'us-east' , 24 . 50 , 45 . 30 , 'active' ), ( 'db-01' , 'eu-west' , 12 . 75 , 78 . 20 , 'active' ), ( 'web-01' , 'ap-south' , 65 . 80 , 89 . 50 , 'active' ); mysql > EXIT ; Install Composer and PHP Extensions $ sudo apt update $ sudo apt install composer php php-curl php-fpm php-bcmath php-json php-mysql php-mbstring php-xml php-tokenizer php-zip -y $ composer --version $ php --version $ sudo systemctl restart php8.3-fpm php-fpm runs PHP as a service Nginx can talk to; php-mysql / php-mbstring / php-xml / php-tokenizer / php-zip cover Laravel's runtime requirements. Create the Laravel Project $ cd ~ $ composer create-project --prefer-dist laravel/laravel laravel-demo $ cd laravel-demo $ php artisan key:generate Edit .env : $ nano .env APP_NAME = laravel-demo APP_ENV = development APP_KEY = base64:APP