The compilation with selinux and audit is optional.
+++ /dev/null
- GNU GENERAL PUBLIC LICENSE
- Version 2, June 1991
-
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.
- 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-
- Preamble
-
- The licenses for most software are designed to take away your
-freedom to share and change it. By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users. This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it. (Some other Free Software Foundation software is covered by
-the GNU Library General Public License instead.) You can apply it to
-your programs, too.
-
- When we speak of free software, we are referring to freedom, not
-price. Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-
- To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-
- For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have. You must make sure that they, too, receive or can get the
-source code. And you must show them these terms so they know their
-rights.
-
- We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-
- Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software. If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-
- Finally, any free program is threatened constantly by software
-patents. We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary. To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-
- The precise terms and conditions for copying, distribution and
-modification follow.
-\f
- GNU GENERAL PUBLIC LICENSE
- TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-
- 0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License. The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language. (Hereinafter, translation is included without limitation in
-the term "modification".) Each licensee is addressed as "you".
-
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope. The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-
- 1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-
- 2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-
- a) You must cause the modified files to carry prominent notices
- stating that you changed the files and the date of any change.
-
- b) You must cause any work that you distribute or publish, that in
- whole or in part contains or is derived from the Program or any
- part thereof, to be licensed as a whole at no charge to all third
- parties under the terms of this License.
-
- c) If the modified program normally reads commands interactively
- when run, you must cause it, when started running for such
- interactive use in the most ordinary way, to print or display an
- announcement including an appropriate copyright notice and a
- notice that there is no warranty (or else, saying that you provide
- a warranty) and that users may redistribute the program under
- these conditions, and telling the user how to view a copy of this
- License. (Exception: if the Program itself is interactive but
- does not normally print such an announcement, your work based on
- the Program is not required to print an announcement.)
-\f
-These requirements apply to the modified work as a whole. If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works. But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-
- 3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-
- a) Accompany it with the complete corresponding machine-readable
- source code, which must be distributed under the terms of Sections
- 1 and 2 above on a medium customarily used for software interchange; or,
-
- b) Accompany it with a written offer, valid for at least three
- years, to give any third party, for a charge no more than your
- cost of physically performing source distribution, a complete
- machine-readable copy of the corresponding source code, to be
- distributed under the terms of Sections 1 and 2 above on a medium
- customarily used for software interchange; or,
-
- c) Accompany it with the information you received as to the offer
- to distribute corresponding source code. (This alternative is
- allowed only for noncommercial distribution and only if you
- received the program in object code or executable form with such
- an offer, in accord with Subsection b above.)
-
-The source code for a work means the preferred form of the work for
-making modifications to it. For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable. However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-\f
- 4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License. Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-
- 5. You are not required to accept this License, since you have not
-signed it. However, nothing else grants you permission to modify or
-distribute the Program or its derivative works. These actions are
-prohibited by law if you do not accept this License. Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-
- 6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions. You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-
- 7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License. If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all. For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices. Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-\f
- 8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded. In such case, this License incorporates
-the limitation as if written in the body of this License.
-
- 9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time. Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-
-Each version is given a distinguishing version number. If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation. If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-
- 10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission. For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this. Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-
- NO WARRANTY
-
- 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-
- 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
-
- END OF TERMS AND CONDITIONS
-\f
- How to Apply These Terms to Your New Programs
-
- If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these terms.
-
- To do so, attach the following notices to the program. It is safest
-to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least
-the "copyright" line and a pointer to where the full notice is found.
-
- <one line to give the program's name and a brief idea of what it does.>
- Copyright (C) <year> <name of author>
-
- This program is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
-
- This program is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
-
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
-
-
-Also add information on how to contact you by electronic and paper mail.
-
-If the program is interactive, make it output a short notice like this
-when it starts in an interactive mode:
-
- Gnomovision version 69, Copyright (C) year name of author
- Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
- This is free software, and you are welcome to redistribute it
- under certain conditions; type `show c' for details.
-
-The hypothetical commands `show w' and `show c' should show the appropriate
-parts of the General Public License. Of course, the commands you use may
-be called something other than `show w' and `show c'; they could even be
-mouse-clicks or menu items--whatever suits your program.
-
-You should also get your employer (if you work as a programmer) or your
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary. Here is a sample; alter the names:
-
- Yoyodyne, Inc., hereby disclaims all copyright interest in the program
- `Gnomovision' (which makes passes at compilers) written by James Hacker.
-
- <signature of Ty Coon>, 1 April 1989
- Ty Coon, President of Vice
-
-This General Public License does not permit incorporating your program into
-proprietary programs. If your program is a subroutine library, you may
-consider it more useful to permit linking proprietary applications with the
-library. If this is what you want to do, use the GNU Library General
-Public License instead of this License.
+++ /dev/null
-vixie-cron-4.2 changes are in vixie-cron.spec
-
-vixie-cron-4.1 and older changes are in /doc
-Installation Instructions
-*************************
-
-Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
-2006 Free Software Foundation, Inc.
-
-This file is free documentation; the Free Software Foundation gives
-unlimited permission to copy, distribute and modify it.
-
Basic Installation
==================
-Briefly, the shell commands `./configure; make; make install' should
-configure, build, and install this package. The following
-more-detailed instructions are generic; see the `README' file for
-instructions specific to this package.
-
- The `configure' shell script attempts to guess correct values for
-various system-dependent variables used during compilation. It uses
-those values to create a `Makefile' in each directory of the package.
-It may also create one or more `.h' files containing system-dependent
-definitions. Finally, it creates a shell script `config.status' that
-you can run in the future to recreate the current configuration, and a
-file `config.log' containing compiler output (useful mainly for
-debugging `configure').
-
- It can also use an optional file (typically called `config.cache'
-and enabled with `--cache-file=config.cache' or simply `-C') that saves
-the results of its tests to speed up reconfiguring. Caching is
-disabled by default to prevent problems with accidental use of stale
-cache files.
-
- If you need to do unusual things to compile the package, please try
-to figure out how `configure' could check whether to do them, and mail
-diffs or instructions to the address given in the `README' so they can
-be considered for the next release. If you are using the cache, and at
-some point `config.cache' contains results you don't want to keep, you
-may remove or edit it.
-
- The file `configure.ac' (or `configure.in') is used to create
-`configure' by a program called `autoconf'. You need `configure.ac' if
-you want to change it or regenerate `configure' using a newer version
-of `autoconf'.
-
-The simplest way to compile this package is:
-
- 1. `cd' to the directory containing the package's source code and type
- `./configure' to configure the package for your system.
-
- Running `configure' might take a while. While running, it prints
- some messages telling which features it is checking for.
-
- 2. Type `make' to compile the package.
-
- 3. Optionally, type `make check' to run any self-tests that come with
- the package.
-
- 4. Type `make install' to install the programs and any data files and
- documentation.
-
- 5. You can remove the program binaries and object files from the
- source code directory by typing `make clean'. To also remove the
- files that `configure' created (so you can compile the package for
- a different kind of computer), type `make distclean'. There is
- also a `make maintainer-clean' target, but that is intended mainly
- for the package's developers. If you use it, you may have to get
- all sorts of other programs in order to regenerate files that came
- with the distribution.
-
-Compilers and Options
-=====================
-
-Some systems require unusual options for compilation or linking that the
-`configure' script does not know about. Run `./configure --help' for
-details on some of the pertinent environment variables.
-
- You can give `configure' initial values for configuration parameters
-by setting variables in the command line or in the environment. Here
-is an example:
-
- ./configure CC=c99 CFLAGS=-g LIBS=-lposix
-
- *Note Defining Variables::, for more details.
-
-Compiling For Multiple Architectures
-====================================
-
-You can compile the package for more than one kind of computer at the
-same time, by placing the object files for each architecture in their
-own directory. To do this, you can use GNU `make'. `cd' to the
-directory where you want the object files and executables to go and run
-the `configure' script. `configure' automatically checks for the
-source code in the directory that `configure' is in and in `..'.
-
- With a non-GNU `make', it is safer to compile the package for one
-architecture at a time in the source code directory. After you have
-installed the package for one architecture, use `make distclean' before
-reconfiguring for another architecture.
-
-Installation Names
-==================
-
-By default, `make install' installs the package's commands under
-`/usr/local/bin', include files under `/usr/local/include', etc. You
-can specify an installation prefix other than `/usr/local' by giving
-`configure' the option `--prefix=PREFIX'.
-
- You can specify separate installation prefixes for
-architecture-specific files and architecture-independent files. If you
-pass the option `--exec-prefix=PREFIX' to `configure', the package uses
-PREFIX as the prefix for installing programs and libraries.
-Documentation and other data files still use the regular prefix.
-
- In addition, if you use an unusual directory layout you can give
-options like `--bindir=DIR' to specify different values for particular
-kinds of files. Run `configure --help' for a list of the directories
-you can set and what kinds of files go in them.
-
- If the package supports it, you can cause programs to be installed
-with an extra prefix or suffix on their names by giving `configure' the
-option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
-
-Optional Features
-=================
-
-Some packages pay attention to `--enable-FEATURE' options to
-`configure', where FEATURE indicates an optional part of the package.
-They may also pay attention to `--with-PACKAGE' options, where PACKAGE
-is something like `gnu-as' or `x' (for the X Window System). The
-`README' should mention any `--enable-' and `--with-' options that the
-package recognizes.
-
- For packages that use the X Window System, `configure' can usually
-find the X include and library files automatically, but if it doesn't,
-you can use the `configure' options `--x-includes=DIR' and
-`--x-libraries=DIR' to specify their locations.
-
-Specifying the System Type
-==========================
-
-There may be some features `configure' cannot figure out automatically,
-but needs to determine by the type of machine the package will run on.
-Usually, assuming the package is built to be run on the _same_
-architectures, `configure' can figure that out, but if it prints a
-message saying it cannot guess the machine type, give it the
-`--build=TYPE' option. TYPE can either be a short name for the system
-type, such as `sun4', or a canonical name which has the form:
-
- CPU-COMPANY-SYSTEM
-
-where SYSTEM can have one of these forms:
-
- OS KERNEL-OS
-
- See the file `config.sub' for the possible values of each field. If
-`config.sub' isn't included in this package, then this package doesn't
-need to know the machine type.
-
- If you are _building_ compiler tools for cross-compiling, you should
-use the option `--target=TYPE' to select the type of system they will
-produce code for.
-
- If you want to _use_ a cross compiler, that generates code for a
-platform different from the build platform, you should specify the
-"host" platform (i.e., that on which the generated programs will
-eventually be run) with `--host=TYPE'.
-
-Sharing Defaults
-================
-
-If you want to set default values for `configure' scripts to share, you
-can create a site shell script called `config.site' that gives default
-values for variables like `CC', `cache_file', and `prefix'.
-`configure' looks for `PREFIX/share/config.site' if it exists, then
-`PREFIX/etc/config.site' if it exists. Or, you can set the
-`CONFIG_SITE' environment variable to the location of the site script.
-A warning: not all `configure' scripts look for a site script.
-
-Defining Variables
-==================
-
-Variables not defined in a site shell script can be set in the
-environment passed to `configure'. However, some packages may run
-configure again during the build, and the customized values of these
-variables may be lost. In order to avoid this problem, you should set
-them in the `configure' command line, using `VAR=value'. For example:
-
- ./configure CC=/usr/local2/bin/gcc
-
-causes the specified `gcc' to be used as the C compiler (unless it is
-overridden in the site shell script).
-
-Unfortunately, this technique does not work for `CONFIG_SHELL' due to
-an Autoconf bug. Until the bug is fixed you can use this workaround:
-
- CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
-
-`configure' Invocation
-======================
-
-`configure' recognizes the following options to control how it operates.
-
-`--help'
-`-h'
- Print a summary of the options to `configure', and exit.
-
-`--version'
-`-V'
- Print the version of Autoconf used to generate the `configure'
- script, and exit.
+In the vixie-cron directory run:
+aclocal
+autoheader
+automake -a
+autoconf
+These commands create from configure.ac executable ./configure
-`--cache-file=FILE'
- Enable the cache: use and save the results of the tests in FILE,
- traditionally `config.cache'. FILE defaults to `/dev/null' to
- disable caching.
+Then you can start installation:
+make
+make install
-`--config-cache'
-`-C'
- Alias for `--cache-file=config.cache'.
+The executable files will be installed in /usr/local/*
-`--quiet'
-`--silent'
-`-q'
- Do not print messages saying which checks are being made. To
- suppress all normal output, redirect it to `/dev/null' (any error
- messages will still be shown).
+Options
+=======
+In the default package are used configure options:
+--with-pam
+--with-selinux
+--with-audit
-`--srcdir=DIR'
- Look for the package's source code in directory DIR. Usually
- `configure' can determine that directory automatically.
-`configure' also accepts some other, not widely useful, options. Run
-`configure --help' for more details.
-SUBDIRS = src man doc
+SUBDIRS = src man
+3. October 2007 mmaslano (at) redhat (dot) com
+This is a clone of 'original' vixie-cron. It was used in Red Hat|Fedora
+system and patched for a long time. Now was made clone tagged with
+version 4.2.
+Changes are mainly in git commit messages, some older changes could be
+found in spec changelog (contrib/vixie-cron.spec).
AC_INIT([vixie-cron],[4.2],[mmaslano@redhat.com])
-AC_PREFIX_DEFAULT(/usr)
AC_CONFIG_HEADER([config.h])
AC_PREREQ(2.7)
VERSION="4.2"
-if test "X$CFLAGS" = "X"; then
-CFLAGS="-O2 -g -Wall -Wno-unused -Wno-comment -D_GNU_SOURCE"
-LDFLAGS="-pie"
-fi
AM_INIT_AUTOMAKE(foreign)
paths.h \
pty.h \
security/pam_appl.h \
+ selinux/selinux.h \
stddef.h \
stdint.h \
sys/audit.h \
AC_SUBST(DAEMON_GROUPNAME)
# Check whether user wants SELinux support
-WITH_SELINUX_LIB=
-with_selinuxval=no
-case "$target" in
- *-*-linux*) with_selinuxval=yes ;;
- esac
- withval=${with_selinuxval}
- AC_ARG_WITH(selinux, [ --with-selinux build with selinux support ])
- if test $withval != no ; then
- AC_DEFINE(WITH_SELINUX, 1, [Build with selinux support?])
- WITH_SELINUX_LIB="-lselinux"
- fi
-AC_SUBST(WITH_SELINUX_LIB)
+SELINUX_MSG="no"
+LIBSELINUX=""
+AC_ARG_WITH(selinux,
+ [ --with-selinux Enable SELinux support],
+ [ if test "x$withval" != "xno" ; then
+ saved_LIBS="$LIBS"
+ AC_DEFINE(WITH_SELINUX,1,[Define if you want SELinux support.])
+ SELINUX_MSG="yes"
+ AC_CHECK_HEADER([selinux/selinux.h], ,AC_MSG_ERROR(SELinux support requires selinux.h header))
+ AC_CHECK_LIB(selinux, setexeccon, [ LIBSELINUX="-lselinux" ],
+ AC_MSG_ERROR(SELinux support requires libselinux library))
+ AC_CHECK_FUNCS(getseuserbyname get_default_context_with_level)
+ LIBS="$saved_LIBS $LIBSELINUX"
+ AC_SUBST(LIBSELINUX)
+ fi ]
+)
# Check whether user wants PAM support
AC_ARG_WITH(pam,
##AC_DEFINE(CRON_GROUP,"crontab",[crontab])
# Check whether user wants Linux audit support
-AC_DEFINE(WITH_AUDIT,1,[Define if you want audit trails])
+AC_ARG_WITH(audit,
+ [ --with-audit Enable audit trails],
+ [ if test "x$withval" != "xno" ; then
+ saved_LIBS="$LIBS"
+ AC_DEFINE(WITH_AUDIT,1,[Define if you want Audit trails.])
+ SELINUX_MSG="yes"
+ AC_CHECK_HEADER([libaudit.h], ,AC_MSG_ERROR(Audit trails requires libaudit.h header))
+ LIBS="$saved_LIBS $LIBAUDIT"
+ AC_SUBST(LIBAUDIT)
+ fi ]
+)
AC_ARG_ENABLE(debug,
[ --enable-debug Turn on debugging],
docdir=${datadir}/doc/cron/
AC_SUBST(docdir)
-AC_CONFIG_FILES(Makefile src/Makefile man/Makefile doc/Makefile\
+AC_CONFIG_FILES(Makefile src/Makefile man/Makefile \
man/bitstring.3 man/cron.8 man/crontab.1 man/crontab.5)
AC_CONFIG_SUBDIRS([src])
AC_OUTPUT
+++ /dev/null
-ISC Cron V4
-
-9. [misc] megapatch from tcmiller (posix compliance, etc).
-8. [bug] fix stepsize 0 infinite loop.
-7. [evol] "enum" version of freebsd fix to env-var settings.
-6. [evol] changes #12-17 from tcmiller (for *BSD alignment).
-5. [feature] give cron a version number and display it.
-4. [bug] handle clock jumps (from freebsd pr# 24485)
-3. [feature] add -n to cron (for nofork).
-2. [evol] merge in many changes from *BSD and Linux.
-1. [port] fixups for nextstep, plus a syslog configuration bug.
-
---------
-
-Vixie Cron V3.0 Patch 2 notes
-Paul Vixie
-12-Dec-1994
-
-3. "Coherent" now supported. All kinds of flock() damage was repaired.
-2. gethostname() now available in compat.c for systems that need it.
-1. There was a problem in the way the environment was being imported.
-
-Vixie Cron Changes from V2 to V3
-Paul Vixie
-29-Dec-1993
-
-The crontab command now conforms to POSIX 1003.2. This means that when you
-install it, if you have any "crontab" command lines floating around in shell
-scripts (such as /etc/rc or /etc/rc.local), you will need to change them.
-
-I have integrated several changes made by BSDi for their BSD/386 operating
-system; these were offerred to me before I started consulting for them, so
-it is safe to say that they were intended for publication. Most notably,
-the name of the cron daemon has changed from "crond" to "cron". This was
-done for compatibility with 4.3BSD. Another change made for the same reason
-is the ability to read in an /etc/crontab file which has an extra field in
-each entry, between the time fields and the command. This field is a user
-name, and it permits the /etc/crontab command to contain commands which are
-to be run by any user on the system. /etc/crontab is not "installed" via
-the crontab(1) command; it is automatically read at startup time and it will
-be reread whenever it changes.
-
-I also added a "-e" option to crontab(1). Nine people also sent me diffs
-to add this option, but I had already implemented it on my own. I actually
-released an interrim version (V2.2, I think) for limited testing, and got a
-chance to fix a bad security bug in the "-e" option thanks to XXX.
-
-The daemon used to be extraordinarily sloppy in its use of file descriptors.
-A heck of a lot of them were left open in spawned jobs, which caused problems
-for the daemon and also caused problems with the spawned jobs if they were
-shell scripts since "sh" and "csh" have traditionally used hidden file
-descriptors to pass information to subshells, and cron was causing them to
-think they were subshells. If you had trouble with "sh" or "csh" scripts in
-V2, chances are good that V3 will fix your problems.
-
-About a dozen people have reminded me that I forgot to initialize
-"crontab_fd" in database.c. Keith Cantrell was the first, so he gets the
-point.
-
-Steve Simmons reminded me that once an account has been deleted from the
-system, "crontab -u USER -d" will not work. My solution is to suggest to
-all of you that before you delete a user's account, you first delete that
-user's crontab file if any. From cron's point of view, usernames can never
-be treated as arbitrary strings. Either they are valid user names, or they
-are not. I will not make an exception for the "-d" case, for security
-reasons that I consider reasonable. It is trivial for a root user to delete
-the entry by hand if necessary.
-
-Dan O'Neil reminded me that I forgot to reset "log_fd" in misc.c. A lot of
-others also reminded me of this, but Dan gets the point. I didn't fix it
-there, since the real bug was that it should have been open in the parent.
-
-Peter Kabal reminded me that I forgot to "#ifdef DEBUGGING" some code in
-misc.c. Hans Trompert actually told me first, but Peter sent the patch so
-he gets the point.
-
-Russell Nelson told me that I'd forgotten to "#include <syslog.h>" in misc.c,
-which explains why a lot of other people complained that it wasn't using
-syslog even when they configured it that way :-). Steve Simmons told me
-first, though, so he gets the point.
-
-An interrim version of the daemon tried to "stat" every file before
-executing it; this turned out to be a horribly bad idea since finding the
-name of a file from a shell command is a hard job (that's why we have
-shells, right?) I removed this bogus code. Dave Burgess gets the point.
-
-Dennis R. Conley sent a suggestion for MMDF systems, which I've added to the
-comments in cron.h.
-
-Mike Heisler noted that I use comments in the CONVERSION file which are
-documented as illegal in the man pages. Thanks, Mike.
-
-Irving Wolfe sent me some very cheerful changes for a NeXT system, but I
-consider the system itself broken and I can't bring myself to #ifdef for
-something as screwed up as this system seems to be. However, various others
-did send me smaller patches which appear to have cause cron to build and run
-correctly on (the latest) NeXT machines, with or without the "-posix" CFLAG.
-Irving also asked for a per-job MAILTO, and this was finally added later when
-I integrated the BSD/386 changes contributed by BSDi, and generalized some of
-the parsing.
-
-Lots of folks complained that the autogenerated "Date:" header wasn't in
-ARPA format. I didn't understand this -- either folks will use Sendmail and
-not generate a Date: at all (since Sendmail will do it), or folks will use
-something other than Sendmail which won't care about Date: formats. But
-I've "fixed" it anyway...
-
-Several people suggested that "*" should be able to take a "/step". One person
-suggested that "N/step" ought to mean "N-last/step", but that's stretching things
-a bit far. "*/step" seems quite intuitive to me, so I've added it. Colin Plumb
-sent in the first and most polite request for this feature.
-
-As with every release of Cron, BIND, and seemingly everything else I do, one
-user stands out with the most critical but also the most useful analysis.
-Cron V3's high score belongs to Peter Holzer, who sent in the nicest looking
-patch for the "%" interpretation problem and also helped me understand a
-tricky bit of badness in the "log_fd" problem.
-
-agulbra@flode.nvg.unit.no wins the honors for being the first to point out the
-nasty security hole in "crontab -r". 'Nuff said.
-
-Several folks pointed out that log_it() needed to exist even if logging was
-disabled. Some day I will create a tool that will compile a subsystem with
-every possible combination and permutation of #ifdef options, but meanwhile
-thanks to everybody.
-
-job_runqueue() was using storage after freeing it, since Jordan told me back
-in 1983 that C let you do that, and I believed him in 1986 when I wrote all
-this junk. Linux was the first to die from this error, and the Linux people
-sent me the most amazing, um, collection of patches for this problem. Thanks
-for all the fish.
-
-Jeremy Bettis reminded me that popen() isn't safe. I grabbed Ken Arnold's
-version of popen/pclose from the ftpd and hacked it to taste. We're safe now,
-from this at least.
-
-Branko Lankester sent me a very timely and helpful fix for a looming security
-problem in my "crontab -e" implementation.
-
---------
-
-Vixie Cron Changes from V1 to V2
-Paul Vixie
-8-Feb-1988
-
-Many changes were made in a rash of activity about six months ago, the exact
-list of which is no longer clear in my memory. I know that V1 used a file
-called POKECRON in /usr/spool/cron to tell it that it was time to re-read
-all the crontab files; V2 uses the modtime the crontab directory as a flag to
-check out the crontab files; those whose modtime has changed will be re-read,
-and the others left alone. Note that the crontab(1) command will do a utimes
-call to make sure the mtime of the dir changes, since the filename/inode will
-often remain the same after a replacement and the mtime wouldn't change in
-that case.
-
-8-Feb-88: made it possible to use much larger environment variable strings.
- V1 allowed 100 characters; V2 allows 1000. This was needed for PATH
- variables on some systems. Thanks to Toerless Eckert for this idea.
- E-mail: UUCP: ...pyramid!fauern!faui10!eckert
-
-16-Feb-88: added allow/deny, moved /usr/spool/cron/crontabs to
- /usr/lib/cron/tabs. allow and deny are /usr/lib/cron/{allow,deny},
- since the sysv naming for this depends on 'at' using the same
- dir, which would be stupid (hint: use /usr/{lib,spool}/at).
-
-22-Feb-88: made it read the spool directory for crontabs and look each one
- up using getpwnam() rather than reading all passwds with getpwent()
- and trying to open each crontab.
-
-9-Dec-88: made it sync to :00 after the minute, makes cron predictable.
- added logging to /var/cron/log.
-
-14-Apr-90: (actually, changes since December 1989)
- fixed a number of bugs reported from the net and from John Gilmore.
- added syslog per Keith Bostic. security features including not
- being willing to run a command owned or writable by other than
- the owner of the crontab 9not working well yet)
+++ /dev/null
-$Id: CONVERSION,v 1.1.1.1 1996/12/16 19:39:48 halley Exp $
-
-Conversion of BSD 4.[23] crontab files:
-
-Edit your current crontab (/usr/lib/crontab) into little pieces, with each
-users' commands in a different file. This is different on 4.2 and 4.3,
-but I'll get to that below. The biggest feature of this cron is that you
-can move 'news' and 'uucp' cron commands into files owned and maintainable
-by those two users. You also get to rip all the fancy 'su' footwork out
-of the cron commands. On 4.3, there's no need for the 'su' stuff since the
-user name appears on each command -- but I'd still rather have separate
-crontabs with seperate environments and so on.
-
-Leave the original /usr/lib/crontab! This cron doesn't use it, so you may
-as well keep it around for a while in case something goes wakko with this
-fancy version.
-
-Most commands in most crontabs are run by root, have to run by root, and
-should continue to be run by root. They still have to be in their own file;
-I recommend /etc/crontab.src or /usr/adm/crontab.src.
-
-'uucp's commands need their own file; how about /usr/lib/uucp/crontab.src?
-'news' also, perhaps in /usr/lib/news/crontab.src...
-
-I say `how about' and `perhaps' because it really doesn't matter to anyone
-(except you) where you put the crontab source files. The `crontab' command
-COPIES them into a protected directory (CRONDIR/SPOOL_DIR in cron.h), named
-after the user whose crontab it is. If you want to examine, replace, or
-delete a crontab, the `crontab' command does all of those things. The
-various `crontab.src' (my suggested name for them) files are just source
-files---they have to be copied to SPOOLDIR using `crontab' before they'll be
-executed.
-
-On 4.2, your crontab might have a few lines like this:
-
- 5 * * * * su uucp < /usr/lib/uucp/uudemon.hr
- 10 4 * * * su uucp < /usr/lib/uucp/uudemon.day
- 15 5 * * 0 su uucp < /usr/lib/uucp/uudemon.wk
-
-...or like this:
-
- 5 * * * * echo /usr/lib/uucp/uudemon.hr | su uucp
- 10 4 * * * echo /usr/lib/uucp/uudemon.day | su uucp
- 15 5 * * 0 echo /usr/lib/uucp/uudemon.wk | su uucp
-
-On 4.3, they'd look a little bit better, but not much:
-
- 5 * * * * uucp /usr/lib/uucp/uudemon.hr
- 10 4 * * * uucp /usr/lib/uucp/uudemon.day
- 15 5 * * 0 uucp /usr/lib/uucp/uudemon.wk
-
-For this cron, you'd create /usr/lib/uucp/crontab.src (or wherever you want
-to keep uucp's commands) which would look like this:
-
- # /usr/lib/uucp/crontab.src - uucp's crontab
- #
- PATH=/usr/lib/uucp:/bin:/usr/bin
- SHELL=/bin/sh
- HOME=/usr/lib/uucp
- #
- 5 * * * * uudemon.hr
- 10 4 * * * uudemon.day
- 15 5 * * 0 uudemon.wk
-
-The application to the `news' cron commands (if any) is left for you to
-figure out. Likewise if there are any other cruddy-looking 'su' commands in
-your crontab commands, you don't need them anymore: just find a good place
-to put the `crontab.src' (or whatever you want to call it) file for that
-user, put the cron commands into it, and install it using the `crontab'
-command (probably with "-u USERNAME", but see the man page).
-
-If you run a 4.2-derived cron, you could of course just install your current
-crontab in toto as root's crontab. It would work exactly the way your
-current one does, barring the extra steps in installing or changing it.
-There would still be advantages to this cron, mostly that you get mail if
-there is any output from your cron commands.
-
-One note about getting mail from cron: you will probably find, after you
-install this version of cron, that your cron commands are generating a lot
-of irritating output. The work-around for this is to redirect all EXPECTED
-output to a per-execution log file, which you can examine if you want to
-see the output from the "last time" a command was executed; if you get any
-UNEXPECTED output, it will be mailed to you. This takes a while to get
-right, but it's amazingly convenient. Trust me.
-
+++ /dev/null
-$Id: FEATURES,v 1.2 2004/01/23 18:56:42 vixie Exp $
-
-Features of ISC cron relative to BSD 4.[23] and SysV crons:
-
--- Environment variables can be set in each crontab. SHELL, USER,
- LOGNAME, and HOME are set from the user's passwd entry; all except
- USER can be changed in the crontab. PATH is especially useful to
- set there. TZ can be set, but cron ignores it other than passing
- it on through to the commands it runs. Format is
-
- variable=value
-
- Blanks surrounding the '=' will be eaten; other blanks in value are
- okay. Leading or trailing blanks can be preserved by quoting, single
- or double quotes are okay, just so they match.
-
- PATH=.:/bin:/usr/bin
- SHELL=/bin/sh
- FOOBAR = this is a long blanky example
-
- Above, FOOBAR would get "this is a long blanky example" as its value.
-
- SHELL and HOME will be used when it's time to run a command; if
- you don't set them, HOME defaults to your /etc/passwd entry
- and SHELL defaults to /bin/sh.
-
- MAILTO, if set to the login name of a user on your system, will be the
- person that cron mails the output of commands in that crontab. This is
- useful if you decide on BINMAIL when configuring cron.h, since binmail
- doesn't know anything about aliasing.
-
--- Weekdays can be specified by name. Case is not significant, but only
- the first three letters should be specified.
-
--- Months can likewise be specified by name. Three letters only.
-
--- Ranges and lists can be mixed. Standard crons won't allow '1,3-5'.
-
--- Ranges can specify 'step' values. '10-16/2' is like '10,12,14,16'.
-
--- Sunday is both day 0 and day 7 -- apparently BSD and ATT disagree
- about this.
-
--- Each user gets their own crontab file. This is a win over BSD 4.2,
- where only root has one, and over BSD 4.3, where they made the crontab
- format incompatible and although the commands can be run by non-root
- uid's, root is still the only one who can edit the crontab file. This
- feature mimics the SysV cron.
-
--- The 'crontab' command is loosely compatible with SysV, but has more
- options which just generally make more sense. Running crontab with
- no arguments will print a cute little summary of the command syntax.
-
--- Comments and blank lines are allowed in the crontab file. Comments
- must be on a line by themselves; leading whitespace is ignored, and
- a '#' introduces the comment.
-
--- (big win) If the `crontab' command changes anything in any crontab,
- the 'cron' daemon will reload all the tables before running the
- next iteration. In some crons, you have to kill and restart the
- daemon whenever you change a crontab. In other crons, the crontab
- file is reread and reparsed every minute even if it didn't change.
-
--- In order to support the automatic reload, the crontab files are not
- readable or writable except by 'crontab' or 'cron'. This is not a
- problem, since 'crontab' will let you do pretty much whatever you
- want to your own crontab, or if you are root, to anybody's crontab.
-
--- If any output is generated by a command (on stdout OR stderr), it will
- be mailed to the owner of the crontab that contained the command (or
- MAILTO, see discussion of environment variables, above). The headers
- of the mail message will include the command that was run, and a
- complete list of the environment that was passed to it, which will
- contain (at least) the USER (LOGNAME on SysV), HOME, and SHELL.
-
--- the dom/dow situation is odd. '* * 1,15 * Sun' will run on the
- first and fifteenth AND every Sunday; '* * * * Sun' will run *only*
- on Sundays; '* * 1,15 * *' will run *only* the 1st and 15th. this
- is why we keep 'e->dow_star' and 'e->dom_star'. I didn't think up
- this behaviour; it's how cron has always worked but the documentation
- hasn't been very clear. I have been told that some AT&T crons do not
- act this way and do the more reasonable thing, which is (IMHO) to "or"
- the various field-matches together. In that sense this cron may not
- be completely similar to some AT&T crons.
-
--- If it exists, the /etc/cron.d/ directory is parsed like the cron
- spool directory, except that the files in it are not user-specific
- and are therefore read with /etc/crontab syntax (the user is
- specified explicitly in the 6th column).
+++ /dev/null
-/* Copyright 1993,1994 by Paul Vixie
- * All rights reserved
- */
-
-/*
- * Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
- * Copyright (c) 1997,2000 by Internet Software Consortium, Inc.
- *
- * Permission to use, copy, modify, and distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
- * OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
- */
-
-$Id: INSTALL,v 1.4 2004/01/23 18:56:42 vixie Exp $
-
-Read the comments at the top of the Makefile, then edit the area marked
-'configurable stuff'.
-
-Edit config.h. The stuff I expect you to change is down a bit from the
-top of the file, but it's clearly marked. Also look at pathnames.h.
-
-You don't have to create the /var/cron or /var/cron/tabs directories, since
-both the daemon and the `crontab' program will do this the first time they
-run if they don't exist. You do need to have a /var, though -- just "mkdir
-/var" if you don't have one, or you can "mkdir /usr/var; ln -s /usr/var /var"
-if you expect your /var to have a lot of stuff in it.
-
-You will also need /usr/local/etc and /usr/local/bin directories unless you
-change the Makefile. These will have to be created by hand, but if you are
-a long-time Usenet user you probably have them already. /usr/local/man is
-where I keep my man pages, but I have the source for `man' and you probably
-do not. Therefore you may have to put the man pages into /usr/man/manl,
-which will be hard since there will be name collisions. (Note that the man
-command was originally written by Bill Joy before he left Berkeley, and it
-contains no AT&T code, so it is in UUNET's archive of freely-distributable
-BSD code.)
-
-LINUX note: /usr/include/paths.h on some linux systems shows _PATH_SENDMAIL
- to be /usr/bin/sendmail even though sendmail is installed in /usr/lib.
- you should check this out.
-
-say:
- make all
-
-su and say:
- make install
-
-Note that if I can get you to "su and say" something just by asking, you have
-a very serious security problem on your system and you should look into it.
-
-Edit your /usr/lib/crontab file into little pieces -- see the CONVERSION file
-for help on this.
-
-Use the `crontab' command to install all the little pieces you just created.
-Some examples (see below before trying any of these!)
-
- crontab -u uucp -r /usr/lib/uucp/crontab.src
- crontab -u news -r /usr/lib/news/crontab.src
- crontab -u root -r /usr/adm/crontab.src
-
-Notes on above examples: (1) the .src files are copied at the time the
-command is issued; changing the source files later will have no effect until
-they are reinstalled with another `crontab -r' command. (2) The crontab
-command will affect the crontab of the person using the command unless `-u
-USER' is given; `-u' only works for root. When using most `su' commands
-under most BSD's, `crontab' will still think of you as yourself even though
-you may think of yourself as root -- so use `-u' liberally. (3) the `-r'
-option stands for `replace'; check the man page for crontab(1) for other
-possibilities.
-
-Kill your existing cron daemon -- do `ps aux' and look for /etc/cron.
-
-Edit your /etc/rc or /etc/rc.local, looking for the line that starts up
-/etc/cron. Comment it out and add a line to start the new cron daemon
--- usually /usr/local/etc/cron, unless you changed it in the Makefile.
-
-Start up this cron daemon yourself as root. Just type /usr/local/etc/cron
-(or whatever); no '&' is needed since the daemon forks itself and the
-process you executed returns immediately.
-
-ATT notes: for those people unfortunate enough to be stuck on a AT&T UNIX,
-you will need the public-domain "libndir", found in the B News source and in
-any comp.sources.unix archive. You will also need to hack the code some.
+++ /dev/null
-[ this is really old mail that came to me in response to my 1986 posting
- to usenet asking for feature suggestions before releasing the first
- version of cron. it is presented here for its entertainment value.
- --vix ]
-
-$Id: MAIL,v 1.1.1.1 1996/12/16 19:39:47 halley Exp $
-
-From ptsfa!lll-crg!ames!acornrc!bob Wed Dec 31 10:07:08 1986
-Date: Wed, 31 Dec 86 08:59:31 pst
-From: lll-crg!ames!acornrc!bob (Bob Weissman)
-To: ptsfa!vixie!paul
-Status: RO
-
-Sure, here's a suggestion: I'd like to be able to run a program, say,
-every two hours. Current cron requires me to write
-0,2,4,6,8,10,12,14,16,18,20,22 in the hours field. How about a notation
-to handle this more elegantly?
-
-<< Okay, I've allowed 0-22/2 as a means of handling this.
- The time specification for my cron is as follows:
- specification = range {"," range}
- range = (start "-" finish ["/" step]) | single-unit
- This allows "1,3,5-7", which the current cron doesn't (it won't
- do a range inside a list), and handles your specific need. >>
-
-From drw@mit-eddie Wed Dec 31 18:25:27 1986
-Date: Wed, 31 Dec 86 14:28:19 est
-From: drw@mit-eddie (Dale Worley)
-To: mit-eddie!vixie!paul
-Status: RO
-
-We have a lot of lines in our crontab of the form
-
- 00 12 * * * su user < /usr/users/user/script.file
-
-This barfs (silently!) on our system (Dec Ultrix 1.2 == 4.2bsd) if
-user's shell is csh. This, I am told, is because csh requires that
-the environment be set up in certain ways, which cron doesn't do.
-(Actually, I believe, it is because /etc/rc, which runs cron, doesn't
-set up the environment enough for csh to run, and cron just inherits
-the situation.) Anyway, the point is that if you find out what csh
-really needs in its environment, you might want to set up cron to
-provide some reasonable defaults (if it isn't supplied by cron's
-parent). Also, could you tell me what csh needs, if you find out, so
-we can hack our /etc/rc?
-
-<< well, the environment IS a problem. processes that cron forks
- will inherit the environment of the person who ran the cron
- daemon... I plan to edit out such useless things as TERMCAP,
- TERM, and the like; supply correct values for HOME, USER, CWD,
- and whatever else comes to mind. I'll make sure csh works... >>
-From ptsfa!ames!seismo!dgis!generous Thu Jan 1 07:33:17 1987
-Date: Thu Jan 1 10:29:20 1987
-From: ames!seismo!dgis!generous (Curtis Generous)
-To: nike!ptsfa!vixie!paul
-Status: RO
-
-Paul:
-
-One of the limitations of the present versions of cron is the lack
-of the capability of specifying a way to execute a command every
-n units of time.
-
-Here is a good example:
-
-# Present method to start up uucico
-02,12,22,32,42,52 * * * * exec /usr/lib/uucp/uucico -r1
-
-# New method ?? (the ':' here is just one possibility for syntax)
-02:10 * * * * exec /usr/lib/uucp/uucico -r1
-
-This method would prove very helpful for those programs that get started
-every few minutes, making the entry long and not easily readable. The first
-number would specify the base time, and the second number the repetition
-interval.
-
-<< Good idea, but bob@acornrc beat you to it. I used '/' instead of
- ':'. This is my personal preference, and seems intuitive when you
- think of the divide operator in C... Does anyone have a preference? >>
-
-From ptsfa!lll-lcc!seismo!decuac!c3pe!c3engr!charles Thu Jan 1 17:04:24 1987
-From: lll-lcc!seismo!c3pe!c3engr!charles (Charles Green)
-To: c3pe!decuac!dolqci!vrdxhq!seismo!lll-lcc!ptsfa!vixie!paul
-Date: Thu Jan 1 19:22:47 1987
-Status: RO
-
-Well, this isn't a compatible extension, but I have in times past wondered
-about a facility to let you start a process at intervals of, say, 17 minutes,
-instead of particular minutes out of each hour.
-
-<< This was a popular request! >>
-
-From seismo!uwvax!astroatc!nicmad!norvax!mann Sun Jan 4 13:04:01 1987
-Date: Fri, 2 Jan 87 09:23:53 cst
-From: lll-lcc!seismo!uwvax!astroatc!nicmad!norvax!mann (Tom Mann)
-To: ptsfa!vixie!paul
-Status: RO
-
-I'm not sure if it is in cron (either SysV or BSD ... if it is, I haven't
-figured it out ) but a comment feature would SURE BE NICE!.
-There are times when I want to comment out an entry
-for a period of time; it might also make it a lot more legible.
-
-<< My cron allows blank lines and standard #-type comments. I know
- that one BSD4.2 cron I've used had it. I don't know about SysV. >>
-
-From ptsfa!hoptoad!hugh Mon Jan 5 10:26:46 1987
-Date: Mon, 5 Jan 87 01:22:17 PST
-From: hoptoad!hugh (Hugh Daniel)
-To: ptsfa!vixie!paul
-Status: RO
-
- Hi, I do have a BIG one that I would like. I want to log ALL output
-from command lines into a file for each line. Thus I might have a chance
-of finding out why my crontab entry did not work.
- This would seem to work best if done by cron, as it is now I have a google
-of shell scripts laying about just to put the error output where I can see
-it.
-
-<< My cron (and the SysV cron) will send mail to the owner of the
- particular crontab file if a command generates any output on stdout
- or stderr. This can be irritating, but if you write a script such
- that any output means a problem occurred, you can avoid most logfile
- needs, and not generate mail except in unforeseen circumstances. >>
-
-From ptsfa!dual!ucbvax!ihnp4!anvil!es!Robert_Toxen Mon Jan 5 13:08:46 1987
-From: dual!ucbvax!ihnp4!anvil!es!Robert_Toxen
-Date: Fri, 2 Jan 87 14:25:29 EST
-To: anvil!ihnp4!ucbvax!dual!ptsfa!vixie!paul
-Status: RO
-
-Here are some suggestions:
-1. Run it through the C preprocessor via "/lib/<whatever>".
-
-<< hmmm. this seems of limited utility, and if you really wanted
- to do it that way, you could do it yourself (since users can
- write to their own crontab files). I'll add '-' (read stdin)
- to the crontab installer program to facilitate this. >>
-
-2. Allow specifying every Nth day of week, i.e., every second Wednesday.
- I did this to calendar by separating the day of week (Wed=4, which one
- to start on and N with slashes). I took modulo the day of year as a
- starting point so that someone with a desk calendar documenting such
- things can easily determine the offset (second number). I did this
- while at SGI; alas I don't have a copy of the code.
-
-<< I can see how this could be useful, but I'm not sure how I'd
- implement it. Cron currently doesn't keep track of the last time
- a given command was run; whether the current Wednesday is the first
- or second since the command was last run would be pretty hard to
- figure out. I'd have to keep a database of commands and their
- execution around, and purge it when the crontab was overwritten.
- This is too much work for me, but if someone adds it, let me know. >>
-
-From ptsfa!ames!seismo!cbmvax!devon!paul Tue Jan 6 05:50:17 1987
-From: ames!seismo!cbmvax!devon!paul
-To: cbmvax!seismo!nike!ptsfa!vixie!paul
-Date: Mon Jan 5 09:29:57 1987
-Status: RO
-
-One problem that has always plagued me with cron is the assumed ORing.
-I'd like to see some type of ANDing implemented. I guess I can best
-describe this by example. Say I have the following line in my crontab
-file:
-
-* * 4-31 * 1-6 /usr/bin/command
-
-What this does is run 'command' on the 4th thru 31st days of the
-month, AND on Monday thru Saturday; which probably means running it
-every day of the month (unless Sunday falls on days 1-3). This
-happens because cron runs the command if the day-of-month OR the
-day-of-week is true.
-
-What I'd like to happen with the above line is to run the command ONLY
-on Monday thru Saturday any time after the 3rd of the month, e.g. if
-the day-of-month AND the day-of-week are true.
-
-My proposal to you is to implement some special chars for the first
-five fields. Examples:
-
-* * !1-3 * 1-6 /usr/bin/command
-
-(run command Mon-Sat, but NOT [!] on the first 3 days of the month)
-
-* * &4-31 * &1-6 /usr/bin/command
-
-(run command if day-of-month AND day-of-week are true)
-
-Get the picture? This would be compatable with existing versions of
-cron (which wouldn't currently be using any special characters, so
-that old crontabs would be handled correctly).
-
-<< This message made me aware of the actual boolean expression involved
- in a crontab entry. I'd assumed that it was
- (minute && hour && DoM && month && DoW)
- But it's really
- (minute && hour && month && (DoM || DoW))
-
- I can see some value in changing this, but with a fixed order of
- fields, operators get to be kindof unary, which && and || really
- aren't. If someone has an idea on a syntax that allows useful
- variations to the standard (&& && && (||)) default, please suggest. >>
-
-From bobkat!pedz Tue Jan 6 20:02:10 1987
-From: pedz@bobkat.UUCP (Pedz Thing)
-Date: 2 Jan 87 17:34:44 GMT
-Status: RO
-
-Log files! It would be nice to be able to specify a log for cron
-itself and also a log for each program's stdout and stderr to go to.
-The latter can of course be done with > and 2> but it would be nice if
-there could be a single line with some sort of pattern like
-`> /usr/spool/log/%' and the command would be substituted for the %.
-Another thing which would be nice is to be able to specify which shell
-to call to give the command to.
-
-<< Log files are done with mail. The '%' idea could be useful if
- a different character were used (% is special to cron, see man
- page); a different directory would have to be chosen, since each
- user has their own crontab file; and something intelligent would
- have to be done in the file naming, since the first word of the
- command might be ambiguous (with other commands). In short, it's
- too much work. Sorry. >>
-
-From guy%gorodish@sun Tue Jan 6 20:03:13 1987
-From: guy%gorodish@sun (Guy Harris)
-Message-ID: <10944@sun.uucp>
-Date: 5 Jan 87 12:09:09 GMT
-References: <429@vixie.UUCP> <359@bobkat.UUCP>
-Sender: news@sun.uucp
-Status: RO
-
-> Another thing which would be nice is to be able to specify which shell
-> to call to give the command to.
-
-Well, the obvious choice would be the user's shell, but this wouldn't work
-for accounts like "uucico".
-
-<< I use the owning user's shell, and to handle "uucico" I check a
- list of "acceptable shells" (currently compiled in, does anybody
- mind?), substituting a default (compiled in) shell if the user's
- shell isn't on the list.
-
- BTW, "compiled in" means that it's in a .h file, easily changed
- during installation, but requiring recompilation to modify. You
- don't have to go digging through the code to find it... >>
-
-From qantel!hplabs!ucbvax!mwm@violet.berkeley.edu Tue Jan 6 21:24:48 1987
-To: hplabs!qantel!vixie!paul (Paul Vixie Esq)
-Date: 04 Jan 87 00:42:35 PST (Sun)
-From: Mike Meyer <mwm@violet.berkeley.edu>
-Status: RO
-
-<<[Discussion of RMS/FSF, and mwm's GNU Cron deleted]>>
-
-Oh, yeah - here are the extensions on my cron:
-
-1) Sunday is both day 0 and day 7, so it complies with both SysV and
-BSD cron.
-
-<< Good idea. I did it too, thanks for informing me. >>
-
-2) At is integrated into the cron. Instead of atrun to scan the
-/usr/spool/at directory, at files are put into the /usr/lib/cron
-directory along with users cron files, and cron fabricates a line from
-a crontab file to run them. This is considered a major win by all who
-use it.
-
-<< I don't use 'at', and my cron doesn't do anything with it. To run
- 'at', I use 'atrun' the same way the current BSD cron does. My
- crontab files are in /usr/spool/cron/crontabs, in the SysV
- tradition -- not in /usr/lib/cron. This is a configuration
- parameter, of course. >>
-
-There are two known restrictions:
-
-1) I don't support any of the SysV security hooks. I don't have a use
-for them, and RMS didn't like the idea at all :-).
-
-<< This means cron.allow and cron.deny. I plan to support them, as
- they've been quite helpful at various HPUX sites I've administered. >>
-
-2) Cron expects to be able to create files with names longer than 14
-characters, which makes it hard to run on SysV. At least one person
-was working on a port, but I don't know how it's going. That might
-make for a good reason for releasing yours, right there.
-
-<< If someone has SysV (with the 14-character limit), they probably
- won't want my cron, since it doesn't add much to the standard
- version (which they may have support for). My cron is not currently
- portable to non-BSD systems, since it relies on interval timers (I
- needed to sleep for intervals more granular than seconds alone would
- allow). The port would be trivial, and I will do it if a lot of
- people ask for it... >>
-
-Oh, yeah - I'm going to see about getting this cron integrated into
-the next 4BSD release.
-
-<< How does one go about this? I have a few nifty gadgets I'd like
- to contribute, this cron being one of them... >>
-
-<<[more FSF/GNU discussion deleted]>>
-
-From qantel!hplabs!ames!ut-sally!ut-ngp!melpad!bigtex!james Tue Jan 6 21:24:57 1987
-Posted-Date: Fri, 2 Jan 87 19:26:16 est
-Date: Fri, 2 Jan 87 19:26:16 est
-From: hplabs!ames!ut-sally!ut-ngp!bigtex!james
-To: vixie!paul
-Status: RO
-
-Yes!!! There are several critical failures in System V cron...
-
-1. Pass all variables in cron's environment into the environment of things
- cron starts up, or at least into the crontab entries started up (at jobs
- will inherit the environment of the user). If nothing else it is critically
- important that the TZ variable be passed on. PATH should be passed on too.
- Basically, passing environment values allows one to design a standard
- environment with TZ and PATH and have that run by everything. If anyone
- tells you this is no big deal, consider what happens when uucico is
- started by cron in CA to make a long distance phone link... Unless the
- administrator is really on his/her toes, calls scheduled at 5pm will really
- go at two in the afternoon, needlessly incurring huge phone bills, all
- because System V refuses to pass the TZ from its environment down. There
- are work arounds, but only putting it in cron will really work. This is
- not a security hole.
-
-<< delete TERM and TERMCAP; modify HOME, USER, and CWD; pass TZ and
- PATH through undisturbed. any other requests out there?
-
- BSD doesn't have this problem -- TZ is passed right on through if
- you define it in the shell before starting my cron daemon. However,
- the BSD I'm running this on doesn't need TZ to be defined anyway...
- The default in the kernel has been just fine so far... But just the
- same, if/when I port to SysV (I guess I really should), I'll make
- sure this works right.
-
- I guess I've been spoiled. HPUX is SysV-based, and I never had a
- problem with cron and TZ when I used it. >>
-
-2. A way to avoid logging stuff in /usr/lib/cron/log. I have a cron entry
- run uudemon.hr every 10 minutes. This is 144 times/day. Each run generates
- three lines of text, for a total of 432 lines of text I don't want to see.
- Obviously this should be optional, but it would be nice if there were a
- way to flag an entry so that it wasn't logged at all unless there was an
- error.
-
-<< I don't know nothin' 'bout no /usr/lib/cron/log. What is this file?
- I don't see any reason to create log entries, given the mail-the-
- output behaviour. Opinions, anyone? >>
-
-I will come up with other ideas no doubt, but I can always implement them
-myself.
-
-<< That's what I like about PD software. Please send me the diffs! >>
-
-The other problem you have is making sure you can run standard
-crontabs. I would suggest something like this: if the command part of the
-entry starts with an unescaped -, then flags and options follow immediately
-thereafter. As in:
-
-2,12,22,32,42,52 * * * * -q /usr/lib/uucp/uudemon.hr
-
-This could mean do not log the uudemon.hr run unless there is a problem of
-some kind. This is probably safe as not many filenames start with "-", and
-those that do are already a problem for people.
-
-<< Since I don't plan on supporting /usr/lib/cron/log in ANY form unless
- many people request it, I won't be needing -q as you've defined it.
- I could use something like this to avoid sending mail on errors, for
- the occasional script that you don't want to bullet-proof.
-
- The compatibility issue is CRITICAL. The 4.3BSD crontab format is
- a crime against the whole philosophy of Unix(TM), in my opinion. >>
-
-One other minor thing to consider is the ulimit: can different users get
-different ulimits for their crontab entries?
-
-<< Boy I'm ignorant today. What's a ulimit, and what should I do with
- it in a crontab? Suggestions, enlightenment, etc ?? >>
-
-From qantel!lll-crg!ames!uw-beaver!uw-nsr!john Tue Jan 6 23:32:44 1987
-Date: Thu, 1 Jan 87 10:53:05 pst
-From: lll-crg!ames!uw-beaver!uw-nsr!john (John Sambrook 5-7433)
-To: vixie!paul
-Status: RO
-
-How about not hardwiring the default environment that cron builds for its
-children in the cron program itself? Our cron does this and it's the pits
-because we are TZ=PST8PDT not TZ=EST5EDT !
-
-<< yeachk. I assure you, I will not hardwire the TZ! >>
-From ptsfa!well!dv Fri Jan 9 04:01:50 1987
-Date: Thu, 8 Jan 87 23:50:40 pst
-From: well!dv (David W. Vezie)
-To: ptsfa!vixie!paul
-Status: RO
-
-6, have a special notation called 'H' which would expand to weekends
- and holidays (you'd have to keep a database somewhere of real
- holidays), and also 'W' for workdays (neither weekend or holiday).
-
-<< Too much work. There should be a standard way to define and
- detect holidays under Unix(TM); if there were, I'd use it. As
- it is, I'll leave this for someone else to add.
-
- I can see the usefulness; it just doesn't quite seem worth it. >>
-From qantel!gatech!akgua!blnt1!jat Wed Jan 14 20:00:40 1987
-Date: Tue, 13 Jan 87 16:39:38 EST
-From: gatech!akgua!blnt1!jat
-Status: RO
-
-1) Add some way to tell cron to reread the files, say kill -1 <pid>
-
-<< whenever the 'crontab' program is run and updates a crontab file,
- a file /usr/spool/cron/POKECRON is created; next time the cron
- daemon wakes up, it sees it, and re-reads the crontab files.
-
- I thought of handling the signal; even implemented it. Then this
- clever idea hit me and I ripped it all out and added a single
- IF-statement to handle the POKECRON file. >>
-
-2) Have some kind of retry time so that if a command fails, cron will try to
- execute it again after a certain period. This is useful if you have some
- type of cleanup program that can run at the scheduled time for some reason
- (such as locked device, unmounted filesystem, etc).
-
-<< Hmmm, sounds useful. I could do this by submitting an 'at' job...
- I'll think about it. >>
-From ptsfa!dual!ucbvax!ihnp4!mtuxo!ender Sat Jan 3 16:54:00 1987
-From: dual!ucbvax!ihnp4!mtuxo!ender
-Date: Sat, 3 Jan 87 14:05:13 PST
-To: ucbvax!dual!ptsfa!vixie!paul
-Status: RO
-
-It would be nice if nonprivileged users can setup personal crontab files
-(~/.cronrc, say) and be able to run personal jobs at regular intervals.
-
-<< this is done, but in the SysV style: the 'crontab' program installs
- a new crontab file for the executing user (can be overridden by root
- for setup of uucp and news). the advantage of this is that (1) when
- a crontab is changed, the daemon can be informed automatically; and
- (2) the file can be syntax-checked before installation. >>
-From ptsfa!ames!seismo!ihnp4!lcc!richard Fri Jan 16 04:47:33 1987
-Date: Fri, 16 Jan 87 07:44:57 EST
-To: nike!ptsfa!vixie!paul
-Status: RO
-
-The System V cron is nice, but it has a few annoying features. One is that
-its mail files will say that the previous message is the output of "one of your
-cron commands." I wish it would say WHICH cron commmand.
-
-<< Done. Also which shell, which user (useful when the mail gets
- forwarded), which home directory, and other useful crud. >>
-
-Another problem is with timezones. It is necessary to specify TZ=PST8PDT (or
-whatever) when you invoke cron (from inittab, or /etc/rc) and it is also
-necessary to add TZ=PST8PDT to each crontab line which might need it. Cron
-should automatically export its idea of the "TZ" to each invoked command, and
-it should be possible to put a line in the crontab file which overrides that
-for every command in the file (e.g., most users are on EST, so cron is run
-with TZ=EST5EDT; but one user is usually on PST and wants all of his cron
-commands to run with TZ=PST8PDT). This might be extended to allow any
-environment variable to be specified once for the whole crontab file (e.g.,
-PATH).
-
-<< Well, since I run the user's shell, you could put this into .cshrc.
- generic environment-variable setting could be useful, though. Since
- I have to modify the environment anyway, I'll consider this. >>
-
-A log file might be a nice idea, but the System V cron log is too verbose.
-I seem to remember that cron keeps it open, too; so you can't even have
-something go and periodically clean it out.
-
-<< I don't do /usr/lib/cron/log. I wasn't aware of this file until I
- got all these suggestions. Do people want this file? Tell me! >>
+++ /dev/null
-doc_DATA = CHANGES CONVERSION FEATURES INSTALL MAIL README THANKS
-
+++ /dev/null
-#/* Copyright 1988,1990,1993 by Paul Vixie
-# * All rights reserved
-# */
-
-##
-## Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC")
-## Copyright (c) 1997,2000 by Internet Software Consortium, Inc.
-##
-## Permission to use, copy, modify, and distribute this software for any
-## purpose with or without fee is hereby granted, provided that the above
-## copyright notice and this permission notice appear in all copies.
-##
-## THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES
-## WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
-## MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
-## ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
-## WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
-## ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT
-## OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
-##
-
-ISC Cron - January 2004
-[V4.0 was November, 2000]
-[V4.0b1 was September 7, 1997]
-[V3.1 was some time after 1993]
-[V3.0 was December 27, 1993]
-[V2.2 was some time in 1992]
-[V2.1 was May 29, 1991]
-[V2.0 was July 5, 1990]
-[V2.0-beta was December 9, 1988]
-[V1.0 was May 6, 1987]
-ftp://ftp.isc.org/isc/cron/
-
-This is a version of 'cron' that is known to run on most systems. It
-is functionally based on the SysV cron, which means that each user can have
-their own crontab file (all crontab files are stored in a read-protected
-directory, usually /var/cron/tabs). No direct support is provided for
-'at'; you can continue to run 'atrun' from the crontab as you have been
-doing. If you don't have atrun (i.e., System V) you are in trouble.
-
-A messages is logged each time a command is executed; also, the files
-"allow" and "deny" in /var/cron can be used to control access to the
-"crontab" command (which installs crontabs). It hasn't been tested on
-SysV, although some effort has gone into making the port an easy one.
-
-To use this: Sorry, folks, there is no cutesy 'Configure' script. You'll
-have to go edit a couple of files... So, here's the checklist:
-
- Read all the FEATURES, INSTALL, and CONVERSION files
- Edit config.h
- Edit Makefile
- (both of these files have instructions inside; note that
- some things in config.h are definable in Makefile and are
- therefore surrounded by #ifndef...#endif)
- 'make'
- 'su' and 'make install'
- (you may have to install the man pages by hand)
- kill your existing cron process
- (actually you can run your existing cron if you want, but why?)
- build new crontabs using /usr/lib/{crontab,crontab.local}
- (either put them all in "root"'s crontab, or divide it up
- and rip out all the 'su' commands, collapse the lengthy
- lists into ranges with steps -- basically, this step is
- as much work as you want to make it)
- start up the new cron
- (must be done as root)
- watch it. test it with 'crontab -r' and watch the daemon track your
- changes.
- if you like it, change your /etc/{rc,rc.local} to use it instead of
- the old one.
-
-$Id: README,v 1.6 2004/01/23 19:03:32 vixie Exp $
+++ /dev/null
-15 January 1990
-Paul Vixie
-
-Many people have contributed to cron. Many more than I can remember, in fact.
-Rich Salz and Carl Gutekunst were each of enormous help to me in V1; Carl for
-helping me understand UNIX well enough to write it, and Rich for helping me
-get the features right.
-
-John Gilmore wrote me a wonderful review of V2, which took me a whole year to
-answer even though it made me clean up some really awful things in the code.
-(According to John the most awful things are still in here, of course.)
-
-Paul Close made a suggestion which led to /etc/crond.pid and the mutex locking
-on it. Kevin Braunsdorf of Purdue made a suggestion that led to @reboot and
-its brothers and sisters; he also sent some diffs that lead cron toward compil-
-ability with System V, though without at(1) capabilities, this cron isn't going
-to be that useful on System V. Bob Alverson fixed a silly bug in the line
-number counting. Brian Reid made suggestions which led to the run queue and
-the source-file labelling in installed crontabs.
-
-Scott Narveson ported V2 to a Sequent, and sent in the most useful single batch
-of diffs I got from anybody. Changes attributable to Scott are:
- -> sendmail won't time out if the command is slow to generate output
- -> day-of-week names aren't off by one anymore
- -> crontab says the right thing if you do something you shouldn't do
- -> crontab(5) man page is longer and more informative
- -> misc changes related to the side effects of fclose()
- -> Sequent "universe" support added (may also help on Pyramids)
- -> null pw_shell is dealt with now; default is /bin/sh
crontab.c misc.c entry.c env.c pw_dup.c security.c
crontab_LDADD = \
- -lselinux -lpam -lpam_misc -laudit
+ $(LIBSELINUX) $(LIBPAM) $(LIBAUDIT)
crond_LDADD = \
- -lselinux -lpam -lpam_misc -laudit
+ $(LIBSELINUX) $(LIBPAM) $(LIBAUDIT)
crond_LDFLAGS = \
- -fpie
+ $(LDFLAGS)
if DEBUG
DBG = debug
projects / cronie / commitdiff