Cấu hình ban đầu Ubuntu LTS chuẩn production tối thiểu 2026

“Cấu hình ban đầu Ubuntu LTS chuẩn production tối thiểu” là bài tiếp theo trong series Devops. Với mạch nội dung này, bài này đóng vai trò là bài “chuẩn hóa hệ điều hành” ngay sau khi đã vào được server an toàn ở “Kết nối SSH lần đầu: key-based login, known_hosts và anti-lockout 2026“, trước khi chuyển sang user/sudo, firewall và web stack ở các bài tiếp theo.

Với dự án mới trong năm 2026, Ubuntu 24.04 LTS vẫn là lựa chọn mặc định hợp lý cho VPS vì đây là bản LTS còn standard security maintenance đến tháng 5/2029, và tài liệu Ubuntu Server hiện cũng tiếp tục khuyến nghị chạy nhánh LTS cho môi trường server thay vì các bản interim 9 tháng.

Điểm quan trọng của bài này không phải là “copy vài lệnh cho xong”, mà là dựng một nền tảng sạch để các bước sau đỡ phát sinh lỗi vặt. Một VPS mới nhận mà không kiểm tra baseline, không đồng bộ thời gian, không cập nhật package và không ghi lại trạng thái ban đầu sẽ rất dễ gây rối khi đến lúc cài Nginx, SSL, database hoặc debug sự cố.

1. Mục tiêu sau bài học

Sau khi làm xong bài này, bạn nên đạt được bốn việc.

Thứ nhất, biết chính xác VPS đang chạy bản Ubuntu nào, kernel nào, RAM/disk/network ra sao và hiện có dịch vụ nào đang lắng nghe. Thứ hai, cập nhật hệ thống theo cách an toàn, có kiểm tra lại sau update. Thứ ba, chuẩn hóa timezone, time sync, hostname và bộ công cụ nền để thao tác thuận tay hơn. Thứ tư, biết khi nào cần reboot và biết kiểm tra reboot-required thay vì reboot theo cảm tính.

2. Vì sao giờ đầu tiên sau khi nhận VPS lại quan trọng

Nhiều lỗi production không bắt đầu từ Nginx hay MariaDB, mà bắt đầu từ tầng hệ điều hành chưa được chuẩn hóa. Ví dụ rất điển hình là log bị lệch giờ do timezone/time sync sai, package cũ gây lỗi tương thích TLS hoặc PHP, hoặc hostname đặt tùy tiện làm việc quản trị nhiều máy trở nên lộn xộn.

Ubuntu Server docs hiện tách khá rõ các mảng quản trị cơ bản như quản lý phần mềm, time synchronization, SSH và firewall. Điều đó cũng phản ánh một nguyên tắc thực chiến: hãy làm sạch lớp nền trước, rồi mới dựng dịch vụ phía trên.

3. Tư duy đúng trước khi bắt đầu

Ở bài này, bạn chưa cần hardening sâu hay tối ưu quá tay. Việc cần làm là thiết lập một mức “production tối thiểu”: hệ điều hành được cập nhật, đồng hồ chuẩn, hostname rõ ràng, công cụ nền đủ dùng, và sau mỗi thay đổi đều có bước kiểm tra lại.

Một nguyên tắc rất đáng giữ là không đụng nhiều lớp nhạy cảm cùng lúc. Ví dụ, trong bài này bạn có thể kiểm tra SSH service đang chạy tốt, nhưng không cần nhảy sang hardening SSH nâng cao; bạn có thể cài công cụ nền và xác minh time sync, nhưng chưa cần bật UFW rule chi tiết vì việc đó nên đi trọn vẹn ở “Firewall và cập nhật tự động: UFW + unattended-upgrades 2026“. Cách chia bước như vậy giúp rollback dễ hơn và khi đọc ít bị rối hơn.

4. Quy trình cấu hình ban đầu Ubuntu LTS chuẩn production tối thiểu

Bước 1: Chụp lại baseline trước khi sửa gì

Đừng update ngay khi vừa vào máy. Việc đầu tiên là chụp lại hiện trạng để biết mình đang đứng ở đâu.

Chạy lần lượt:

cat /etc/os-release
uname -r
uptime
free -h
df -hT
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
ip -brief a
ip route
ss -tulpn
systemctl --failed

Mục đích của bước này là rất thực tế. Bạn biết bản Ubuntu hiện tại, kernel hiện tại, disk có đang thiếu dung lượng hay không, mạng có bao nhiêu interface, và có dịch vụ nào đang mở cổng sẵn. Nhiều VPS image từ nhà cung cấp có thể đã kèm cloud-init, agent giám sát, hoặc một vài service nền khác; nếu bạn không ghi lại từ đầu, sau này rất khó phân biệt cái gì là “mặc định từ image” và cái gì là “do mình vừa cài”. Đây cũng là lý do nên lưu lại output vào note nội bộ hoặc ticket triển khai.

Bước 2: Cập nhật package theo cách an toàn

Ubuntu Server docs hiện vẫn dùng quy trình cơ bản là:

sudo apt update && sudo apt upgrade -y

để cập nhật package đã cài trên hệ thống. Đây là điểm khởi đầu hợp lý cho một VPS mới. Ubuntu cũng có cơ chế phased updates, nghĩa là cùng một gói cập nhật có thể được rollout theo đợt thay vì đến mọi máy cùng lúc, nên đừng vội kết luận “server A mới hơn server B” chỉ vì hai máy vừa apt update xong mà chưa thấy cùng số phiên bản.

Sau khi chạy upgrade, nên kiểm tra lại:

apt list --upgradable
sudo systemctl --failed

Nếu danh sách upgradable còn lại không đáng kể hoặc là các gói bạn chủ động giữ lại, bạn có thể đi tiếp. Nếu có service bị fail sau nâng cấp, phải dừng lại đọc log trước khi sang bước khác. Đừng để tình trạng “update xong thấy không báo đỏ nên đi tiếp”, vì lỗi thật thường nằm trong systemd status hoặc journal.

Bước 3: Kiểm tra có cần reboot hay chưa

Đây là bước nhiều tutorial bỏ qua, nhưng với Ubuntu 24.04 thì càng đáng chú ý hơn. Release notes của 24.04 nêu rõ needrestart đã được thay đổi để tự động restart những service bị ảnh hưởng bởi library upgrade, kể cả trong các tình huống non-interactive như unattended-upgrade. Điều đó tốt cho bảo mật, nhưng cũng có nghĩa là sau update bạn càng cần kiểm tra lại trạng thái service, thay vì giả định mọi thứ vẫn nguyên như trước.

Để biết hệ thống có đang chờ reboot hay không, dùng:

test -f /var/run/reboot-required && echo "Reboot required"
test -f /var/run/reboot-required.pkgs && cat /var/run/reboot-required.pkgs

Canonical cũng ghi nhận rằng khi một số package như kernel, libc hoặc dbus yêu cầu reboot, bạn có thể xem danh sách package đã phát tín hiệu trong /var/run/reboot-required.pkgs. Đây là cách kiểm tra tốt hơn nhiều so với reboot theo thói quen.

Một cách làm thực tế là: nếu đây là VPS mới chưa chạy workload thật, và update vừa chạm kernel hoặc các package nền lớn, hãy reboot ngay ở bước này để về trạng thái sạch. Làm vậy tốt hơn là để một máy production tương lai chạy nửa mới nửa cũ trong nhiều ngày.

Bước 4: Chuẩn hóa timezone và kiểm tra time sync

Thời gian sai là nguồn gốc của rất nhiều lỗi khó chịu: log lệch giờ, cron chạy sai thời điểm, token/SSL validation bất thường, hoặc debug sự cố bị “nhìn log mà tưởng nhầm timeline”.

timedatectl là công cụ chuẩn để xem và đặt timezone:

timedatectl
timedatectl list-timezones | grep Ho_Chi_Minh
sudo timedatectl set-timezone Asia/Ho_Chi_Minh
timedatectl

Theo man page của timedatectl, set-timezone sẽ cập nhật timezone hệ thống bằng cách đổi symlink /etc/localtime. Ubuntu Server docs hiện cũng tách riêng hướng dẫn cho timedatectl/timesyncd và cho chrony, đồng thời giải thích rằng không nên để nhiều time-sync service “tranh nhau” đồng hồ hệ thống. Từ các tài liệu này có thể rút ra một nguyên tắc an toàn cho VPS 24.04: đừng giả định máy đang dùng daemon nào; hãy kiểm tra daemon đang hoạt động rồi mới cấu hình.

Bạn có thể kiểm tra như sau:

timedatectl status
systemctl status systemd-timesyncd --no-pager
systemctl status chrony --no-pager

Nếu một trong hai đang active và thời gian đã synchronized, vậy là đủ. Ở bài này chưa cần đi sâu vào NTS hay serve NTP. Mục tiêu chỉ là đảm bảo log và scheduler của bạn sống trong một timeline đúng.

Bước 5: Đặt hostname rõ ràng, dễ quản trị

Hostname không làm server chạy nhanh hơn, nhưng nó làm mọi thứ phía sau gọn hơn rất nhiều: prompt terminal, log, monitoring, inventory, backup và ticket nội bộ đều dễ đọc hơn.

Kiểm tra hostname hiện tại:

hostnamectl status
hostname

Đổi hostname nếu cần:

sudo hostnamectl set-hostname web-01
hostnamectl status

Tài liệu Ubuntu cũng thường dùng hostnamectl set-hostname khi cần chuẩn hóa hostname hoặc FQDN cho server. Với VPS đơn lẻ, bạn chưa nhất thiết phải đặt FQDN ngay; nhưng ít nhất nên chọn một hostname có quy ước, ví dụ web-01, db-01, staging-01, thay vì để ubuntu-s-1vcpu-1gb hoặc chuỗi hostname ngẫu nhiên từ provider.

Bước 6: Cài nhóm công cụ nền thật sự hữu ích

Rất nhiều bài “cấu hình ban đầu” cài cả một đống package rồi cuối cùng người dùng không đụng đến 80% trong số đó. Với bài này, nên giữ một bộ công cụ nền gọn nhưng hữu ích:

sudo apt install -y curl wget git rsync unzip zip ca-certificates jq htop tmux dnsutils lsof

Bộ này giải quyết được đa số nhu cầu trong giai đoạn đầu: tải file, clone repo, đồng bộ dữ liệu, giải nén, gọi API, xem tài nguyên, giữ phiên làm việc, kiểm tra DNS và truy vết process/file mở. Phần mềm nền càng gọn, baseline hệ thống càng sạch. Những thứ chuyên sâu hơn như fail2ban, nginx, php-fpm, mariadb, monitoring agent hoặc backup tool nên để đúng bài chuyên đề phía sau trong series.

Bước 7: Xác minh SSH service và giữ đường lui sau reboot

Bài này không phải bài hardening SSH, nhưng sau update hoặc reboot bạn vẫn cần chắc rằng đường vào server còn hoạt động bình thường.

Kiểm tra:

sudo systemctl status ssh --no-pager
ss -tulpn | grep :22

Nếu trước đó bạn đã chỉnh gì liên quan đến SSH từ “Kết nối SSH lần đầu: key-based login, known_hosts và anti-lockout 2026“, hãy nhớ Ubuntu docs khuyến nghị sudo sshd -t trước khi restart ssh.service. Quy tắc này không thay đổi: test config trước, restart sau, rồi mở phiên mới để xác nhận lại.

Bước 8: Reboot chủ động nếu hệ thống đang chờ reboot

Nếu bước 3 cho thấy có reboot-required, đây là lúc phù hợp để reboot chủ động trong một khung kiểm soát, thay vì để nó rơi vào một thời điểm khác khó đoán hơn.

sudo reboot

Sau khi máy lên lại, đăng nhập vào và kiểm tra nhanh:

uptime
uname -r
timedatectl
systemctl --failed
sudo systemctl status ssh --no-pager

Nếu cả SSH, thời gian và systemd đều sạch, bạn đã có một lớp nền đủ ổn để đi tiếp sang các bài tiếp theo trong series.

5. Command snippets quan trọng

Đây là nhóm lệnh nên có trong phần snippet của bài để người đọc copy nhanh:

cat /etc/os-release
uname -r
free -h
df -hT
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
ip -brief a
ss -tulpn
sudo apt update && sudo apt upgrade -y
apt list --upgradable
test -f /var/run/reboot-required && echo "Reboot required"
test -f /var/run/reboot-required.pkgs && cat /var/run/reboot-required.pkgs
timedatectl
sudo timedatectl set-timezone Asia/Ho_Chi_Minh
systemctl status systemd-timesyncd --no-pager
systemctl status chrony --no-pager
hostnamectl status
sudo hostnamectl set-hostname web-01
sudo apt install -y curl wget git rsync unzip zip ca-certificates jq htop tmux dnsutils lsof
sudo systemctl status ssh --no-pager
sudo reboot

6. Kiểm tra sau khi cấu hình

Một bài tutorial hữu ích không kết thúc ở chỗ “lệnh chạy xong”. Nó chỉ kết thúc khi bạn kiểm tra được ba lớp sau.

Thứ nhất, hệ điều hành đã update sạch hoặc bạn biết rõ còn package nào đang được giữ lại. Thứ hai, đồng hồ hệ thống đúng timezone và đang synchronized. Thứ ba, sau reboot bạn vẫn vào được máy, SSH service vẫn chạy, và systemctl --failed không có gì bất thường.

Nếu muốn chắc hơn, có thể chạy thêm:

journalctl -p 3 -xb --no-pager

để xem các lỗi mức cao kể từ lần boot hiện tại.

7. Lỗi thường gặp và cách tránh

Lỗi phổ biến nhất là cập nhật package xong rồi đi tiếp ngay, không hề kiểm tra reboot-required hay trạng thái service. Với Ubuntu 24.04, chuyện service restart sau library upgrade không còn là thứ quá hiếm, nên thói quen “update rồi bỏ đó” càng dễ trả giá.

Lỗi thứ hai là đặt timezone nhưng không kiểm tra time sync daemon đang chạy. Timezone đúng không đồng nghĩa đồng hồ đang synchronized.

Lỗi thứ ba là cài quá nhiều package nền ngay từ ngày đầu. Càng nhiều package không cần thiết, hệ thống càng khó audit và càng khó biết lỗi đến từ đâu.

Lỗi thứ tư là coi bài này như nơi xử lý luôn firewall, hardening SSH, user/sudo và automatic updates. Những phần đó nên đọc sang những bài khác để mỗi thay đổi đều có mục tiêu, cách test và rollback riêng.

8. FAQ

8.1. Có nên dùng Ubuntu 22.04 LTS thay vì 24.04 LTS không?

Có thể, nếu bạn đang bám một stack cũ hoặc cần tương thích với hệ thống đã chuẩn hóa trên 22.04. Nhưng với dự án mới trong 2026, 24.04 LTS là nhánh mặc định hợp lý hơn vì vẫn còn standard security maintenance đến tháng 5/2029.

8.2. Có nên chạy apt full-upgrade ngay ở bài hướng dẫn này không?

Không phải lúc nào cũng cần. Với một VPS mới, apt update && apt upgrade -y là điểm khởi đầu sạch và đúng theo tài liệu Ubuntu Server. Chỉ nên đi xa hơn khi bạn hiểu vì sao có package bị giữ lại hoặc cần thay đổi dependency lớn.

8.3. Tôi nên dùng chrony hay timesyncd?

Với bài này, điều quan trọng hơn là hệ thống đang dùng cái gì và nó có synchronized hay không. Ubuntu hiện tài liệu hóa cả hai hướng, và nhấn mạnh không nên để nhiều time-sync service xung đột với nhau.

8.4. Có nên bật UFW và unattended-upgrades luôn trong bài này không?

Không nên nhồi hết vào lúc này. Về mặt trải nghiệm học và vận hành, tốt hơn là tham khảo “Firewall và cập nhật tự động: UFW + unattended-upgrades 2026” để bạn hiểu kỹ từng lớp bảo vệ và tránh tự khóa máy khi bật firewall quá sớm.

9. Kết luận

Cấu hình ban đầu Ubuntu LTS chuẩn production tối thiểu không phải là một bài để “làm một lần rồi quên”, mà là bước dọn nền cho toàn bộ phần còn lại của series. Khi bạn làm đúng theo bài hướng dẫn này, các bài sau về user/sudo, firewall, Nginx, PHP, SSL, backup và monitoring đều bớt lỗi hơn rất nhiều. Một giờ đầu tiên làm kỹ thường tiết kiệm cho bạn rất nhiều giờ debug về sau.