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

Simo Sorce simo at redhat.com
Mon Sep 22 16:55:13 UTC 2014


On Mon, 22 Sep 2014 17:36:01 +0200
Martin Basti <mbasti at redhat.com> wrote:

> 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.

Ok I completely misunderstood the environment then. Yes if we have a
custom unit file for DNSSEC we should definitely mask the original one.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list