Bất cứ khi nào có thể thay đổi sshd trong CentOS7, một lần chơi ngẫu nhiên trong tương lai không thể kết nối

Đây là một vấn đề đủ khó chịu khi tôi nghĩ rằng cuối cùng tôi cũng sẽ hỏi cộng đồng về giải pháp khả thi. Thậm chí còn khó chịu hơn khi tôi dường như là người duy nhất gặp phải vấn đề này.

Về cơ bản, bất cứ lúc nào trong CentOS 7.x, sshd config hoặc bất kỳ phần nào của sshd đều được sửa đổi và trình nền được khởi động lại / tải lại tại một số "điểm ngẫu nhiên" trong 3 phút tiếp theo, tất cả các kết nối ssh sẽ được đặt lại, và sau đó máy chủ đó không thể truy cập trong một vài giây qua ssh.

Điều này đặc biệt là một vấn đề đối với ansible ở chỗ đôi khi nó cần thực hiện những thay đổi này thành sshd và cũng có thể tải lại nó (ví dụ như trong các bản dựng máy chủ CentOS 7x mới). Nhưng sau đó trong các lần chơi sau, nó chỉ ngẫu nhiên không thể kết nối với ssh, và nó sẽ thổi tung phần còn lại của playbook / lượt chơi cho máy chủ đó không liên lạc được. Điều này đặc biệt tệ cho một mẫu máy chủ lớn, vì một số ít sẽ hoàn thành ngẫu nhiên, nhưng các mẫu khác sẽ thất bại ở các giai đoạn khác nhau dọc theo playbook sau khi sshd bị thao túng. Điều đáng lưu ý là không có gì thuộc loại này xảy ra trong CentOS 5x, 6x hoặc thậm chí trên Solaris.

Điều tốt nhất tôi có thể làm để tránh điều này là tạo ra 90 giây chờ đợi sau khi có bất kỳ thay đổi nào đối với sshd và thậm chí điều này không hoàn toàn dễ bị đánh lừa. Nó làm cho những cuốn sách đó mất hơn 20 phút để chạy mặc dù nếu nó được gọi 7-8 lần.

Dưới đây là một số sự thật về môi trường này:

Tất cả các cài đặt mới là từ ISO DVD chính thức. Mỗi máy chủ là một khách siêu năm 2012 Mỗi máy chủ có vấn đề này là CentOS 7.x

Đây là một số đầu ra thực tế của các vấn đề và một số giải pháp bị hack:

Sự thất bại:

fatal: [voltron]: UNREACHABLE! => {"changed": false, "msg": "All items         completed", "results": [{"_ansible_item_result": true, "item": ["rsync", "iotop", "bind-utils", "sysstat.x86_64", "lsof"], "msg": "Failed to connect to the host via ssh: Shared connection to voltron closed.\r\n", "unreachable": true}]}

Ví dụ về một trong những thay đổi đối với sshd:

- name: Configure sshd to disallow root logins for security purposes on CentOS and Redhat 7x servers.
    lineinfile:
      backup: yes
      dest: /etc/ssh/sshd_config
      regexp: '^(#PermitRootLogin)'
      line: "PermitRootLogin no"
      state: present
    when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")
    notify: sshd reload Linux 7x

Trình xử lý sau:

- name: sshd reload Linux 7x
   systemd:
     state: restarted
     daemon_reload: yes
     name: sshd

Cuối cùng, bản sửa lỗi ghetto của tôi để thử và giải quyết vấn đề này:

- name: Wait a bit on CentOS/Redhat 7x servers to ensure changes don't mess up ssh and screw up further plays.
    pause:
      seconds: 90
    when: (ansible_distribution == "CentOS" or "RedHat") and (ansible_distribution_major_version == "7")

Phải có một giải pháp tốt hơn những gì tôi nghĩ ra, và thật khó để tin rằng mọi người khác gặp phải điều này và cũng đưa ra nó. Có thứ gì tôi cần cấu hình trong máy chủ CentOS 7.x để ngăn chặn điều này không? Có một cái gì đó trong ansible cần thiết để đối phó với điều này, chẳng hạn như nhiều lần thử ssh cho mỗi lần chơi trong lần thất bại đầu tiên?

Cảm ơn trước!

Thay vì sử dụng systemdmô-đun, hãy thử servicemô-đun:

- name: Restart secure shell daemon post configuration
  service: 
    name: sshd
    state: restarted

Đây dường như là một vấn đề phổ biến. Bản vá cho Ansible ssh thử lại từ năm 2016

Một giải pháp tốt hơn có thể là đợi sshd sẵn sàng kết nối. Chủ đề gốc với giải pháp mã ansible này:

[Nhiệm vụ tạo VM ...]

  - name: Đợi quá trình cài đặt Kickstart hoàn tất và VM khởi động lại local_action: Wait_for host = {{vm_hostname}} port = 22 delay = 30 timeout = 1200 state = started

  - name: Bây giờ cấu hình VM ...