On Mon, 22 Sep 2014 17:36:01 +0200 Martin Basti <mba...@redhat.com> wrote:
> On 22/09/14 17:29, Simo Sorce wrote: > > 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. > > > 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 _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
