Operations on KnightLi Blog

Sync Local Markdown Notes with a Self-Hosted Git Server on a NAS

Sat, 30 May 2026 16:14:19 +0800

If you already have a local NAS and want to keep your notes as much as possible under your own control, you can put Markdown notes into a Git Server on the NAS and sync them with Android and Windows clients. This setup does not depend on public cloud drives, and it works well with note tools centered on local Markdown files, such as Obsidian, Markor, VS Code, and Typora.

The basic idea is simple:

Create a bare Git repository on the NAS as the central notes repository.
Clone the repository on Windows and write notes with a normal editor.
Clone the same repository on Android and use a Git client to pull and push.
Before switching devices, run pull; after writing, run commit and push.

This is not the most hands-off sync method, but it gives good control and clear version history. Once you build the habit of committing, you can keep notes, configuration, and image attachments on your own NAS for long-term storage.

Who This Setup Is For

This setup is suitable for people who:

Already have a NAS at home or in the office.
Mainly write notes as Markdown files.
Want note data stored inside a local network instead of only on a commercial cloud drive.
Need sync between Windows and Android devices.
Can accept basic Git operations such as clone, pull, commit, and push.

If you want fully automatic and invisible sync, Syncthing, WebDAV, or the built-in sync of a notes app may be easier. Git is better for a notes library where version history, rollback, migration, and control matter.

1. Install Git Server on the NAS

Different NAS systems expose this in different places, but the goal is the same: let the NAS provide a Git repository that can be accessed through SSH.

There are three common approaches:

Method	Suitable Scenario
Install Git Server from the NAS package center	Synology, QNAP, and other consumer NAS systems when you want less setup work
Deploy Gitea with Docker	You want a web UI, account management, and a more complete Git service
Use SSH + a bare repository directly	You only use it yourself and want something simple and stable

For personal note sync, SSH + a bare repository is usually enough. Suppose the NAS has a dedicated Git user named git, and repositories are stored under /volume1/git. On the NAS terminal, run:

1
2
3

mkdir -p /volume1/git/notes.git
cd /volume1/git/notes.git
git init --bare

A bare repository is not edited directly. It only acts as the sync center. The actual note-writing directory lives locally on Windows or Android.

Then confirm that SSH can access the NAS:

`1`	`ssh git@192.168.1.10`

If the NAS supports SSH public-key login, configure keys so you do not need to enter a password every time you push. Windows and Android can each generate their own SSH key, and then you can add the public keys to the NAS authorized_keys file or the Git Server user settings.

2. Windows Setup

On Windows, install Git for Windows first. Then choose a local directory for notes, such as D:\Notes.

Initial clone:

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git D:\Notes`

After entering the directory, you can create a basic structure:

1
2

cd D:\Notes
mkdir inbox, daily, projects, resources

Then open D:\Notes with Obsidian, VS Code, Typora, or another Markdown editor. After writing the first batch of notes, commit them:

1
2
3

git add .
git commit -m "初始化笔记库"
git push origin main

If the default branch is master, replace main with master in the command. You can also standardize it to main:

1
2

git branch -M main
git push -u origin main

For daily use, keep this rhythm on Windows:

git pull --rebase
git add .
git commit -m "更新笔记"
git push

3. Android Setup

On Android, use a client that supports Git to sync the local Markdown directory. Common choices include:

Tool	Usage
Termux	Most flexible, close to a Linux command line
MGit	Graphical Git client, suitable if you do not want to type many commands
GitJournal	More like a notes app, suitable for simple Markdown notes

If you choose Termux, first install Git and OpenSSH:

1
2

pkg update
pkg install git openssh

Generate an SSH key:

`1`	`ssh-keygen -t ed25519 -C "android-notes"`

Add the generated public key to the Git user authorization on the NAS. Then choose a local directory on the phone and clone the repository:

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git ~/notes`

If you want ordinary Android editors to access this directory, you can put the repository in shared storage, for example:

1
2

cd /sdcard
git clone git@192.168.1.10:/volume1/git/notes.git Notes

Then open /sdcard/Notes with Markor, Obsidian Android, or another Markdown editor. After editing on the phone, return to Termux and run:

cd /sdcard/Notes
git pull --rebase
git add .
git commit -m "手机更新笔记"
git push

Permissions and paths are the easiest sources of trouble on Android. Termux’s own home directory is more stable, but some editors may not access it directly. /sdcard is easier for editors to access, but permissions, file watching, and performance may be limited by the system. Test with a small number of notes before deciding on the final directory.

4. How Obsidian and Joplin Fit In

The NAS Git Server only solves where files live and how they sync. You still need to choose a notes app for writing. Here, the setup can be split into an Obsidian path and a Joplin path.

Setup	Sync Method	Best For	Notes
Obsidian + Git	The notes directory is the Git repository, and Windows and Android both pull the same repository	People who want backlinks, knowledge graphs, plugins, and pure Markdown files	On Android, test whether the Git client and Obsidian can access the same directory correctly
Joplin + Git	Do not put the Joplin database directly into Git; use Joplin’s own sync or export Markdown to Git regularly	People who want web clipping, end-to-end encryption, and a traditional notebook structure	Joplin’s local data is not a normal Markdown folder and is not suitable as a direct Git-synced notes library

Obsidian Setup

Obsidian is the best fit for this NAS Git sync setup. Its vault is essentially an ordinary folder containing Markdown files, image attachments, and configuration files. You can directly use D:\Notes or /sdcard/Notes as the Obsidian vault.

Windows workflow:

`1`	`git clone git@192.168.1.10:/volume1/git/notes.git D:\Notes`

Then open D:\Notes in Obsidian.

Android workflow:

1
2

cd /sdcard
git clone git@192.168.1.10:/volume1/git/notes.git Notes

Then open /sdcard/Notes in Obsidian Android.

Suggestions for the Obsidian setup:

For single-user use, you can commit .obsidian/ so themes, plugins, and some settings sync across devices.
If Android and Windows use very different plugins, commit only the note content and exclude device-state files such as .obsidian/workspace.json.
Put image attachments under attachments/ to avoid scattering them across directories.
Before opening Obsidian, run git pull --rebase; after writing, run commit and push.

You can prepare a .gitignore to reduce conflicts caused by device-state files:

1
2
3

.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/

Joplin Setup

Joplin works differently from Obsidian. Although it uses Markdown syntax, its local data is mainly managed by the application’s database. It is not a normal Markdown folder that can be synced directly with Git. Therefore, do not put Joplin’s configuration or database directory directly into a Git repository.

If you prefer Joplin, two safer approaches are:

Approach	Description
Use Joplin’s built-in sync	Sync through WebDAV, Nextcloud, Joplin Cloud, Dropbox, OneDrive, and similar options. The NAS can provide WebDAV or Nextcloud
Export Markdown to Git regularly	Use Joplin as the main notes app, regularly export notes as Markdown, and commit them to the NAS Git repository as a backup

If your NAS already has WebDAV or Nextcloud, connecting Joplin directly to the NAS for sync is smoother than Git. It can also enable end-to-end encryption, which is suitable for people who do not want to handle Git conflicts but still want data under their own control.

The recommended Joplin + NAS path is:

Enable WebDAV on the NAS or deploy Nextcloud.
Configure the same sync target on Joplin for Windows.
Configure the same sync target on Joplin for Android.
When versioned backup is needed, export Markdown to the Git repository regularly.

Simple rule of thumb:

Choose Obsidian if you want “local Markdown folder + backlinks + Git history”.
Choose Joplin if you want “traditional notes app + web clipping + encrypted sync”.
If you want the NAS Git Server as the main sync center, Obsidian is more suitable.
If you want the NAS to act as a private cloud sync backend, Joplin is more suitable.

5. Recommended Notes Directory Structure

Do not design the notes library too elaborately at the beginning. Start with a structure like this:

Notes/
  inbox/
  daily/
  projects/
  resources/
  attachments/
  README.md

The meaning is straightforward:

inbox/ stores temporary notes.
daily/ stores journals, logs, and daily records.
projects/ stores project notes.
resources/ stores long-term reference material.
attachments/ stores images, PDFs, and other attachments.

If you use Obsidian, you can use this directory directly as a vault. Whether to commit .obsidian/ depends on personal preference. For single-user multi-device use, committing it is fine. If plugins differ greatly across devices, commit only part of the configuration.

6. Avoiding Sync Conflicts

The key to syncing notes with Git is not complicated commands, but stable habits.

Recommended rules:

Before writing on another device, run git pull --rebase.
After a writing session, run commit and push promptly.
Do not edit the same file on two devices for a long time at the same time.
Do not keep adding unlimited images and large attachments into the Git repository.
Regularly keep another backup of the repository outside the NAS.

If a conflict happens, Git will mark the conflicting files. Markdown text conflicts are usually not hard to resolve, but the experience is worse on a phone, so try to resolve conflicts on Windows.

7. Do You Need Automatic Sync?

You can write a simple Windows script that chains pull, add, commit, and push. But for note sync, fully automatic commits are not recommended, because accidental deletions, empty commits, conflicts, and large attachments may all be pushed automatically.

A safer approach is semi-automatic:

Pull manually before opening notes.
Run a script to commit after writing.
Use a simple commit message that says what changed.

For example, you can prepare a sync-notes.ps1 on Windows:

git pull --rebase
git add .
git commit -m "更新笔记"
git push

If there are no changes, git commit will report nothing to commit. That is not a problem.

8. Pros and Cons of This Setup

Aspect	Description
Pros	Data stays on the local NAS, version history is clear, rollback is possible, migration is easy, and it suits Markdown
Cons	Requires understanding Git, conflicts need manual handling, and the mobile experience is not as smooth as cloud sync
Best for	Technical users, local-first notes, personal knowledge bases, project documentation
Not for	People who do not want to touch a command line, need real-time multi-user collaboration, or frequently sync large attachments

My Recommendation

If you only want to sync ordinary Markdown notes between Android and Windows, start with the smallest setup: one bare repository on the NAS, Git for Windows on Windows, and Termux or MGit on Android. Do not introduce complex permissions, automation scripts, or excessive categorization on day one.

After this workflow runs smoothly, then consider Gitea, automatic backups, per-device SSH key management, a separate attachment repository, scheduled tasks, and other extensions. The most important thing for a notes system is long-term stability, not filling it with every feature on the first day.

In one sentence: a NAS Git Server is suitable for turning Markdown notes into a local-first, traceable, and portable personal knowledge library. It is less effortless than cloud sync, but the control is clearer.

Choosing a Linux Server Distribution in 2026: Debian, Rocky Linux, AlmaLinux, and Ubuntu Server Compared

Thu, 07 May 2026 21:03:12 +0800

When choosing a Linux server distribution in 2026, the key question is not “which one is best,” but “which one fits your operations model.”

If you need the most stable community distribution, Debian remains one of the best choices. If you need the RHEL-compatible ecosystem but do not want to buy RHEL directly, Rocky Linux and AlmaLinux are the most natural CentOS successors. If you care most about cloud images, documentation, fast deployment, and newer packages, Ubuntu Server is still the easiest path.

Below is a practical comparison from a server perspective.

Quick Conclusion

Distribution	Best For	Main Strengths	Main Notes
Debian	Long-term stability, self-hosting, basic services	Stable, clean, strong community, deep free-software tradition	Default packages are conservative; enterprise commercial support is less explicit than RHEL/Ubuntu
Rocky Linux	RHEL-compatible production environments	Close to RHEL habits, suitable for enterprise CentOS migration	Conservative package cadence; desktop and new-tech experience are not the focus
AlmaLinux	RHEL-compatible production, cloud, enterprise replacement	RHEL compatible, active community, clear lifecycle	Still has some differences from RHEL; read release notes
Ubuntu Server	Cloud servers, containers, development deployment	Strong cloud support, rich docs, fast deployment, long LTS lifecycle	Snap, HWE kernels, and PPAs need team-wide rules

In one sentence:

Safest general-purpose choice: Debian.
Enterprise RHEL ecosystem replacement: Rocky Linux / AlmaLinux.
Cloud and development efficiency first: Ubuntu Server.

Debian: Rock-Solid Stability

As of May 2026, the current Debian stable release is Debian 13 trixie. Debian 12 bookworm has moved into oldstable and still receives security and LTS support, but new server deployments should generally start with Debian 13.

Debian’s characteristics have always been clear:

conservative default package selection;
clean system structure;
no strong commercial-vendor binding;
mature community governance;
well suited to long-running basic services.

Debian is comfortable if your servers mainly run:

Nginx / Apache;
PostgreSQL / MariaDB / Redis;
Docker / Podman;
WireGuard / Tailscale;
file services, backup services, monitoring services;
small self-hosted applications.

Debian’s advantage is not being “the newest,” but requiring less fuss. Many servers can run for years with normal security updates and minor maintenance.

Debian is suitable when:

you want the system to stay simple and not be too affected by vendor strategy;
you are familiar with apt, systemd, and Debian file layout;
you can accept software versions that are not the newest;
you care more about stability, security updates, and predictable upgrades.

Debian is less suitable when:

a vendor only certifies RHEL or Ubuntu;
you need enterprise commercial support with an SLA;
you depend on the newest kernel, GPU stack, or new hardware support;
your team has already built operations standards around the RHEL ecosystem.

My take: for personal servers, self-hosting, lightweight SaaS, and small-team infrastructure, Debian remains an excellent first choice.

Rocky Linux: A Steady CentOS Successor

Rocky Linux has a clear position: it serves users who need the RHEL-compatible ecosystem and continues the role that CentOS Linux played in enterprise production environments.

In 2026, both Rocky Linux 9 and Rocky Linux 10 are within their support periods. Rocky Linux 9 fits more conservative production environments, while Rocky Linux 10 is better for new projects, newer hardware, and a longer future runway.

Rocky Linux fits scenarios such as:

enterprise environments that previously ran CentOS 7 / CentOS 8;
RHEL-style directory structure, package names, and operations habits;
reliance on dnf, RPM, SELinux, and firewalld;
software vendors that explicitly support RHEL-compatible distributions;
internal automation scripts written around Enterprise Linux.

Its advantage is low migration friction. Many teams have years of CentOS-based Ansible playbooks, monitoring rules, audit scripts, and security baselines. Moving to Rocky Linux is mentally much easier than moving to Debian or Ubuntu.

Things to note about Rocky Linux:

packages are conservative by design; this is a feature of Enterprise Linux, not a flaw;
very new user-space components may require EPEL, third-party repositories, or containers;
RHEL compatibility does not mean every commercial software vendor automatically offers formal support, so check certification lists;
Rocky Linux 10 has new hardware baselines and ecosystem requirements, so validate before production.

My take: if your server environment is already CentOS / RHEL based, Rocky Linux is a very natural replacement, especially for stable production environments and internal enterprise services.

AlmaLinux: A More Proactive RHEL-Compatible Route

AlmaLinux is another important CentOS successor. It is also enterprise-grade, long-term supported, and RHEL compatible.

It shares many traits with Rocky Linux:

both target the RHEL-compatible ecosystem;
both fit server production environments;
both have long-term 8, 9, and 10 release lines;
both are suitable for CentOS migration;
both can use a large set of Enterprise Linux ecosystem tools.

The difference is that AlmaLinux is more proactive in documenting and handling upstream differences while remaining RHEL compatible. For example, AlmaLinux 10 provides an x86-64-v2 architecture option for older hardware and clearly documents differences from RHEL in release notes.

This is useful for some users: they want to stay in the RHEL ecosystem but also want a community distribution with more flexibility around hardware support, package builds, and EPEL compatibility.

AlmaLinux is suitable when:

you need RHEL compatibility but do not want to be fully constrained by RHEL release strategy;
you value community governance and transparent release notes;
you need a stable base system for cloud platforms, container images, and enterprise workloads;
you want a smooth migration from CentOS or older Enterprise Linux.

The key caution: AlmaLinux is not “identical to RHEL with your eyes closed.” For strict compliance, vendor certification, database certification, or hardware certification scenarios, check whether the software vendor explicitly supports AlmaLinux.

My take: both Rocky Linux and AlmaLinux can replace CentOS. If you prefer a more conservative and traditional CentOS-style story, look at Rocky. If you value community transparency and a more flexible compatibility route, look at AlmaLinux.

Ubuntu Server: Best Cloud Support and Deployment Efficiency

Ubuntu Server’s advantage is practical: cloud platforms, documentation, community tutorials, images, automation tools, and developer ecosystem are all strong.

For new server deployments in 2026, the main choice is still Ubuntu 24.04 LTS. Ubuntu LTS usually has 5 years of standard support and can be extended through ESM. For cloud servers, container hosts, development environments, and CI/CD nodes, Ubuntu Server is often the fastest to get working.

Ubuntu Server fits:

AWS, Azure, Google Cloud, Oracle Cloud, Alibaba Cloud, Tencent Cloud, and other cloud servers;
Docker, Kubernetes, GitLab Runner, CI/CD;
AI / GPU / CUDA development environments;
teams that need abundant tutorials and community recipes;
environments where development and production should stay similar.

Ubuntu’s strengths:

high-quality cloud images;
lots of official and third-party documentation;
often more active new hardware support;
clear LTS cadence;
convenient developer toolchain updates;
many commercial software vendors provide Ubuntu installation instructions first.

Things to watch:

not every team likes Snap on servers, so decide your policy in advance;
PPAs are convenient, but overusing them in production increases maintenance risk;
choose clearly between HWE kernel, cloud kernel, and standard kernel;
for minimal-stability purists, Ubuntu’s default system feels busier than Debian.

My take: if you mainly run cloud servers, containers, development deployment, or AI toolchains, Ubuntu Server is usually the most efficient choice. It is not the most “pure” distribution, but it reduces lookup time and friction for many tasks.

How to Choose Among the Four

Personal VPS / Self-Hosting

Debian or Ubuntu Server first.

If you want stability, low maintenance, and less fuss, choose Debian. If you often follow tutorials to deploy new projects or need a newer software stack, choose Ubuntu Server.

Enterprise Production

Rocky Linux, AlmaLinux, or RHEL first.

If the company used CentOS before, migration to Rocky / Alma is the cheapest path. If commercial databases, hardware certification, security compliance, or vendor support are involved, check certification lists first.

Cloud Native and Container Hosts

Ubuntu Server, Debian, and Rocky / Alma can all work.

If the team values development efficiency, choose Ubuntu Server. If you want minimal stability, choose Debian. If the enterprise standard is RHEL-based, choose Rocky / Alma.

AI / GPU Servers

Look at Ubuntu Server first, then Rocky / Alma.

The reason is simple: NVIDIA, CUDA, PyTorch, TensorFlow, driver installation tutorials, and community experience are usually richest on Ubuntu. Enterprise GPU clusters built around the RHEL ecosystem can choose Rocky / Alma, but drivers, CUDA, container runtime, and monitoring tools should be validated in advance.

Traditional Business Systems

Rocky Linux / AlmaLinux first.

Traditional Java, databases, middleware, commercial software, auditing, and operations standards often lean toward the RHEL ecosystem. In that case, Rocky / Alma fits existing systems more easily than Debian / Ubuntu.

What to Check Before Choosing

Do not choose only by distribution name. For server selection, judge by these questions:

Lifecycle: until which year is this version maintained?
Upgrade path: is major-version upgrade mature? Is smooth migration supported?
Software sources: do you rely on third-party repositories? Who maintains them?
Security updates: are security advisories, patch cadence, and CVE handling clear?
Hardware support: have CPU, NIC, RAID, GPU, and storage controllers been validated?
Team experience: is the team more familiar with apt or dnf? Debian-style or RHEL-style systems?
Vendor certification: does the business software explicitly support this distribution?
Automation assets: can existing Ansible, Terraform, and image-building scripts be reused?

The real cost is often not the installation ISO. It is upgrades, audits, troubleshooting, and handover over the next five years.

My Default Recommendations

If I had to give a default 2026 server selection guide:

Scenario	Recommendation
Personal VPS, self-hosting	Debian 13
Cloud server, fast deployment	Ubuntu Server 24.04 LTS
CentOS migration	Rocky Linux 9 / AlmaLinux 9
New enterprise project	Rocky Linux 10 / AlmaLinux 10, after ecosystem validation
AI / GPU development	Ubuntu Server 24.04 LTS
Strict-compliance commercial production	RHEL, or Rocky / Alma after vendor support is confirmed

Short Conclusion

Debian’s keywords are stability, simplicity, community, and free-software tradition. It is suitable for long-running base servers.

Rocky Linux and AlmaLinux are about RHEL compatibility, enterprise production, and CentOS replacement. They fit teams that already have Enterprise Linux operations systems.

Ubuntu Server is about cloud, documentation, development efficiency, and ecosystem completeness. It fits fast deployment, containers, AI/GPU, and cloud servers.

There is no forever-correct distribution. There is only the distribution that best matches your team, business, hardware, and lifecycle. The best server choice is usually not the hottest one, but the one you will still be willing to maintain five years later.

Debian Releases: https://www.debian.org/releases/
Ubuntu Releases: https://releases.ubuntu.com/
Rocky Linux Release and Version Guide: https://wiki.rockylinux.org/rocky/version/
AlmaLinux Release Notes: https://wiki.almalinux.org/release-notes/

Nginx Rate Limiting: Add rate limit for high-frequency 404 and 400 scan requests

Fri, 01 May 2026 05:41:31 +0800

If your website logs suddenly show a large number of 404 and 400 responses, the cause is often not normal users clicking broken links. It is usually an automated scanner probing paths such as .env, .git, wp-admin, phpmyadmin, and xmlrpc.php.

These requests create several problems:

access log grows quickly
error log fills with useless noise
static sites or reverse proxy services waste connections on invalid requests
real issues get buried under scan noise

Nginx can use limit_req and limit_conn to control this. But first, one point matters: Nginx cannot natively rate-limit directly by “response status code is 404 or 400”, because rate limiting happens before the response is generated.

The practical approach is to rate-limit scan paths, suspicious sources, and high-frequency site-wide requests before they produce 404 / 400 responses.

Basic idea

Use three layers:

Apply gentle site-wide rate limiting to prevent one IP from hammering the site.
Apply strict rate limiting to common scan paths and return 404 directly.
Limit concurrent connections per IP.

A safer rollout order is: first add the scan path rule and access_log off, observe for one day, and only add site-wide limit_req if there are still many random-path 404 requests.

Define rate-limit zones in http first

limit_req_zone and limit_conn_zone must be placed inside http {}. They cannot be placed inside a single site’s server {}.

You can add them directly to the http {} block in /etc/nginx/nginx.conf:

http {
    # 按客户端 IP 限速，普通页面请求
    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;

    # 更严格：疑似扫描路径
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;

    # 并发连接限制
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

You can also create a new file:

`1`	`sudo nano /etc/nginx/conf.d/limit-zones.conf`

Write:

1
2
3

limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

This assumes your nginx.conf really includes this inside http {}:

`1`	`include /etc/nginx/conf.d/*.conf;`

Then use the zones in server

A site config file is usually something like /etc/nginx/sites-enabled/www.example.com, and it usually contains server {}. Do not write limit_req_zone there. Only use zones already defined earlier.

Example:

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    # 全站温和限速：允许短时突发，降低误伤正常用户的概率
    limit_req zone=perip_general burst=30 nodelay;
    limit_conn addr_conn 20;

    # 对常见扫描路径严格限速，并关闭访问日志
    location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
        access_log off;
        limit_req zone=perip_scan burst=5 nodelay;
        return 404;
    }

    # 你原来的 location /、listen ssl 等配置继续放这里
}

If you are worried about hurting normal traffic with site-wide rate limiting, start with only the scan path rule:

location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
    access_log off;
    limit_req zone=perip_scan burst=5 nodelay;
    return 404;
}

What these parameters mean

This line:

`1`	`limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;`

means:

limit_req_zone: defines the accounting zone for request rate limiting.
$binary_remote_addr: uses client IP as the rate-limit key, and uses less memory than $remote_addr.
zone=perip_general:20m: creates a shared memory zone named perip_general with size 20m.
rate=5r/s: each IP is allowed an average of 5 requests per second.

This line:

`1`	`limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;`

is similar, but stricter:

perip_scan: used specifically for suspicious scan paths.
rate=1r/s: each IP is allowed only 1 request per second.

This line:

`1`	`limit_conn_zone $binary_remote_addr zone=addr_conn:20m;`

means:

limit_conn_zone: defines the accounting zone for concurrent connection limits.
$binary_remote_addr: still counts by client IP.
zone=addr_conn:20m: creates a connection-counting shared memory zone named addr_conn.

The actual concurrent connection limit is:

`1`	`limit_conn addr_conn 20;`

It means each IP can have at most 20 simultaneous connections.

Understanding burst and nodelay

For example:

`1`	`limit_req zone=perip_general burst=30 nodelay;`

You can read it like this:

rate=5r/s: the long-term average rate is 5 requests per second.
burst=30: allow 30 extra requests during a short burst.
nodelay: when requests exceed the average rate but are still within burst, process them immediately instead of queueing; reject only after burst is exceeded.

Without nodelay, Nginx tries to delay and queue some requests. For ordinary web pages, nodelay is usually easier to reason about. For APIs or especially sensitive endpoints, adjust according to actual behavior.

Common error: limit_req_zone in the wrong place

If you see this error:

`1`	`2026/04/30 21:33:48 [emerg] 2290771#2290771: "limit_req_zone" directive is not allowed here in /etc/nginx/sites-enabled/example.com:9`

It means limit_req_zone was written in a context where it is not allowed.

A common incorrect configuration is placing it inside server {}:

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;

    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;
}

This will not work.

One-line memory aid:

limit_req_zone defines the pool, so put it in http {}.
limit_req uses the pool, so put it in server {} or location {}.
limit_conn_zone defines the connection pool, so put it in http {}.
limit_conn uses the connection pool, so put it in server {} or location {}.

Temporarily block clearly abnormal IPs

If the logs confirm that several IPs are continuously sending scan requests, you can temporarily block them:

deny 45.95.42.164;
deny 185.177.72.51;
deny 185.177.72.5;
deny 185.177.72.56;
deny 185.177.72.58;

These deny directives can be placed inside server {} or a specific location {}. Whether to keep them long term depends on false-positive risk and traffic sources.

Check and reload

Check the configuration first:

`1`	`sudo nginx -t`

If there is no error, reload:

`1`	`sudo systemctl reload nginx`

Do not restart the service directly. reload lets Nginx load the new configuration gracefully, which is safer.

Recommended parameters

For a personal site or static site, start with:

normal pages: rate=5r/s to 10r/s
scan paths: rate=1r/s
scan path burst=5
site-wide burst=30
per-IP concurrency: 10 to 20

If normal traffic is very low, the settings can be stricter. If the site has many images, scripts, or API requests, loosen the normal page limit to avoid hurting real users.

The safest approach is a staged rollout:

First apply access_log off + return 404 to scan paths.
Then add strict perip_scan rate limiting.
Observe logs for one day.
If random-path 404s are still heavy, enable gentle site-wide rate limiting.

Ubuntu 26.04 LTS GPU and Hardware Updates: CUDA, ROCm, DPC++, and More Platform Changes

Sun, 26 Apr 2026 19:35:57 +0800

If the previous article worked as a desktop-focused overview of Ubuntu 26.04 LTS, this one is better read as its hardware and compute-side follow-up. In this 26.04 cycle, Ubuntu pushed a number of AI, GPU computing, and platform compatibility changes into the main archive or formal support scope.

The short version is this: the most important part of this round is not just desktop and kernel upgrades, but that Ubuntu is bringing Intel, NVIDIA, and AMD GPU computing stacks into the distribution in a more systematic way.

Starting with 26.04, Intel’s open-source oneAPI DPC++ compiler is available directly from Ubuntu Archive for building SYCL code. Its runtime also includes adapters for Intel GPUs.

Two related components are also now available from Ubuntu repositories:

oneDPL, the DPC++ library, which provides higher-productivity developer APIs
oneDNN, built with dpclang-6, which can run on Intel GPUs

That means if you are already working with SYCL, heterogeneous computing, or AI workloads on Intel GPUs, Ubuntu now offers a more direct path instead of forcing you to maintain a separate external stack for everything.

Ubuntu also calls out one practical requirement: users need to be in the render group to actually use these Intel GPU-related capabilities.

2. The NVIDIA CUDA toolkit can now be installed directly with `apt`

For many developers and operators, this may be one of the most immediately useful changes in the notes.

Starting with 26.04, the NVIDIA CUDA toolkit can now be installed directly from Ubuntu Archive:

`1`	`sudo apt install cuda-toolkit`

The value here is bigger than just saving a few setup steps.

For developers shipping software on Ubuntu, this new model means they can simply declare a dependency on the CUDA runtime, while Ubuntu manages installation and compatibility at the distribution level. That makes CUDA feel more like a native system capability on Ubuntu, rather than an extra software layer that always has to be maintained separately.

3. AMD ROCm 7.1.0 is now in Universe

On the AMD side, Ubuntu Universe now includes ROCm 7.1.0.

These libraries mainly provide:

backend infrastructure for AI training and inference on AMD GPUs
software foundations for machine learning and high performance computing

Canonical also notes that ROCm-related components are continuously tested in its CI/CD pipeline. Beyond autopkgtests, that includes several user-space applications such as:

llama.cpp
pytorch
Blender
Lemonade Server

That detail matters, because it shows Ubuntu is not just dropping packages into the archive. It is validating ROCm as a maintainable software stack.

4. The bigger story is that all three GPU ecosystems are landing

It becomes easier to see the direction of 26.04 when DPC++, CUDA, and ROCm are viewed together:

Intel: bringing SYCL / oneAPI components into official repositories
NVIDIA: giving the CUDA toolkit a distribution-managed installation path
AMD: shipping ROCm 7.1.0 in Universe with ongoing testing

If you work with these kinds of workloads on Ubuntu, this release will probably feel more relevant:

local LLM inference
GPU-accelerated training or fine-tuning
Blender, scientific computing, and HPC
development environments that need to move across different GPU platforms

In other words, Ubuntu is no longer just “a system where you can install a GPU driver.” It is starting to carry a fuller user-space software stack for AI and GPU computing.

5. NVIDIA Dynamic Boost is enabled by default

Since 25.04, Dynamic Boost has been enabled by default on supported NVIDIA laptops.

The idea is straightforward: depending on system load, power can be shifted dynamically between the CPU and GPU. In gaming scenarios, that usually means giving more power to the GPU when needed to extract more performance.

It only applies under two conditions:

the laptop is connected to AC power
the GPU load is high enough

It does not engage while the system is running on battery.

6. Support for new Intel integrated and discrete GPUs keeps moving forward

Ubuntu also continues expanding support for new Intel GPUs, including:

Integrated:

Intel Core Ultra Xe2
Intel Core Ultra Xe3

Discrete:

Intel Arc 5 B570
Intel Arc 5 B580
Intel Arc Pro B50
Intel Arc Pro B60
Intel Arc Pro B65
Intel Arc Pro B70

Ubuntu also highlights several features already available around these devices:

improved GPU and CPU ray tracing performance through Intel Embree, benefiting applications such as Blender 4.2+
hardware video encoding for AVC, JPEG, HEVC, and AV1 on “Battlemage” devices
a new CCS optimization in Intel Compute Runtime
enabled debugging support for Intel Xe GPUs

If you are watching follow-up releases, 25.10 also continues to bring in more capabilities, including:

initial support for Intel’s next-generation client platform codenamed Panther Lake through Linux kernel 6.17
improved IOMMU, PCIe subsystem, and multi-GPU support
Mesa 25.2.3 enabling VK_KHR_shader_bfloat16 for Battlemage and Panther Lake
intel-media-driver 25.3.0 adding Panther Lake decode support and VP9 encoding
intel-compute-runtime 25.31 adjusting the Level Zero USM pool and local device memory event allocation behavior
level-zero 1.24 and level-zero-raytracing 1.1.0 bringing broader spec and RTAS extension support

7. Suspend and resume is more stable on Nvidia desktops too

Starting with 25.10, Ubuntu enables suspend-resume support in the proprietary Nvidia driver to reduce corruption and freezing when waking a desktop system.

This is not the most visible kind of change, but it matters a lot in everyday use, especially on desktops that stay on for long periods and frequently suspend and resume.

8. ARM, Raspberry Pi, RISC-V, and IBM Z also get harder platform-level changes

Beyond the GPU software stack, the release notes also include several platform-level changes worth calling out separately.

ARM64 desktop platforms

Starting with 25.10, the ARM64 linux-generic kernel provides broader desktop compatibility for ARM64 desktop platforms that boot through UEFI.

A new Raspberry Pi boot layout

One change introduced in 25.10 and refined in 26.04 is a new boot partition layout for Raspberry Pi systems.

Its goal is to improve boot reliability: newly written boot assets are first “tested” before they are committed as the new “known good” set.

The firmware date requirements are the part most users will want to remember:

Pi 3 / 3+ / CM3+ / Zero 2W: no additional action required, the boot firmware is in the image itself
Pi 4 / 400 / CM4: boot firmware must be dated no earlier than 2022-11-25
Pi 5 / 500 / CM5: boot firmware must be dated no earlier than 2025-02-11

You can check it with:

`1`	`sudo rpi-eeprom-update`

If the firmware is too old and you are using Ubuntu 24.04 LTS or newer, you can update it like this:

1
2

sudo rpi-eeprom-update -a
sudo reboot

Raspberry Pi desktop images now use desktop-minimal

Since 25.10, Ubuntu Desktop images for Raspberry Pi are based on desktop-minimal rather than the full desktop seed.

Ubuntu gives a very concrete benefit here: the default app set is smaller, saving about 777MB on the uncompressed image and on installed systems.

If you want to remove that default app set in bulk after upgrading, you can use:

`1`	`sudo apt purge ubuntu-desktop --autoremove`

If you want to keep some of those applications, just mark them as manually installed with apt first.

Swap on Raspberry Pi is now handled by cloud-init

Since 25.10, swap file creation on Raspberry Pi desktop images is handled by cloud-init.
If you want to customize swap size before first boot, you can edit user-data on the boot partition directly.

RISC-V requirements have moved up

Starting with 25.10, the RISC-V build of Ubuntu 26.04 LTS requires hardware that implements the RVA23S64 ISA profile.

Systems that do not meet that requirement can no longer run Ubuntu 26.04 LTS. If you still have boards based on earlier RVA20 processor cores, you need to stay on the support line provided by Ubuntu 24.04 LTS.

According to Ubuntu, as of April 2026, there is still no real RVA23S64 hardware available. So the only currently supported platform is effectively a QEMU virtualized environment configured with -cpu rva23s64.

IBM Z now requires z15 at minimum

Starting with 26.04, the minimum requirement for the s390x architecture has moved up to z15.

That means:

z14 / LinuxONE II and older systems can no longer install Ubuntu 26.04 LTS
z15 / LinuxONE III and newer systems should see better performance

9. Who should read this first

This article is more useful than the desktop overview if you fall into any of these cases:

you use Ubuntu for CUDA, ROCm, SYCL, or local AI inference
you do development or compute work on Intel, NVIDIA, or AMD GPUs
you maintain Raspberry Pi, ARM64, RISC-V, IBM Z, or other non-standard x86 platforms
you are especially sensitive to repository availability, driver behavior, runtimes, and platform requirements after an upgrade

10. One-line takeaway

The key point of Ubuntu 26.04 LTS on the hardware and AI stack side is not that one GPU vendor got a standout upgrade. It is that Intel’s DPC++, NVIDIA’s CUDA, and AMD’s ROCm are all entering the Ubuntu ecosystem in a more official, in-repository, and maintainable way.

If you used to think of Ubuntu as “the system first, then I assemble the GPU environment myself,” 26.04 starts to look more like a distribution that is willing to actively carry AI and heterogeneous computing workloads.

Ubuntu 26.04 LTS Released: Major Desktop Updates with GNOME 50 and Linux 7.0

Sun, 26 Apr 2026 16:10:25 +0800

Ubuntu 26.04 LTS was released on April 23, 2026, under the codename Resolute Raccoon. This is the new long-term support release, with standard support through April 2031. If you use Ubuntu Pro, security maintenance can be extended to 10 years.

If you are upgrading from Ubuntu 24.04 LTS, this is more than a routine release. It also folds in the major changes introduced across 24.10, 25.04, and 25.10. So this article works best as a quick guide to what is worth checking before you upgrade.

If you only want the biggest takeaways from this release, remember these four points first:

GNOME 50 has landed in an LTS release, bringing clearer improvements to desktop experience and display support
Linux kernel 7.0 becomes the new baseline, refreshing both hardware support and the long-term maintenance base
Ubuntu Desktop has now fully moved to Wayland
The default app set has been refreshed across the board, with major updates to Firefox, LibreOffice, Thunderbird, and GIMP

1. Start with the key updates

Ubuntu 26.04 LTS is a long-term support release with standard support through 2031-04
The desktop environment has been updated to GNOME 50
The generic kernel has moved to Linux kernel 7.0
Ubuntu Desktop now provides only a Wayland session
Older versions cannot jump directly to 26.04

If you are still on Ubuntu 22.04 LTS or 25.04, the official recommendation is to upgrade to Ubuntu 24.04 LTS or 25.10 first, then continue to 26.04 LTS.

2. Biggest change #1: GNOME 50 is now in LTS

The most visible desktop-side change this time is that GNOME 50 has finally entered an LTS release. For most users, the value is not one flashy standalone feature, but a smoother desktop experience overall:

Better usability on small screens and narrow windows
Notifications can be grouped by app
Continued improvements to HDR, VRR, and fractional scaling
Better smoothness and stability in remote desktop, Wayland, and NVIDIA-related scenarios
Stronger accessibility support, including clear updates to the Orca screen reader

Ubuntu has also added a few practical changes of its own:

GNOME Shell global search can directly find available snap apps
Web searches can also be triggered directly from search
The Yaru theme continues moving closer to upstream GNOME styling
Permissions, file access, and drag-and-drop behavior for snap apps feel more natural on the desktop

If you mainly use the desktop edition, the real point of this LTS is not a dramatic visual overhaul. It is that many small frictions from the past have been polished away together.

3. Biggest change #2: the default apps got a broad refresh

Compared with 24.04 LTS, the built-in app set in 26.04 LTS has been updated in a big way:

Firefox moves to 150
LibreOffice goes from 24.2 to 25.8
Thunderbird moves to 140
GIMP jumps from 2.10 to 3.2

There are also several replacements that matter in day-to-day use:

The PDF viewer is now Papers, replacing Evince
The image viewer is now Loupe
The terminal is now Ptyxis
The system monitor is now Resources
The default video player is now Showtime

The direction behind these changes is clear: Ubuntu is leaning more fully into a new generation of GNOME applications built on GTK4, libadwaita, and in some cases Rust-based rewrites.

4. Biggest change #3: Wayland is now the only desktop session

This is the most important change for many long-time users.

The shift that started in 25.10 is now fully settled in 26.04 LTS: Ubuntu Desktop runs only on the Wayland backend, because GNOME Shell can no longer run as an X.org session.

That does not mean old applications suddenly stop working. The official notes make it clear that X.org applications can still run through the XWayland compatibility layer. But if your workflow still depends on older graphics drivers, certain remote desktop methods, screen recording tools, or input method details, this is still something you should verify before upgrading.

5. Biggest change #4: Linux kernel 7.0 and the lower stack move forward together

The GA generic stack in Ubuntu 26.04 LTS moves from Linux 6.8 to Linux 7.0, and the HWE stack is also unified on 7.0.

Among the lower-level changes highlighted by Ubuntu, the most relevant ones for general users and operators are:

Crash dump is enabled by default on both desktop and server
sched_ext introduces a new scheduler extension model that lets developers implement scheduling policies with eBPF
The linux-lowlatency binary package is being retired, replaced by linux-generic plus the user-space lowlatency-kernel package for low-latency tuning
The amd64v3 architecture variant is available as an option, but still opt-in by default

If your machine is relatively new, amd64v3 is worth keeping an eye on. The official notes give this enablement method:

1
2
3

echo 'APT::Architecture-Variants "amd64v3";' | sudo tee /etc/apt/apt.conf.d/99enable-amd64v3
sudo apt update
sudo apt upgrade

That said, it is not enabled automatically. Ubuntu is still prioritizing compatibility first.

6. Hardware requirements and install baseline

The official recommended baseline for Ubuntu Desktop 26.04 LTS is:

A 2 GHz dual-core processor or better
At least 6 GB RAM
At least 25 GB of available storage

If your machine is on the lighter side, the official recommendation is to consider Ubuntu flavors such as Xubuntu or Lubuntu.
The server edition has a lower floor. The documentation notes it can start from 1.5 GB RAM and 4 GB of storage, though the real requirement still depends on your workload.

7. Who should prioritize upgrading

If you are already on 24.04 LTS and want the following, 26.04 LTS is worth a close look:

A full-generation desktop stack refresh instead of minor patching
More mature Wayland and display support
A more up-to-date default application set
A newer kernel with a longer support runway

But if you still depend heavily on older X11 workflows, special drivers, or custom desktop extensions, or if your production environment is extremely conservative about changes, it is still best to do a compatibility pass before upgrading.

8. One-line summary

The value of Ubuntu 26.04 LTS is not one especially flashy headline feature. It is that Ubuntu has rolled two years of desktop, kernel, application, and compatibility progress into a new LTS baseline all at once.

If you want the shortest possible judgment, it is this: this is an Ubuntu LTS release that feels broadly newer and more stable as a whole, rather than one built around a single standout feature.

Official release notes: https://documentation.ubuntu.com/release-notes/26.04/
Summary for LTS users: https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users/

Understanding the nftables Framework: Tables, Chains, Rules, and Sets

Sat, 18 Apr 2026 10:31:12 +0800

When learning nftables, it is easy to start with command details: how to add a rule, how to delete a handle, or how to write a port match. Commands matter, but if you understand the framework first, reading rules, troubleshooting, and designing rule sets become much easier.

You can think of nftables as a layered structure:

table isolates rule namespaces.
family decides which network protocols the rules apply to.
chain decides at which stage rules are executed.
rule defines the actual match and action.
set, map, and verdict map reduce repeated rules and make rule sets easier to maintain.

The following sections explain these concepts layer by layer.

table: Rule Namespace

table is the outermost rule container in nftables. Different tables are isolated from each other, so a common practice is to put related rules into the same table.

For example, you can separate filtering rules, NAT rules, or custom testing rules. This keeps boundaries clear: when debugging, you know which group of rules you are changing; when cleaning up, you are less likely to delete unrelated content by mistake.

A table itself does not directly process packets. The chain and rule objects inside the table are what actually participate in packet processing.

family: Which Protocols the Rules Apply To

When creating a table, you need to choose a family. It determines what kind of packets the rules in the table apply to.

Common families can be understood this way:

ip: handles IPv4 only.
ip6: handles IPv6 only.
inet: handles both IPv4 and IPv6.
arp: handles ARP.
bridge: handles bridge-layer traffic.
netdev: closer to the network device ingress path, suitable for handling traffic at an earlier stage.

For ordinary firewall rules, inet is commonly used. It lets you keep IPv4 and IPv6 rules in the same table and avoids maintaining two similar rule structures.

chain: Where Rules Are Executed

chain is a list of rules. After a packet enters a hook, it passes through the rules in the chain in order.

Chains can roughly be divided into two types:

Base chain: attached to a hook in the kernel network path and actively called by the packet flow.
Regular chain: not directly attached to a hook; it must be called by jumps from other rules.

A base chain usually specifies several key properties:

type: the purpose of the chain, such as filter, nat, or route.
hook: the processing stage, such as prerouting, input, forward, output, or postrouting.
priority: when multiple chains exist on the same hook, this decides which runs first.
policy: the default action when no rule matches, commonly accept or drop.

The key point is that rules do not take effect just anywhere. The same rule has completely different meaning when placed in input, forward, or output.

rule: Match Conditions Plus Actions

rule is where nftables actually makes decisions. It usually consists of two parts:

Match conditions: source IP, destination IP, protocol, port, interface, connection state, and so on.
Actions: accept, drop, reject, counter, jump, return, and so on.

Rules are evaluated in order. After a packet matches an action that terminates processing, subsequent rules are no longer evaluated. If nothing matches, evaluation continues until the chain ends or the default policy is triggered.

This is why rule order matters: more specific rules usually need to appear before broader rules, otherwise they may never get a chance to run.

set: Group Values Together

If you need to match many IP addresses, ports, or interfaces, writing many separate rules becomes hard to maintain. set lets you manage a group of values of the same type in one place.

For example, a group of trusted IPs, a group of blocked ports, or a group of addresses that need rate limiting can all be stored in a set. The rule only needs to check whether a value belongs to that set.

The benefits of set are:

Fewer rules.
Better readability.
Easier element additions and removals later.

When a rule set contains many repeated conditions, it is usually time to consider set.

map: Map a Matched Value to a Result

map can be understood as a lookup table. It returns a result based on an input value.

For example, different ports can map to different marks, or different addresses can map to different processing parameters. Compared with writing many if/else-style rules, map is more centralized and easier to maintain.

set answers “is this value in the collection”; map answers “what result corresponds to this value”.

verdict map: Map a Matched Value to an Action

verdict map is an important use of map: it maps a matched value to a verdict, which means a rule action.

For example, different IP ranges can correspond to accept, drop, or jumps to different chains. This can compress many branches into one structure.

When a rule set grows more complex, verdict map is very useful. It reduces repeated rules and expresses policy more like a table rather than a long list of conditional statements.

Designing Rules from the Concepts

When designing nftables rules, you can think in this order:

First decide which family the rules belong to.
Then decide which table they should go into.
Choose the proper hook and chain.
Write the concrete rule.
If there are many repeated conditions, introduce set, map, or verdict map.

Rules written this way are easier to maintain and easier to troubleshoot.

Summary

nftables concepts are not complicated, but the hierarchy matters:

table defines rule boundaries.
family defines protocol scope.
chain defines execution position.
rule defines matching and action.
set, map, and verdict map manage complexity.

Understand these concepts first, then look at concrete commands. That is more reliable than memorizing commands directly. Especially after a rule set grows, clear concepts help you determine whether a problem is in protocol scope, execution stage, rule order, or the match condition itself.

References

https://docs.redhat.com/zh-cn/documentation/red_hat_enterprise_linux/10/html/configuring_firewalls_and_packet_filters/concepts-in-the-nftables-framework

nftables Quick Start: Tables, Chains, Rules, and Common Operations

Sat, 18 Apr 2026 10:22:07 +0800

nftables is a common packet filtering and firewall rule management tool on Linux. If you only need device access control, traffic counters, port matching, or basic rate limiting, you do not need to learn the entire rule system at once. Start with three concepts:

table: a container for rules.
chain: where rules are evaluated, usually attached to a hook.
rule: the actual matching condition and action.

This article outlines a minimal workflow that is suitable for testing first in a safe environment.

Basic Structure

Prepare a few variables first. The following commands reuse them:

table=customtable
chain=custom_control
target=drop
ip=192.168.18.251
mac=00:00:01:02:03:04

Create an inet table that supports both IPv4 and IPv6:

`1`	`nft add table inet $table`

Then create a chain attached to the forward stage:

`1`	`nft add chain inet $table $chain { type filter hook forward priority 0\; }`

Here, type filter means this is a filtering rule chain, and hook forward means it processes forwarded packets.

Common Matching Methods

Match by source IP. This is usually useful for the upload direction:

`1`	`nft add rule inet $table $chain ip saddr $ip $target`

Match by destination IP. This is usually useful for the download direction:

`1`	`nft add rule inet $table $chain ip daddr $ip $target`

When matching by MAC address, ether saddr can be used to control upstream traffic:

`1`	`nft add rule inet $table $chain ether saddr $mac $target`

Note that in networks involving bridging, forwarding, or address translation, downstream packets may not always be reliably filtered by destination MAC. For device access control, start by validating ether saddr or IP-based rules first.

To match ports, you can cover both TCP and UDP:

`1`	`nft add rule inet $table $chain { tcp, udp } dport 22 $target`

To match a port range, use a comparison expression:

`1`	`nft add rule inet $table $chain tcp dport \>= 1024 $target`

Count Traffic for One Device

If you only want to count upload and download traffic for an IP address, use counter return. After a match, it records the counter and returns, which can reduce further matching overhead when more statistic rules exist later.

1
2

nft add rule inet $table $chain ip saddr $ip counter return
nft add rule inet $table $chain ip daddr $ip counter return

View the statistics:

`1`	`nft list chain inet $table $chain`

If you need to see the handle for each rule, add -a:

`1`	`nft -a list chain inet $table $chain`

handle is important because nftables usually relies on it to delete a single rule.

Basic Rate Limiting

Rate limiting can be done with limit rate over. For example, limit traffic over a specified rate by MAC address:

rate=10
unit=mbytes

nft add rule inet $table $chain ether saddr $mac limit rate over $rate $unit/second drop

Here, mbytes and kbytes can be understood as the usual M and K units. You do not need to manually multiply by 8. In practice, start with a more relaxed value, confirm the matching direction and effect, then tighten it if needed.

Delete and Clean Up Rules

First list rules with handle values:

`1`	`nft -a list chain inet $table $chain`

Then delete a rule by handle:

`1`	`nft delete rule inet $table $chain handle <handle>`

Flush a chain:

`1`	`nft flush chain inet $table $chain`

Delete a chain:

`1`	`nft delete chain inet $table $chain`

Delete the entire table:

`1`	`nft delete table inet $table`

During daily debugging, only clean up the table you created yourself. Avoid directly changing tables automatically generated by the system or other services. This makes rollback easier even if a rule is written incorrectly.

Usage Notes

When using nftables, it is often safer to create your own independent table and chain first. This has two benefits:

Your rules are less likely to mix with existing system rules.
Debugging, flushing, and deletion are safer.

After writing rules, always use nft list chain to check actual matching behavior. MAC, interface, port, and rate-limit rules may behave differently across devices, bridge setups, and system versions. Small-scope testing is safer than writing complex rules all at once.

References

https://www.right.com.cn/forum/thread-8369750-1-1.html

go2rtc with Xiaomi Camera RTSP: Feed NVR, HomeKit, and Frigate

Sat, 11 Apr 2026 08:14:47 +0800

This note shows how to use go2rtc to pull Xiaomi camera streams directly and reuse them across NVR, HomeKit, and Frigate.

Docker deployment example

services:
  go2rtc:
    container_name: go2rtc
    image: alexxit/go2rtc:master-hardware
    restart: always
    network_mode: host
    privileged: true
    environment:
      - TZ=Asia/Shanghai
    volumes:
      - /vol1/1000/docker/go2rtc:/config

go2rtc web UI:

`1`	`http://192.168.3.217:1984/`

Stream config example

streams:
    micam1:
     - xiaomi://xxx
    #H265转H264,Homekit预览会用到
    #micam1_h264:
     #- ffmpeg:micam1#video=h264#width=1280#height=720#hardware#raw=-r 15
    micam2:
     - xiaomi://xxx
    micam3:
     - xiaomi://xxx

RTSP URL format:

`1`	`rtsp://192.168.3.217:8554/micam1`

Quality and parameters

Quality is controlled with values from 0 to 5:

0 usually means auto
1 means sd
2 means hd (default in go2rtc)

Some newer models may map HD to 3. Older models can break codec settings at 3, so avoid applying one fixed value to all devices.

Use subtype=hd/sd/auto/0-5 to set quality:

1
2

streams:
  xiaomi1: xiaomi://***&subtype=sd

For dual-lens cameras, use second channel with channel=2:

1
2

streams:
  xiaomi1: xiaomi://***&channel=2

Summary

Once go2rtc is in front, one RTSP source can serve NVR recording, Frigate detection, and HomeKit preview at the same time, which simplifies maintenance.

References

Camera support list: https://github.com/AlexxIT/go2rtc/issues/1982
Official Xiaomi notes: https://github.com/AlexxIT/go2rtc/blob/master/internal/xiaomi/README.md
Docker image: https://hub.docker.com/r/alexxit/go2rtc

Windows Task Manager data stops updating: the refresh speed is usually set to Paused

Thu, 09 Apr 2026 18:15:53 +0800

Sometimes when you open Windows Task Manager, the data on the Processes or Performance tab appears frozen. CPU, memory, disk, or network values may stay unchanged for a long time. At first glance this can look like a system problem, but in reality running programs, network traffic, and resource usage are still changing normally.

In most cases, the system is not actually stuck. The more likely reason is that Task Manager’s refresh speed has been changed to Paused.

Symptoms

Common signs include:

CPU, memory, and other values on the Processes tab stop changing
Graphs on the Performance tab no longer update
Programs are clearly still running, but Task Manager looks frozen

Here is an example of what the issue looks like:

Cause

Task Manager lets you adjust the Update speed, with options such as High, Normal, Low, or Paused.

If this setting is changed to Paused, the statistics shown in the interface stop refreshing. That is why CPU, memory, or network information can appear to be completely frozen.

As shown below, this option is usually available from the View menu in Task Manager:

Fix

Check the following:

Open Task Manager
Click the View menu
Find Update speed
Check whether it is currently set to Paused
Change it back to Normal or High

After that, watch the Processes or Performance tab again. In most cases, the data will start updating normally right away.

Additional notes

If the data still does not refresh after switching back to Normal, check a few other possibilities:

Whether you are using system-tuning tools or third-party performance monitoring software
Whether you are connected through a remote session and the interface is not refreshing correctly
Whether Task Manager itself is stuck, in which case you can close it and open it again

That said, in most cases this issue is simply caused by Update speed being accidentally set to Paused, so checking that first is usually the fastest fix.

Two Ways to Remotely Access Feiniu NAS and Their Comparison

Sat, 04 Apr 2026 11:00:00 +0800

There are two common ways to remotely access a Feiniu NAS:

Direct public IP access
FN Connect remote access service

Below is a practical guide organized by “how to use + key notes + best-fit scenarios.”

Option 1: Direct Public IP Access

This is suitable when your home network has a public IP and you can configure port forwarding on the router.
After that, you can access it by entering the public IPv4/IPv6 address and port in a browser or in the Feiniu App.
You can also set up DDNS and access via domain name.

Notes

Default ports for Feiniu private cloud fnOS: HTTP = 8000, HTTPS = 8001
If port forwarding is configured, the access URL must include the port number; otherwise, access will fail.
Direct public IP access usually has no extra relay, so speed loss is lower.
If security certificates are not configured properly, HTTP is plaintext. Use only in trusted network environments.
Many broadband providers block common ports such as 80 and 8080. If common ports do not work, try less common ports.

Option 2: FN Connect Remote Access Service

FN Connect is a remote-access service provided by Feiniu.
After enabling it, you get a unique FN ID to identify your Feiniu NAS and access it remotely through the corresponding method.

Notes

FN Connect requires you to register or sign in with a Feiniu account.
FN Connect provides an SSL certificate for the subdomain mapped to your FN ID, enabling secure HTTPS access.
FN Connect automatically chooses a better connection method based on your current network environment.
When direct public access is available, the web client can choose whether to use direct public IP access.
FN Connect relay forwarding has traffic cost, so rate limiting applies.

Comparison of the Two Methods

Dimension	Direct Public IP Access	FN Connect
Getting started	Requires public IP + router port forwarding	Lower barrier with account login and guided setup
Access speed	Usually faster with a more direct path	Close to direct mode when direct; possibly limited when relayed
Security	Depends on your own certificate and exposure strategy	Certificate support by default, easier HTTPS setup, depends on Feiniu’s own security
Maintenance cost	You maintain network and security settings yourself	Lower day-to-day maintenance effort
Best for	Users with networking experience and performance focus	Users who prioritize ease of use and stability

Recommendations

If you are comfortable with networking and want higher bandwidth/lower latency, prioritize direct public IP access.
If you care more about ease of use and secure access experience, prioritize FN Connect.
In practice, you can mix both: use FN Connect by default, and switch to direct public IP when conditions allow.

Automatically Renew Let's Encrypt Certificates on Ubuntu (Certbot + Nginx)

Fri, 03 Apr 2026 00:00:00 +0000

Let’s Encrypt certificates are valid for only 90 days, so production sites should always enable automatic renewal to avoid HTTPS downtime.

If you already issued the certificate with Certbot, there are usually two things left:

Configure a scheduled renewal task
Verify the renewal workflow actually works

First, Check Whether Certbot Already Created a Scheduler

Depending on your distro, Certbot may already install a scheduler (for example, a systemd timer or /etc/cron.d/certbot).

You can check with:

`1`	`systemctl list-timers \| grep certbot`

If a valid timer already exists, you usually do not need an extra crontab entry.

Add a Crontab Job Manually (Recommended Example)

If you prefer managing renewal explicitly, edit root crontab:

`1`	`sudo crontab -e`

Add this line (runs daily at 03:00):

`1`	`0 3 * * * certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" >> /tmp/certbot-renew.log 2>&1`

What it means:

0 3 * * *: run at 03:00 every day
certbot renew: renew certificates that are close to expiration
--pre-hook: stop Nginx before renewal (common for standalone mode)
--post-hook: start Nginx after renewal
>> /tmp/certbot-renew.log 2>&1: append logs for troubleshooting

Run a Dry Test Before Relying on Cron

After adding the task, validate the full flow manually:

`1`	`sudo certbot renew --dry-run`

If dry-run succeeds, you can safely rely on the scheduled job.

Common Notes

If you use the webroot or nginx plugin, you often do not need to stop Nginx. In many setups, reloading Nginx after renewal is enough:

`1`	`certbot renew --deploy-hook "systemctl reload nginx"`

certbot renew only performs actual renewal near expiration, so running it daily is normal.
For long-term maintenance, consider writing logs to a persistent path such as /var/log/letsencrypt/.

Summary

Reliable certificate auto-renewal is not just about writing a command. The key is confirming the workflow can run end to end.

A stable setup is usually just these three steps:

Check whether system-level scheduling already exists
Add cron if needed and keep logs
Validate once with --dry-run

How to Verify Whether Certbot Can Renew a Let's Encrypt Certificate Successfully

Thu, 08 Dec 2022 00:00:00 +0000

After using Certbot to issue a free Let’s Encrypt certificate, the most important follow-up question is whether automatic renewal will work.

Let’s Encrypt certificates are valid for a limited time. If renewal fails silently, HTTPS may break after the certificate expires. Certbot provides a dry-run mode that can simulate the renewal process without replacing the real certificate.

Use Certbot Dry Run

Run:

`1`	`certbot renew --dry-run`

This command asks Certbot to simulate certificate renewal. It checks whether the current account, domain validation method, web server integration and renewal configuration can still complete the process.

If the command succeeds, Certbot prints a success message similar to:

`1`	`Congratulations, all simulated renewals succeeded`

That means the renewal workflow is currently valid.

What Dry Run Checks

The dry run does not simply check the certificate file. It also verifies the renewal path:

whether the domain can still be validated;
whether the web server configuration allows the validation challenge;
whether Certbot can read the existing renewal configuration;
whether the certificate account and plugins are available;
whether the deploy/reload hooks can run.

This makes it more useful than only checking the certificate expiration date.

Common Failure Causes

If certbot renew --dry-run fails, common causes include:

the domain no longer points to the server;
port 80 or 443 is blocked;
Nginx or Apache configuration changed;
the webroot path no longer matches the renewal configuration;
firewall rules block Let’s Encrypt validation;
the Certbot plugin used during issuance is missing;
deploy hooks or reload commands fail.

Fix the error reported by Certbot, then run the dry run again.

Check The Renewal Timer

On systems using systemd, Certbot usually installs a timer:

`1`	`systemctl status certbot.timer`

You can list scheduled timers with:

`1`	`systemctl list-timers \| grep certbot`

If the timer is active and dry-run renewal succeeds, automatic renewal should work normally.

Summary

To verify whether Certbot can renew a Let’s Encrypt certificate, the most direct command is:

`1`	`certbot renew --dry-run`

Run it after changing web server configuration, firewall rules, domain DNS or Certbot plugins. This simple check can prevent an expired certificate from breaking HTTPS unexpectedly.

Use OpenWrt and WireGuard to Connect Two Remote LANs over the Internet

Thu, 14 Apr 2022 00:00:00 +0000

WireGuard can be used on OpenWrt routers to connect two LANs in different locations. After configuration, devices on both sides can access each other as if they were connected through a private routed network.

This is useful for home labs, NAS access, remote monitoring, backup synchronization and small office interconnection.

Basic Topology

Assume there are two sites:

1
2
3

Site A LAN: 192.168.1.0/24
Site B LAN: 192.168.2.0/24
WireGuard tunnel: 10.10.10.0/24

Each OpenWrt router runs WireGuard. One side can act as the peer with a public endpoint, or both sides can connect through a reachable server.

Install WireGuard

On OpenWrt, install the required packages:

1
2

opkg update
opkg install wireguard-tools luci-proto-wireguard

After installation, the LuCI web interface can configure WireGuard interfaces.

Create Keys

Generate private and public keys for each side:

`1`	`wg genkey \| tee privatekey \| wg pubkey > publickey`

Keep private keys secret. Exchange only public keys between the two routers.

Configure The Tunnel

Create a WireGuard interface on each router, for example wg0.

Example tunnel addresses:

1
2

Site A wg0: 10.10.10.1/24
Site B wg0: 10.10.10.2/24

For Site A, add Site B as a peer and set allowed IPs to:

1
2

10.10.10.2/32
192.168.2.0/24

For Site B, add Site A as a peer and set allowed IPs to:

1
2

10.10.10.1/32
192.168.1.0/24

These routes tell each router which remote subnet should go through the WireGuard tunnel.

Firewall And Routing

Create or assign a firewall zone for the WireGuard interface. Allow forwarding between LAN and WireGuard zones according to your policy.

At minimum, each side needs:

LAN to WireGuard forwarding;
WireGuard to LAN forwarding;
UDP port open for WireGuard on the side with a public endpoint;
correct allowed IPs for the remote subnet.

If NAT is not required, routed access is cleaner. Each LAN should know that the other LAN is reachable through the WireGuard router.

Test Connectivity

After both sides are configured, test the tunnel address first:

1
2

ping 10.10.10.1
ping 10.10.10.2

Then test a host in the remote LAN:

`1`	`ping 192.168.2.1`

If tunnel IPs work but LAN hosts fail, check firewall forwarding and remote subnet routes.

Summary

OpenWrt plus WireGuard is a lightweight way to connect two remote LANs. The important points are key exchange, tunnel addresses, allowed IPs, firewall forwarding and correct routing between the two LAN segments.

Operations on KnightLi Blog

Sync Local Markdown Notes with a Self-Hosted Git Server on a NAS

Who This Setup Is For

1. Install Git Server on the NAS

2. Windows Setup

3. Android Setup

4. How Obsidian and Joplin Fit In

Obsidian Setup

Joplin Setup

5. Recommended Notes Directory Structure

6. Avoiding Sync Conflicts

7. Do You Need Automatic Sync?

8. Pros and Cons of This Setup

My Recommendation

Choosing a Linux Server Distribution in 2026: Debian, Rocky Linux, AlmaLinux, and Ubuntu Server Compared

Quick Conclusion

Debian: Rock-Solid Stability

Rocky Linux: A Steady CentOS Successor

AlmaLinux: A More Proactive RHEL-Compatible Route

Ubuntu Server: Best Cloud Support and Deployment Efficiency

How to Choose Among the Four

Personal VPS / Self-Hosting

Enterprise Production

Cloud Native and Container Hosts

AI / GPU Servers

Traditional Business Systems

What to Check Before Choosing

My Default Recommendations

Short Conclusion

Related Links

Nginx Rate Limiting: Add rate limit for high-frequency 404 and 400 scan requests

Basic idea

Define rate-limit zones in http first

Then use the zones in server

What these parameters mean

Understanding burst and nodelay

Common error: limit_req_zone in the wrong place

Temporarily block clearly abnormal IPs

Check and reload

Recommended parameters

Ubuntu 26.04 LTS GPU and Hardware Updates: CUDA, ROCm, DPC++, and More Platform Changes

1. Intel DPC++ and related components are now in Ubuntu Archive

2. The NVIDIA CUDA toolkit can now be installed directly with apt

3. AMD ROCm 7.1.0 is now in Universe

4. The bigger story is that all three GPU ecosystems are landing

5. NVIDIA Dynamic Boost is enabled by default

6. Support for new Intel integrated and discrete GPUs keeps moving forward

7. Suspend and resume is more stable on Nvidia desktops too

8. ARM, Raspberry Pi, RISC-V, and IBM Z also get harder platform-level changes

ARM64 desktop platforms

A new Raspberry Pi boot layout

Raspberry Pi desktop images now use desktop-minimal

Swap on Raspberry Pi is now handled by cloud-init

RISC-V requirements have moved up

IBM Z now requires z15 at minimum

9. Who should read this first

10. One-line takeaway

Ubuntu 26.04 LTS Released: Major Desktop Updates with GNOME 50 and Linux 7.0

1. Start with the key updates

2. Biggest change #1: GNOME 50 is now in LTS

3. Biggest change #2: the default apps got a broad refresh

4. Biggest change #3: Wayland is now the only desktop session

5. Biggest change #4: Linux kernel 7.0 and the lower stack move forward together

6. Hardware requirements and install baseline

7. Who should prioritize upgrading

8. One-line summary

Related links

Understanding the nftables Framework: Tables, Chains, Rules, and Sets

table: Rule Namespace

family: Which Protocols the Rules Apply To

chain: Where Rules Are Executed

rule: Match Conditions Plus Actions

set: Group Values Together

map: Map a Matched Value to a Result

verdict map: Map a Matched Value to an Action

Designing Rules from the Concepts

Summary

References

nftables Quick Start: Tables, Chains, Rules, and Common Operations

Basic Structure

2. The NVIDIA CUDA toolkit can now be installed directly with `apt`