Чому я пропускаю / var / run / sshd після кожного завантаження?

Я запускаю контейнер Ubuntu 16.04 під Proxmox 5.2-11. Після застосування останнього раунду виправлень 1 я не можу увійти на консоль або над ssh.

Я встановив контейнер кореневої FS на гипервизор і додав pts/0до /etc/security/access.conf(ми біжимо pam_access) , і що дозволило кореневої входу в консоль. У нас, root : lxc/tty0 lxc/tty1 lxc/tty2в access.confяких я вважав, що це достатньо, тому чому мені це потрібно pts/0зараз, є дивовижне.

Я помітив, що ssh не працює, тому спробував запустити його вручну ( /usr/sbin/sshd -DDD -f /etc/ssh/sshd_config) і отримав цю помилку:

Missing privilege separation directory: /var/run/sshd

Я створив каталог вручну, запустив sshі зміг остаточно увійти, але після перезавантаження проблема зберігається. Каталог не створюється. Тільки корисні біти в, journalctlі єдина цікава частина - це щось про "операцію не дозволено", але немає додаткової інформації.

Я не надто знайомий з 16.04, тому цікаво, як я можу дізнатися більше про проблему. У мене немає жодного /var/log/syslogабо /var/log/messagesтільки kern.logтакого роду загубленого.

1

systemd-sysv 229-4ubuntu21.9
libpam-systemd 229-4ubuntu21.9
libsystemd0 229-4ubuntu21.9
systemd 229-4ubuntu21.9
udev 229-4ubuntu21.9
libudev1 229-4ubuntu21.9
iproute2 4.3.0-1ubuntu3.16.04.4
libsasl2-modules-db 2.1.26.dfsg1-14ubuntu0.1
libsasl2-2 2.1.26.dfsg1-14ubuntu0.1
ldap-utils 2.4.42dfsg-2ubuntu3.4
libldap-2.4-2 2.4.42dfsg-2ubuntu3.4
libsasl2-modules 2.1.26.dfsg1-14ubuntu0.1
libgs9-common 9.25dfsg1-0ubuntu0.16.04.3
ghostscript 9.25dfsg1-0ubuntu0.16.04.3
libgs9 9.25dfsg1-0ubuntu0.16.04.3

[2]

Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[474]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 mysqld_safe[495]: Starting mysqld daemon with databases from /var/lib/mysql/mysql
Nov 27 10:13:48 host16 mysqld[500]: 181127 10:13:48 [Note] /usr/sbin/mysqld (mysqld 10.0.36-MariaDB-0ubuntu0.16.04.1) starting as process 499 ...
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[502]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[503]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:48 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: Failed to reset devices.list on /system.slice/ssh.service: Operation not permitted
Nov 27 10:13:48 host16 systemd[1]: Starting OpenBSD Secure Shell server...
Nov 27 10:13:48 host16 sshd[504]: Missing privilege separation directory: /var/run/sshd
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Control process exited, code=exited status=255
Nov 27 10:13:48 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:48 host16 systemd[1]: ssh.service: Failed with result 'exit-code'.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Service hold-off time over, scheduling restart.
Nov 27 10:13:49 host16 systemd[1]: Stopped OpenBSD Secure Shell server.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Start request repeated too quickly.
Nov 27 10:13:49 host16 systemd[1]: Failed to start OpenBSD Secure Shell server.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Unit entered failed state.
Nov 27 10:13:49 host16 systemd[1]: ssh.service: Failed with result 'start-limit-hit'.
Nov 27 10:13:49 host16 systemd[1]: Started /etc/rc.local Compatibility.
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-quit.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Starting Terminate Plymouth Boot Screen...
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/plymouth-quit-wait.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Starting Hold until boot process finishes up...
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/rc-local.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Started Hold until boot process finishes up.
Nov 27 10:13:49 host16 systemd[1]: Started Container Getty on /dev/pts/1.
Nov 27 10:13:49 host16 systemd[1]: Started Container Getty on /dev/pts/0.
Nov 27 10:13:49 host16 systemd[1]: Failed to reset devices.list on /system.slice/console-getty.service: Operation not permitted
Nov 27 10:13:49 host16 systemd[1]: Started Console Getty.
Nov 27 10:13:49 host16 systemd[1]: Reached target Login Prompts.
Nov 27 10:13:49 host16 systemd[1]: Started Terminate Plymouth Boot Screen.
Nov 27 10:13:52 host16 nslcd[338]: accepting connections
Nov 27 10:13:52 host16 nslcd[275]:    ...done.
Nov 27 10:13:52 host16 systemd[1]: Started LSB: LDAP connection daemon.
Nov 27 10:13:52 host16 systemd[1]: Failed to reset devices.list on /system.slice/cron.service: Operation not permitted
Nov 27 10:13:52 host16 systemd[1]: Started Regular background program processing daemon.
Nov 27 10:13:52 host16 systemd[1]: Failed to reset devices.list on /system.slice/atd.service: Operation not permitted

Додано systemd-tmpfiles --createвихід

Дійсно химерно .... Я перевірив, /tmpі ці файли не існують

Одна помилка, яку ви зробили, намагалася почати sshdвід руки.

Якщо ви замість цього починаєте sshdофіційними засобами, це має просто працювати. serviceКоманда знає , що правильний спосіб запуску служби на вашому розподілу, і це повинно працювати:

service ssh start

У випадку sysv init-скриптів, це все, що вам потрібно зробити. Причиною відсутності каталогу є те, що /var/runє символьним посиланням на /runта /runє tmpfsточкою монтування. Це означає, що кожен завантажувач /var/runпочне пустувати. Коли ви використовуєте serviceкоманду, /etc/init.d/sshсценарій буде використовуватися для запуску, sshdале перед тим, як це створити, /var/run/sshdякщо його не існує.

З systemdречами працює трохи інакше. З'явиться файл /usr/lib/tmpfiles.d/sshd.confіз цим вмістом:

d /var/run/sshd 0755 root root

Під час завантаження це повинно спричинити створення /var/run/sshdкаталогу. Що потрібно, щоб переконатися, що файл існує та має правильний вміст. Якщо /var/run/sshdкаталог все ще відсутній, ви можете перевірити, чи він створений під час запуску systemd-tmpfiles --createвручну.

Отже / run (і / var / run, пов’язаний з ним), відтворюється при кожному перезавантаженні. За винятком того, що systemd-tmpfiles не робить цього для деяких файлів, включаючи (/ var) / run / sshd.

Мабуть, це виправлено оновленням ядра OpenVZ. Але щоб насправді це виправити, ви редагуєте /usr/lib/tmpfiles.d/sshd.confта видаляєте /varз рядка d /var/run/sshd 0755 root rootчитання замість цього: d /run/sshd 0755 root root

І це все..!

І коли openssh-сервер отримує оновлення, ми сподіваємось, що вони виправлять цю помилку (чи це справді помилка у systemd? Або openvz ??) - інакше ви можете зіткнутися з тією ж проблемою.

Мабуть, це вирішується при запуску ядра OpenVZ 2.6.32-042stab134.7 або новішого. Мені здається дивним, що в системних сценаріях запуску якось виправити неможливо. Можливо, такий некрасивий хак, як автоматичне створення / запуск / sshd / після запуску та запуску sshd, спрацює.

Вихід мого systemd-tmpfiles --create:

[/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
fchownat() of /run/named failed: Invalid argument
Failed to openat(/dev/simfs): Operation not permitted
Failed to validate path /var/run/screen: Too many levels of symbolic links
Failed to validate path /var/run/sshd: Too many levels of symbolic links
Failed to validate path /var/run/sudo: Too many levels of symbolic links
Failed to validate path /var/run/sudo/ts: Too many levels of symbolic links
fchownat() of /run/systemd/netif failed: Invalid argument
fchownat() of /run/systemd/netif/links failed: Invalid argument
fchownat() of /run/systemd/netif/leases failed: Invalid argument
fchownat() of /run/log/journal failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc failed: Invalid argument
fchownat() of /run/log/journal/e9e1d08bc42c48999865b96c250f40cc/system.journal failed: Invalid argument

Журнал змін OpenVZ 2.6.32-042stab134.7 говорить про це:

Запуск контейнерів Ubuntu з systemd 229-4ubuntu21.9 може призвести до того, що служби не запускаються, оскільки systemd-tmpfiles не зміг перевірити шлях через проблеми, що посилаються на них. (PSBM-90038)

За стільки проблем, як у мене з системою протягом багатьох років, я повинен визнати, що ця проблема пов'язана замість директиви Ansible синхронізації .

Чомусь після надання цьому хосту нашими сценаріями ansbile він залишив / каталог (а також / etc, / opt та інші), що належить користувачеві адміністратора, а не root. Після запуску chownдля виправлення речей, /var/run/sshdтепер створюється на завантаженні знову.

Я дуже ціную весь вхід, але тут немає помилок, принаймні в тому сенсі, що застосування невідповідної власності до кореневих каталогів спричинило не визначену поведінку системи.