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

[Simo Sorce]

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.

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