问题描述
我正在尝试实现一种配置机制，该机制允许在某个项目中通过 svn 部署一个 cron 配置。
我立即认为我应该做的是从 /etc/cron.d/到我项目的 cron 文件(又由 vcs 控制)的符号链接，但这似乎不起作用。
我发现一些旧论坛消息指出不支持符号链接，而其他人则表示支持。它是哪一个？
有没有其他方法或任何其他好的方法来实现这一目标？
最佳方案
根据 man crond
\\n
CAVEATS
\\n
All crontab files have to be regular files or symlinks to regular files, they must not be executable or writable for anyone else but the owner. This requirement can be overridden by using the -p option on the crond command line. If inotify support is in use, changes in the symlinked crontabs are not automatically noticed by the cron daemon. The cron daemon must receive a SIGHUP signal to reload the crontabs. This is a limitation of the inotify API.
\\n
The syslog output will be used instead of mail, when sendmail is not installed.
\\n
它也惹恼了我的生活垃圾，简而言之，您可以使用符号链接，但是，如果不是常规文件或常规文件的符号链接，它必须使用 -p 开关。
次佳方案
这具有安全隐患。 /etc/cron.d/中的脚本由具有 root 权限的 root 运行。在那里对非 root 用户拥有和可写的脚本进行符号链接是一个坏主意，因为您的系统可能会以这种方式受到损害
第三种方案
我会检查你的 Ubuntu 版本的 cron 手册页(我假设我们在这个论坛上谈论的是 Ubuntu！)：
\\n
Files in this directory have to be owned by root, do not need to be\\n executable (they are configuration files, just like /etc/crontab) and\\n must conform to the same naming convention as used by run-parts(8): they must consist solely of upper- and lower-case letters, digits,\\n underscores, and hyphens. This means that they cannot contain any dots.
\\n
正如 Florian 所指出的，如果此文件可由非 root 用户写入，则这是一个安全漏洞，因为这些作业将由 root 运行(对于文件中被指定为作业所有者的人)。因此，还要注意，
\\n
This directory can contain any file defining tasks following the format used in /etc/crontab, i.e. unlike the user cron spool,\\n these files must provide the username to run the task as in the task definition.
\\n
即在要运行的命令之前弹出用户名。