Tạo database và user MariaDB riêng cho WordPress: Phân quyền đúng chuẩn, tạm biệt thói quen xài chung root

Phạm vi thực hành: Hệ điều hành Ubuntu 24.04 LTS trên máy chủ VPS thử nghiệm riêng biệt với tên miền lab lab-cf02.localhost.vn. Chỉ thực hiện các thao tác trên hệ thống do chính bạn quản lý. Phần biên bản thực nghiệm cuối bài ghi lại đợt tách tài khoản DB riêng cho bản khôi phục (restore) lúc 23:20 ngày 30/09/2026 và đợt rà soát ở chế độ chỉ đọc (read-only) với hai tài khoản đang chạy lúc 10:50 ngày 01/10/2026. Ngoài ra, đợt thực nghiệm lúc 11:18 cùng ngày khởi tạo một cặp DB/user tạm thời độc lập để nghiệm thu thao tác nhập mật khẩu qua dấu nhắc (prompt) và bài tập tạo bảng. Các bước xác minh này tập trung vào phạm vi bài học, không thay thế cho một đợt kiểm toán bảo mật (security audit) toàn bộ tài khoản trên máy chủ.

Nếu bạn từng thấy cảnh một VPS chạy 5 website WordPress nhưng cả 5 file wp-config.php đều xài chung một tài khoản database (thậm chí xài luôn tài khoản root cho “đỡ phải phân quyền”), thì xin chúc mừng: chỉ cần một plugin trên một site bị dính lỗ hổng SQL Injection hoặc lộ file cấu hình là kẻ tấn công có thể dạo chơi, sửa xóa dữ liệu của cả 4 website còn lại như chốn không người. Nguyên tắc thiết kế hệ thống lành mạnh rất đơn giản: mỗi website phải ở một căn hộ riêng và cầm đúng chiếc chìa khóa của căn hộ đó. Bài viết tạo database và user riêng cho WordPress hôm nay sẽ hướng dẫn bạn khoanh vùng quyền truy cập chuẩn chỉ trên MariaDB — để ứng dụng web chỉ có đúng quyền đọc/ghi bài viết và cấu hình của chính nó chứ không bao giờ chạm được vào phần còn lại của VPS.

Chọn nhánh thực hành theo trạng thái website của bạn

Nhánh A — Nếu bạn đang đi tiếp liền mạch từ bài 37: Lúc này website của bạn đã có sẵn database, tài khoản user riêng và file wp-config.php đang chạy bon bon. Hãy giữ nguyên toàn bộ cấu hình hiện tại! Bạn sẽ dùng bài viết này như một bảng kiểm (checklist) để đối chiếu lại phạm vi quyền và độ cô lập: chỉ quan sát ở Bước 1, bỏ qua không chạy các lệnh CREATE/GRANT ở Bước 2, sau đó dùng chính user/database đang có để đọc quyền ở Bước 3 và thử kết nối ở phần đầu Bước 4. Tuyệt đối không chạy lệnh tạo bảng nháp và không sửa đổi thông tin đăng nhập ở Bước 5. Cuối cùng, mở lại trang chủ và Dashboard để xác nhận mọi bài viết cũ vẫn nguyên vẹn.

Nhánh B — Nếu bạn đang chuẩn bị cho một website mới tinh (chưa cài đặt WordPress): Hãy đi theo trọn vẹn quy trình khởi tạo mới từ đầu đến cuối cho một database trống. Còn nếu bạn đã hoàn thành bài 37 nhưng vẫn ngứa nghề muốn gõ thử các lệnh tạo bảng, hãy tạo một database nháp hoàn toàn độc lập (hoặc thực hành trên site thử nghiệm thứ hai). Tuyệt đối đừng lấy thông tin của database nháp trống trơn đem điền đè vào file wp-config.php của website đang chạy, kẻo trang web mất kết nối tới dữ liệu cũ và bật lại màn hình cài đặt từ đầu!

Đừng nhầm lẫn “ba ông trùng tên” trên cùng một VPS

Người mới làm quen với VPS rất hay bị tẩu hỏa nhập ma giữa ba loại tài khoản khác nhau: (1) tài khoản user hệ điều hành Linux dùng để đăng nhập SSH và phân quyền file, (2) tài khoản user cơ sở dữ liệu MariaDB dùng để mã nguồn PHP kết nối vào đọc/ghi bảng dữ liệu, và (3) tài khoản user quản trị WordPress dùng để đăng nhập vào trang /wp-admin viết bài. Ba lớp danh tính này hoàn toàn độc lập, nằm ở ba tầng phần mềm khác nhau và chẳng bao giờ tự động đồng bộ tên đăng nhập hay mật khẩu với nhau cả.

Trong mô hình LEMP đơn máy chủ của chúng ta, cả tiến trình PHP-FPM lẫn dịch vụ MariaDB đều nằm chung trên một VPS, do đó phần định danh máy chủ nguồn (host) của tài khoản MariaDB luôn được khóa chặt là localhost. Bạn đừng bao giờ tiện tay thay 'localhost' bằng ký tự đại diện '%' theo mấy bài hướng dẫn mì ăn liền trên mạng nhé: dấu % đồng nghĩa với việc cho phép kết nối từ bất kỳ địa chỉ mạng nào nếu cổng DB vô tình bị hở, tiềm ẩn rủi ro bảo mật cực lớn.

Trước khi bắt đầu, hãy xác nhận dịch vụ MariaDB đang chạy ổn định và tài khoản Linux của bạn có thể mở trình quản trị qua lệnh sudo mariadb. Hãy mở sẵn trình quản lý mật khẩu (Password Manager) để lưu trữ bộ thông tin của từng site gồm: tên database, tên user MariaDB, host (localhost) và một chuỗi mật khẩu dài ngẫu nhiên, độc nhất vô nhị. Nhớ nguyên tắc vàng: không bao giờ đẩy mật khẩu vào kho Git hay chụp ảnh màn hình có chứa mật khẩu.

Sơ đồ minh họa kiến trúc do đội ngũ localhost.vn biên soạn nhằm phân biệt rõ 3 lớp tài khoản trên VPS, không phải ảnh chụp màn hình trên máy chủ lab.

Bước 1: rà soát hiện trạng trước khi tạo mới

Hãy mở trình khách dòng lệnh của MariaDB dưới quyền quản trị, đồng thời gắn biến môi trường hướng file lịch sử sang /dev/null để các câu lệnh chứa mật khẩu gõ trong phiên không bị lưu lại trên ổ đĩa:

sudo env MYSQL_HISTFILE=/dev/null mariadb

Khi dấu nhắc MariaDB [(none)]> hiện ra, hãy kiểm tra nhanh phiên bản dịch vụ và danh sách các cơ sở dữ liệu đang tồn tại trên máy:

SELECT VERSION();
SHOW DATABASES;

Hãy nhìn kỹ danh sách trả về trước khi gõ bất kỳ lệnh tạo mới nào. Nếu bạn đang đi theo Nhánh A (tiếp nối bài 37), việc nhìn thấy tên database của mình nằm sẵn trong danh sách là hoàn toàn bình thường — hãy giữ nguyên đó và nhảy thẳng sang Bước 3. Ngược lại, nếu bạn đang dựng một website mới (Nhánh B) mà thấy cái tên mình định đặt đã tồn tại từ bao giờ, hãy dừng lại kiểm tra xem nó thuộc về dự án nào rồi chọn một cái tên mới khác biệt; tuyệt đối không gõ DROP DATABASE để “dọn chỗ” khi chưa rõ bên trong chứa dữ liệu gì.

Lưu ý quan trọng về quy tắc đặt tên: Trong các khối lệnh mẫu bên dưới, những chữ in hoa như TEN_DB_DA_CHON, USER_DB_DA_CHON và MAT_KHAU_SINH_RIENG chỉ là nhãn giữ chỗ (placeholder) để bạn thay bằng thông tin riêng của mình. Khi đặt tên cho một database mới, lời khuyên chân thành của đàn anh là chỉ nên dùng chữ cái thường và chữ số liền nhau (ví dụ: sitebloglab), tránh dùng dấu gạch dưới _ hoặc dấu phần trăm %. Lý do là trong câu lệnh phân quyền GRANT của MariaDB/MySQL, ký tự _ có thể bị trình phân tích hiểu nhầm thành ký tự đại diện cho “bất kỳ một ký tự nào” ngay cả khi tên DB được bọc trong dấu backtick! (Chẳng hạn cấp quyền trên `wp_lab`.* mà không escape dấu gạch dưới thì user đó có thể truy cập được cả database tên là wpXlab). Với những database cũ trót có dấu gạch dưới, bạn phải dùng cú pháp escape \_ khi GRANT, còn tạo mới thì cứ chữ thường liền mạch mà dùng cho khỏe người.

Bước 2: khởi tạo database và tài khoản — chỉ áp dụng cho site mới

CREATE DATABASE `TEN_DB_DA_CHON`
  CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'USER_DB_DA_CHON'@'localhost'
  IDENTIFIED BY 'MAT_KHAU_SINH_RIENG';
GRANT ALL PRIVILEGES ON `TEN_DB_DA_CHON`.*
  TO 'USER_DB_DA_CHON'@'localhost';

Sau khi bạn thay nhãn giữ chỗ bằng tên database viết liền (chữ thường và số), cụm lệnh trên sẽ tạo ra một cơ sở dữ liệu chuẩn bảng mã utf8mb4_unicode_ci (hỗ trợ trọn vẹn tiếng Việt có dấu lẫn biểu tượng cảm xúc emoji) và cấp quyền cho tài khoản mới chỉ trong phạm vi đúng database đó, tuyệt đối không đụng tới *.*. WordPress cần đầy đủ các quyền thao tác dữ liệu (SELECT, INSERT, UPDATE, DELETE) và quyền cấu trúc bảng (CREATE, ALTER, INDEX, DROP) để phục vụ việc cài đặt plugin hoặc nâng cấp phiên bản core, nhưng nó hoàn toàn không cần quyền GRANT OPTION (quyền đi cấp quyền cho người khác).

Khi điền mật khẩu vào phần IDENTIFIED BY '...', hãy chọn một chuỗi dài ngẫu nhiên từ trình quản lý mật khẩu. Tránh những mật khẩu ngây thơ kiểu password123 hay admin@123 ngay cả trên máy chủ thử nghiệm, vì thói quen xuề xòa lúc thử nghiệm rất dễ đi thẳng lên môi trường thật.

Mặc dù ở Bước 1 chúng ta đã dùng MYSQL_HISTFILE=/dev/null để ngăn trình khách MariaDB ghi lại lịch sử gõ lệnh ra file ~/.mysql_history, bạn vẫn không nên quay video hay chụp ảnh màn hình lúc đang hiển thị câu lệnh chứa mật khẩu thật trên terminal. Trên các hệ thống doanh nghiệp có bật tính năng ghi nhật ký kiểm toán (server audit log), quản trị viên cũng cần phân quyền bảo vệ nghiêm ngặt thư mục chứa log đó.

Bước 3: đọc và xác minh bảng phân quyền

SHOW GRANTS FOR 'USER_DB_DA_CHON'@'localhost';

Nếu bạn đi tiếp từ bài 37, hãy thay nhãn giữ chỗ bằng đúng tên user và host đang khai báo trong file cấu hình của bạn. Khi nhìn vào kết quả trả về của lệnh SHOW GRANTS, bạn sẽ thấy hai dòng: dòng đầu tiên thường là GRANT USAGE ON *.* — đừng giật mình, trong thuật ngữ của MariaDB/MySQL thì USAGE trên *.* thực chất có nghĩa là “không có quyền toàn cục nào cả, chỉ cho phép đăng nhập vào cổng máy chủ”. Dòng thứ hai mới là dòng quyết định: quyền thực tế phải được gắn chặt vào đúng một tên database cụ thể của site đó.

Một chi tiết kỹ thuật thú vị: vì chúng ta quản lý tài khoản chuẩn mực thông qua câu lệnh CREATE USER và GRANT, MariaDB đã tự động cập nhật bảng quyền trong bộ nhớ ngay lập tức, nên bạn không cần phải gõ thêm lệnh FLUSH PRIVILEGES; theo thói quen cũ từ thời sửa trực tiếp bảng hệ thống mysql.user nữa.

Sơ đồ minh họa kiến trúc do đội ngũ localhost.vn biên soạn nhằm giải thích nguyên tắc cô lập quyền theo từng database, không phải ảnh chụp màn hình trên máy chủ lab.

Bước 4: đóng vai ứng dụng để thử đăng nhập trực tiếp

Đừng bao giờ chỉ tạo tài khoản xong dưới quyền root rồi yên tâm đóng máy. Hãy gõ EXIT; để thoát khỏi phiên quản trị MariaDB, sau đó thử đăng nhập lại từ dòng lệnh Linux bằng chính tài khoản ứng dụng vừa tạo:

mariadb --user=USER_DB_DA_CHON --password TEN_DB_DA_CHON

Hãy để ý cách chúng ta truyền tham số --password để trống không kèm chuỗi mật khẩu phía sau: cách viết này buộc trình khách MariaDB bật dấu nhắc Enter password: ở chế độ ẩn ký tự. Tuyệt đối không bao giờ gõ kiểu --password=MatKhauCuaBan ngay trên dòng lệnh, vì bất kỳ tiến trình nào chạy lệnh ps aux trên máy chủ lúc đó hoặc người đọc lại file .bash_history đều sẽ nhìn thấy mật khẩu của bạn phơi bày rõ mồn một! Sau khi đăng nhập thành công, hãy gõ tiếp:

SELECT CURRENT_USER(), DATABASE();
SHOW TABLES;

Nếu bạn đang thực hành trên website đã cài sẵn từ bài 37 (Nhánh A), lệnh SHOW TABLES; sẽ liệt kê đầy đủ 12 bảng dữ liệu tiêu chuẩn của WordPress. Nhìn thấy danh sách bảng đó nghĩa là tài khoản của bạn đã hoạt động hoàn hảo — hãy dừng lại tại đây, gõ EXIT; và mở trình duyệt xác nhận website vẫn chạy mượt mà.

Riêng với những bạn đang thực hành trên một database trống mới tinh của site thử nghiệm độc lập (Nhánh B), lệnh SHOW TABLES; sẽ báo Empty set. Lúc này bạn có thể chạy thêm bài tập nhỏ dưới đây để tận tay xác nhận quyền tạo bảng, ghi dòng dữ liệu và xóa bảng của tài khoản mới:

CREATE TABLE localhost_setup_check (id INT PRIMARY KEY);
INSERT INTO localhost_setup_check (id) VALUES (1);
SELECT COUNT(*) FROM localhost_setup_check;
DROP TABLE localhost_setup_check;

Hãy quan sát kết quả COUNT(*) trả về đúng bằng 1 trước khi lệnh DROP TABLE dọn sạch bảng nháp. Xin nhắc lại một lần nữa: chỉ chạy khối lệnh tạo/xóa bảng nháp này trên một database trống phục vụ việc học, không gõ vào database đang chạy thật. Phần cuối bài viết sẽ trình bày biên bản thực nghiệm chi tiết cho cả hai kịch bản này trên máy chủ LAB-CF-02.

Bước 5: kết nối thông tin tài khoản vào WordPress

Với Nhánh A (website đã chạy từ bài 37): Bạn chỉ cần đối chiếu lại thông tin trong trình quản lý mật khẩu khớp với file wp-config.php hiện hành rồi giữ nguyên mọi thứ, tuyệt đối không lấy thông tin của database bài tập chép đè vào.

Với Nhánh B (dựng website mới): Hãy điền bộ tứ thông số DB_NAME, DB_USER, DB_PASSWORD và DB_HOST (đặt là localhost) vào file wp-config.php của website mới. Cách khóa quyền file cấu hình ở mức 640 để tránh rò rỉ thông tin nhạy cảm sẽ được hướng dẫn tỉ mỉ ngay ở bài tiếp theo.

Một kinh nghiệm bắt bệnh thực tế: việc bạn đăng nhập thành công bằng lệnh mariadb trên CLI mới chứng minh được tên user, mật khẩu và quyền trong DB là đúng, chứ chưa đảm bảo 100% là tiến trình PHP-FPM cũng kết nối được! Nếu đăng nhập CLI ngon lành mà mở web lên WordPress vẫn báo lỗi kết nối cơ sở dữ liệu, thủ phạm thường nằm ở việc thiếu gói thư viện mở rộng php-mysql (mysqli), sai đường dẫn Unix socket trong cấu hình PHP, hoặc bạn đang sửa nhầm file wp-config.php của một thư mục khác.

Sơ đồ minh họa kiến trúc do đội ngũ localhost.vn biên soạn nhằm tóm tắt các bước nghiệm thu tài khoản database, không phải ảnh chụp màn hình trên máy chủ lab.

Các lỗi kinh điển và phương án hoàn nguyên (Rollback)

Lỗi Access denied for user: Hãy bình tĩnh đối chiếu từng ký tự của tên user, mật khẩu và đặc biệt là phần host. Trong MariaDB, 'user'@'localhost' (kết nối qua Unix socket) và 'user'@'127.0.0.1' (kết nối qua giao thức TCP) được coi là hai định danh khác nhau hoàn toàn. Và nhớ nhé: khi gặp lỗi Access denied, hãy tìm đúng chỗ lệch để sửa chứ đừng bao giờ nóng ruột điền đại tài khoản root vào cho xong chuyện!

Lỗi Unknown database: Kiểm tra xem bạn có gõ nhầm chính tả tên database trong wp-config.php không, hoặc bước CREATE DATABASE trước đó đã thực sự chạy thành công chưa. Nếu đây là một website đang vận hành mà bỗng dưng báo Unknown database, tuyệt đối không được gõ lệnh tạo một database rỗng trùng tên để “làm mất thông báo lỗi”, mà phải kiểm tra ngay dịch vụ MariaDB và phương án khôi phục từ bản sao lưu.

Xử lý khi nghi ngờ lộ mật khẩu DB: Nếu bạn lỡ tay dán đoạn cấu hình có mật khẩu thật lên diễn đàn hoặc chụp dính vào ảnh báo cáo, việc xóa bức ảnh đó đi không làm mật khẩu trở nên an toàn trở lại. Quy trình xử lý chuẩn là: tạo một chuỗi mật khẩu mới trong Password Manager, dùng lệnh ALTER USER trong MariaDB để đổi mật khẩu mới, cập nhật lại ngay trong wp-config.php vào khung giờ thấp điểm rồi tải lại trang web để xác nhận kết nối thông suốt.

Có nên dùng chung một tài khoản DB cho nhiều website để đỡ phải nhớ không? Về mặt kỹ thuật thì chạy được, nhưng về mặt an toàn vận hành thì đó là một quả bom nổ chậm. Tách riêng mỗi website một database và một user giúp bạn khoanh vùng sự cố cực nhanh: lỡ một site bị tấn công hoặc cần thu hồi quyền bảo trì, các site còn lại trên VPS vẫn bình yên vô sự. Thực tế trên máy chủ LAB-CF-02, chúng tôi đã tiến hành tách riêng tài khoản DB cho bản website khôi phục (restore) và nghiệm thu khả năng chống truy cập chéo ngay dưới đây.

Biên bản thực nghiệm cô lập database trên LAB-CF-02

Biên bản tách tài khoản database và nghiệm thu giới hạn quyền truy cập dưới đây được thực hiện vào khung giờ 23:20:40–23:20:45 ngày 30/09/2026 (UTC+7). Trước thời điểm này, bản website khôi phục (restore site) trên máy lab vẫn đang dùng chung tài khoản DB với website gốc; trong đợt thực hành này, chúng tôi đã khởi tạo một user MariaDB riêng cho bản restore, cập nhật file wp-config.php của bản restore sang tài khoản mới, đồng thời thu hồi quyền truy cập vào DB restore khỏi tài khoản của site gốc.

Kết quả trên chứng minh rõ ràng hai tài khoản ứng dụng đã được cô lập hoàn toàn với nhau: chìa khóa nhà nào chỉ mở được cửa nhà nấy. Tất nhiên, vì cả hai website vẫn đang đặt chung trên một máy chủ VPS vật lý nên việc tách user DB này giải quyết bài toán cô lập ở tầng cơ sở dữ liệu chứ không thay thế cho việc sao lưu ra máy chủ ngoài (offsite backup) hay cô lập ở cấp độ hệ điều hành.

Lưu ý nhỏ cho quá trình vận hành: vì quyền truy cập của tài khoản cũ vào DB restore đã bị thu hồi (REVOKE), nên nếu sau này bạn vô tình chép đè bản sao lưu wp-config.php cũ (chứa tên user cũ) quay ngược trở lại bản restore thì website sẽ báo lỗi kết nối ngay. Khi hoàn nguyên bất kỳ thay đổi nào liên quan tới mật khẩu hay tài khoản, hãy luôn đối chiếu đồng bộ cả hai phía: cấu hình trong file PHP và bảng phân quyền trong MariaDB.

Ảnh chụp console xác minh hai tài khoản hiện hành ngày 01/10

Vào lúc 10:50:12 ngày 01/10/2026 (UTC+7), chúng tôi chạy một kịch bản xác minh ở chế độ chỉ đọc (read-only) trên LAB-CF-02 bằng chính hai tài khoản ứng dụng của hai site để kiểm chứng lại trạng thái cô lập sau đợt tách quyền ngày 30/09.

Ảnh chụp màn hình console thực tế lúc 10:50:56 ngày 01/10/2026 (UTC+7), giữ nguyên điểm ảnh gốc và đính kèm logo nhận diện. Mốc thời gian hệ thống 03:50:12 UTC trong ảnh tương ứng chính xác với 10:50:12 giờ Việt Nam. Đầu ra hiển thị tóm tắt kết quả xác minh đã ẩn toàn bộ chuỗi mật khẩu nhạy cảm. Bấm vào ảnh để xem kích thước đầy đủ.

Mã băm của cả hai file wp-config.php trước và sau khi chạy kịch bản xác minh đều giữ nguyên không đổi. Đợt chạy lúc 10:50 này chỉ kiểm tra trạng thái phân quyền hiện có chứ không chạy lệnh CREATE hay GRANT mới. Để nghiệm thu trọn vẹn thao tác nhập mật khẩu qua dấu nhắc và bài tập tạo/xóa bảng ở Bước 4, chúng tôi thực hiện tiếp đợt thực nghiệm lúc 11:18 ngay dưới đây.

Thực nghiệm nhập mật khẩu qua dấu nhắc và tạo bảng tạm ngày 01/10

Trong khoảng thời gian 11:18:42–11:18:43 ngày 01/10/2026 (UTC+7), chúng tôi khởi tạo trên máy lab một cơ sở dữ liệu trống cùng một tài khoản MariaDB tạm thời dành riêng cho bài tập Bước 4 (chỉ cấp quyền trên đúng schema tạm đó và không có GRANT OPTION). Sau khi bước khởi tạo hoàn tất, kịch bản mở trình khách mariadb thực thụ bên trong một thiết bị đầu cuối giả lập (PTY), chờ dấu nhắc Enter password: xuất hiện và xác nhận terminal đã tắt chế độ hiển thị ký tự (echo off) rồi mới truyền mật khẩu vào. Nhờ vậy, mật khẩu hoàn toàn không xuất hiện trên danh sách tham số tiến trình của hệ điều hành hay trong file nhật ký.

Ảnh chụp màn hình console thực tế lúc 11:19:04 ngày 01/10/2026 (UTC+7), giữ nguyên điểm ảnh gốc và đính kèm logo ở chân ảnh. Mốc thời gian 04:18:42–43 UTC trên màn hình tương ứng với 11:18:42–43 giờ Việt Nam. Bấm vào ảnh để xem bản rõ nét.

Đợt thực nghiệm này chứng minh trọn vẹn luồng đăng nhập bằng dấu nhắc mật khẩu và chuỗi câu lệnh kiểm tra quyền đọc/ghi bảng ở Bước 4 trên một database trống. Toàn bộ thư mục tạm (mode 700), file định danh tạm (mode 600) cùng database và user bài tập đã được dọn dẹp sạch sẽ ngay sau khi hoàn tất mà không ảnh hưởng mảy may tới các website WordPress đang vận hành trên máy chủ.

Nguồn tham khảo và bước tiếp theo

Các tài liệu kỹ thuật chính thức được đội ngũ đối chiếu ngày 30/09/2026 bao gồm: MariaDB: CREATE USER, MariaDB: GRANT và WordPress: thiết lập wp-config.php. Các tình huống bắt bệnh và mẫu biên bản nghiệm thu trong bài được biên soạn riêng cho chuỗi bài thực hành này.

Tài liệu được rà soát bổ sung vào ngày 01/10/2026: MariaDB command-line client về nguyên tắc sử dụng cờ --password không kèm giá trị để nhập mật khẩu an toàn qua dấu nhắc.

Xem toàn bộ lộ trình WordPress trên VPS. Bài trước: Cài WordPress trên VPS đến màn hình đăng nhập. Bài tiếp theo: Cấu hình WordPress mà không lộ bí mật DB.