Looks like we're massively behind on vixie-cron releases. The most recent offical release is 4.1, available from ftp://ftp.isc.org/isc/cron/ . Pretty much all of our existing patcheset fails to apply cleanly. I'll have a play later today unless anyone's particularly attached to this package...
so bump it yourself ... this package has never had a maintainer ... hell i didnt even realize anyone used it ;)
Ok, 4.1 in the tree but package.masked. It almost certainly has nasty bugs, given that I had to redo every single frickin' patch... selinux people: I've tried to forward port your patch, and I've gotten to the stage where it'll at least apply cleanly. I don't have the kit to compile test or the knowledge to know whether it'll actually still work. Please fix :) Brave people, please try it once the files hit the mirrors and report in this bug.
Looks like this new version insists that users are listed in cron.allow. Not sure whether we want to patch this out, since we make users be in the 'cron' group to run crontab anyway. Thoughts?
I vote for patch it out (no, I don't know how). I think it redundant and a lot of uesrs will cry because he/she missed that ewarn thing.
i dont think we should go changing upstream behavior just because we dont want users 'to cry' ...
I think I have a sneaky way around this... If we install a blank /etc/cron.deny and no /etc/cron.allow by default, it'll work as expected (and as per older versions) without breaking upstream behaviour. Anyone who really wants to use cron.{allow,deny} can just edit them as normal. Ebuild updated...
make it less sneaky by making the cron.deny have examples in it only and no real entries :) then no one will guess at why we *really* install a 'blank' cron.deny
Good plan. Ebuild updated.
Has the format of files in /etc/cron.d changed? I noticed the two cron entries I have in there fail with: /bin/sh: line 1: root: command not found Null message body; hope that's ok "root" is the user it is supposed to run the cronjob as.
Aaron -- could you please paste in the cron.d entries which are causing problems? I've had entries which specify a username work fine here.
Before I just had: 0 0 * * * root /usr/bin/chkrootkit -q | mail -s "$HOSTNAME: chkrootkit output" 0 5,19 * * * root /root/bin/stats.sh | mail -s "$HOSTNAME: system statistics" Added another one with my normal user just now to test: */2 * * * * ka0ttic /usr/bin/fortune with the same results: /bin/sh: line 1: ka0ttic: command not found
selinux patch looks good
Has the prob in comment #11 been fixed?
No, the problem in comment #11 is going to involve me rewriting a fairly large chunk of one of the Gentoo specific patches, so it may be a few days before that can be done.
Please cc ppc again when vixie-cron 4.1 needs testing on ppc. Keep up the good work.
Ok, I finally got some free time to look into the cron.d entry parsing bug, and after many hours of hair-pulling I finally realized what the problem was (One of those doh! bugs). For system crontabs, the previous version of cron called process_crontab with: process_crontab("root", "*system*", ...); and if fname (2nd arg) was not "*system*" then getpwname(uname) was called assuming it was a user crontab entry. With this new version, the fname arg should be NULL for system crontabs. If not, then getpwname(uname) is called and once it gets to load_entry() (entry.c), pw will not be NULL, and username parsing will not occur, hence our bug. So, ciaranm, you will not have to rewrite signifigant portions of the patch, but rather change the call from: process_crontab("root", "*system*", ...); to: process_crontab("root", NULL, ...); in the /etc/cron.d readdir() loop (specifically, database.c:114) and all should be well. Besides this bug, I have run into 0 problems with this version over the last couple weeks. IMO, after fixing this bug, it is ready to be unmasked for some more widespread testing. I'd fix it myself, but I'm not part of the base-system herd, and I don't particularly want ciaranm chasing me down with a unix pipe :P
Cheers Aaron. 4.1-r1 should now work. I'll unmask in a day or two if no-one reports any further problems.
unleashed.
