Cảnh báo của OpenVPN về nhiều script --up: chỉ một cái chạy

Cảnh báo về nhiều script nghe như một lời phàn nàn về lịch trình, nên cách sửa hiển nhiên là sắp xếp lại các dòng cho đến khi nó biến mất. Nhưng đó không phải lời phàn nàn về lịch trình. Một định nghĩa --up sau đó sẽ thay thế lệnh đã được lưu cho giai đoạn ấy, và bộ phân tích nói đúng như vậy, nghĩa là trong hai script của bạn chỉ đúng một cái từng chạy. Cái còn lại không xếp hàng phía sau; nó đã biến mất.

Đó là lý do cảnh báo này đáng được chú ý dù không gây chết người: điều nó báo trước là một bản cập nhật DNS hoặc một thay đổi tuyến đường đã âm thầm ngừng xảy ra.

Cảnh báo không phải về thứ tự

OpenVPN lưu một lệnh script người dùng duy nhất cho giai đoạn up. Khi bộ phân tích gặp một định nghĩa khác, từ hồ sơ, từ tệp được bao gồm hoặc từ dòng lệnh, nó thay thế thứ mình đã giữ và phát ra cảnh báo. Không có gì được nối lại, không có gì chạy hai lần, và không tồn tại câu hỏi về thứ tự. Lệnh sống sót là lệnh bộ phân tích thấy cuối cùng, vì vậy di chuyển một dòng có thể đổi người thắng trong khi script kia vẫn chết.

Cùng một mẫu áp dụng cho các giai đoạn script khác: mỗi giai đoạn một lệnh. Nếu hai công việc đều phải xảy ra, chúng cần một điểm vào duy nhất, không phải hai chỉ thị trông giống một danh sách.

Tìm cả hai định nghĩa trong lần khởi chạy thật

Hãy bắt đầu từ thứ daemon thực sự nhận được, không phải từ hồ sơ bạn đã sửa. ps -ef và ExecStart của unit hiển thị dòng lệnh, nơi có thể thêm --up từ điểm vào của container hoặc từ một trình bao; tệp init của bản phân phối cũng có thể làm vậy. systemctl cat openvpn-server@server tiết lộ những gì chính dịch vụ thêm vào, và một grep đệ quy trên thư mục cấu hình tìm ra các định nghĩa ở cấp tệp. Bản trùng thường đến từ các lớp khác nhau, và đó chính là lý do việc sửa một tệp không thay đổi gì.

Sao chép một script sang thư mục khác hoặc đổi tên cũng không loại bỏ một chỉ thị. Bộ phân tích đếm định nghĩa, không đếm tệp.

Để một hook duy nhất sở hữu công việc

Giải pháp lâu bền là một bộ điều phối duy nhất thực thi cả hai hành động theo một thứ tự có chủ đích. Một script shell ngắn với set -eu gọi phần tích hợp cần thiết rồi đến hành động cục bộ, và chuyển tiếp "$@" để ranh giới đối số tồn tại, giữ hành vi ở một nơi có thể kiểm toán. Chuyển tiếp đối số chỉ bảo toàn chúng; nó không chứng minh hai trình trợ giúp mong đợi cùng một giao diện, nên hãy đọc hợp đồng của từng cái. Quyết định điều gì phải xảy ra khi lỗi và liệu các thay đổi một phần có cần hoàn tác không.

Nếu trình khởi chạy cung cấp một hook mở rộng được hỗ trợ, hãy ưu tiên nó hơn chuỗi tự tạo. Ảnh container hoặc gói nhà cung cấp thường có một chỗ được ghi tài liệu cho công việc bổ sung, và dùng nó giúp bản nâng cấp không ghi đè bộ điều phối của bạn.

Việc dọn dẹp thuộc về giai đoạn down tương ứng. Một hành động up ghi lại DNS hoặc thêm tuyến đường cần một sự hoàn tác được ghi tài liệu, và một bộ điều phối chỉ xử lý khởi động là nửa thiết kế.

Xác nhận tích hợp, không chỉ sự im lặng

Loại bỏ cảnh báo trùng lặp là phần dễ; tích hợp vẫn phải hoạt động. Kiểm tra trạng thái bộ phân giải sau khi kết nối bằng resolvectl status hoặc bằng cách đọc /etc/resolv.conf, và xác nhận tuyến đường bằng ip route. Sau đó ngắt và kết nối lại, vì một hook được nối vội thường để lại thứ gì đó từ phiên trước. journalctl -u openvpn-server@server -b cho thấy bộ điều phối của bạn có chạy không và nó đã in gì.

Giữ đặc quyền của hook ở đúng chỗ. Nâng script-security hoặc chạy daemon với nhiều quyền hơn không phải cách sửa cho một hook đã bị thay thế; nó mở rộng những gì mọi script tương lai có thể làm, kể cả cái mà kẻ tấn công đặt tên.

Dấu hiệu bản sửa là thật không phải sự im lặng trong nhật ký. Đó là câu trả lời DNS, mục tuyến đường và việc dọn dẹp đều hoạt động đúng sau hai lần kết nối lại.