Заметки о systemd, часть 3, проблемы и решения

Возникающие затруднения и их решения

Здесь я опишу перечислением те проблемы, которые возникли после установки Fedora 17 под системой инициализации systemd, которые пришлось специально разрешать, и те способы, которыми это было решено.

Q: Не удаётся запустить сервер SSH.

A: Во многих дистрибутивах, и в более ранних версиях Fedora (14, 15) сервер SSH запускается сразу после установки его средствами пакетной системы этого дистрибутива. Это одна из самых необходимых для работы служб, и всегда было привычно, что она под рукой. Но после установки c помощью yum пакета SSH сервер не стартует, попытка подключения с внешнего хоста заканчивается неудачей:

$ ssh olej@192.168.1.5
ssh: connect to host 192.168.1.5 port 22: Connection refused

Сервер SSH хоть и инсталлирован, но не активен, демона sshd здесь нет:

$ ps -A | grep ssh
$

$ service sshd status

Redirecting to /bin/systemctl status  sshd.service

sshd.service - OpenSSH server daemon

  Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)

  Active: inactive (dead) since Tue, 23 Oct 2012 19:56:39 +0300; 5s ago

 Process: 756 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)

 Process: 723 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)

  CGroup: name=systemd:/system/sshd.service

После установки OpenSSH запрещён (disabled) системой инициализации systemd. С помощью  его же  средств и запустим этот сервер:

# service sshd start
Redirecting to /bin/systemctl start sshd.service

$ service sshd status
Redirecting to /bin/systemctl status  sshd.service
sshd.service - OpenSSH server daemon
 Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
 Active: active (running) since Tue, 23 Oct 2012 19:58:05 +0300; 2s ago
Process: 7354 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
Main PID: 7360 (sshd)
 CGroup: name=systemd:/system/sshd.service
 └ 7360 /usr/sbin/sshd -D

Oct 23 19:58:05 notebook sshd[7360]: Server listening on 0.0.0.0 port 22.
Oct 23 19:58:05 notebook sshd[7360]: Server listening on :: port 22.

Проверяем результат с внешнего хоста LAN и убеждаемся, что теперь сервер работает:

$ ssh olej@192.168.1.5
The authenticity of host '192.168.1.5 (192.168.1.5)' can't be established.
RSA key fingerprint is 45:32:32:17:bd:6f:9c:d5:19:09:d0:fa:e2:06:bb:41.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.5' (RSA) to the list of known hosts.
Nasty PTR record "192.168.1.5" is set up for 192.168.1.5, ignoring
olej@192.168.1.5's password:
-bash-4.2$ cat /etc/system-release
RFRemix release 17 (Beefy Miracle)

...

Но вам, наверное, хочется, чтобы сервер SSH был запущен не вручную, разово, а стартовал бы при каждой загрузке системы? Достигаем этого так:

# systemctl enable sshd.service
ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'

И при следующей перезагрузке системы:

$ ps -A | grep ssh
7389 ? 00:00:00 sshd


Q: Как запустить FTP сервер?

A: Многие годы в SysV это делалось элементарно, но под systemd это порождает новые проблемы! Под  systemd это может оказаться связанным с тем, что в умалчиваемой инсталляции он запускает  суперсервер xinetd, для которого некорректные настройки его FTP сервиса препятствуют старту сервиса (так происходит, например, в инсталляции Fedora 17 по умолчанию):

$ systemctl status xinetd.service
xinetd.service - Xinetd A Powerful Replacement For Inetd
 Loaded: loaded (/usr/lib/systemd/system/xinetd.service; enabled)
 Active: active (running) since Mon, 22 Oct 2012 14:46:17 +0300; 34min ago
Process: 705 ExecStart=/usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.pid $EXTRAOPTIONS (code=exited, status=0/SUCCESS)
Main PID: 709 (xinetd)
 CGroup: name=systemd:/system/xinetd.service
 └ 709 /usr/sbin/xinetd -stayalive -pidfile /var/run/xinetd.pid

$ ps -A | grep xinetd
709 ? 00:00:00 xinetd

Попытка подключения из удалённого узла:

$ ftp 192.168.1.5
Connected to 192.168.1.5 (192.168.1.5).
421 Service not available, remote server has closed connection
ftp> ...

В принципе, суперсервер по такому запросу должен поднять сервис xproftpd:

$ ls -w 100 /etc/xinetd.d

chargen-dgram daytime-stream echo-dgram   rlogin  tcpmux-server  time-stream
chargen-stream discard-dgram echo-stream  rsh     telnet    xproftpd
daytime-dgram discard-stream rexec     rsync   time-dgram

Что он благополучно и делает, но стартовавший сервис тут же завершается из-за ошибок настройки:

# tail -n 5 /var/log/messages
Oct 22 15:41:27 notebook xinetd[709]: START: ftp pid=3032 from=::ffff:192.168.1.5

Oct 22 15:41:32 notebook proftpd[3033]: 192.168.1.5 - Failed binding to ::, port 21: Адрес уже используется
Oct 22 15:41:32 notebook xinetd[709]: EXIT: ftp status=0 pid=3032 duration=5(sec)
Oct 22 15:41:32 notebook proftpd[3033]: 192.168.1.5 - Check the ServerType directive to ensure you are configured correctly.
Oct 22 15:41:32 notebook proftpd[3033]: 192.168.1.5 - Unable to start proftpd; check logs for more details

Я не стану описывать настройку xinetd, это отдельный предмет для будущих заметок - мы просто остановим суперсервер, и отдельно запустим сервер proftp (такой сервер установлен как сервис в Fedora 17 по умолчанию, но может быть использована любая другая реализация) ...

# systemctl stop xinetd.service

$ systemctl status xinetd.service
xinetd.service - Xinetd A Powerful Replacement For Inetd
Loaded: loaded (/usr/lib/systemd/system/xinetd.service; enabled)
Active: inactive (dead) since Fri, 10 Aug 2012 14:58:07 +0300; 1s ago
Main PID: 733 (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/xinetd.service

Aug 10 12:07:24 notebook xinetd[733]: removing exec
Aug 10 12:07:24 notebook xinetd[733]: removing login
Aug 10 12:07:24 notebook xinetd[733]: removing shell
Aug 10 12:07:24 notebook xinetd[733]: removing rsync
Aug 10 12:07:24 notebook xinetd[733]: removing tcpmux
Aug 10 12:07:24 notebook xinetd[733]: removing telnet
Aug 10 12:07:24 notebook xinetd[733]: removing time
Aug 10 12:07:24 notebook xinetd[733]: removing time
Aug 10 12:07:24 notebook xinetd[733]: xinetd Version 2.3.15 started with libwrap loadavg labeled-networking options...ed in.
Aug 10 12:07:24 notebook xinetd[733]: Started working: 1 available service

К этому времени xinetd остановлен и может быть запущен автономный сервис FTP:

# systemctl start proftpd.service

$ ps -A | grep ftp
3228 ? 00:00:00 proftpd

Всё! Можно подсоединяться.


Q: А если помимо FTP нужен для обслуживания других сервисов и xinetd?

A: Тогда можно службу FTP просто вывести из-под контроля xinetd. Для этого в конфигурационном файле /etc/xinetd.d/xproftpd заменим в одной строке yes на no:

$ cat /etc/xinetd.d/xproftpd

service ftp

{

disable = no

...

Теперь после перезапуска xinetd сообщение об отказе соединения поменяет вид (сравните с показанным выше) - порт просто не обслуживается:

$ ftp 192.168.1.5
ftp: connect: В соединении отказано
ftp> ...

Теперь можно точно так же, как в показанном ранее случае, запустить сервис proftpd не останавливая суперсервера xinetd, теперь они не будут конфликтовать.