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

Martin Basti mbasti at redhat.com
Mon Sep 22 15:36:01 UTC 2014


On 22/09/14 17:29, Simo Sorce wrote:
> On Mon, 22 Sep 2014 17:05:15 +0200
> Martin Basti <mbasti at redhat.com> wrote:
>
>> On 22/09/14 08:53, Martin Kosek wrote:
>>> On 09/19/2014 06:33 PM, 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
>>>>>> readinghttp://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?
>>>>>>
>>>>>> 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.
>>>>
>>> Probably yes, I already had a discussion with systemd folks about a
>>> native systemd way to manage the services. I filed a ticket:
>>>
>>> https://fedorahosted.org/freeipa/ticket/4552
>>>
>>> This shouldn't stop these patches though, especially if they are
>>> required for the DNSSEC feature.
>>>
>>> Martin
>> Back to my question.
>>
>> Should we use the mask as systemd specific and use it in disable, or
>> create the mask method in platform module?
>>
>> IMHO, IPA is mainly used on systemd platforms, so we could add mask
>> method, which can be used as alias for disabling on other systems.
> I do not understand why you would mask something, why isn't it
> sufficient to disable a service ?
>
> Simo.
>
As Petr^2 wrote,  user must not run original DNSSEC signer daemon, which 
is replaced by IPA signer daemon, otherwise it could broke DNSSEC signing.

-- 
Martin Basti




More information about the Freeipa-devel mailing list