Series
Hướng dẫn OpenClaw
Bạn đang xem1/14
Xem trang series·Tất cả series
Cơ bản
- . Hướng dẫn OpenClaw chi tiết nhất từ A tới Z
- 2. Cài OpenClaw lên VPS Việt Nam để chạy 24/7
- 3. Tùy biến OpenClaw: Tạo trợ lý AI theo phong cách riêng của bạn
- 4. Tự động hoá với OpenClaw: Cron Jobs, Heartbeats và Webhooks
- 5. Cài đặt và tạo Skills cho OpenClaw: Mở rộng khả năng không giới hạn
Nâng cao
- 6. Kết nối OpenClaw với nhiều AI cùng lúc: Claude, ChatGPT, Gemini
- 7. OpenClaw + GitHub: Quản lý toàn bộ dev workflow bằng chat
- 8. OpenClaw + Home Assistant: Điều khiển nhà thông minh bằng chat
- 9. Tích hợp OpenViking vào OpenClaw: Nâng cấp bộ nhớ AI Agent, giảm 83% token cost
- 12. So sánh cách chạy OpenClaw: VPS, Mac Mini, Windows, Linux, Docker, Raspberry Pi
- 13. OpenClaw hybrid: Gateway trên VPS + Node trên Mac local
- 10. Bảo mật OpenClaw: hướng dẫn cấu hình an toàn theo từng bước
- 11. Một số skill nên cân nhắc cho OpenClaw
- 14. Tối ưu chi phí OpenClaw: Cách giảm 70% token usage mà vẫn giữ chất lượng
Bạn quản lý 5 cái VPS: production, staging, database, hai cái app server. Mỗi lần cần kiểm tra gì đó, bạn phải nhớ IP, username, SSH key nào dùng cho server nào, rồi mở terminal, gõ lệnh, lặp lại cho từng server. Nhân lên nếu bạn quản lý 10, 20 servers — và chắc chắn sẽ có lúc bạn nhầm server production với staging.
Trong doanh nghiệp lớn, người ta dùng CMDB (Configuration Management Database) — một hệ thống trung tâm ghi lại tất cả thông tin về hạ tầng: server nào chạy gì, IP bao nhiêu, ai quản lý, kết nối với nhau ra sao. Nghe phức tạp, nhưng bản chất nó chỉ là một nơi duy nhất chứa mọi thông tin về server của bạn.
Bài viết này hướng dẫn bạn biến OpenClaw thành CMDB cá nhân. Từ việc chuẩn bị kết nối SSH an toàn, ghi thông tin server, đặt rules giới hạn quyền để bot không phá server production, đến sử dụng hàng ngày và tự động hoá. Đây là phần bạn nên đọc kỹ nhất nếu đang dùng OpenClaw để quản lý server thật.
Chuẩn bị kết nối SSH
Trước khi OpenClaw có thể quản lý server, bạn cần cho nó khả năng SSH vào các VPS. Phần này hướng dẫn chi tiết từng bước, bao gồm cả việc bảo mật — vì cho bot quyền SSH vào server mà không giới hạn là cực kỳ nguy hiểm.
Bước 1: Tạo SSH key trên server chạy OpenClaw
Trên server đang chạy OpenClaw, tạo một SSH key riêng dành cho bot:
ssh-keygen -t ed25519 -C "openclaw-bot" -f ~/.ssh/id_ed25519_openclawKhi được hỏi passphrase, bạn có thể để trống (Enter 2 lần) để bot có thể SSH tự động mà không cần nhập mật khẩu. Mình dùng ed25519 thay vì RSA vì nó nhanh hơn, key ngắn hơn, và bảo mật tương đương RSA-3072 trở lên.
Sau khi tạo xong, bạn sẽ có hai file:
~/.ssh/id_ed25519_openclaw— private key (giữ trên server OpenClaw, không chia sẻ)~/.ssh/id_ed25519_openclaw.pub— public key (copy sang các VPS)
Bước 2: Tạo user riêng cho bot trên mỗi VPS
Đây là bước quan trọng nhất mà nhiều người bỏ qua. Không bao giờ cho bot SSH bằng root. Hãy tạo một user riêng với quyền hạn chế trên mỗi VPS cần quản lý:
# SSH vào VPS bằng root hoặc user có sudo
ssh root@VPS_IP
# Tạo user riêng cho bot
adduser openclaw --disabled-password --gecos ""
# Tạo thư mục .ssh cho user mới
mkdir -p /home/openclaw/.ssh
chmod 700 /home/openclaw/.ssh
chown openclaw:openclaw /home/openclaw/.sshBước 3: Copy SSH key sang các VPS
Cách nhanh nhất là dùng ssh-copy-id từ server chạy OpenClaw:
ssh-copy-id -i ~/.ssh/id_ed25519_openclaw.pub openclaw@VPS_IPNếu ssh-copy-id không dùng được (VPS chưa có password cho user openclaw), copy thủ công:
# Trên server OpenClaw, xem public key
cat ~/.ssh/id_ed25519_openclaw.pub
# Trên VPS, paste vào authorized_keys của user openclaw
echo "ssh-ed25519 AAAA... openclaw-bot" >> /home/openclaw/.ssh/authorized_keys
chmod 600 /home/openclaw/.ssh/authorized_keys
chown openclaw:openclaw /home/openclaw/.ssh/authorized_keysTest kết nối từ server OpenClaw:
ssh -i ~/.ssh/id_ed25519_openclaw openclaw@VPS_IP "hostname && whoami"Nếu thấy hostname và username openclaw hiện ra — thành công.
Bước 4: Cấu hình SSH config
Thay vì nhớ IP, port, user của từng server, tạo file ~/.ssh/config trên server OpenClaw để đặt alias:
# ~/.ssh/config trên server chạy OpenClaw
Host web-prod
HostName 203.0.113.10
User openclaw
IdentityFile ~/.ssh/id_ed25519_openclaw
Port 22
Host web-staging
HostName 203.0.113.20
User openclaw
IdentityFile ~/.ssh/id_ed25519_openclaw
Port 2222
Host db-master
HostName 203.0.113.30
User openclaw
IdentityFile ~/.ssh/id_ed25519_openclaw
Port 22
Host app-01
HostName 203.0.113.41
User openclaw
IdentityFile ~/.ssh/id_ed25519_openclaw
Host app-02
HostName 203.0.113.42
User openclaw
IdentityFile ~/.ssh/id_ed25519_openclawBây giờ thay vì ssh -i ~/.ssh/id_ed25519_openclaw openclaw@203.0.113.10, bạn (và bot) chỉ cần gõ ssh web-prod. Gọn hơn rất nhiều, và bot cũng dễ hiểu hơn khi bạn nói “SSH vào web-prod”.
Bước 5: Giới hạn sudo cho user bot
User openclaw cần chạy một số lệnh với sudo (xem log, check service status), nhưng tuyệt đối không được có quyền chạy mọi thứ. Trên mỗi VPS, tạo file sudoers riêng:
# Trên VPS, tạo file sudoers cho user openclaw
visudo -f /etc/sudoers.d/openclawNội dung tuỳ theo loại server. Ví dụ cho production server (chỉ cho phép đọc):
# /etc/sudoers.d/openclaw — Production (READ-ONLY)
# Cho phép xem status, không cho phép thay đổi
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --no-pager *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/df -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/free -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/top -bn1
openclaw ALL=(ALL) NOPASSWD: /usr/bin/tail /var/log/*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/cat /etc/nginx/nginx.conf
openclaw ALL=(ALL) NOPASSWD: /usr/bin/nginx -t
# Chặn tuyệt đối các lệnh nguy hiểm
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/rm *
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/dd *
openclaw ALL=(ALL) NOPASSWD: !/usr/sbin/reboot
openclaw ALL=(ALL) NOPASSWD: !/usr/sbin/shutdown *
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/systemctl restart *
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/systemctl stop *Cho staging server (cho phép nhiều hơn):
# /etc/sudoers.d/openclaw — Staging (READ + WRITE)
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart php*-fpm
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --no-pager *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/df -h, /usr/bin/free -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/tail /var/log/*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/nginx -t
# Vẫn chặn các lệnh huỷ diệt
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/rm -rf *
openclaw ALL=(ALL) NOPASSWD: !/usr/sbin/reboot
openclaw ALL=(ALL) NOPASSWD: !/usr/bin/dd *Đây là lớp bảo vệ ở tầng Linux. Dù bot có “muốn” chạy rm -rf / cũng không được phép.
Kết nối qua Tailscale (khuyến nghị)
Cách ở trên dùng SSH truyền thống qua public IP — hoạt động tốt nhưng có nhược điểm: bạn phải mở port SSH ra internet. Nếu có Tailscale, mọi thứ đơn giản và an toàn hơn nhiều.
Cài Tailscale trên server OpenClaw
# Cài Tailscale
curl -fsSL https://tailscale.com/install.sh | sh
# Kết nối vào Tailscale network
sudo tailscale up
# Kiểm tra IP Tailscale
tailscale ip -4
# Ví dụ output: 100.64.0.1Lần đầu chạy tailscale up, nó sẽ cho bạn một link để đăng nhập trên trình duyệt và xác thực máy vào Tailscale network.
Cài Tailscale trên các VPS cần quản lý
Lặp lại quy trình tương tự trên mỗi VPS:
# Trên mỗi VPS
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale upSau khi tất cả máy join xong, kiểm tra trên server OpenClaw:
tailscale status
# Output mẫu:
# 100.64.0.1 openclaw-server thach@ linux -
# 100.64.0.2 web-prod thach@ linux -
# 100.64.0.3 web-staging thach@ linux -
# 100.64.0.4 db-master thach@ linux -Bây giờ thay vì dùng public IP trong SSH config, bạn dùng Tailscale IP:
# ~/.ssh/config — dùng Tailscale IP
Host web-prod
HostName 100.64.0.2
User openclaw
IdentityFile ~/.ssh/id_ed25519_openclaw
Host db-master
HostName 100.64.0.4
User openclaw
IdentityFile ~/.ssh/id_ed25519_openclawBật Tailscale SSH (tuỳ chọn nâng cao)
Tailscale có tính năng SSH tích hợp — bạn không cần quản lý SSH key thủ công nữa. Trên mỗi VPS:
sudo tailscale set --sshSau đó bot có thể SSH trực tiếp mà không cần copy key. Tailscale xác thực dựa trên danh tính máy trong network. Bạn kiểm soát quyền SSH bằng ACL trên Tailscale dashboard.
So sánh: SSH truyền thống vs Tailscale SSH
Để dễ hình dung khi nào nên dùng cách nào:
┌─────────────────────┬──────────────────────┬──────────────────────┐
│ │ SSH truyền thống │ Tailscale SSH │
├─────────────────────┼──────────────────────┼──────────────────────┤
│ Mở port ra internet │ Có (port 22) │ Không │
│ Quản lý SSH key │ Thủ công │ Tự động │
│ Mã hoá │ SSH encryption │ WireGuard + SSH │
│ VPS đổi IP │ Phải update config │ Không ảnh hưởng │
│ Setup ban đầu │ Đơn giản │ Cần cài Tailscale │
│ Phụ thuộc │ Không │ Tailscale service │
│ Phù hợp khi │ Ít server, đơn giản │ Nhiều server, team │
└─────────────────────┴──────────────────────┴──────────────────────┘Khuyến nghị của mình: Nếu quản lý từ 3 server trở lên, dùng Tailscale. Bạn sẽ cảm ơn mình khi không phải mở port 22 ra internet và không phải nhớ IP nào của server nào.
Ghi thông tin server vào TOOLS.md
TOOLS.md là file ghi chú kỹ thuật trong workspace OpenClaw. Bot đọc file này mỗi phiên để biết bạn có những tài nguyên gì. Ghi thông tin tất cả server vào đây, càng chi tiết càng tốt.
Format chuẩn cho mỗi server
Mỗi server nên có đủ các trường sau:
### Servers
#### Production — web-prod
- SSH: `ssh web-prod` (100.64.0.2 qua Tailscale)
- User: openclaw
- OS: Ubuntu 24.04
- CPU/RAM: 4 vCPU / 8GB RAM
- Disk: 80GB SSD (cảnh báo khi > 70%)
- Stack: Nginx 1.26 + PHP 8.3-FPM + MySQL 8.0
- Dịch vụ quan trọng: nginx, php8.3-fpm, mysql
- Backup: daily snapshot lúc 3:00 AM
- 🔴 RISK: HIGH — xem Server Rules bên dướiGiải thích tại sao cần ghi từng trường:
- SSH alias: Bot biết cách kết nối mà không cần hỏi
- OS + Stack: Bot biết chạy lệnh gì (apt vs yum, systemctl vs service)
- Disk + ngưỡng cảnh báo: Bot tự biết khi nào cần alert
- Dịch vụ quan trọng: Bot biết check status những service nào
- Backup schedule: Bot kiểm tra backup có chạy đúng không
- Risk level: Bot biết mức độ cẩn thận cần thiết — đây là trường quan trọng nhất
Ví dụ TOOLS.md đầy đủ
### Servers
#### Production — web-prod
- SSH: `ssh web-prod` (100.64.0.2)
- User: openclaw
- OS: Ubuntu 24.04
- CPU/RAM: 4 vCPU / 8GB
- Disk: 80GB SSD (cảnh báo khi > 70%)
- Stack: Nginx 1.26 + PHP 8.3-FPM + MySQL 8.0
- Dịch vụ: nginx, php8.3-fpm, mysql
- Backup: daily snapshot 3AM
- SSL: Let's Encrypt, auto-renew
- 🔴 HIGH RISK — READ-ONLY cho bot
#### Staging — web-staging
- SSH: `ssh web-staging` (100.64.0.3)
- User: openclaw
- OS: Ubuntu 24.04
- CPU/RAM: 2 vCPU / 4GB
- Disk: 40GB SSD
- Stack: giống production
- 🟡 MEDIUM RISK — bot được restart services
#### Database — db-master
- SSH: `ssh db-master` (100.64.0.4)
- User: openclaw
- OS: Ubuntu 22.04
- CPU/RAM: 4 vCPU / 16GB
- Disk: 200GB NVMe (cảnh báo khi > 60%)
- Stack: MySQL 8.0 (master), Redis 7
- Backup: mysqldump daily 2AM → /backup/mysql/
- 🔴 HIGH RISK — KHÔNG BAO GIỜ restart MySQL khi chưa hỏi
#### App Servers — app-01, app-02
- SSH: `ssh app-01`, `ssh app-02` (100.64.0.5, 100.64.0.6)
- User: openclaw
- OS: Ubuntu 24.04
- Stack: Node.js 22, PM2
- Note: chạy behind load balancer, deploy cả 2 cùng lúc
- 🟡 MEDIUM RISK — bot được restart PM2 apps⚠️ Đặt rules giới hạn quyền cho agent
Đây là phần quan trọng nhất của bài viết. Nếu bạn chỉ đọc một phần, hãy đọc phần này.
OpenClaw có quyền SSH vào server và chạy lệnh. Nếu bạn không đặt giới hạn, nó có thể thực thi bất kỳ lệnh nào — bao gồm rm -rf /, DROP DATABASE, hay restart production lúc nửa đêm. Bot không có ý định xấu, nhưng nó có thể hiểu nhầm yêu cầu của bạn hoặc đưa ra quyết định sai.
Mình chia thành 4 lớp bảo vệ, từ nhẹ đến nặng. Bạn nên áp dụng ít nhất 2 lớp.
Lớp 1: Rules trong TOOLS.md / AGENTS.md (bắt buộc)
Đây là lớp đơn giản nhất — bạn viết rules bằng ngôn ngữ tự nhiên, bot đọc và tuân thủ. Thêm một section “Server Rules” vào TOOLS.md hoặc AGENTS.md:
### Server Rules
#### Quy tắc chung
- Mỗi lệnh có thể thay đổi state (restart, delete, modify config) phải HỎI XÁC NHẬN trước khi chạy
- KHÔNG BAO GIỜ chạy rm -rf trên bất kỳ server nào
- KHÔNG chạy DROP DATABASE, TRUNCATE TABLE trên production
- KHÔNG sửa file config (.conf, .env) trên production mà không confirm trước
- Khi được hỏi "deploy lên production" → luôn deploy staging trước, test, rồi mới hỏi lại về production
#### Production (🔴 HIGH RISK)
- Chế độ: READ-ONLY
- Được phép: xem log, check status, check disk/ram/cpu, đọc config, test nginx config
- KHÔNG được: restart service, sửa config, xoá file, chạy migration
- Mọi thay đổi phải: (1) giải thích sẽ làm gì, (2) hỏi xác nhận, (3) chờ approve
#### Staging (🟡 MEDIUM RISK)
- Được phép: deploy code, restart services, sửa config, chạy migration
- KHÔNG được: xoá database, format disk, thay đổi SSH config
- Deploy xong: tự động chạy health check và báo cáo
#### Dev/Test (🟢 LOW RISK)
- Bot được tự do thao tác
- Vẫn hỏi trước khi xoá dataLưu ý: Rules trong file chỉ là “lời hứa” — bot tuân thủ vì nó đọc và hiểu. Nhưng không có gì ngăn bot phá vỡ rules nếu nó hiểu nhầm yêu cầu. Đó là lý do bạn cần thêm các lớp bảo vệ tiếp theo.
Lớp 2: Phân quyền Linux trên server (khuyến nghị)
Đây là lớp bảo vệ ở tầng hệ điều hành — dù bot có “muốn” chạy lệnh cấm cũng không thể. Mình đã hướng dẫn tạo user openclaw và cấu hình sudoers ở phần trên. Đây là tóm tắt theo từng loại server:
Production server — chỉ cho phép đọc:
# /etc/sudoers.d/openclaw
# CHỈ cho phép xem, không cho phép thay đổi
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --no-pager *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/df -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/free -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/top -bn1
openclaw ALL=(ALL) NOPASSWD: /usr/bin/tail /var/log/*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/nginx -tStaging server — cho phép restart service cụ thể:
# /etc/sudoers.d/openclaw
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl status *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart php8.3-fpm
openclaw ALL=(ALL) NOPASSWD: /usr/bin/systemctl reload nginx
openclaw ALL=(ALL) NOPASSWD: /usr/bin/journalctl --no-pager *
openclaw ALL=(ALL) NOPASSWD: /usr/bin/df -h, /usr/bin/free -h
openclaw ALL=(ALL) NOPASSWD: /usr/bin/tail /var/log/*
openclaw ALL=(ALL) NOPASSWD: /usr/bin/nginx -tLưu ý: Không thêm dòng openclaw ALL=(ALL) NOPASSWD: ALL — dòng này cho full sudo và vô hiệu hoá mọi giới hạn.
Lớp 3: OpenClaw exec policy
OpenClaw có cơ chế approval cho các lệnh nguy hiểm. Khi bot cần chạy một lệnh yêu cầu elevated permissions (ví dụ: lệnh có sudo, lệnh chạy trên host thay vì sandbox), nó sẽ dừng lại và hỏi bạn approve trước khi thực thi.
Bạn sẽ thấy thông báo dạng:
🔒 Lệnh cần approval:
ssh web-prod "sudo systemctl restart nginx"
/approve allow-once ← cho phép lần này
/approve allow-always ← cho phép luôn lệnh tương tự
/approve deny ← từ chốiĐây là lớp bảo vệ cuối cùng — bạn luôn có quyền từ chối trước khi lệnh được thực thi. Đặc biệt hữu ích cho production server.
Lớp 4: Phân loại server theo mức rủi ro
Kết hợp tất cả các lớp ở trên, bạn có thể phân loại server thành 3 mức rủi ro. Đây là cách mình tổ chức:
🔴 Production (HIGH RISK)
├── Rules: READ-ONLY trong TOOLS.md
├── Linux: sudoers chỉ cho phép đọc
├── Exec: mọi lệnh cần approval
└── Bot chỉ được: xem log, check status, check disk/ram
🟡 Staging (MEDIUM RISK)
├── Rules: READ + WRITE cụ thể trong TOOLS.md
├── Linux: sudoers cho phép restart service chỉ định
├── Exec: lệnh restart cần approval, lệnh đọc không cần
└── Bot được: deploy, restart nginx/php, sửa config
🟢 Dev/Test (LOW RISK)
├── Rules: tự do trong TOOLS.md
├── Linux: sudoers rộng hơn
├── Exec: không cần approval
└── Bot được tự do thao tácTemplate TOOLS.md an toàn cho người mới
Nếu bạn mới bắt đầu, copy template này vào TOOLS.md rồi thay thông tin server của bạn:
### Servers
#### [Tên server] — [SSH alias]
- SSH: `ssh [alias]` ([IP])
- User: openclaw
- OS: [Ubuntu/AlmaLinux + version]
- CPU/RAM: [specs]
- Disk: [size] (cảnh báo khi > [%])
- Stack: [Nginx/Apache + PHP/Node + DB]
- Dịch vụ: [service1, service2]
- Backup: [schedule]
- [🔴/🟡/🟢] [HIGH/MEDIUM/LOW] RISK
### Server Rules
#### Quy tắc chung
- Mỗi lệnh thay đổi state → HỎI XÁC NHẬN trước
- KHÔNG rm -rf, KHÔNG DROP DATABASE trên production
- KHÔNG sửa config production mà không confirm
- Deploy production → staging trước, test xong mới production
#### [Tên server production] (🔴)
- READ-ONLY: chỉ xem log, check status, check tài nguyên
- Mọi thay đổi: giải thích → xác nhận → chờ approve
#### [Tên server staging] (🟡)
- Được: deploy, restart, sửa config
- Không: xoá data, thay đổi hạ tầng
#### [Tên server dev] (🟢)
- Tự do thao tácSử dụng hàng ngày
Sau khi setup xong, bạn tương tác hoàn toàn bằng ngôn ngữ tự nhiên. Dưới đây là các ví dụ thực tế.
Kiểm tra tài nguyên toàn bộ server
Bạn: “Kiểm tra disk và RAM tất cả server”
Bot sẽ: SSH vào từng server trong TOOLS.md, chạy df -h và free -h, tổng hợp kết quả:
📊 Báo cáo tài nguyên:
web-prod: Disk 45/80GB (56%) | RAM 5.2/8GB (65%) ✅
web-staging: Disk 12/40GB (30%) | RAM 1.8/4GB (45%) ✅
db-master: Disk 142/200GB (71%) | RAM 12/16GB (75%) ⚠️
app-01: Disk 8/40GB (20%) | RAM 2.1/4GB (53%) ✅
app-02: Disk 9/40GB (23%) | RAM 2.3/4GB (58%) ✅
⚠️ db-master: disk > 70% ngưỡng cảnh báo. Kiểm tra /backup có file cũ cần dọn không?Kiểm tra service status
Bạn: “Check nginx và MySQL có chạy bình thường trên production không?”
Bot sẽ: SSH vào web-prod, chạy systemctl status nginx và systemctl status mysql, phân tích output:
🟢 web-prod service status:
nginx: active (running) since Mon 2026-03-10 08:15:00 — uptime 4 days
mysql: active (running) since Mon 2026-03-10 08:15:12 — uptime 4 days
Cả hai service chạy bình thường, không có lỗi trong journal gần đây.Xem log lỗi
Bạn: “Xem error log nginx trên production 1 giờ qua, tóm tắt cho mình”
Bot sẽ: SSH vào web-prod, chạy sudo tail -n 200 /var/log/nginx/error.log, lọc log trong 1 giờ qua, phân tích và tóm tắt:
📋 Nginx error log — web-prod (1 giờ qua):
- 12 lần "upstream timed out" từ PHP-FPM → có thể PHP xử lý chậm
- 3 lần "client sent too large body" → client upload file > limit
- Không có lỗi 5xx nghiêm trọng
💡 Đề xuất: kiểm tra PHP-FPM process manager, có thể cần tăng pm.max_children.So sánh config giữa 2 server
Bạn: “So sánh config nginx giữa production và staging, xem khác nhau chỗ nào”
Bot sẽ: SSH cả hai server, lấy file nginx.conf, diff và highlight khác biệt:
🔍 Khác biệt nginx.conf — production vs staging:
1. worker_connections: prod=2048, staging=1024
2. client_max_body_size: prod=50m, staging=100m ← staging cho phép upload lớn hơn
3. SSL certificate: prod dùng Let's Encrypt, staging dùng self-signed
4. Gzip: prod bật gzip_static on, staging không có
Còn lại giống nhau. Bạn muốn sync config nào từ prod sang staging không?Deploy lên staging
Bạn: “Deploy version mới lên staging”
Bot sẽ: Thực hiện step-by-step theo quy trình:
📦 Deploy lên web-staging:
1. ✅ SSH vào web-staging
2. ✅ cd /var/www/app && git pull origin main
→ Updated: 3 files changed, 45 insertions, 12 deletions
3. ✅ composer install --no-dev
4. ✅ php artisan migrate --force
→ Migrated: 2026_03_14_create_orders_table
5. ✅ sudo systemctl restart php8.3-fpm
6. ✅ Health check: curl -s -o /dev/null -w "%{http_code}" https://tech.nhatkychuyenhoa.link → 200
🟢 Deploy thành công. Staging đang chạy version mới.
Bạn muốn mình test thêm endpoint nào không?Lưu ý: nếu bạn nói “deploy lên production”, bot sẽ hỏi xác nhận trước (vì rules trong TOOLS.md yêu cầu), và có thể đề xuất deploy staging trước.
Tự động hoá với Cron Jobs
Cron jobs cho phép bot tự động chạy kiểm tra định kỳ mà bạn không cần nhớ. Kết hợp với bài 4 về Cron Jobs, dưới đây là các cron jobs phổ biến cho quản lý server:
Báo cáo sức khoẻ hàng ngày
openclaw cron add "Kiểm tra tất cả server trong TOOLS.md: uptime, CPU load, RAM, disk usage. Chỉ báo cáo chi tiết nếu có vấn đề (disk > 70%, RAM > 80%, load > CPU cores). Còn lại tóm tắt 1 dòng mỗi server." \
--cron "0 8 * * *" --channel telegramMỗi sáng lúc 8h, bạn nhận tin nhắn Telegram tóm tắt tình trạng tất cả server. Chỉ cần đọc 30 giây là biết mọi thứ ổn hay có gì cần xử lý.
Kiểm tra backup
openclaw cron add "SSH vào db-master, kiểm tra file backup MySQL mới nhất trong /backup/mysql/. Cảnh báo nếu: (1) backup cũ hơn 24 giờ, (2) file size nhỏ bất thường (< 100MB khi bình thường > 500MB), (3) không tìm thấy file backup nào." \
--cron "0 7 * * *" --channel telegramKiểm tra SSL certificate
openclaw cron add "Kiểm tra ngày hết hạn SSL certificate trên web-prod. Chạy: echo | openssl s_client -connect web-prod:443 -servername domain.com 2>/dev/null | openssl x509 -noout -dates. Cảnh báo nếu còn dưới 14 ngày." \
--cron "0 9 * * 1" --channel telegramSSL certificate hết hạn mà không ai biết là lỗi phổ biến. Cron job này kiểm tra mỗi thứ Hai và cảnh báo sớm 2 tuần.
Tổng hợp log lỗi hàng tuần
openclaw cron add "SSH vào web-prod, đọc /var/log/nginx/error.log 7 ngày gần nhất. Tổng hợp top 5 lỗi phổ biến nhất, số lần xuất hiện, và đề xuất fix nếu có thể." \
--cron "0 9 * * 1" --channel telegramSecurity audit hàng tuần
openclaw cron add "Kiểm tra bảo mật trên tất cả server: (1) có package nào cần security update không (apt list --upgradable), (2) có SSH login thất bại bất thường không (journalctl -u sshd --since '7 days ago' | grep Failed), (3) có user lạ nào được tạo mới không. Tóm tắt kết quả." \
--cron "0 10 * * 0" --channel telegramChủ nhật hàng tuần, bot rà soát security cơ bản. Không thay thế được security audit chuyên nghiệp, nhưng bắt được 80% vấn đề phổ biến.
Inventory tracking trong memory
Bot có memory dài hạn — nó có thể ghi lại mọi thay đổi trên server. Đây là lợi thế mà terminal thông thường không có: bạn có changelog tự động mà không cần duy trì thủ công.
Bot tự ghi changelog
Mỗi khi bạn yêu cầu bot thực hiện thay đổi trên server, nó sẽ ghi vào memory file. Ví dụ:
# memory/2026-03-14.md
## Server Changes
- 10:30 — Updated Nginx 1.24 → 1.26 on web-prod (requested by Thạch)
- 11:00 — Deployed v2.5.0 to web-staging, ran migration create_orders_table
- 14:15 — Increased PHP memory_limit 256M → 512M on web-prod (approved by Thạch)
- 16:00 — Cleaned /backup/mysql/ on db-master, removed backups older than 30 daysHỏi lại lịch sử
Sau này bạn có thể hỏi:
- “Lần cuối update Nginx production là khi nào?” → Bot tìm trong memory: “2026-03-14, Nginx 1.24 → 1.26”
- “Tuần qua có thay đổi gì trên db-master?” → Bot tổng hợp từ memory files
- “Ai yêu cầu tăng PHP memory_limit?” → Bot: “Thạch, ngày 14/3, từ 256M lên 512M”
Đây chính là CMDB cá nhân: một nơi duy nhất chứa thông tin server (TOOLS.md) + lịch sử thay đổi (memory) + khả năng truy vấn bằng ngôn ngữ tự nhiên.
Kết luận
Quản lý nhiều VPS bằng OpenClaw không khó (nếu chưa cài, xem hướng dẫn từ A tới Z) — setup SSH, ghi thông tin server, đặt vài cron jobs là xong. Đảm bảo bạn đã cài OpenClaw lên VPS trước khi bắt đầu. Nhưng phần quan trọng nhất không phải là tính năng mà là bảo mật.
Hãy nhớ 4 lớp bảo vệ:
- Rules trong TOOLS.md — bot đọc và tuân thủ
- Phân quyền Linux — user
openclawchỉ có quyền cần thiết - Exec policy — lệnh nguy hiểm cần approval
- Phân loại server — production read-only, staging cho phép thay đổi
Áp dụng ít nhất 2 lớp, lý tưởng là cả 4. Một agent có quyền SSH vào server mà không có giới hạn giống như đưa chìa khoá nhà cho người lạ — có thể không có chuyện gì xảy ra, nhưng bạn không muốn test điều đó trên production.
Kết hợp với bài 9 về giám sát server, bạn có một hệ thống vừa phản ứng (nhận alert khi có sự cố) vừa chủ động (kiểm tra định kỳ, quản lý hạ tầng bằng chat) hoàn chỉnh.
Các bài trong serie:
- Bài 1: Hướng dẫn OpenClaw từ A-Z cho người mới bắt đầu
- Bài 2: Cài OpenClaw lên VPS Việt Nam để chạy 24/7
- Bài 3: Tùy biến OpenClaw
- Bài 4: Tự động hoá: Cron Jobs, Heartbeats và Webhooks
- Bài 5: Cài đặt và tạo Skills
- Bài 6: Kết nối nhiều AI cùng lúc
- Bài 7: OpenClaw cho team
- Bài 8: 10 cách sử dụng OpenClaw hữu ích
- Bài 9: Biến OpenClaw thành NOC Engineer
- Bài 10: Quản lý nhiều VPS bằng OpenClaw (bài này)
- Hướng dẫn OpenClaw
- Cơ bản
- Nâng cao
- Chuẩn bị kết nối SSH
- Bước 1: Tạo SSH key trên server chạy OpenClaw
- Bước 2: Tạo user riêng cho bot trên mỗi VPS
- Bước 3: Copy SSH key sang các VPS
- Bước 4: Cấu hình SSH config
- Bước 5: Giới hạn sudo cho user bot
- Kết nối qua Tailscale (khuyến nghị)
- Cài Tailscale trên server OpenClaw
- Cài Tailscale trên các VPS cần quản lý
- Bật Tailscale SSH (tuỳ chọn nâng cao)
- So sánh: SSH truyền thống vs Tailscale SSH
- Ghi thông tin server vào TOOLS.md
- Format chuẩn cho mỗi server
- Ví dụ TOOLS.md đầy đủ
- ⚠️ Đặt rules giới hạn quyền cho agent
- Lớp 1: Rules trong TOOLS.md / AGENTS.md (bắt buộc)
- Lớp 2: Phân quyền Linux trên server (khuyến nghị)
- Lớp 3: OpenClaw exec policy
- Lớp 4: Phân loại server theo mức rủi ro
- Template TOOLS.md an toàn cho người mới
- Sử dụng hàng ngày
- Kiểm tra tài nguyên toàn bộ server
- Kiểm tra service status
- Xem log lỗi
- So sánh config giữa 2 server
- Deploy lên staging
- Tự động hoá với Cron Jobs
- Báo cáo sức khoẻ hàng ngày
- Kiểm tra backup
- Kiểm tra SSL certificate
- Tổng hợp log lỗi hàng tuần
- Security audit hàng tuần
- Inventory tracking trong memory
- Bot tự ghi changelog
- Hỏi lại lịch sử
- Kết luận
No Comment! Be the first one.