Cuộc khủng hoảng máy chủ lúc 2 giờ sáng và sự mong manh của /etc/passwd
Đó là lúc 2 giờ sáng khi điện thoại của tôi rung lên với một cảnh báo nghiêm trọng. Một máy chủ production đang gặp sự cố sau khi một script tự động hóa bị lỗi làm hỏng tệp /etc/passwd. Nếu bạn quản lý các hệ thống Linux, bạn sẽ hiểu rõ sự phân mảnh này. Danh tính người dùng bị rải rác trong /etc/shadow, /etc/passwd và /etc/group, trong khi dữ liệu thực tế của họ nằm ở /home/user. Đây là một thiết kế đã 40 năm tuổi và cực kỳ mong manh.
Việc khôi phục trong đêm đó rất tẻ nhạt. Tôi đã mất ba giờ đồng hồ để đối chiếu thủ công các UID và GID trên năm tệp cấu hình khác nhau. Trải nghiệm này đã thôi thúc tôi chuyển đổi hệ thống của mình sang systemd-homed. Thay vì phân tán metadata, nó coi tài khoản người dùng như một đối tượng duy nhất, độc lập. Khi bạn chuyển thư mục home của người dùng sang một máy mới, thông tin xác thực, khóa mã hóa và quyền hạn của họ sẽ đi theo. Không cần đồng bộ hóa thủ công.
Bắt đầu nhanh: Triển khai người dùng được quản lý trong chưa đầy 5 phút
Việc bắt đầu khá đơn giản. Hầu hết các bản phân phối hiện đại như Arch, Fedora hoặc Ubuntu 22.04+ đều có sẵn gói này, mặc dù nó hiếm khi được kích hoạt mặc định.
# Cài đặt dịch vụ (Ví dụ trên Ubuntu/Debian)
sudo apt update && sudo apt install systemd-homed
# Kích hoạt daemon
sudo systemctl enable --now systemd-homedKhi dịch vụ đã hoạt động, bạn có thể tạo một người dùng an sau, được mã hóa chỉ bằng một lệnh. Tôi sử dụng backend LUKS cho các hệ thống production vì nó mang lại sự cân bằng tốt nhất giữa bảo mật và hiệu suất I/O.
# Tạo người dùng 'devops' với quota 5GB và mã hóa LUKS
sudo homectl create devops --storage=luks --disk-size=5GLệnh này tự động hóa nhiều bước. Nó tạo một tệp loopback được mã hóa LUKS (thường ở /home/devops.home), định dạng nó và tạo một bản ghi JSON có chữ ký chứa metadata của người dùng. Để kiểm tra chi tiết, hãy chạy:
homectl inspect devopsKiến trúc: Tại sao systemd-homed vượt trội về mặt cấu trúc
Người dùng Linux truyền thống là những thực thể cố định. Thư mục home của họ nằm không mã hóa trên đĩa, và UID của họ được ghi cứng vào trạng thái hệ thống toàn cục. systemd-homed thay đổi vòng đời này. Khi người dùng đăng xuất, hệ thống sẽ khóa bằng mật mã và unmount thư mục của họ. Hệ điều hành thực tế sẽ “quên” sự tồn tại của người dùng cho đến khi họ xác thực lại.
Chọn Storage Backend
Bạn có bốn tùy chọn chính dựa trên kiến trúc hệ thống tệp của mình:
- LUKS: Tiêu chuẩn ngành. Nó tạo một tệp loopback được mã hóa, lý tưởng cho ext4 hoặc XFS.
- Subvolumes: Tốt nhất cho người dùng Btrfs, tận dụng mã hóa subvolume gốc.
- fscrypt: Mã hóa hệ thống tệp ở cấp độ kernel với độ trễ tối thiểu.
- Directory: Một thư mục thông thường, không mã hóa. Chỉ sử dụng tùy chọn này để thử nghiệm các hệ thống cũ.
Trên một node thử nghiệm với 4GB RAM và 40 tài khoản nhà phát triển tạm thời, kiến trúc này đã giúp cắt giảm 70% thời gian cấp phát tài khoản. Bằng cách để daemon xử lý việc mount, tôi đã loại bỏ được các mục /etc/fstab phức tạp và các script quota dễ lỗi từng gây ra tình trạng nghẽn I/O trong giờ cao điểm.
Quản lý nâng cao: Quota và Giới hạn tài nguyên
Quản lý dung lượng đĩa trong môi trường chia sẻ thường là một vấn đề đau đầu. Các quota truyền thống yêu cầu các tùy chỉnh ở cấp độ hệ thống tệp và dễ bị hỏng trong quá trình di chuyển.
Giới hạn động
Với homectl, bạn có thể sửa đổi các giới hạn ngay lập tức mà không cần unmount ổ đĩa. Nếu người dùng ‘devops’ chạm mức giới hạn 5GB, bạn có thể tăng gấp đôi nó ngay tức khắc:
sudo homectl update devops --disk-size=10GVì systemd-homed tích hợp với cgroups, bạn cũng có thể giới hạn CPU và bộ nhớ. Điều này ngăn chặn một script Python lỗi kích hoạt OOM killer và làm sập các dịch vụ cốt lõi của bạn lúc 3 giờ sáng.
sudo homectl update devops --tasks-max=500 --memory-high=2GSức mạnh của khả năng di động
Danh tính của người dùng được lưu trữ bên trong ổ đĩa mã hóa trong tệp ~/.identity. Điều này có nghĩa là bạn có thể di chuyển tệp /home/devops.home sang bất kỳ máy chủ nào đang chạy systemd-homed. Máy chủ mới sẽ nhận diện tài khoản ngay lập tức. Không cần phải khớp UID thủ công hoặc sao chép các mã băm trong /etc/shadow giữa các node.
Xử lý sự cố thực tế cho Sysadmin
Chuyển sang công nghệ này đòi hỏi một sự thay đổi trong cách bạn xử lý các tác vụ quản trị thông thường. Đây là những gì tôi đã học được trong quá trình triển khai.
1. Vấn đề với SSH Key
Daemon SSH không thể đọc ~/.ssh/authorized_keys nếu thư mục home đang bị mã hóa và khóa. Để khắc phục, hãy lưu trữ khóa công khai trực tiếp trong bản ghi người dùng:
homectl update devops --ssh-authorized-keys="ssh-rsa AAAA..."Daemon sẽ chuyển các khóa này cho SSHD trong quá trình xác thực, cho phép đăng nhập không mật khẩu mượt mà mà vẫn kích hoạt được việc giải mã ổ đĩa.
2. Giải quyết tình trạng kẹt Mount
Nếu một phiên làm việc bị treo, thư mục home có thể vẫn ở trạng thái mount, ngăn cản các cập nhật quản trị. Bạn có thể thiết lập lại trạng thái bằng cách khóa và mở khóa thủ công:
sudo homectl lock devops
sudo homectl unlock devops3. Tương thích môi trường Desktop
Đối với người dùng giao diện đồ họa (GUI), hãy đảm bảo trình quản lý hiển thị (GDM, SDDM hoặc LightDM) được cấu hình với pam_systemd_home. Nếu thiếu module này, bạn sẽ xác thực thành công nhưng hệ thống sẽ không mở khóa được ổ đĩa, dẫn đến phiên làm việc bị lỗi hoặc chỉ nhận được một thư mục home tạm thời.
Chuyển sang systemd-homed mang lại cảm giác giống như chuyển từ cấu hình thủ công sang sử dụng một API hiện đại. Nó đòi hỏi một tư duy khác, nhưng lợi ích về bảo mật và khả năng di động là không thể phủ nhận. Lần tới khi máy chủ gặp sự cố, tôi sẽ chỉ cần di chuyển các tệp .home và để đống hỗn độn /etc/passwd lại phía sau.
