On Mon, 22 Sep 2014 17:05:15 +0200 Martin Basti <mba...@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<mko...@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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
