On 22/09/14 17:37, Rob Crittenden wrote:
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 ?
Think of the case of kadmind with the old KDB. IIRC just starting the
service would corrupt the database. Preventing it from starting at all
would have been a really nice thing to have. If DNSSEC has similar needs
I can see it.
I guess the question is, other than DNSSSEC, what is the use case?
Typically when we disable something it is during uninstall in which case
we should be restoring things to the way they were initially, which
probably means not masked (but I didn't check).
rob
Currently during IPA service creation status of affected services is
stored, and during uninstall IPA services status of the services is
restored.
--
Martin Basti
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
