[devel] rsync-server и systemd

[devel] rsync-server и systemd

[alexei]

Приветствую!

По мотивам https://bugzilla.altlinux.org/show_bug.cgi?id=30508#c6

Я не совсем понимаю, а зачем было реализовывать такой подход, по принудительному
неработающему состоянию для rsyncd? В чем отличие systemctl enable rsyncd.socket от
chkconfig rsync on ?

Re: [devel] rsync-server и systemd

[Евгений Терешков]

Taf пишет:

> По мотивам https://bugzilla.altlinux.org/show_bug.cgi?id=30508#c6
> Я не совсем понимаю, а зачем было реализовывать такой подход, по принудительному
> неработающему состоянию для rsyncd? В чем отличие systemctl enable rsyncd.socket от
> chkconfig rsync on ?

Насколько я понимаю, дело в том, что systemd всё равно будет запускать
выключенный (disabled) сервер если кто-ли в какой-либо транзакции заявит,
что хочет его (безусловно НЕ запускает systemd только замаскированные
(masked) сервисы). Что довольно легко, наверное, получить, установив
определённый набор пакетов. Т.е. нельзя гарантировать, что rsyncd не
запустится с конфигурацией по умолчанию. Думаю что предложенный в баге
способ с правкой /e/s/rsyncd это метод гарантировать, что админ поправил
конфигурацию до (и для) выставления rsyncd в сеть. Как вариант, можно было
бы маскировать сервис по умолчанию.

-- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru

Re: [devel] rsync-server и systemd

[alexei]

----- Исходное сообщение -----
> От: "Евгений Терешков" <evg-krsk@yandex.ru>
> Кому: devel@lists.altlinux.org
> Отправленные: Понедельник, 1 Декабрь 2014 г 15:20:07
> Тема: Re: [devel] rsync-server и systemd

> Taf пишет:
> 
>> По мотивам https://bugzilla.altlinux.org/show_bug.cgi?id=30508#c6
>> Я не совсем понимаю, а зачем было реализовывать такой подход, по принудительному
>> неработающему состоянию для rsyncd? В чем отличие systemctl enable rsyncd.socket
>> от
>> chkconfig rsync on ?
> 
> Насколько я понимаю, дело в том, что systemd всё равно будет запускать
> выключенный (disabled) сервер если кто-ли в какой-либо транзакции заявит,
> что хочет его (безусловно НЕ запускает systemd только замаскированные
> (masked) сервисы). Что довольно легко, наверное, получить, установив
> определённый набор пакетов. Т.е. нельзя гарантировать, что rsyncd не
> запустится с конфигурацией по умолчанию. Думаю что предложенный в баге
> способ с правкой /e/s/rsyncd это метод гарантировать, что админ поправил
> конфигурацию до (и для) выставления rsyncd в сеть. Как вариант, можно было
> бы маскировать сервис по умолчанию.

Тогда, на мой взгляд, лучше реализовать вариант с маскированным сервисом, тогда
сразу все видно и диагностируется штатными средствами. А то так получается, что
открутили топливный насос, чтобы случайно кто-то случайно не воспользовался машиной
вместо маршрутки.

Re: [devel] rsync-server и systemd

[Евгений Терешков]

Taf пишет:

>> Насколько я понимаю, дело в том, что systemd всё равно будет запускать
>> выключенный (disabled) сервер если кто-ли в какой-либо транзакции заявит,
>> что хочет его (безусловно НЕ запускает systemd только замаскированные
>> (masked) сервисы). Что довольно легко, наверное, получить, установив
>> определённый набор пакетов. Т.е. нельзя гарантировать, что rsyncd не
>> запустится с конфигурацией по умолчанию. Думаю что предложенный в баге
>> способ с правкой /e/s/rsyncd это метод гарантировать, что админ поправил
>> конфигурацию до (и для) выставления rsyncd в сеть. Как вариант, можно было
>> бы маскировать сервис по умолчанию.
> Тогда, на мой взгляд, лучше реализовать вариант с маскированным сервисом, тогда
> сразу все видно и диагностируется штатными средствами. А то так получается, что
> открутили топливный насос, чтобы случайно кто-то случайно не воспользовался машиной
> вместо маршрутки.

Тогда не очевидно, что нужно поправить конфиг на более подходящий к реалиям
установки (да поправит меня маинтайнер rsync если ошибаюсь).

-- 
С уважением, Терешков Евгений.
Jabber ID: evg@altlinux.org, evg_krsk@jabber.ru

Re: [devel] rsync-server и systemd

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

On Mon, Dec 01, 2014 at 02:36:40PM +0700, Евгений Терешков wrote:
> Taf пишет:
> 
> >> Насколько я понимаю, дело в том, что systemd всё равно будет запускать
> >> выключенный (disabled) сервер если кто-ли в какой-либо транзакции заявит,
> >> что хочет его (безусловно НЕ запускает systemd только замаскированные
> >> (masked) сервисы). Что довольно легко, наверное, получить, установив
> >> определённый набор пакетов. Т.е. нельзя гарантировать, что rsyncd не
> >> запустится с конфигурацией по умолчанию. Думаю что предложенный в баге
> >> способ с правкой /e/s/rsyncd это метод гарантировать, что админ поправил
> >> конфигурацию до (и для) выставления rsyncd в сеть. Как вариант, можно было
> >> бы маскировать сервис по умолчанию.
> > Тогда, на мой взгляд, лучше реализовать вариант с маскированным сервисом, тогда
> > сразу все видно и диагностируется штатными средствами. А то так получается, что
> > открутили топливный насос, чтобы случайно кто-то случайно не воспользовался машиной
> > вместо маршрутки.
> 
> Тогда не очевидно, что нужно поправить конфиг на более подходящий к реалиям
> установки (да поправит меня маинтайнер rsync если ошибаюсь).

Для того, чтобы функционировал "rsync --daemon", нужно настроить /etc/rsyncd.conf .
В пакете rsync-server традиционно упакован /etc/rsyncd.conf с обширными
комментариями, но без каких-либо раздаваемых модулей.
Включать "rsync --daemon" без настройки /etc/rsyncd.conf не надо.
Проверить средствами systemd, настроен ли /etc/rsyncd.conf,
не представляется возможным (точнее говоря, я не придумал).
В любом случае установка пакета rsync-server не должна приводить
к активизации слушателей на порту 873.

Вариантов было два:
- превратить /etc/rsyncd.conf в пустой файл (совсем пустой, размером 0), и
запаковать рядом традиционный rsyncd.conf под каким-нибудь другим именем,
например, rsyncd.conf.dist);
- завести новый конфигурационный файл /etc/sysconfig/rsyncd (традиционный
механизм передачи параметров запускаемым сервисам в systemd), и повесить
зависимость на него.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]