Add Solaris support to ncm-cron. #201
Conversation
This change involves: o Adding a new variable securitypath to identify where the cron.allow/deny files live o Added processing to share crontab files with users on Solaris. This is because Solaris uses an old version of cron. o Solaris specific cron tests. o Updated pan files for securitypath The most interesting change involves the shared use of user crontabs. To make this work ncm-cron uses the concept of separate file sections within the crontab. The ncm section is identified by the use of the tags NCM-CRON BEGIN:and NCM-CRON END:. Entries either side of these section identifiers are not modified.
Code called unlink directly which meant that it was not noaction safe. Switched to using LC::Check::absence as it supports noaction. Tidied up the code and moved some repetetive sections to their own functions.
Switching unlink for LC::Check::absence exposed a long standing bug where the unit tests were trying to delete files in /etc/cron.d but silently failing. The module was correctly flagging up the failure via using $self->error(...) however these errors are ignored by the unit testing system. LC::Check is not unit test safe so added mocked methods for LC::Check::status and LC::Check::absence to the linux configure test.
|
Automatic reply from Jenkins: Can I test this? |
|
ok to test |
Solaris cron ignores environment variables on the preceding line (linux style). Solaris does not check to see if the crontabs have been changed so the cron daemon needs to be refreshed. Fixed file permission problems with solaris crontabs
|
Can you clarify the difference between the terms of your disclaimer and those of the Apache license that the quattor codebase is maintained under? |
|
@jrha - the licence used by Quattor is considered to be an "equivalent disclaimer". Unfortunately we are still required to attach this disclaimer to every patch. |
|
Ugh. |
| my $ncmStop = "###### NCM-CRON END:"; | ||
| my $ncmMsg = "Do not edit lines from NCM-CRON BEGIN to NCM-CRON END"; | ||
| my $ncmMsgEnd = "This comment intentionally left blank"; | ||
| our $osname = $OSNAME; # 'our' is required for testing to override the os |
There was a problem hiding this comment.
Arent these good old constants?
|
After rereading this, can you please refactor the code into Linux-specific and Solaris-specific methods for all those blocks that start with if ($osname eq 'solaris')? You can then call $self->do_something(...);and choose the versions at load time by doing: use constant FOO => ...;
if ($osname eq 'solaris') {
*do_something = \&do_something_solaris;
*do_something_else = \&do_something_else_solaris;
...
} else {
*do_something = \&do_something_linux;
*do_something_else = \&do_something_else_linux;
...
} |
|
Or split it into two modules and |
|
This is policy question on how we are to structure multi os ncm components. One that I feel shouldn't be left up to chance. I know Mark Banister discussed this for his spma changes for solaris. I'm pretty happy to do it what ever way, however I wonder at this early stage of multi os support if it wouldn't be wise to figure out how this should be done, rather than everyone doing it a slightly different way. Puppet for example has the concept of "providers" that allows for an abstracted interface to resources that are handled under the hood by the os default (or selected) provider. Should we be introducing this concept here? Or is multi os support something that isn't that important to quattor so it can be handled on an ad-hoc basis? I'll join the standup tomorrow to see if I can get a feel for some direction. |
Indeed. I see three cases here:
Yes, but SPMA is special enough not to consider it a role model.
We have something similar since the last release. You can write your own alternative Perl module for any component, and locate it in any path under # Run metaconfig too inside the myblueelephant
path "/software/components/myblueelephant/ncm-module" = "metaconfig";
# Use an alternative implementation for managing services
"/software/components/chkconfig/ncm-module" = "systemd";The only requirement is that the Perl code has to discover its configuration path by calling
|
|
Merged for 14.6, we can argue about style and philosophy again later! |
|
This is actually on my todo list, unfortunately it keeps on getting trumped by higher priority jobs. So when it gets done I will open another PR. |
add caf_serviceaction type
This change involves:
cron.allow/deny files live
The most interesting change involves the shared use of user crontabs. To
make this work ncm-cron uses the concept of separate file sections
within the crontab. The ncm section is identified by the use of the
tags NCM-CRON BEGIN:and NCM-CRON END:. Entries either side of these
section identifiers are not modified.
THE FOLLOWING DISCLAIMER APPLIES TO ALL SOFTWARE CODE
AND OTHER MATERIALS CONTRIBUTED IN CONNECTION WITH THIS
SOFTWARE:
THIS SOFTWARE IS LICENSED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE AND ANY WARRANTY OF NON-
INFRINGEMENT, ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE. THIS SOFTWARE MAY BE REDISTRIBUTED TO OTHERS
ONLY BY EFFECTIVELY USING THIS OR ANOTHER EQUIVALENT
DISCLAIMER AS WELL AS ANY OTHER LICENSE TERMS THAT MAY
APPLY.