Re: [Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd?
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?
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?
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?
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?
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?
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?
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?
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?
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
[Freeipa-devel] Should mask/unmask be part of disabling/enabling services in systemd?
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 -- 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?
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?
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?
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
