On 19.9.2014 18:33, 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 reading http://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?
This is my requirement for DNSSEC implementation.
IPA replaces original ods-signerd daemon from opendnssec package with
IPA-specific implementation of ods-signerd daemon.
Bad things will happen if the original daemon is started before the
IPA-version so I asked Martin^2 Basti to mask the old service to prevent it
from running.
I expect that admins familiar with OpenDNSSEC but not-yet-familiar with IPA
integration could mess with it accidentally. Also I'm not 100 % that some
problem can not be caused by socket activation on a shared socket etc.
Petr^2 Spacek
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.
--
Petr^2 Spacek
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
