lyda / chkcrontab Goto Github PK

https://github.com/lyda/chkcrontab/blob/master/setup.py#L29

My suggestion to fix this is to

1. add an install_requires or similar argument containing the unittest2 package for python < 2.7
2. move the import to inside the method where it's used

This was the other remaining issue from code.google: want an rpm spec file.

It's been a long time since I've made an rpm spec file but I can give it a go. Should be easy enough to get a fedora docker image. I'll see what other python projects do for packaging files.

The maximum command length is 999 characters.
Adding such validation would be great.

It would be great if there was a quiet option that would emit nothing if no error or warnings were found, but would emit the warning or error if one is found.

Use case is to have chkcrontab running from a file in /etc/cron.d on a regular basis so any errors that slipped in will be picked up and emailed to root.

so a cron entry like:

5 * * * * root for i in /etc/cron.d/*; do /usr/local/bin/chkcrontab -q $i ; done

would only email the user if an error was detected.

The Debian packaging standard has rules on acceptable filenames for files destined to cron.d. Enabling these with a flag would be better than the current solution.

http://www.debian.org/doc/manuals/maint-guide/dother.en.html#crond

When checking files in a package's debian/ directory, filenames should only match the (\S+\.)?cron.d as opposed to the other names currently accepted. In addition the error for this should probably point the user at the above link.

I suspect other packaging systems have their own standards, so need to investigate those first.

As seen below, randomly typing a nonexistent filename chkcrontab would take it in fine with no complaints and gives an okay exist code (0).

$ ls -l
total 16
-rw-r--r--  1 ye  staff   120 Nov  7 18:04 Dockerfile
-rw-r--r--  1 ye  staff  2145 Nov  8 11:02 test-crontab
$ chkcrontab ./8e5f63ef-915b-4616-ad90-31a1a590922d
Checking correctness of ./8e5f63ef-915b-4616-ad90-31a1a590922d
$ echo $?
0
$ chkcrontab 
ERROR: No crontab file was specified.
$ echo $?
1

It should probably exit with an error exitcode(1) and print out an error message just as if I didn't provide a file or similar. "ERROR: ./8e5f63ef-915b-4616-ad90-31a1a590922d doesn't exist."

It would be nice to have a version flag. And generally setting the version in a sane way would be nice - preferably via git describe so I don't screw up version names in future pypi uploads...

I am running CRON on Debian 9 machine with Vixie CRON.
The MAILTO field cannot have space between commas. E.g, this is not legal:
MAILTO="[email protected], [email protected]"
but removing the comma between the two will make it legal:
MAILTO="[email protected],[email protected]"

Can a warning be added that checks for this case.

Reference: https://serverfault.com/questions/133058/how-to-send-the-output-from-a-cronjob-to-multiple-e-mail-addresses#comment616379_133062

See the output of https://gist.github.com/2901598

I suspect the weirdness in the setup.py but I am not sure.

I just encountered a case where the cron file is valid, but the permissions on the file allowed write by "other". A chmod o-w file fixed it, and chkcrontab did not capture this as I assume it doesn't check the file permissions. When the cron service started, it was not processing the file, throwing an error in /var/log/syslog: ffamfe_da_cron_1 | Jan 18 12:16:01 ffa24 cron[1084]: (*system*ffamfe_da) INSECURE MODE (group/other writable) (/etc/cron.d/ffamfe_da)

While I was busy in The Big Blue Room it seems @spahan made a bunch of really useful changes. So I'll work on merging those in.

Add the ability to parse user crontabs: https://code.google.com/p/chkcrontab/issues/detail?id=2

Many crontab files are written without a user. Can we have a flag for this. I do not mind if it disables optional user by default, but would very much appreciate if there exists an option to do so.