Возникающие затруднения и их решения
Здесь я опишу перечислением те проблемы, которые возникли после установки 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
# 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.
$ 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'
Но вам, наверное, хочется, чтобы сервер 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
$ 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
Я не стану описывать настройку 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:
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: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
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
# 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, теперь они не будут конфликтовать.ftp: connect: В соединении отказано
ftp> ...