[Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd?

[Petr Spacek]

On 19.9.2014 18:33, Simo Sorce wrote:
> On Fri, 19 Sep 2014 17:50:16 +0200
> Martin Kosek <mkosek at redhat.com> wrote:
>
>> On 09/19/2014 05:23 PM, Rob Crittenden wrote:
>>> Martin Basti wrote:
>>>> Hello list,
>>>>
>>>> I need to use systemd mask/unmask in ipa service.
>>>>
>>>> But as Honza wrote:
>>>> "IMO masking/unmasking should be part of disabling/enabling a
>>>> service in systemd. AFAIK in most other init systems when you
>>>> disable a service, it has the same effect as masking the service
>>>> in systemd - it will never be started until it is enabled/unmasked
>>>> again. "
>>>>
>>>> So my questions is, should be masking part of disabling service in
>>>> systemd, to be platform independent?
>>>> Or should we add mask/unmask methods to
>>>> ipaplatform.base.services.PlatformService where mask is alias for
>>>> disable?
>>>>
>>>> Martin^2
>>>>
>>>
>>> After reading http://0pointer.de/blog/projects/three-levels-of-off I
>>> disagree that disabling in SysV is the same as masking in systemd,
>>> though I guess it depends on the meaning of disable. According to
>>> that page chkconfig off <service> is equivalent to systemctl disable
>>> <service>.service, which is what we do now AFAIR.
>>>
>>> Why do you need to mask a service, e.g. render it completely
>>> unstartable?

This is my requirement for DNSSEC implementation.

IPA replaces original ods-signerd daemon from opendnssec package with 
IPA-specific implementation of ods-signerd daemon.

Bad things will happen if the original daemon is started before the 
IPA-version so I asked Martin^2 Basti to mask the old service to prevent it 
from running.

I expect that admins familiar with OpenDNSSEC but not-yet-familiar with IPA 
integration could mess with it accidentally. Also I'm not 100 % that some 
problem can not be caused by socket activation on a shared socket etc.

Petr^2 Spacek

>>> rob
>>
>> I do not have full context, but looks like a good question. We only
>> enable ipa "service" and starts via ipactl all other services. So we
>> can disable/enable/mask services on the LDAP level, not on systemd
>> level.
>
> I do not think masking is right for now, however I'd like to chime in
> given there is work around this.
>
> The current ipactl method was necessary due to issues in using systemd
> fully, however if newer systemds have bugs about enabling/disabling unit
> files from another one fixed then we should look into making the
> ipa.service use ipactl *only* to enable/disable unit files.
> This way if we can create the various unit files as eg:
> ipa-httpd.service where the only thing we do is add an After:
> ipa.service and then include the system's httpd.service file we will be
> in a better situation.
> Especially on shutdown, as no matter what changed in LDAP on shutdown
> we do not even lookup anything and just let systemd tear down all
> services in the ipa group (I guess there is a way to tell systemd that
> if ipa.service goes down all it's dependent services also need to go
> down.
>
> I know this is a major refactoring, but if we can pull it off, this is
> the correct way to go with systemd integration in the longer term.
>
> Simo.
>


-- 
Petr^2 Spacek