Làm cách nào để định cấu hình tên giao diện mạng khởi động từ phương tiện chỉ đọc?

trong hệ thống Ubuntu 12.04, chúng tôi muốn định cấu hình tên của các giao diện mạng (vật lý) (như eth0, eth1, ...) bằng các quy tắc udev như các quy tắc được tạo trong /etc/udev/rules.d/70-persistent-net.rules. Mặc dù phương tiện khởi động chỉ đọc, chúng tôi vẫn muốn có thể kiên trì (tái) cấu hình các quy tắc này cho các lần khởi động trong tương lai (ví dụ: sau khi thẻ mạng đã được thay thế). Để duy trì, chúng tôi muốn lưu trữ các quy tắc vào một đĩa cứng cục bộ (có thể ghi) (khác với phương tiện khởi động chỉ đọc).

Vấn đề dường như là, làm thế nào để thông báo sớm cho udev về các quy tắc được lưu trữ: Rõ ràng, điều này không thể xảy ra trước khi đĩa cứng cục bộ với các quy tắc được lưu trữ được gắn kết. Việc gắn đĩa phụ thuộc vào udev nhận ra thiết bị đĩa cứng cục bộ. Đồng thời, udev cũng nhận ra các giao diện mạng và kích hoạt cấu hình của chúng (có khả năng trước khi các quy tắc từ đĩa cứng cục bộ có hiệu lực).

Làm thế nào các khởi tạo cần thiết được phối hợp chính xác trong khi khởi động?

— Carsten Scholtes
nguồn

Giải pháp hiện tại của chúng tôi, sử dụng ba công việc mới bắt đầu, dường như hoạt động (vui lòng nhận xét):

Chúng tôi sử dụng một nhiệm vụ mới bắt đầu /etc/init/hold-interfaces.conf để trì hoãn cấu hình của các giao diện mạng (trong các công việc mới bắt đầu /etc/init/network-interface.conf ) cho đến khi các quy tắc mạng được lưu trữ đã được cài đặt (vào /etc/udev/rules.d/71-persistent-net.rules, Ở đâu /etc/ đã được phủ lên trong initrd/init với một tmpfs cho khả năng ghi).
```
# /etc/init/hold-interfaces.conf

start on starting network-interface and started mark-configured

instance holding${INTERFACE:+/}${INTERFACE:-}

task

exec :
```
- Các start on điều kiện yêu cầu starting network-interface. Đây là phương pháp thông thường để cấm một công việc mới bắt đầu mà không sửa đổi tệp công việc hiện có (trong trường hợp này /etc/init/network-interface.conf ), xem Sách dạy nấu ăn mới nổi .
- Vì sẽ có những trường hợp riêng biệt của network-interface công việc (một cho mỗi giao diện), cũng phải có các trường hợp tương ứng của hold-interfaces. Vì thế instance khai báo (tương tự như tìm thấy trong /etc/init/network-interface-security.conf ).
- Các start on điều kiện cũng đòi hỏi started mark-configured. Điều này báo hiệu rằng các quy tắc mạng đã được cập nhật và việc khởi tạo các giao diện được phép tiếp tục. Không thể trực tiếp chờ đợi một sự kiện mới bắt đầu được phát ra: Một sự kiện như vậy chỉ cho phép một trường hợp duy nhất là hold-interfaces để tiếp tục. Cách giải quyết được đề xuất là mô phỏng một số loại sự kiện liên tục bằng cách sử dụng một công việc mới bắt đầu, trong trường hợp này /etc/init/mark-configured.conf (Cf. LP: # 447654 ).
Công việc mới bắt đầu /etc/init/mark-configured.conf cung cấp một dấu hiệu liên tục rằng tất cả các tệp cấu hình mạng đã được cập nhật:
```
start on network-rules-ready

task

exec :
```
- Một sự kiện duy nhất network-rules-ready là đủ để bắt đầu công việc này. Sau đó, công việc mark-configured được biết đến là started trong đó phát hành các trường hợp chờ đợi của hold-interfaces hậu quả là những network-interface.

Công việc mới bắt đầu thứ ba /etc/init/configure_interfaces.conf cài đặt các quy tắc mạng, ngăn chặn sự chậm trễ network-interface các công việc (vì chúng có thể được bắt đầu với dữ liệu cấu hình từ các quy tắc mạng cũ), phát ra sự kiện phát hành và truy xuất tất cả các sự kiện udev thêm một thiết bị mạng.

# /etc/init/configure_interfaces.conf

start on local-filesystems

task

script
    find_and_mount_local_hard_disk # abbreviated
    install_stored_rules_and_other_network_configurations # abbreviated

    udevadm control --reload-rules

    # Stop all active network-interface upstart jobs (with data from old rules)
    stop_active_network_interface_jobs # abbreviated, using: initctl stop network-interface <interface>

    # Allow next network-interface jobs
    # (with data from stored rules) to complete.
    initctl emit --no-wait network-rules-ready

    # Trigger udev recognition.
    udevadm trigger --action='add' --subsystem-match='net'
end script

Trên một hệ thống thử nghiệm (với ba giao diện mạng), điều này dường như hoạt động. Mặt khác, chúng tôi không chắc chắn nếu đôi khi nó có thể không bị lỗi / ít nhất là trên các hệ thống khác:

Có đảm bảo rằng tất cả các thiết bị đĩa cứng cục bộ có sẵn khi find_and_mount_local_hard_disk chạy?
Có một điều kiện cuộc đua có thể dẫn đến một số thiết bị mạng không được công nhận? (Ví dụ: Trước khi đọc các quy tắc udev mới, kernel có thể chuyển một thiết bị mới cho udev để nó bắt đầu một công việc mới bắt đầu network-interface sử dụng các quy tắc cũ. Có thể mất một lúc cho đến khi mới bắt đầu có thể nhận ra công việc này để dừng nó. Có phải trong khi đó các quy tắc mới của udev có thể được tải, dừng lại network-interface công việc bỏ lỡ công việc mới nổi và tín hiệu network-rules-ready được phát ra sao cho thiết bị sau này vẫn được bắt đầu sử dụng các thuộc tính cũ?)
Làm thế nào các công việc mới nổi /etc/init/network-interface-security.conf bị trì hoãn / kiểm soát phù hợp? Các công việc hoặc sự kiện khác có nên bị trì hoãn / truy xuất không?
- Các công việc /etc/init/network-interface-security.conf nên được trì hoãn phù hợp, nếu cấu hình mạng mà chúng bị ảnh hưởng được cài đặt đủ sớm (cùng với các quy tắc mạng).
- Ngoài ra, nếu bất kỳ giao diện được tổ chức nào được cấu hình là auto trong /etc/network/interfaces, điều này làm chậm tín hiệu static-network-up (phát ra bởi /etc/network/if-up.d/upstart sau tất cả auto giao diện đang lên). Do đó, hầu hết các công việc phụ thuộc vào mạng nên được trì hoãn một cách phù hợp, bao gồm bắt đầu các tập lệnh init SysV (được kích hoạt bởi /etc/init/rc-sysinit.conf ).
Những vấn đề khác?

(Có cách nào dễ dàng hơn để trì hoãn cấu hình của tất cả các thiết bị mạng (và các tác vụ khởi động phụ thuộc) thông qua kernel, udev, upstart hoặc các tính năng khác cho đến khi đĩa cứng cục bộ được gắn và các quy tắc mạng mới có hiệu lực?)

— Carsten Scholtes
nguồn