-
Notifications
You must be signed in to change notification settings - Fork 0
Operations vi
Chạy SkimMail sau khi đã cài: giữ dữ liệu an toàn, nhìn được nó đang làm gì, cập nhật nó, và hiểu những gì nó tự làm trên đĩa mà không cần ai bảo.
Mọi màn hình nhắc ở đây đều là màn hình có thật trong bản đã phát hành. Chỗ nào chưa có giao diện, trang này nói thẳng và đưa lệnh thay thế.
Một thư mục duy nhất, DATA_DIR — với gói apt là /var/lib/skimmail:
| Đường dẫn | Là gì |
|---|---|
skimmail.db |
Cơ sở dữ liệu: tài khoản, header thư, rule, cài đặt |
blobs/ |
Nội dung thư đã cache (xem Cache nội dung thư) |
master.key |
Khoá mã hoá mọi mật khẩu tài khoản đang lưu |
plugins/ |
Plugin runtime, tải về khi cần |
Mất master.key là không cứu được. Mọi mật khẩu tài khoản trong cơ sở dữ
liệu đều mã hoá bằng nó, và từ 1.11.0 nội dung thư đã cache cũng vậy. Một cơ sở
dữ liệu không có khoá không phải là instance bị suy giảm — nó là instance
không đọc được. Bản sao lưu nào đáng giá thì phải chứa cả hai; sao lưu mỗi
skimmail.db gần như vô nghĩa.
Chiều ngược lại cũng đúng, và đây là chỗ người ta hay làm sai khi dọn dẹp: xoá
master.key mà giữ cơ sở dữ liệu là trạng thái tệ nhất trong ba khả năng.
Xoá cả DATA_DIR hoặc không xoá gì.
Settings ▸ Backup, chỉ owner. Hướng dẫn đầy đủ — archive chứa gì, quy tắc mã hoá và mật khẩu, sao lưu theo lịch, cách phục hồi, và cách thực sự kiểm chứng một lần phục hồi trước khi cần tới nó — nằm ở trang riêng: Backup và restore.
Một điều đáng nhắc lại ở đây vì nó giải thích bảng phía trên: archive mang
master.key như một mục riêng bên trong nó. Đó chính là lý do mất file đó
không phải kiểu vấn đề "phục hồi từ backup" như mất một dòng trong cơ sở dữ
liệu — cơ sở dữ liệu thiếu khoá và archive thiếu mục khoá đều hỏng theo cùng
một cách.
Settings ▸ Logs. Mức log (debug / info / warn / error) là công tắc
sống: đổi là có hiệu lực ngay, không cần khởi động lại, và nó thắng giá trị
khởi động mặc định từ LOG_LEVEL (xem Cấu hình).
Ba cách để thực sự đọc log:
-
Bộ xem trực tiếp trong app, ngay trên màn hình đó — một luồng thời gian thực qua WebSocket, nạp sẵn ~400 dòng gần nhất khi mở, lọc được theo mức và tìm theo chữ tự do, có pause/resume để một instance đang bận không cuốn mất dòng bạn định đọc. Không cần quyền truy cập shell vào máy chủ.
-
File xoay vòng, khi
LOG_FILEđược đặt (gói apt đặt nó là/var/log/skimmail/skimmail.log). Bản thân đường dẫn là env-only — không gì trong UI hay API đổi được nó, nên không gì chạy bên trong SkimMail có thể bị lừa ghi vào một file tuỳ ý. Cái UI đổi được lúc chạy: bật/tắt ghi vào file, kích cỡ xoay vòng (LOG_MAX_SIZE_MB, 1–1024 MB, mặc định 10), và số bản xoay vòng giữ lại (LOG_MAX_BACKUPS, 0–20, mặc định 3). Một thanh mức dùng cho biết file hiện đầy bao nhiêu; Download stream file về trình duyệt, và Truncate xoá sạch nó sau khi xác nhận. -
Journal, luôn bật bất kể có file sink hay không:
sudo journalctl -u skimmail -fNhớ
sudo. Thiếu nó bạn sẽ thấy journal rỗng hoặc thiếu chứ không thấy lỗi — đọc lên cứ như "chẳng có gì xảy ra", trong khi thực ra bạn không được phép xem.
Format (text hay json, LOG_FORMAT) là env-only và chỉ đọc trong UI —
mức log và xoay vòng là hai công tắc sống duy nhất.
Về phân quyền. Tab này mở được từ mức operator trở lên, và xem bộ xem
trực tiếp là hành động của operator. Mọi thứ khác ở đây — đọc hay đổi mức log
và cài đặt xoay vòng, tải file về, và truncate — chỉ dành cho owner trong
API (GET/PUT /api/settings/logs, GET /api/logs/download,
POST /api/logs/truncate). Vì màn hình nạp cài đặt trước khi hiển thị bất cứ
gì khác, một operator mở Settings ▸ Logs hôm nay sẽ thấy màn hình không
bao giờ tải xong, thay vì một bộ xem có phần cài đặt bị ẩn đi — đáng biết
trước khi phân vai quanh tab này. Xem Người dùng và phân quyền.
Settings ▸ Updates, chỉ owner. SkimMail có thể tự kiểm tra release feed
của mình (mặc định là GitHub Releases; ghi đè bằng UPDATE_FEED_URL cho một
mirror tự lưu trữ hoặc air-gapped — xem Cấu hình) và, tuỳ
cách triển khai, tự cài bản cập nhật.
Kiểm tra là opt-in và mặc định tắt — không có gì gọi ra GitHub cho tới khi bạn bật nó lên hoặc bấm Check now. Bật kiểm tra tự động thì nó thăm dò theo chu kỳ (mặc định 24 giờ, chỉnh được), bắt đầu hai phút sau khi khởi động, để một lần restart không bao giờ gây ra một cuộc gọi về bất ngờ. Một bản mới hơn bản đang chạy sẽ hiện ghi chú phát hành và một huy hiệu phiên bản; Skip ghi lại phiên bản đó để nó ngừng được thông báo.
Nút có cài được hay không phụ thuộc vào cách bạn triển khai:
| Kiểu triển khai | SkimMail báo cáo gì | Nút Update làm gì |
|---|---|---|
| Binary tarball dựng sẵn, giải nén vào thư mục do chính user chạy dịch vụ sở hữu | self |
Tải, xác minh, hoán đổi và tự khởi động lại tại chỗ |
| Container (Docker / containerd / Kubernetes) | managed |
Từ chối; kéo và chạy image mới thay vào |
| Gói apt | managed |
Cũng từ chối — ProtectSystem=strict trong unit systemd đi kèm khiến /usr/bin chỉ đọc với user dịch vụ skimmail, nên binary không tự ghi đè được chính nó dù không nằm trong container |
Việc phát hiện là tự động (SkimMail tìm /.dockerenv và cgroup của container,
rồi thử tạo một file tạm ngay cạnh chính binary của nó) — không có cài đặt
nào để ghi đè việc này. Vì đường apt cũng là managed, hãy cập nhật theo cách
thông thường:
sudo apt update && sudo apt install --only-upgrade skimmail
Báo "Unable to locate package" ngay sau một bản phát hành hầu như luôn là do
index cục bộ cũ, không phải publish hỏng. Chạy sudo apt update trước.
Khi nút chạy được — kiểu triển khai self, có asset phát hành cho đúng
nền tảng của bạn, và bản build mang khoá xác minh phát hành (mọi bản chính
thức qua apt/Docker/tarball đều có) — Update now tải asset phát hành cùng
SHA256SUMS và chữ ký .minisig của nó; xác minh chữ ký đối chiếu với khoá
cố định đóng cứng trong các bản build chính thức; kiểm SHA256 của asset đối
chiếu danh sách checksum đã xác minh; giải nén binary; đổi tên binary hiện tại
sang <binary>.old; đổi tên binary mới vào chỗ cũ; và re-exec vào nó — tiến
trình tự thay thế chính nó nên không có bước "khởi động lại" riêng. Nếu bước
hoán đổi thành công nhưng re-exec thất bại (hiếm, tuỳ nền tảng), binary mới đã
được cài và chỉ cần khởi động lại dịch vụ thủ công để xong việc.
Bản build không có khoá xác minh thì dừng ở mức thông báo. Nó sẽ báo có bản cập nhật và từ chối cài thay vì cài một thứ nó không kiểm được — cùng chiếc khoá này cũng đứng sau chữ ký manifest plugin mô tả ở phần Plugin bên dưới.
Rollback là thủ công, và chỉ khả thi với triển khai self. Bước apply
không bao giờ xoá <binary>.old khi thành công, nên nếu bản mới có vấn đề bạn
có thể dừng dịch vụ, đổi .old trở lại thành binary hiện hành, rồi khởi động
lại. Không có nút nào cho việc này và cũng không có phát hiện tự động một bản
cập nhật lỗi — cả quyết định lẫn khắc phục đều là của bạn.
Cài cập nhật tự động (nằm dưới công tắc kiểm tra, và vô tác dụng trừ khi
công tắc đó cũng bật) áp dụng một bản cập nhật tự-cài-được ngay khi một lần
kiểm tra tìm thấy nó. Trên triển khai managed, công tắc này không có gì để
tác động, vì bản cập nhật nó định kích hoạt bị từ chối giống hệt cách nút bị
từ chối; UI ghi chú điều đó ngay cạnh công tắc.
Settings ▸ Plugins, chỉ owner. Các tính năng egress và remote access ship dưới dạng plugin runtime thay vì biên dịch thẳng vào binary gốc, để một cài đặt chỉ-đọc-mail giữ được nhẹ. Có ba plugin tồn tại hôm nay:
| Plugin | Loại | Phục vụ cho |
|---|---|---|
cloudflared |
external (binary chính thức của Cloudflare, đã ghim) | Remote access — Cloudflare Tunnel |
skimmail-tunnel-ts |
SkimMail tự build | Remote access — Tailscale |
skimmail-egress-wg |
SkimMail tự build | WireGuard engine nhúng trên Connections |
Chúng nằm dưới DATA_DIR/plugins/ (xem "Mọi thứ nằm ở đâu" phía trên), chạy
như tiến trình con với đúng quyền của server, và được xác minh lại mỗi lần
được spawn — không chỉ lúc cài.
Install tải trước artifact đã ghim cho đúng OS/kiến trúc của bạn, kiểm SHA256, và hiện thanh tiến trình tải; chưa có gì đang chạy nên không cần xác nhận. Update đối chiếu một plugin đã cài về đúng phiên bản manifest đang ghim — nếu nó đang phục vụ thứ gì đang chạy sống (một tunnel đang chạy, một egress WireGuard nhúng đang bật), một hộp xác nhận sẽ nêu tên thứ sẽ gián đoạn ngắn trong lúc nó dừng rồi bật lại. Uninstall xoá hẳn file và cũng nêu tên tác động trước. WireGuard engine nhúng còn có một bản build "builtin" chạy trong tiến trình, dùng trước khi plugin tồn tại trên đĩa; nó không cài được cũng không gỡ được từ màn hình này, vì chưa có file nào để thao tác.
Đọc danh mục là một route ở mức operator trong API, nhưng cả tab Settings ▸ Plugins đòi owner trong UI, nên trên thực tế không ai dưới owner chạm được màn hình này qua app.
Danh mục những gì cài được, và ở phiên bản nào, đến từ plugins.json, xuất
bản cạnh apt repository trên cùng GitHub Pages origin với feed self-update.
Trên bản build mang khoá xác minh phát hành (từ 1.10.0, và đúng với mọi
bản build chính thức), chữ ký .minisig của chính manifest được kiểm trước
khi bất cứ gì trong đó được tin — thiếu chữ ký bị từ chối thẳng — vì một hash
đã ghim chỉ đáng tin bằng đúng tài liệu mang nó, và xoá một file không được
phép trở thành cách tắt phép kiểm đó. Một bản build không có khoá xác minh
(build tuỳ chỉnh chưa đặt UPDATE_PUBKEY) vẫn thực thi việc ghim SHA256 cho
từng artifact, nhưng ghi một cảnh báo một lần rằng bản thân cái ghim đó chưa
được xác minh.
Settings ▸ Sync. Trạng thái từng tài khoản, lỗi gần nhất, và số lần lỗi liên tiếp. Tài khoản lỗi nhiều lần sẽ bị tự động dừng thay vì thử lại mãi; bảng này là nơi bạn thấy điều đó và bật lại.
Việc dừng là cố ý, và các tính năng khác tôn trọng nó. Chẳng hạn prefetch nội dung thư ở nền bỏ qua hoàn toàn tài khoản đã bị tự động dừng, và không bao giờ ghi lỗi của chính nó vào bộ đếm đó — việc chạy nền tuỳ chọn không được phép làm ngưng một hộp thư vốn khoẻ mạnh.
Mô hình đầy đủ — ba trạng thái của bảng, ngưỡng tự động dừng cùng các mức chặn của nó, và những công tắc sync nào cần khởi động lại mới có hiệu lực — nằm ở trang riêng: Sync và Sync Health.
Nội dung thư đã cache nay có vòng đời. Mô tả đầy đủ ở Cache nội dung thư; về mặt vận hành, có ba việc tự xảy ra:
Một lượt hoà giải ở lần khởi động đầu của 1.11.0. Nó dựng index cho nội dung đã được các bản trước cache, và với lưu trữ trên đĩa thì xoá luôn phần mồ côi chúng để lại. Bạn sẽ thấy đúng một lần:
reconciled body cache store=fs indexed=1843 bytes=284127744 extra=12 deleted=12
Đúng một lần. Nó ghi lại là đã chạy, nên khởi động lại không lặp.
Với S3 thì chỉ đếm rồi dừng. Dòng log kết thúc bằng needs_purge=true và
không xoá gì cả, vì bucket đó có thể đang chứa cả archive sao lưu của bạn và
SkimMail sẽ không đoán. Xoá là quyết định của bạn:
Settings ▸ Security ▸ Cache nội dung thư ▸ Dọn phần không rõ chủ, hoặc vẫn việc đó qua API:
curl -sS -b cookies -X POST http://localhost:8080/api/settings/cache/purge
Chỉ owner, cả hai đường. Nút bấm có từ 1.11.1; trên 1.11.0, API là lối duy nhất, vì panel khi đó nằm trong một tab Settings đang ẩn.
Dọn liên tục. Vượt CACHE_MAX_SIZE_MB thì nội dung lâu không đọc nhất đi
trước; quá BODY_TTL_DAYS thì hết hạn theo tuổi. Biến môi trường đặt giá trị
khởi tạo (xem Cấu hình); từ 1.11.1, đúng hai giới hạn
đó sửa được trong Settings ▸ Security, và giá trị lưu ở đó sẽ thắng biến
môi trường từ lúc ấy trở đi.
apt remove dừng và gỡ đăng ký dịch vụ, để nguyên DATA_DIR — gồm cả
master key. apt purge cũng vậy: không có script postremove nào, nên không có
gì tự động xoá thư của bạn.
Xoá là việc thủ công và không hoàn tác được:
sudo rm -rf /var/lib/skimmail
sudo userdel skimmail # tuỳ chọn: tài khoản dịch vụ
Cài lại mà không xoá thì chạy tiếp đúng chỗ đang dở — không phải tải lại gì cả.
Tham khảo — Trang chủ · Cấu hình · Bảo mật · Khắc phục sự cố · Câu hỏi thường gặp
SkimMail · skimmail@base101.app · 2026-09-15 · commit dffbb18