Setting variables that have type "cron" such as "update/check/cron/entry" to values containing a name-based range such as "5 4 * * Thu,Fri" emits a warning that the value is invalid. This is not be a huge problem with the univention-config-registry program as it still exits with code 0. However, the check is still wrong. More problematic is that the "univention_config_registry" Ansible plugin from the "ucs_modules" collection fails due to stuff being emitted on STDERR, and I'm pretty sure the same validation code is used for both. How to reprocue: ucr set update/check/cron/entry='5 4 * * Thu,Fri' ucr set update/check/cron/entry='5 4 * * Thu-Fri' ucr set update/check/cron/entry='5 4 * aug,sep *' ucr set update/check/cron/entry='5 4 * aug-sep *' Now "man 5 crontab" doesn't explicitly list an example combining month names & ranges, but it states: > day of week 0–7 (0 or 7 is Sun, or use names) and > A field may be an asterisk (*), which always stands for ``first-last''. hinting that names & numbers can be used interchangeably. Additionally it just plain works. I've used name-based ranges for ages, and looking at my syslog I can confirm that the job is definitely executed. Ranges with numbers are accepted (e.g. '5 4 * * 4,5' and '5 4 * * 4-5'), as are single names (e.g. '5 4 * * Thu'). The same applies to month numbers & names.
(In reply to Moritz Bunkus from comment #0) > Now "man 5 crontab" doesn't explicitly list an example combining month names > & ranges, but it states: > > > day of week 0–7 (0 or 7 is Sun, or use names) > and > > A field may be an asterisk (*), which always stands for ``first-last''. The next lines of <man:crontab(5)> forbids using names in ranges: > Ranges of numbers are allowed. Ranges are two numbers separated with a hyphen. and later > Ranges or lists of names are not allowed. There are many more implementations for the Cron-syntax <https://en.wikipedia.org/wiki/Cron>. While Vixie-Cron may allow it, other implementations might not. > More problematic is that the "univention_config_registry" Ansible plugin > from the "ucs_modules" collection fails due to stuff being emitted on > STDERR, and I'm pretty sure the same validation code is used for both. That's a bug in the Ansible module as handling any output to STDERR as an error is wrong; UCR prints a "Warning" only.
Huh… I totally overlooked that sentence. Sorry!