Hi all!
Next week I will move cronie[1] package to Factory, so it will replace old cron. If someone is against this step, please just write what's wrong.
As I announced earlier, you could find Cronie in Base:System repo [2] there is also prepared wiki about known changes after switch to cronie [3]
[1]https://fedorahosted.org/cronie/ [2]https://build.opensuse.org/package/show?package=cronie&project=Base%3ASy... [3]http://en.opensuse.org/Cron_replace#Differences_between_old_openSUSE.27s_cro...
The crontab in there is basically a new setuid root program and the daemon too, so we need to audit it before 11.3 release.
I have opened an AUDIT-0 bug for it.
Is there any history to the daemon and tools? Where they forked from vixie cron?
Ciao, Marcus
Version 3 of Vixie cron was released in late 1993. Version 4.1 was renamed to ISC Cron and was released in January 2004
Fedora continue with own release 4.2 and 4.3
then they reorganize sources and clean up the package add anacron 2.3 and switch name to cronie v 1.0 ( this started sometime around Fedora 9)
but upstart with planned features will probably replace cron,at and anacron at the end ...
Am Freitag 12 Februar 2010 schrieb Michal Seben:
but upstart with planned features will probably replace cron,at and anacron at the end ...
You should note that these upstart features are planned since 2007...
Greetings, Stephan
On Friday 12 February 2010 09:21:22 Michal Seben wrote:
One question: Why do you want to make that move?
Thanks, Roman.
* fixes from Fedora comes to our distro * versioning, clean package (without old patches) currently we have ~20 patches, often in terrible state - it's the result of non existing upstream * cronie includes also anacron project and libaudit support
Am Fri 12 Feb 2010 10:21:22 AM CET schrieb Michal Seben mseben@suse.cz:
Next week I will move cronie[1] package to Factory, so it will replace old cron. If someone is against this step, please just write what's wrong.
As I announced earlier, you could find Cronie in Base:System repo [2] there is also prepared wiki about known changes after switch to cronie [3]
I'd appreeciate if you'd take the pain to create a feature and set the "docimpact" flag. In case cronie is fully backwards compatible, please state it there -- this could save us quite some time...
[BTW, I hate footnotes in mails... ;) It is neither reader friendly nor compatible with traditional quoting.]
[1]https://fedorahosted.org/cronie/ [2]https://build.opensuse.org/package/show?package=cronie&project=Base%3ASy... [3]http://en.opensuse.org/Cron_replace#Differences_between_old_openSUSE.27s_cro...
On Tuesday 16 February 2010 06:49:33 Karl Eichwalder wrote:
Am Fri 12 Feb 2010 10:21:22 AM CET schrieb Michal Seben mseben@suse.cz:
Next week I will move cronie[1] package to Factory, so it will replace old cron. If someone is against this step, please just write what's wrong.
As I announced earlier, you could find Cronie in Base:System repo [2] there is also prepared wiki about known changes after switch to cronie [3]
I'd appreeciate if you'd take the pain to create a feature and set the "docimpact" flag. In case cronie is fully backwards compatible, please state it there -- this could save us quite some time...
https://features.opensuse.org/309015
[BTW, I hate footnotes in mails... ;) It is neither reader friendly nor compatible with traditional quoting.]
[1]https://fedorahosted.org/cronie/ [2]https://build.opensuse.org/package/show?package=cronie&project=Base%3A System [3]http://en.opensuse.org/Cron_replace#Differences_between_old_openSUSE.2 7s_cron_and_new_openSUSE.27s_cronie
* Michal Seben mseben@suse.cz [02-12-10 03:29]:
Next week I will move cronie[1] package to Factory, so it will replace old cron. If someone is against this step, please just write what's wrong.
11.2 x86_64 KDE44
I replaced cron with cronie and experienced problems with repetitive processes hanging, expecially: */10 * * * * /usr/bin/mairix -p > /dev/null
I reverted to cron.
On 16/02/10 18:41, Patrick Shanahan wrote:
I replaced cron with cronie and experienced problems with repetitive processes hanging, expecially: */10 * * * * /usr/bin/mairix -p > /dev/null
What kind of problems ?
* Cristian Rodríguez crrodriguez@opensuse.org [02-16-10 17:57]:
On 16/02/10 18:41, Patrick Shanahan wrote:
I replaced cron with cronie and experienced problems with repetitive processes hanging, expecially: */10 * * * * /usr/bin/mairix -p > /dev/null
What kind of problems ?
The next instance cannot run because the previous has not cleared/ended. And the only thing I had done was install cronie. Reinstalling cron corrected the problem.
But it requires "rpm -e cronie" before reinstalling cron.
I can go thru it again and make checks/tests, if you wish and describe what you want.
On Wednesday 17 February 2010 01:32:25 Patrick Shanahan wrote:
- Cristian Rodríguez crrodriguez@opensuse.org [02-16-10 17:57]:
On 16/02/10 18:41, Patrick Shanahan wrote:
I replaced cron with cronie and experienced problems with repetitive processes hanging, expecially: */10 * * * * /usr/bin/mairix -p > /dev/null
What kind of problems ?
The next instance cannot run because the previous has not cleared/ended. And the only thing I had done was install cronie. Reinstalling cron corrected the problem.
But it requires "rpm -e cronie" before reinstalling cron.
I can go thru it again and make checks/tests, if you wish and describe what you want.
thanks Patrick ! I file a bug report : bnc#580438 and i will check what's going on
thanks again !
* Michal Seben mseben@suse.cz [02-17-10 02:44]:
On Wednesday 17 February 2010 01:32:25 Patrick Shanahan wrote:
- Cristian Rodríguez crrodriguez@opensuse.org [02-16-10 17:57]:
On 16/02/10 18:41, Patrick Shanahan wrote:
I replaced cron with cronie and experienced problems with repetitive processes hanging, expecially: */10 * * * * /usr/bin/mairix -p > /dev/null
What kind of problems ?
The next instance cannot run because the previous has not cleared/ended. And the only thing I had done was install cronie. Reinstalling cron corrected the problem.
But it requires "rpm -e cronie" before reinstalling cron.
I can go thru it again and make checks/tests, if you wish and describe what you want.
thanks Patrick ! I file a bug report : bnc#580438 and i will check what's going on
further info:
reinstalled cronie
received duplicate cron error emails that mairix failed for existing lock.file
but mairix_database *was* updated
Apparently cronie is starting *three* instances of: */10 * * * * /usr/bin/mairix -p > /dev/null
The first is successful and the other two fail
rpm -e --nodeps cronie reinstalled cron
This information was added to the bug_report bnc#580438
* Patrick Shanahan ptilopteri@gmail.com [02-17-10 20:45]:
further info:
reinstalled cronie
received duplicate cron error emails that mairix failed for existing lock.file
but mairix_database *was* updated
Apparently cronie is starting *three* instances of: */10 * * * * /usr/bin/mairix -p > /dev/null
The first is successful and the other two fail
rpm -e --nodeps cronie reinstalled cron
This information was added to the bug_report bnc#580438
I closed the bug, WORKS FOR ME. Investigation revealed that the install somehow provided multiple processes of cron active. Whether I did it or the install script, I don't know. Killing the extra processes resolved the problem and cronie has performed properly for the last eight hours.
Will advise if further problems.
tks,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2010-02-12 at 09:21 -0000, Michal Seben wrote:
Hi all!
Next week I will move cronie[1] package to Factory, so it will replace old cron. If someone is against this step, please just write what's wrong.
As I announced earlier, you could find Cronie in Base:System repo [2] there is also prepared wiki about known changes after switch to cronie [3]
I found a mis-feature of cronie:
If a user has a crontab entry that starts with a dash (meaning: don't log) the entire line is skipped. Existing crontab entries like that fail silently.
If a user tries to create a crontab with a line like that, he gets an error:
File /tmp/crontab.hA3Nld saved crontab: installing new crontab "/tmp/crontab.hA3Nld":5: bad option errors in crontab file, can't install.
that doesn't explain anything. However, there is an entry in the syslog that does:
... crontab 4032 - - (CRON) ERROR (Only privileged user can disable logging)
This is hardcoded, it is not possible to disable; see:
https://fedorahosted.org/cronie/browser/src/entry.c, *load_entry().
The possible workaround is to add a file to /etc/cron.d/, where entries have a syntax that specifies under which user the entry runs, and allows the dash.
- -- Cheers, Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Hi,
On Sun, Jun 05, 2011 at 04:12:11AM +0200, Carlos E. R. wrote:
I found a mis-feature of cronie:
If a user has a crontab entry that starts with a dash (meaning: don't log) the entire line is skipped. Existing crontab entries like that fail silently.
If a user tries to create a crontab with a line like that, he gets an error:
File /tmp/crontab.hA3Nld saved crontab: installing new crontab "/tmp/crontab.hA3Nld":5: bad option errors in crontab file, can't install.
that doesn't explain anything. However, there is an entry in the syslog that does:
... crontab 4032 - - (CRON) ERROR (Only privileged user can disable logging)
This is hardcoded, it is not possible to disable; see:
https://fedorahosted.org/cronie/browser/src/entry.c, *load_entry().
The possible workaround is to add a file to /etc/cron.d/, where entries have a syntax that specifies under which user the entry runs, and allows the dash.
That's because it is a system crontab. Disabling logging is permitted only for system crontabs and for the user with uid 0 (root).
The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."
But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).
As I see it, The current cronie behaviour is correct. Well, the manual page should mention the logging disabling ability as the old manual did.
-- Vita Cizek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-06 10:15, Vitezslav Cizek wrote:
But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).
Didn't know it was a bug, as I found it useful.
As I see it, The current cronie behaviour is correct. Well, the manual page should mention the logging disabling ability as the old manual did.
It would be better if the feature could be disabled for certain users, with a list, such as the one allowed users.
Linux machines are not always big multiuser installations, but also home, personal systems. No reason why a plain user should not be able to disable logging, if the root (same person) so wishes.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Carlos E. R. wrote:
On 2011-06-06 10:15, Vitezslav Cizek wrote:
But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).
Didn't know it was a bug, as I found it useful.
As I see it, The current cronie behaviour is correct. Well, the manual page should mention the logging disabling ability as the old manual did.
It would be better if the feature could be disabled for certain users, with a list, such as the one allowed users.
Linux machines are not always big multiuser installations, but also home, personal systems. No reason why a plain user should not be able to disable logging, if the root (same person) so wishes.
Sounds like a feature request? (as it's not a current cronie functionality).
Am Mon, 6 Jun 2011 10:15:39 +0200 schrieb Vitezslav Cizek vcizek@suse.cz:
The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."
But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).
As I see it, The current cronie behaviour is correct.
Well. I would argue that "correct" in this case would be to not disable logging, but to still execute the command. Principle of least surprise. Maybe additionally log a warning that this is going to no longer work in after dec 31 2020 or something like that.
Crontabs not working after upgrade which did work fine before is IMHO nothing I'd call "correct".
On Mon, Jun 06, 2011 at 04:36:58PM +0200, Stefan Seyfried wrote:
Am Mon, 6 Jun 2011 10:15:39 +0200 schrieb Vitezslav Cizek vcizek@suse.cz:
The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."
But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).
As I see it, The current cronie behaviour is correct.
Well. I would argue that "correct" in this case would be to not disable logging, but to still execute the command. Principle of least surprise. Maybe additionally log a warning that this is going to no longer work in after dec 31 2020 or something like that.
I meant "correct" as "cron was intended to behave like that".
Submitted a fixed cron package:
crontab.5 now includes: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."
Also, when an unprivileged user uses the dash, cron complains about incorrect minute, instead of an invalid option.
Crontabs not working after upgrade which did work fine before is IMHO nothing I'd call "correct".
You're right. But as this behaviour was caused by a bug, I think it should be fixed.
-- Vita Cizek
Hello I get broken factory links on factory [1] I click on for example CodeAnalyst-2.12.3-2.3.x86_64.rpm I get a '404 Not Found' It happens for files on the noarch repo as well [2] [1] and [2] resolve to:- http://mirror.internode.on.net/pub/opensuse/factory/repo/oss/suse/%7Bx86_64,... Glenn
[1] http://download.opensuse.org/factory/repo/oss/suse/x86_64/
[2] http://download.opensuse.org/factory/repo/oss/suse/noarch/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-06 18:20, doiggl@velocitynet.com.au wrote:
Hello I get broken factory links on factory [1]
Please don't hijack threads. Create your own.
We are talking here about cronie, not links.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
Am Mon, 6 Jun 2011 17:02:17 +0200 schrieb Vitezslav Cizek vcizek@suse.cz:
You're right. But as this behaviour was caused by a bug, I think it should be fixed.
Then we should probably fix the crontabs during the update. The user hit by a regression will not care if this worked due to a bug before.
it will probably be something like
for i in /var/spool/cron/tabs/*; do case $i in */*) continue ;; # no crontabs present */root) continue ;; # root is allowed *) sed -i 's/^-//' $i ;; esac done
in %postin
You'll have to do this for the next SLES anyway as such a regression will probably not be tolerated there ;)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-06 17:02, Vitezslav Cizek wrote:
On Mon, Jun 06, 2011 at 04:36:58PM +0200, Stefan Seyfried wrote:
Crontabs not working after upgrade which did work fine before is IMHO nothing I'd call "correct".
You're right. But as this behaviour was caused by a bug, I think it should be fixed.
Yes, it should be fixed that cronie fails silently when it finds an entry with a dash. It should complain in the log and/or the email that the plain users can not use the dash; and ignore the dash and execute the entry, and log it.
The current behavior of silently ignoring the entry is a bug.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
On Mon, Jun 06, 2011 at 11:57:32PM +0200, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-06 17:02, Vitezslav Cizek wrote:
On Mon, Jun 06, 2011 at 04:36:58PM +0200, Stefan Seyfried wrote:
Crontabs not working after upgrade which did work fine before is IMHO nothing I'd call "correct".
You're right. But as this behaviour was caused by a bug, I think it should be fixed.
Yes, it should be fixed that cronie fails silently when it finds an entry with a dash. It should complain in the log and/or the email that the plain users can not use the dash; and ignore the dash and execute the entry, and log it.
It doesn't fail silently, it complains to syslog with: "(CRON) ERROR (Only privileged user can disable logging)"
I prefer Stefan's approach, cron will strip leading dashes from unprivileged users' crontabs during an update.
The only case when a dash can slip to a user's crontab remains, when someone copies a crontab between different systems, but this is the user's fault and he should handle it himself.
-- Vita Cizek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-07 14:11, Vitezslav Cizek wrote:
On Mon, Jun 06, 2011 at 11:57:32PM +0200, Carlos E. R. wrote:
Yes, it should be fixed that cronie fails silently when it finds an entry with a dash. It should complain in the log and/or the email that the plain users can not use the dash; and ignore the dash and execute the entry, and log it.
It doesn't fail silently, it complains to syslog with: "(CRON) ERROR (Only privileged user can disable logging)"
It fails silently.
The syslog entry existed already, machine was using cron. Then machine is upgraded to oS 11.4, cron changed to cronie (not my decision), entry is no longer valid, it is not executed, nothing in syslog. Silence.
It complains to syslog when the user edits the entry; but then remember that a plain user is not authorized to see what is in syslog (-rw-r----- root root), so to all purposes the failure is also silent.
I prefer Stefan's approach, cron will strip leading dashes from unprivileged users' crontabs during an update.
Too late. 11.4 was released.
The only case when a dash can slip to a user's crontab remains, when someone copies a crontab between different systems, but this is the user's fault and he should handle it himself.
You forget supported scenario of openSUSE upgrade. Not the user fault, but the packager fault.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/06/2011 10:36 AM, Stefan Seyfried wrote:
Am Mon, 6 Jun 2011 10:15:39 +0200 schrieb Vitezslav Cizek vcizek@suse.cz:
The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."
But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).
As I see it, The current cronie behaviour is correct.
Well. I would argue that "correct" in this case would be to not disable logging, but to still execute the command. Principle of least surprise. Maybe additionally log a warning that this is going to no longer work in after dec 31 2020 or something like that.
Crontabs not working after upgrade which did work fine before is IMHO nothing I'd call "correct".
Agreed. This is really the only approach that would make cronie an acceptable replacement.
- -Jeff
- -- Jeff Mahoney SUSE Labs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-07 14:20, Jeff Mahoney wrote:
Agreed. This is really the only approach that would make cronie an acceptable replacement.
But 11.4 was released with a faulty cronie. That is how I found out.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 06/07/2011 09:48 AM, Carlos E. R. wrote:
On 2011-06-07 14:20, Jeff Mahoney wrote:
Agreed. This is really the only approach that would make cronie an acceptable replacement.
But 11.4 was released with a faulty cronie. That is how I found out.
Ugh. This is gonna need an update.
- -Jeff
- -- Jeff Mahoney SUSE Labs
I filed two separate bugs for this issue:
On Mon, Jun 06, 2011 at 10:15:39AM +0200, Vitezslav Cizek wrote:
Hi,
On Sun, Jun 05, 2011 at 04:12:11AM +0200, Carlos E. R. wrote:
I found a mis-feature of cronie:
If a user has a crontab entry that starts with a dash (meaning: don't log) the entire line is skipped. Existing crontab entries like that fail silently.
https://bugzilla.novell.com/show_bug.cgi?id=698549
and the other is:
The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."
But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).
https://bugzilla.novell.com/show_bug.cgi?id=698267
-- Vita Cizek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2011-06-07 16:33, Vitezslav Cizek wrote:
I filed two separate bugs for this issue:
and the other is:
The old cron manual said: "If the uid of the owner is 0 (root), he can put a "-" as first character of a crontab entry. This will prevent cron from writing a syslog message about this command getting executed."
But as you say, it worked even for unprivileged users' crontabs. (Probably a bug in old cron).
Bug 698267 - VUL-1: Ordinary user is allowed to disable logging of a cron command execution to syslog
]> However, there is a bug in cron, that provides this feature even to ]> unprivileged users.
Ah, you mean in cron, not cronie.
- -- Cheers / Saludos,
Carlos E. R. (from 11.4 x86_64 "Celadon" at Telcontar)
-
Carlos E. R. -
Carlos E. R. -
Cristian Rodríguez -
doiggl＠velocitynet.com.au -
Jeff Mahoney -
Karl Eichwalder -
Michal Seben -
Patrick Shanahan -
Per Jessen -
Stefan Seyfried -
Stephan Kulow -
Vitezslav Cizek