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

2014-10-09 Thread Martin Basti

On 22/09/14 09:52, Jan Cholasta wrote:

Dne 19.9.2014 v 17:23 Rob Crittenden napsal(a):

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.


I don't think that's entirely correct. They are equivalent 
mechanically (a symlink is added/removed when a service is 
enabled/disabled), but effectively they are different. AFAIK in SysV, 
services can be started either manually or automatically on boot and 
if you disable a service the only way it will start is when you do it 
manually. In systemd, there are more ways services can be started 
automatically (socket, D-Bus, etc.) and disabling a service will only 
disable automatic start *on boot*, but it can still be started 
automatically, which contrasts with what SysV does.




Why do you need to mask a service, e.g. render it completely 
unstartable?


rob





Let's continue with discussion,

1) should we add general method mask/unmask to ipaplatform, or
2) make mask/unmask part of enabling/disabling in systemd

Martin^2

--
Martin Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2014-09-22 Thread Petr Spacek

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


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

2014-09-22 Thread Martin Kosek
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 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?

 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

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2014-09-22 Thread Jan Cholasta

Dne 19.9.2014 v 17:23 Rob Crittenden napsal(a):

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.


I don't think that's entirely correct. They are equivalent mechanically 
(a symlink is added/removed when a service is enabled/disabled), but 
effectively they are different. AFAIK in SysV, services can be started 
either manually or automatically on boot and if you disable a service 
the only way it will start is when you do it manually. In systemd, there 
are more ways services can be started automatically (socket, D-Bus, 
etc.) and disabling a service will only disable automatic start *on 
boot*, but it can still be started automatically, which contrasts with 
what SysV does.




Why do you need to mask a service, e.g. render it completely unstartable?

rob




--
Jan Cholasta

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2014-09-22 Thread Martin Basti

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 Kosekmko...@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.




--
Martin Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2014-09-22 Thread Simo Sorce
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 Kosekmko...@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


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

2014-09-22 Thread Martin Basti

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 Kosekmko...@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.


--
Martin Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2014-09-22 Thread Rob Crittenden
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 Kosekmko...@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

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2014-09-22 Thread Simo Sorce
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 Kosekmko...@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


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

2014-09-19 Thread Rob Crittenden
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?

rob

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2014-09-19 Thread Martin Kosek

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?

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.


Martin

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


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

2014-09-19 Thread Simo Sorce
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?
 
  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.

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

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel