Am 05.04.2011 09:19, schrieb Thomas S Hatch:

I can think of three considerations for a cron daemon: 1 . Minimal - its a cron daemon, it does not need to be complex 2. Active development 3. Anacron functionality

As far as I can see this leaves us with fcron, dcron and cronie. Cronie probably has the highest assurance for upstream development because it is backed by redhat. But I think that having a cron daemon as default that has issues executing jobs on time and as they are defined is highly questionable.

Before the current maintainer took over dcron, we had that same discussion. Aaron even contacted the fcron maintainer (he posted the reply to arch-general or arch-dev-public, if anyone could find the link in the archives, please post it). The author responded that he considered fcron feature-complete, so didn't develop it anymore. However, he would fix bugs when they are reported, and I think there are no known bugs right now. That said, fcron lacks /etc/cron.d/ functionality which was the most important argument against it. I personally don't need that and I like fcron a lot. As for your conditions: 1) It is very small software, 1.2MB installed, and it has lots of features. It is by no means minimal though. 2) I commented on that above. 3) dcron has @daily, @hourly and so on. In fcron, you can use standard crontab entries and add &bootrun to the beginning of the line to repeat "missed" cronjobs. I don't know cronie, so maybe you can elaborate more.

On Wed, Apr 6, 2011 at 2:49 PM, Heiko Baums wrote:

Am Wed, 06 Apr 2011 22:27:27 +0200 schrieb Thomas Bächler :

...

That said, fcron lacks /etc/cron.d/ functionality which was the most important argument against it. I personally don't need that and I like fcron a lot.

Are you sure about that? I mean, I didn't need /etc/cron.d, yet. So I don't know exactly, but somehow I think it has this functionality. But don't nail me down on it. I can be totally wrong regarding this. And I bet I am. ;-)

Nevertheless is this feature really a knockout argument? Is this feature really necessary? Can't things in /etc/cron.d be transferred into /etc/cron.{hourly,...} or the usual fcrontab?

Btw., people who really need /etc/cron.d for whatever reason can easily install a different cron daemon. The question is not to putting fcron into [core] and removing every other cron from the repos. The question is which cron shall be the default cron.

...

As for your conditions: 1) It is very small software, 1.2MB installed, and it has lots of features. It is by no means minimal though. 2) I commented on that above. 3) dcron has @daily, @hourly and so on. In fcron, you can use standard crontab entries and add &bootrun to the beginning of the line to repeat "missed" cronjobs.

And it runs those missed jobs reliably as soon as it's started at boot time.

And I would say that this reliability is much more important than /etc/cron.d.

...

I don't know cronie, so maybe you can elaborate more.

As far as I know cronie doesn't have anacron features (&bootrun) like fcron has.

Heiko

Well, seems I am invested... :) Ok, I think that cronie is worth advanced investigation... dcron and fcron are not under active development, cronie is cronie is small - 0.20MB installed cronie is developed by Red Hat - it is not going anywhere and we have a guaranteed upgrade path As far as I can tell cronie has no deps beyond glibc and pam cronie has /etc/cron.d support cronie has configurable anacron support via an anacrontab config file cronie extends the original vixie cron package so the syntax, core feature set, etc are stable cronie implements advanced security hooks as well and can integrate with SELINUX (I am saving the "include SELINUX support in base for a latter date") At the outset I think that cronie looks to be the most viable option, but merits further investigation. -Thomas S Hatch -Arch Linux Trusted User

On Wed, Apr 6, 2011 at 3:43 PM, Sander Jansen wrote:

On Wed, Apr 6, 2011 at 4:30 PM, Thomas S Hatch wrote:

...

On Wed, Apr 6, 2011 at 2:49 PM, Heiko Baums wrote:

...

Am Wed, 06 Apr 2011 22:27:27 +0200 schrieb Thomas Bächler :

...

That said, fcron lacks /etc/cron.d/ functionality which was the most important argument against it. I personally don't need that and I like fcron a lot.

Are you sure about that? I mean, I didn't need /etc/cron.d, yet. So I don't know exactly, but somehow I think it has this functionality. But don't nail me down on it. I can be totally wrong regarding this. And I bet I am. ;-)

Nevertheless is this feature really a knockout argument? Is this feature really necessary? Can't things in /etc/cron.d be transferred into /etc/cron.{hourly,...} or the usual fcrontab?

Btw., people who really need /etc/cron.d for whatever reason can easily install a different cron daemon. The question is not to putting fcron into [core] and removing every other cron from the repos. The question is which cron shall be the default cron.

...

As for your conditions: 1) It is very small software, 1.2MB installed, and it has lots of features. It is by no means minimal though. 2) I commented on that above. 3) dcron has @daily, @hourly and so on. In fcron, you can use standard crontab entries and add &bootrun to the beginning of the line to repeat "missed" cronjobs.

And it runs those missed jobs reliably as soon as it's started at boot time.

And I would say that this reliability is much more important than /etc/cron.d.

...

I don't know cronie, so maybe you can elaborate more.

As far as I know cronie doesn't have anacron features (&bootrun) like fcron has.

Heiko

Well, seems I am invested... :)

Ok, I think that cronie is worth advanced investigation...

dcron and fcron are not under active development, cronie is cronie is small - 0.20MB installed cronie is developed by Red Hat - it is not going anywhere and we have a guaranteed upgrade path As far as I can tell cronie has no deps beyond glibc and pam cronie has /etc/cron.d support cronie has configurable anacron support via an anacrontab config file cronie extends the original vixie cron package so the syntax, core feature set, etc are stable cronie implements advanced security hooks as well and can integrate with SELINUX (I am saving the "include SELINUX support in base for a latter date")

At the outset I think that cronie looks to be the most viable option, but merits further investigation.

This seems to be a monthly recurring discussion. How about not providing any default, just put all the different cron(s) in extra? I think eventually systemd will provide a cron-like service :)

Cheers,

Sander

Unfortunately this particular issue is not like the good ol' syslog-ng vs rsyslog debate, this one is about the present default having bugs that upstream is not fixing. I have nothing against dcron as a cron daemon, but if upstream bugs are not being fixed than a move needs to happen. And yes, someday systemd will change my baby's diapers, but it doesn't today :) (my understanding though is that the stated position of Arch was "no systemd" btw)

On Wed, Apr 6, 2011 at 4:16 PM, Grigorios Bouzakis wrote:

Thomas S Hatch wrote:

...

I am saving the "include SELINUX support in base for a latter date"

my understanding though is that the stated position of Arch was "no systemd"

s/was/is/g

That is also my understanding in regards to selinux. Although i am not familiar with "stated positions" about either.

PS. Ntp is fine application that will keep your clock synchronised. It seems to be 5 days off. :)

Yes the systemd topic keeps popping up, right now we don't know if certain upstream changes are going to force Arch into using systemd or not. In my communications with the developers I have been continually placed under the understanding that while Arch will support systemd, it will not be part of base by default. As for adding SELinux support in base but keeping it turned off by default, +1

On Wed, Apr 6, 2011 at 4:32 PM, Heiko Baums wrote:

Am Wed, 6 Apr 2011 16:25:42 -0600 schrieb Thomas S Hatch :

...

As for adding SELinux support in base but keeping it turned off by default, +1

Then you mean adding it to [core]. (base) is supposed to be installed on every system. And SELinux is definitely not necessary for a minimal base Linux installation.

Heiko

SELinux is a compile flag in the kernel and base utils, it is not required for a minimal system, but just adding the compile flags is a minor change and makes setting up more secure systems a possibility. I think that the only reason it is omitted is because most people are horrified by it, but if it is disabled by default then it is off and no one need know that support is compiled in.

2011/4/6 Tom Gundersen :

On Thu, Apr 7, 2011 at 6:46 AM, Thomas S Hatch wrote:

...

On Wed, Apr 6, 2011 at 4:32 PM, Heiko Baums wrote:

...

Am Wed, 6 Apr 2011 16:25:42 -0600 schrieb Thomas S Hatch :

...

As for adding SELinux support in base but keeping it turned off by default, +1

Then you mean adding it to [core]. (base) is supposed to be installed on every system. And SELinux is definitely not necessary for a minimal base Linux installation.

Heiko

SELinux is a compile flag in the kernel and base utils, it is not required for a minimal system, but just adding the compile flags is a minor change and makes setting up more secure systems a possibility.

I think that the only reason it is omitted is because most people are horrified by it, but if it is disabled by default then it is off and no one need know that support is compiled in.

I would just like to chime in and point out that if we want to allow selinux, then we would need someone committed to supporting it. I have never used it myself, but from what I hear it would need to be supported by things like initscripts to be used properly. If such support can be added elegantly and securely then I am not opposed to it.

Cheers,

Tom

I personallly dislike SELinux, so -1 -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com

On Wed, Apr 6, 2011 at 9:01 PM, DrCR wrote:

Could you guys elaborate on why you dislike selinux. I would appreciate it. Do you prefer AppArmor, or do you dislike that as well?

On Wed, Apr 6, 2011 at 7:13 PM, Grigorios Bouzakis wrote:

...

...

As for adding SELinux support in base but keeping it turned off by default, +1

Although this isnt a vote, mine was for no selinux at all, so its just 1. :)

2011/4/6 Ángel Velásquez :

...

I personallly dislike SELinux, so -1

I spent quite some time as a trainer for Red Hat and taught classes on SELinux. Normally when someone disliked SELinux it was because it gave them trouble setting up a particular service. I was fed a never ending stream of stories about how SELinux had caused somebody pain. All this did was reaffirm my respect for SELinux, because it was a security layer that seasoned engineers could not bypass. But it also helped me understand when, where and how to deploy SELinux so that it was a functional security layer without becoming cumbersome. SELinux is superior to app armor in that the secity layer is cleaner and much more secure, you cannot bypass SELinux without root access, while AppArmor can be bypassed simply by discovering violations in the security. AppArmor is easier to use, but SELinux is far more secure. I think that Arch would benefit from inducing SELinux as an option because it expands the venues available for Arch Linux systems, I also think that inclusion in base of SELinux requires a minimal amount of maintenance and SELinux is completely non-intrusive if it is disabled. If you want an easy to use, yet thin layer of application level security, use AppArmor, if you want a solid security layer, learn SELinux.

On Wed, Apr 6, 2011 at 7:53 PM, Tom Gundersen wrote:

On Thu, Apr 7, 2011 at 6:46 AM, Thomas S Hatch wrote:

...

On Wed, Apr 6, 2011 at 4:32 PM, Heiko Baums wrote:

...

Am Wed, 6 Apr 2011 16:25:42 -0600 schrieb Thomas S Hatch :

...

As for adding SELinux support in base but keeping it turned off by default, +1

Then you mean adding it to [core]. (base) is supposed to be installed on every system. And SELinux is definitely not necessary for a minimal base Linux installation.

Heiko

SELinux is a compile flag in the kernel and base utils, it is not required for a minimal system, but just adding the compile flags is a minor change and makes setting up more secure systems a possibility.

I think that the only reason it is omitted is because most people are horrified by it, but if it is disabled by default then it is off and no one need know that support is compiled in.

I would just like to chime in and point out that if we want to allow selinux, then we would need someone committed to supporting it. I have never used it myself, but from what I hear it would need to be supported by things like initscripts to be used properly. If such support can be added elegantly and securely then I am not opposed to it.

Cheers,

Tom

I like to hear that Tom! Unfortunately many people think that having SELinux compiled in means that it is running, having SELinux compiled into the core utils and the kernel but leaving it turned off has 0 negative effect on the system. Adding support for SELinux into Arch does not, in any way force anyone use it, if that were the case I would be %100 against it. I will need to set up SELinux in my datacenters very soon, because it is a very fundamental security layer, when I have it running I will give you all of the patches that the initscripts may need and make sure that they are non intrusive.

On Thu, Apr 7, 2011 at 2:08 AM, Thomas Bächler wrote:

...

I like to hear that Tom! Unfortunately many people think that having SELinux compiled in means

Am 07.04.2011 04:36, schrieb Thomas S Hatch: that

...

it is running, having SELinux compiled into the core utils and the kernel but leaving it turned off has 0 negative effect on the system.

If that just were true. I think we compiled SELinux into our kernel once or twice, just to remove it again. It caused random stuff to fail even though it was not enabled - at least this is what I remember (I'd have to look up the ML threads related to this).

If you find those threads please forward them to me, because I will be enabling SELinux in my environment and will need to work out these issues, thanks Thomas!

On Wednesday, April 06, 2011 18:13:04 Grigorios Bouzakis wrote:

Thomas S Hatch wrote:

...

On Wed, Apr 6, 2011 at 4:16 PM, Grigorios Bouzakis wrote:

...

Thomas S Hatch wrote:

...

I am saving the "include SELINUX support in base for a latter date"

my understanding though is that the stated position of Arch was "no systemd"

s/was/is/g

That is also my understanding in regards to selinux. Although i am not familiar with "stated positions" about either.

PS. Ntp is fine application that will keep your clock synchronised. It seems to be 5 days off. :)

Yes the systemd topic keeps popping up, right now we don't know if certain upstream changes are going to force Arch into using systemd or not.

I dont think such a topic keeps popping up. In fact I dont remember reading a discussion between Arch developers about it, ever. I could probably go on ranting about stuff thats been shoved down users mouths the last years for months but its futile and a waste of time.

It was a discussion that popped up here, a debate between users who felt replacing sysvinit was completely unneeded to those who seemed to want to use systemd for some useless, unneeded feature maybe less than 1% of Arch users were going to actually use.

...

As for adding SELinux support in base but keeping it turned off by default, +1

Although this isnt a vote, mine was for no selinux at all, so its just 1. :)

Selinux is another unneeded thing, but even worse is that it practically requires a doctorate in computer science to manipulate. Can't deny its security, though. +1 to leaving it out of Arch, not that anyone's asking Arch to.

On Thursday 07 April 2011 18:08:39 Yaro Kasear wrote:

Selinux is another unneeded thing, but even worse is that it practically requires a doctorate in computer science to manipulate. Can't deny its security, though. +1 to leaving it out of Arch, not that anyone's asking Arch to.

I don't see the harm in have proper SELinux support. It would make it easier to learn SELinux if one could have it officially supported and working well on everyone's Arch laptop. Plus added security is a good practice. Not sure why having official SELinux should stir some to vote against it when one can easily disable it. -- Divan Santana

On Thu, Apr 7, 2011 at 12:51 PM, Grigorios Bouzakis wrote:

Yaro Kasear wrote:

...

On Wednesday, April 06, 2011 18:13:04 Grigorios Bouzakis wrote:

...

Thomas S Hatch wrote:

...

Yes the systemd topic keeps popping up, right now we don't know if certain upstream changes are going to force Arch into using systemd

or

...

not.

I dont think such a topic keeps popping up. In fact I dont remember reading a discussion between Arch developers about it, ever. I could probably go on ranting about stuff thats been shoved down users mouths the last years for months but its futile and a waste of time.

It was a discussion that popped up here, a debate between users who felt replacing sysvinit was completely unneeded to those who seemed to want to use systemd for some useless, unneeded feature maybe less than 1% of Arch users were going to actually use.

I guess you mean http://thread.gmane.org/gmane.linux.arch.general/32759 Didnt enjoy skimming through it much, except maybe this part: http://article.gmane.org/gmane.linux.arch.general/32874 And indeed, it was just user talk. The only developer who got even remotely interested in participating got flamed.

...

...

...

As for adding SELinux support in base but keeping it turned off by default, +1

Although this isnt a vote, mine was for no selinux at all, so its just

...

...

:)

Selinux is another unneeded thing, but even worse is that it practically requires a doctorate in computer science to manipulate. Can't deny its security, though. +1 to leaving it out of Arch, not that anyone's asking Arch to.

All these seem like the natural sideffects of Arch's growth along with the (d)evolution (as in degeneration) of Linux.

---- Greg

Thanks for the link, I did not want to bring up SELinux yet, because I will not be getting to it for a few months, but this will help a great deal! -Thomas S Hatch

On Thu, 2011-04-07 at 22:31 +0300, Grigorios Bouzakis wrote:

Thomas S Hatch wrote:

...

On Thu, Apr 7, 2011 at 12:51 PM, Grigorios Bouzakis wrote:

...

I guess you mean http://thread.gmane.org/gmane.linux.arch.general/32759

Thanks for the link, I did not want to bring up SELinux yet, because I will not be getting to it for a few months, but this will help a great deal!

-Thomas S Hatch

Glad i could help :)

---- Greg

SELinux would maybe bring extra security too archlinux, but what I don't see in this thread is how much harder / more bugs it would make for developers/TU's to package if you use SELinux. So in general what is the benefits / costs for SELinux? And on a side note, I don't like archlinux forcing users to use SELinux because users should have a choice to use any MAC software they want. That's why AppArmor /Tomoyo are nicer solutions cause they don't require recompiling of packages -> increasing bugs/problems. -- Jelle van der Waa

On Fri, Apr 8, 2011 at 3:44 AM, Jelle van der Waa wrote:

And on a side note, I don't like archlinux forcing users to use SELinux because users should have a choice to use any MAC software they want. That's why AppArmor /Tomoyo are nicer solutions cause they don't require recompiling of packages -> increasing bugs/problems.

If we compile our packages with SELinux support, does that force users to use SELinux? I was under the impression that these changes would be completely benign on non-SELinux enabled systems. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

On Fri, Apr 8, 2011 at 7:32 AM, Allan McRae wrote:

In my opinion, SELinux would be better supported in a user provided repo. Work with the guy (whose name I can not remember...) who has done an awesome job getting this all done and into the AUR.

Okay I don't know a thing about SELinux but if anyone wants to maintain a repo I'd be happy to host it. And I don't believe this is the first time I've made this offer. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

Nicky726 wrote:

If I may add more to this SELinux related thread, I would like to aply for TU and bring SELinux packages to community in the summer, to make using SELinux easier.

I dont think thats gonna work since you'll have to provide the same packages as in [core] built differently. See for example: http://article.gmane.org/gmane.linux.arch.tur.user/19324 ---- Greg

Allan McRae wrote:

On 09/04/11 00:24, Grigorios Bouzakis wrote:

...

Nicky726 wrote:

...

If I may add more to this SELinux related thread, I would like to aply for TU and bring SELinux packages to community in the summer, to make using SELinux easier.

I dont think thats gonna work since you'll have to provide the same packages as in [core] built differently. See for example: http://article.gmane.org/gmane.linux.arch.tur.user/19324

Providing a set of packages that is configured/built for a different purpose is different that providing a package with a patch not supported upstream.

Nope, its exactly the same. The xcb cairo backend is part of the cairo source not a patch. Cairo can be configured to take advantage of it without messing with the xlib backend using the --enable-xcb & --disable-xlib_xcb same as pam for example needs the --enable-selinux in order to use selinux https://aur.archlinux.org/packages/selinux-pam/PKGBUILD ---- Greg

On Fri, Apr 8, 2011 at 3:55 PM, Allan McRae wrote:

On 09/04/11 00:53, Grigorios Bouzakis wrote:

...

Allan McRae wrote:

...

On 09/04/11 00:24, Grigorios Bouzakis wrote:

...

Nicky726 wrote:

...

If I may add more to this SELinux related thread, I would like to aply for TU and bring SELinux packages to community in the summer, to make using SELinux easier.

I dont think thats gonna work since you'll have to provide the same packages as in [core] built differently. See for example: http://article.gmane.org/gmane.linux.arch.tur.user/19324

Providing a set of packages that is configured/built for a different purpose is different that providing a package with a patch not supported upstream.

Nope, its exactly the same. The xcb cairo backend is part of the cairo source not a patch. Cairo can be configured to take advantage of it without messing with the xlib backend using the --enable-xcb& --disable-xlib_xcb same as pam for example needs the --enable-selinux in order to use selinux https://aur.archlinux.org/packages/selinux-pam/PKGBUILD

Hmm... I thought it was a a patch. Was it declared unstable/unsupported upstream then? There was something weird like that.

Anyway, I still see nothing wrong with creating SELinux packages and having them available in [community], although I would like to see a separate repo at least for the start.

Allan

If thats the case, then I will look into working with Nicky726 (The maintainer of the SELinux packages in the AUR) and find a home for a third party SELinux repo. -Thomas S Hatch

Dne So 9. dubna 2011 00:02:20 Thomas S Hatch napsal(a):

On Fri, Apr 8, 2011 at 3:55 PM, Allan McRae wrote:

...

Hmm... I thought it was a a patch. Was it declared unstable/unsupported upstream then? There was something weird like that.

Anyway, I still see nothing wrong with creating SELinux packages and having them available in [community], although I would like to see a separate repo at least for the start.

Allan

If thats the case, then I will look into working with Nicky726 (The maintainer of the SELinux packages in the AUR) and find a home for a third party SELinux repo.

-Thomas S Hatch

OK, having the packages in binary form is imo better than in the AUR so I dont mind if it is in the [community] or in a separate repo that much. And of course I would be glad for any help from other Archers. Nicky -- Don't it always seem to go That you don't know what you've got Till it's gone (Joni Mitchell)

On Friday, April 08, 2011 05:43:51 Kaiting Chen wrote:

On Fri, Apr 8, 2011 at 3:44 AM, Jelle van der Waa wrote:

...

And on a side note, I don't like archlinux forcing users to use SELinux because users should have a choice to use any MAC software they want. That's why AppArmor /Tomoyo are nicer solutions cause they don't require recompiling of packages -> increasing bugs/problems.

If we compile our packages with SELinux support, does that force users to use SELinux? I was under the impression that these changes would be completely benign on non-SELinux enabled systems. --Kaiting.

No, SELinux-patched tools do not force one to use SELinux. But they can potentially have plenty of bugs introduced by the patches. And there's the fact that SELinux is not necessary and there's not point in putting it in the default Arch install just for the minority who'll actually use it. At most, it should be in [core]. At the very least, [community]. I definitely see no good reason to make it part of the base install, though.

Am Fri, 8 Apr 2011 10:55:16 -0600 schrieb Thomas S Hatch :

Yaro makes many good points, I think that my recommendation would be to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to move to core in the future than do so, otherwise leave it in community.

I'd prefer a separate [selinux] repo. So that people know what they are doing. I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view. This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default. Heiko

On Fri, 2011-04-08 at 16:08 -0400, Jeremiah Dodds wrote:

On Fri, Apr 8, 2011 at 3:29 PM, Heiko Baums wrote:

...

I'd prefer a separate [selinux] repo. So that people know what they are doing.

+1 from a users perspective, the changes in a machine's setup from non-SE to SE are non-trivial to the point that a separate repo would make things much easier and less cluttered/possibly confusing, not to mention reducing noise in results while looking for packages.

I don't know how huge of a frustration that would be for package maintainers.

It's far *more* important to find a dev who is willing to introduce SELinux into archlinux. So for the time being you can create your own 3rd party repo and rebuild [core] with SELinux support. -- Jelle van der Waa

On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear wrote:

On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:

...

Am Fri, 8 Apr 2011 10:55:16 -0600

schrieb Thomas S Hatch :

...

Yaro makes many good points, I think that my recommendation would be to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to move to core in the future than do so, otherwise leave it in community.

I'd prefer a separate [selinux] repo. So that people know what they are doing.

I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view.

This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default.

Heiko

Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux "unofficial" to all the upstream?

SELinux has been in the vanilla kernel for quite some time, say the 2.6.20 ish realm, and the majority of the core utils have had SELinux support built in for years. SELinux is official upstream. But I don't want to argue about this anymore :) I think that we have a solution, I will be putting up an SELinux third party repo for testing in the next month or two and then once we have an assurance that it is working well we look into moving SELinux support into community. This has been a great discussion, and I am excited to get some work done on improving SELinux support on Arch! -Thomas S Hatch

On Sat, Apr 9, 2011 at 11:49 AM, Yaro Kasear wrote:

On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote:

...

On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear wrote:

...

On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:

...

Am Fri, 8 Apr 2011 10:55:16 -0600

schrieb Thomas S Hatch :

...

Yaro makes many good points, I think that my recommendation would

be

...

...

to allow someone to maintain support for SELinux in community. If SELinux support is deemed something that would be a good idea to

move

...

...

to core in the future than do so, otherwise leave it in community.

I'd prefer a separate [selinux] repo. So that people know what they are doing.

I know, packages with SELinux support could and should be named something like selinux-XXX or XXX-selinux, but I think a new repo would be better and more secure - not only from SELinux' view.

This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default.

Heiko

Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux "unofficial" to all the upstream?

SELinux has been in the vanilla kernel for quite some time, say the 2.6.20 ish realm, and the majority of the core utils have had SELinux support built in for years. SELinux is official upstream.

But I don't want to argue about this anymore :) I think that we have a solution, I will be putting up an SELinux third party repo for testing in the next month or two and then once we have an assurance that it is working well we look into moving SELinux support into community.

This has been a great discussion, and I am excited to get some work done on improving SELinux support on Arch!

-Thomas S Hatch

What about the SELinux patches for things other than the kernel? Are those "official" to upstream? This is not for an argument, now I'm just genuinely curious.

The vast majority are, but there are a few places where patches are needed, like in pam and ssh. So yes, there is a "half and half" going on. Basic SELinux support works without patches, but adding some of the more advanced features to some of the core applications require a few patches. -Thomas S Hatch

On Sat, Apr 9, 2011 at 11:56 AM, Yaro Kasear wrote:

...

On Sat, Apr 9, 2011 at 11:49 AM, Yaro Kasear wrote:

...

On Saturday, April 09, 2011 12:01:04 Thomas S Hatch wrote:

...

On Sat, Apr 9, 2011 at 9:18 AM, Yaro Kasear wrote:

...

On Friday, April 08, 2011 14:29:34 Heiko Baums wrote:

...

Am Fri, 8 Apr 2011 10:55:16 -0600

schrieb Thomas S Hatch : > Yaro makes many good points, I think that my recommendation

would

...

...

be

...

> to allow someone to maintain support for SELinux in community. If > SELinux support is deemed something that would be a good idea to

move

...

> to core in the future than do so, otherwise leave it in > community.

I'd prefer a separate [selinux] repo. So that people know what

On Saturday, April 09, 2011 12:54:23 Thomas S Hatch wrote: they

...

...

are

...

...

...

doing.

I know, packages with SELinux support could and should be

named

...

...

...

...

something like selinux-XXX or XXX-selinux, but I think a new repo

would

...

...

...

be better and more secure - not only from SELinux' view.

This way SELinux users can just add [selinux] to pacman.conf above [core]. For the other users it should be deactivated by default.

Heiko

Here's another question. Isn't it general packaging policy to not fully support packages that have unofficial upstream patches applied? Isn't SELinux "unofficial" to all the upstream?

SELinux has been in the vanilla kernel for quite some time, say the

2.6.20

...

ish realm, and the majority of the core utils have had SELinux support built in for years. SELinux is official upstream.

But I don't want to argue about this anymore :) I think that we have a solution, I will be putting up an SELinux third party repo for testing in the next month or two and then once we have an assurance that it is

working

...

well we look into moving SELinux support into community.

This has been a great discussion, and I am excited to get some work done

on

...

improving SELinux support on Arch!

-Thomas S Hatch

What about the SELinux patches for things other than the kernel? Are those "official" to upstream? This is not for an argument, now I'm just genuinely curious.

The vast majority are, but there are a few places where patches are needed, like in pam and ssh.

So yes, there is a "half and half" going on. Basic SELinux support works without patches, but adding some of the more advanced features to some of the core applications require a few patches.

-Thomas S Hatch

Great! Well, I look forward to maybe testing out your repository. Maybe I'll actually get SELinux working.

Thats good to hear! SELinux really is amazing stuff :)

Yaro Kasear (2011-04-08 11:32):

...

So in general what is the benefits / costs for SELinux?

Benefits: Probably the most effective MAC for Linux. Once it runs it's arguably not too hard to allow/deny certain access due to some third party tools simplifying things a bit. You can't deny the NSA-grade security it brings which the U.S. military requires AT MINIMUM for critical infrastructure.

Costs: Painfully overcomplicated. Painfully difficult to set up and configure. Requires well over half the core system to be patched to support it, potentially introducing bugs. There was a mondo security vulnerability a few years back that could actually use SELinux to grant unrestricted access to the system. Only a few filesystems actually have support for its attributes. Even its policies have to be recompiled if they have to change. Way too much can easily go wrong during set up without you having even the slightest clue how to figure out exactly what DID, turning "repairs" for SELinux into an almost weekend-long Google crawl.

Benefits from a base Arch perspective: I can't honestly see how this would benefit Arch from putting it in the base group.

Costs from a base Arch perspective: Big one being that it's entirely unnecessary, and base is meant to have ONLY what's needed to have a more or less FUNCTIONAL Linux system. Being secure is not a requirement of being functional. Other cost being that it would introduce an entirely new layer of configuration we don't need at install time, and would also guarantee that Arch would only be able to "officially" support the few filesystems that actually support SELinux's labelling.

To sum up, it's GREAT when you actually NEED the security benefits it can bring, otherwise, it's better to seek out AppArmor (Which I believe is actually defunct.) or Tomoyo (Which I can never find any information on.), or just leave MAC off altogether if you're not doing anything altogether mission or security critical. Home desktop users would probably be better off ignoring MAC.

An interesting read, thanks. -- -- Rogutės Sparnuotos

On Thursday 07 April 2011 00:25:42 Thomas S Hatch wrote:

As for adding SELinux support in base but keeping it turned off by default, +1

+1 -- Divan Santana

On 04/06/2011 04:43 PM, Sander Jansen wrote:

This seems to be a monthly recurring discussion. How about not providing any default, just put all the different cron(s) in extra? I think eventually systemd will provide a cron-like service :)

Cheers,

Sander

Oh no, every distro needs a default cron -- matters not what it is called, it is fundamental to many server packages that require some type of cron functionality. It seems that keeping a default cron makes sense. To me, I don't need any of the advanced features, but I do need something to sweep for new addresses, faxes, etc.. From a user standpoint (not that Arch is an entry level distro by any stretch), but nevertheless, the new user working with Arch will be far better served by having a basic cron in place rather than not having one and experiencing dependency questions later in the install and be left scratching his head. Upstream stability makes sense. If redhat is behind cronie, then that seems like the logical choice. Otherwise, we are bound to repeat this discussion 12 months from now when fcron or dcron has problems that are not being fixed. -- David C. Rankin, J.D.,P.E.

On 04/06/2011 10:34 PM, Heiko Baums wrote:

...

Upstream stability makes sense. If redhat is behind cronie, then that

...

seems like the logical choice. Why is this logical? Is it the developer what makes a software good or is it the features and the stability? If Redhat's cronie has less features than fcron then fcron is the logical choice, of course.

Heiko, You are correct. The long term stability was just my thought. Like I said earlier in my message -- It doesn't matter to me which cron we have -- as long as we have one that works :) I have no say in the matter, so I will, of course, defer to whatever decision you guys reach. I just want to make sure we have a cron by default :) -- David C. Rankin, J.D.,P.E.

On 21.04.2011 08:32, Kaiting Chen wrote:

On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin < drankinatty@suddenlinkmail.com> wrote:

...

On 04/06/2011 10:34 PM, Heiko Baums wrote:

...

Upstream stability makes sense. If redhat is behind cronie, then that

...

...

seems like the logical choice. Why is this logical? Is it the developer what makes a software good or is it the features and the stability? If Redhat's cronie has less features than fcron then fcron is the logical choice, of course.

You are correct. The long term stability was just my thought. Like I said earlier in my message -- It doesn't matter to me which cron we have -- as long as we have one that works :) I have no say in the matter, so I will, of course, defer to whatever decision you guys reach. I just want to make sure we have a cron by default :)

So what's the status here? I pulled cronie into [community-testing] a couple of days ago and will probably merge it into [community] soon. So that's the one I vote.

But regardless of which one we choose in my opinion the sooner we get rid of dcron the better. --Kaiting.

I second this suggestion. cronie upstream isn't dead at all. cronie is a drop-in unlike fcron which was favored earlier. Kaiting said he would even be willing to become a developer to maintain this in [core] himself in case no other developer was interested. Is there anything that would keep us from making it default and also replace dcron? -- Sven-Hendrik

Am Thu, 21 Apr 2011 13:18:33 +0200 schrieb Heiko Baums :

I can be wrong, but I really have the feeling that switching the default cron daemon to cronie will be a big mistake.

And, btw., what's about the licenses? fcron is GPL, cronie has a custom license called ISC. I don't know this ISC but this should be checked before. Heiko

On 04/21/2011 02:18 PM, Heiko Baums wrote:

Am Thu, 21 Apr 2011 08:48:04 +0200 schrieb Sven-Hendrik Haase:

...

I second this suggestion. cronie upstream isn't dead at all. cronie is a drop-in unlike fcron which was favored earlier.

Is it such a drop-in like the new dcron when dcron upstream was adopted by this Arch user?

Better look at the features and the use cases (don't only think of some 24/7 servers, but also think of the desktop users) and not at some small differences in the crontab syntax. It's definitely not such a big work to re-adjust a few crontab entries if this is necessary at all. And this work has to be done only once and can probably be done with sed.

i think you are not understanding the process. if cronie is moved in core, it won't have a replaces=dcron. Only new installations will get cronie by default instead of dcron. -- Ionuț

On Thu, Apr 21, 2011 at 9:33 PM, Ionut Biru wrote:

Only new installations will get cronie by default instead of dcron.

+1 from me for replacing dcron like this, but with fcron, not cronie.

On 04/22/2011 12:11 AM, Grigorios Bouzakis wrote:

Ionut Biru wrote:

...

On 04/21/2011 02:18 PM, Heiko Baums wrote:

...

Am Thu, 21 Apr 2011 08:48:04 +0200 schrieb Sven-Hendrik Haase:

...

I second this suggestion. cronie upstream isn't dead at all. cronie is a drop-in unlike fcron which was favored earlier.

Is it such a drop-in like the new dcron when dcron upstream was adopted by this Arch user?

Better look at the features and the use cases (don't only think of some 24/7 servers, but also think of the desktop users) and not at some small differences in the crontab syntax. It's definitely not such a big work to re-adjust a few crontab entries if this is necessary at all. And this work has to be done only once and can probably be done with sed.

i think you are not understanding the process.

if cronie is moved in core, it won't have a replaces=dcron. Only new installations will get cronie by default instead of dcron.

How is that possible? Are you saying that the broken dcron will stay in core and there will two packages for cron? Otherwise i dont understand how it wont be replaced (for all users).

if this will happen, the steps are very simple 1) remove dcron from core 2) add cronie/fcron to core in base group and depending on the package, it might have conflicts=dcron but not replaces this way the existent systems will still have a "working" cron and new installations will have the new cron -- Ionuț

On Apr 21, 2011, at 17:30, Grigorios Bouzakis wrote:

Ionut Biru wrote:

...

On 04/22/2011 12:11 AM, Grigorios Bouzakis wrote:

...

Ionut Biru wrote:

...

On 04/21/2011 02:18 PM, Heiko Baums wrote:

...

Am Thu, 21 Apr 2011 08:48:04 +0200 schrieb Sven-Hendrik Haase:

...

I second this suggestion. cronie upstream isn't dead at all. cronie is a drop-in unlike fcron which was favored earlier.

Is it such a drop-in like the new dcron when dcron upstream was adopted by this Arch user?

Better look at the features and the use cases (don't only think of some 24/7 servers, but also think of the desktop users) and not at some small differences in the crontab syntax. It's definitely not such a big work to re-adjust a few crontab entries if this is necessary at all. And this work has to be done only once and can probably be done with sed.

i think you are not understanding the process.

if cronie is moved in core, it won't have a replaces=dcron. Only new installations will get cronie by default instead of dcron.

How is that possible? Are you saying that the broken dcron will stay in core and there will two packages for cron? Otherwise i dont understand how it wont be replaced (for all users).

if this will happen, the steps are very simple 1) remove dcron from core 2) add cronie/fcron to core in base group and depending on the package, it might have conflicts=dcron but not replaces

this way the existent systems will still have a "working" cron and new installations will have the new cron

Has that ever happened before? That means the existing systems will have a package from base thats not supported by the Arch developers. But since its not replaced, it would make it an infinite part of Arch so it should also be supported. Plus, the 2010.05 ISOs will still (try to) install it, but it wont be there, and there wont be an upgrade path either. Anyway, first time i've heard about such a plan. It makes absolutely no sense to me. I seriously doubt its gonna work. But good luck.

---- Greg

Things have got to be deprecated eventually. Why can't we keep dcron in [core] for a while longer? And remove it when any install media that requires it becomes unsupported? Kiwis and Limes: http://kaitocracy.blogspot.com/

On 22/04/11 00:30, Grigorios Bouzakis wrote:

Ionut Biru wrote:

...

if this will happen, the steps are very simple 1) remove dcron from core 2) add cronie/fcron to core in base group and depending on the package, it might have conflicts=dcron but not replaces

this way the existent systems will still have a "working" cron and new installations will have the new cron

Has that ever happened before? That means the existing systems will have a package from base thats not supported by the Arch developers.

The package will no longer be in the 'base' group, and most likely end up in the AUR. Therefore, it will not be a supported package, and the output of `pacman -Qm' will reflect that.

But since its not replaced, it would make it an infinite part of Arch so it should also be supported.

As I mention above, my understanding is that dcron will be moved to the AUR.

Plus, the 2010.05 ISOs will still (try to) install it, but it wont be there, and there wont be an upgrade path either.

In offline installations, the package will exist on the installation media. On netinstalls, the new cron daemon will get installed to the target system instead.

Anyway, first time i've heard about such a plan. It makes absolutely no sense to me. I seriously doubt its gonna work. But good luck.

On 22/04/11 10:18, Grigorios Bouzakis wrote:

An unsupported package installed by the official installation media. Like i said it doesnt make sense to me. But you got a plan. So just go with it. And hopefully there'll never be another debate about cron around here in the future.

There is actually a plan? I though there was just a bunch of talk so far...

On Thursday, April 21, 2011 01:48:04 Sven-Hendrik Haase wrote:

On 21.04.2011 08:32, Kaiting Chen wrote:

...

On Fri, Apr 8, 2011 at 11:32 AM, David C. Rankin <

drankinatty@suddenlinkmail.com> wrote:

...

On 04/06/2011 10:34 PM, Heiko Baums wrote:

...

Upstream stability makes sense. If redhat is behind cronie, then that

...

...

seems like the logical choice.

Why is this logical? Is it the developer what makes a software good or is it the features and the stability? If Redhat's cronie has less features than fcron then fcron is the logical choice, of course.

You are correct. The long term stability was just my thought. Like I said

earlier in my message -- It doesn't matter to me which cron we have -- as long as we have one that works :) I have no say in the matter, so I will, of course, defer to whatever decision you guys reach. I just want to make sure we have a cron by default :)

So what's the status here? I pulled cronie into [community-testing] a couple of days ago and will probably merge it into [community] soon. So that's the one I vote.

But regardless of which one we choose in my opinion the sooner we get rid of dcron the better. --Kaiting.

I second this suggestion. cronie upstream isn't dead at all. cronie is a drop-in unlike fcron which was favored earlier. Kaiting said he would even be willing to become a developer to maintain this in [core] himself in case no other developer was interested.

Is there anything that would keep us from making it default and also replace dcron?

-- Sven-Hendrik

I'm still trying to understand WHY we suddenly feel the need to replace dcron when its not even broken. Replacing packages with other packages purely because they're new is something Fedora and Ubuntu would do, I though Arch wasn't about arbitrarily replacing its defaults but using what was simple and what works. Can someone explain to me why we think we need a new crond?

Yaro Kasear wrote:

I'm still trying to understand WHY we suddenly feel the need to replace dcron when its not even broken. Replacing packages with other packages purely because they're new is something Fedora and Ubuntu would do, I though Arch wasn't about arbitrarily replacing its defaults but using what was simple and what works.

Can someone explain to me why we think we need a new crond?

Because of these: https://bugs.archlinux.org/index.php?string=dcron&project=1 Mostly https://bugs.archlinux.org/task/18681 ---- Greg

Dimitrios Apostolou [2011.04.22 0126 +0300]:

On Thu, 21 Apr 2011, Grigorios Bouzakis wrote:

...

Because of these: https://bugs.archlinux.org/index.php?string=dcron&project=1 Mostly https://bugs.archlinux.org/task/18681

The "run many times per day" bug hasn't bitten me since months ago. And I used to see it really often. Maybe it is fixed?

Nope. Just saw it yesterday. N.

Kaiting Chen wrote:

So what's the status here? I pulled cronie into [community-testing] a couple of days ago and will probably merge it into [community] soon. So that's the one I vote.

But regardless of which one we choose in my opinion the sooner we get rid of dcron the better. --Kaiting.

You forgot to remove it from the AUR though: https://aur.archlinux.org/packages.php?ID=37260 No matter which cron implemention replaces dcron that means that most likely dcron will be dropped to the AUR, so it would be nice having 2 implementions in binary form, despite the fact that cronie only has 4 votes. Has anyone actually tested it as a dcron replacement on Arch, now that its built with anacron support? ---- Greg

On Thu 21 Apr 2011 10:46 +0200, Lukas Fleischer wrote:

On Thu, Apr 21, 2011 at 02:32:42AM -0400, Kaiting Chen wrote:

...

So what's the status here? I pulled cronie into [community-testing] a couple of days ago and will probably merge it into [community] soon. So that's the one I vote.

But regardless of which one we choose in my opinion the sooner we get rid of dcron the better. --Kaiting.

I don't want to be pedantic, but what's the point of that? Moving arbitrary cron daemons that no one uses to [community] is nonsense (according to the TU guidelines, you shouldn't even have moved it without prior discussion and consensus on aur-general at all - but as I said before, I don't want to be pedantic here...)

This is supposed to be a rule, not just a guideline. The rule doesn't exactly apply to [community-testing]. Perhaps it should? https://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines#Rules_for_P...

Am Wed, 6 Apr 2011 22:03:23 -0600 schrieb Thomas S Hatch :

I would say that we should consider compatibility with vixie cron syntax - this is and has been the expected syntax for the default cron daemon for a LONG time and avoids hindering Arch Linux adoption.

Why do you need vixie cron syntax? Can't you migrate once to a new syntax? Btw., most of fcron's syntax is the same as the syntax of every cron daemon. You can easily take your previous crontabs. You probably have only to do some changes which could most likely be done by sed. In first place you need stability, reliability and useful features. And this is given by fcron. And don't tell me anything about compatibility. I would consider this argument if fcron was a new cron daemon and if it was totally incompatible. Fcron is known since years and it's known to be stable and reliable, while cronie seems to be pretty new. There are absolutely no informations about cronie's features, no documentations, no feature comparisons to other cron daemons, etc. on upstream's website. And it's still in AUR and has only 3 votes there.

I spent quite some time as a trainer for Red Hat and taught classes on SELinux.

Is this why you want to push cronie so heavily? Heiko

Am Thu, 7 Apr 2011 21:53:58 +0200 schrieb Marek Otahal :

Sorry to sound rude, but Heiko, it's you who is pushing fcron so unhealthily heavily. I wouldn't have no opinion on the two crons but after reading the discussion I'd stick to cronie. Just my 2c.

Well, on the one hand yes, on the other hand no. But let's try to get objective again. dcron: Known to be buggy. fcron: Known to work reliably since years, works for 24/7 servers as well as for home desktop computers, features are known and well documented on upstream's website. cronie: Quite new, not known well, if at all, and at least I can't find neither a feature list nor a documentation on upstream's website. Doesn't seem to work for home desktop computers, at least not as easy as fcron (separate crontab and anacrontab), from what I read in this thread and from the very few descriptions on upstream's website. A feature comparison between all the cron daemons, at least between fcron and cronie would be nice. That are my concerns. Again, it's just a question about the default cron daemon, not the one and only in the repos. I wouldn't care, btw., if cronie would go into the repos, too, even if it has only 3 votes in AUR, yet. On the other hand this issue could be solved in a different way without any further discussions. There's a need for installing one cron daemon, but no need for a default cron daemon. It's pretty the same issue as with the bootloaders. There's no default bootloader anymore and currently it doesn't make sense anymore to define one bootloader as the default, because they all have different features and it depends on the system configuration which bootloader is the best. In the development isos AIF asks the user to choose one of currently two bootloaders (grub and syslinux), more (grub2 and lilo) could or should be added. And this bootloader is automatically chosen by AIF in the package selection. The same could be made for the cron daemons. Put every cron daemon into [core] and let the user choose his preferred cron daemon during installation. But if this shouldn't be done, and if there shall be a default cron daemon it must be a daemon which fulfills every use case and not only the needs of servers which are running 24/7. Heiko

On Thu, 7 Apr 2011 23:16:46 +0200 Heiko Baums wrote:

On the other hand this issue could be solved in a different way without any further discussions. There's a need for installing one cron daemon, but no need for a default cron daemon. It's pretty the same issue as with the bootloaders. There's no default bootloader anymore and currently it doesn't make sense anymore to define one bootloader as the default, because they all have different features and it depends on the system configuration which bootloader is the best. In the development isos AIF asks the user to choose one of currently two bootloaders (grub and syslinux), more (grub2 and lilo) could or should be added. And this bootloader is automatically chosen by AIF in the package selection. The same could be made for the cron daemons. Put every cron daemon into [core] and let the user choose his preferred cron daemon during installation.

Can we do the same thing for cron daemons? Don't other packages contain crontab files, or something like that? I.e. is it possible to just swap crons and keep a (stock) Arch system working? If so, it *could* be possible to do what you suggest, but don't forget, Arch primary objective is simplicity, not choice. If there is a cron daemon that does what we need, we should just make it the default, period. Dieter

On Fri, 8 Apr 2011 06:45:29 -0400 Kaiting Chen wrote:

On Fri, Apr 8, 2011 at 3:33 AM, Dieter Plaetinck wrote:

...

...

On the other hand this issue could be solved in a different way without any further discussions. There's a need for installing one cron daemon, but no need for a default cron daemon. It's pretty the same issue as with the bootloaders. There's no default bootloader anymore and currently it doesn't make sense anymore to define one bootloader as the default, because they all have different features and it depends on the system configuration which bootloader is the best. In the development isos AIF asks the user to choose one of currently two bootloaders (grub and syslinux), more (grub2 and lilo) could or should be added. And this bootloader is automatically chosen by AIF in the package selection. The same could be made for the cron daemons. Put every cron daemon into [core] and let the user choose his preferred cron daemon during installation.

Can we do the same thing for cron daemons? Don't other packages contain crontab files, or something like that? I.e. is it possible to just swap crons and keep a (stock) Arch system working? If so, it *could* be possible to do what you suggest, but don't forget, Arch primary objective is simplicity, not choice.

If there is a cron daemon that does what we need, we should just make it the default, period.

I think we're talking about what the default daemon should be, as in the one that comes installed with the system on a clean install.

Maybe you should actually read the text I quoted. Just a thought. Dieter

On Fri, Apr 8, 2011 at 1:33 AM, Dieter Plaetinck wrote:

On Thu, 7 Apr 2011 23:16:46 +0200 Heiko Baums wrote:

...

On the other hand this issue could be solved in a different way without any further discussions. There's a need for installing one cron daemon, but no need for a default cron daemon. It's pretty the same issue as with the bootloaders. There's no default bootloader anymore and currently it doesn't make sense anymore to define one bootloader as the default, because they all have different features and it depends on the system configuration which bootloader is the best. In the development isos AIF asks the user to choose one of currently two bootloaders (grub and syslinux), more (grub2 and lilo) could or should be added. And this bootloader is automatically chosen by AIF in the package selection. The same could be made for the cron daemons. Put every cron daemon into [core] and let the user choose his preferred cron daemon during installation.

Can we do the same thing for cron daemons? Don't other packages contain crontab files, or something like that? I.e. is it possible to just swap crons and keep a (stock) Arch system working? If so, it *could* be possible to do what you suggest, but don't forget, Arch primary objective is simplicity, not choice.

If there is a cron daemon that does what we need, we should just make it the default, period.

Dieter

Yes, If we start making the user pick all of these things in the installer than we end up with a bit of a can of worms, we would end up with making more installer level choices, like system logger, systemd and many other cumbersome questions that I don't think belong in the installer. My vote on this concept is simplicity. Just provide a default.

On Fri, Apr 8, 2011 at 5:42 AM, Allan McRae wrote:

On 08/04/11 07:16, Heiko Baums wrote:

...

But let's try to get objective again.

No need. A new cron for [core] has to pass only one condition... :)

1) a developer is willing to maintain it.

So far that seems to be Thomas and fcron.

Anyway, I recall mention in our bug report of a patch being submitted upstream that fixed the dcron timing issue. Would this be "solved" - at least in the short term - if we got a copy of that patch and fixed dcron?

Allan

My only concern with the continued use of dcron is the fact that this bug took well over a year to be fixed, and we don't know if it is fixed with the patch. As for finding a maintainer, I hope that would not be too difficult, cronie and fcron are not complex packages.

On 08.04.2011 00:15, Kaiting Chen wrote:

On Thu, Apr 7, 2011 at 6:32 AM, Heiko Baums wrote:

...

Why do you need vixie cron syntax? Can't you migrate once to a new syntax? Btw., most of fcron's syntax is the same as the syntax of every cron daemon. You can easily take your previous crontabs. You probably have only to do some changes which could most likely be done by sed.

In first place you need stability, reliability and useful features. And this is given by fcron. And don't tell me anything about compatibility. I would consider this argument if fcron was a new cron daemon and if it was totally incompatible.

Fcron is known since years and it's known to be stable and reliable, while cronie seems to be pretty new. There are absolutely no informations about cronie's features, no documentations, no feature comparisons to other cron daemons, etc. on upstream's website. And it's still in AUR and has only 3 votes there.

The thing is that cronie is forked from vixie-cron which is much older than fcron. And I would venture to say that vixie-cron or some derivative is the default crond for the vast majority of distributions out there. --Kaiting.

cronie also appears to be the nicest migration choice for users who are not used to fcron. It seems to support anachron features, cron.d, daily/weekly/etc, is able to actually keep time and works just like expected whereas fcron has fcrontab with a slightly different syntax. We could actually make cronie replace dcron. fcron would be nice but it is not a drop in like cronie. What do you say? If you agree, I shall make (or somebody who steps up) a plan to the replacement and that's that. -- Sven-Hendrik

On Fri, 08 Apr 2011 00:34:42 +0200 Sven-Hendrik Haase wrote:

cronie also appears to be the nicest migration choice for users who are not used to fcron. It seems to support anachron features, cron.d, daily/weekly/etc, is able to actually keep time and works just like expected whereas fcron has fcrontab with a slightly different syntax. We could actually make cronie replace dcron.

I agree with this instead i'm a fcron user. But because it is say so much often, is there really anyone who have something in /etc/cron.d? See you, Attila

Am Wed, 6 Apr 2011 15:30:26 -0600 schrieb Thomas S Hatch :

dcron and fcron are not under active development,

fcron is under active development. It's just feature complete and therefore not developed anymore, but bugs are still fixed if they occur. So don't mix it up with a "dead" project. I guess dcron most likely can be assumed to be dead.

cronie is cronie is small - 0.20MB installed cronie is developed by Red Hat - it is not going anywhere and we have a guaranteed upgrade path

What does that mean? Look at the size and you can see that it can't be as feature rich as fcron.

As far as I can tell cronie has no deps beyond glibc and pam cronie has /etc/cron.d support cronie has configurable anacron support via an anacrontab config file

But you need a separate anacrontab. So it's the same as having installed a cron and a separate anacron. With fcron you just need one cron daemon which has anacron features integrated. This means you don't need to have a separate anacrontab. So you don't need to decide if a task needs to be run by cron or by anacron. You just can add every task into one single crontab resp. fcrontab and just put &bootrun at the beginning of the line as Thomas already explained. This means that this task is run at the desired time if the system is up and the cron is running, and if not then this task is automagically run as soon as fcron is started the next time and that very reliably. So this is much easier and much more flexible than a separate cron/anacron solution. That's why fcron is still the best. And neither /etc/cron.d support nor the fact that cronie is developed by Redhat is an argument in my opinion. /etc/cron.d can easily be moved to /etc/cron.{hourly,daily,weekly,monthly} or to fcrontab. So /etc/cron.d is not needed. So this is not an argument in my opinion. I guess this transition takes about 5 to 10 minutes maximum if at all.

cronie extends the original vixie cron package so the syntax, core feature set, etc are stable cronie implements advanced security hooks as well and can integrate with SELINUX (I am saving the "include SELINUX support in base for a latter date")

Well, is SELinux really a default? Does SELinux run on Arch at all? Is this really an argument regarding the decision which cron shall be the default. As said before, the question is not having removed every other cron from the repos. The question is about the default cron. Most people who are regularly discussing this topic here on the mailing list tend to fcron for a lot of good reasons. And the few people who really need /etc/cron.d or SELinux support - I'm not sure if fcron is not able to run with SELinux - can easily install another cron daemon. dcron was just kept as the default, because the formerly dead project was adopted by an Arch user who said, that he wants do keep developing it and to fixing the bugs. As already said the most important bug wasn't fixed in a year. And in the meantime it was nothing heard from this Arch user anymore. So it can be assumed dead in my opinion.

At the outset I think that cronie looks to be the most viable option, but merits further investigation.

I definitely still vote for fcron for reason which have been explained many times here on the list - not only by me. Alternatively it can be done as it is already done with the boot manager in AIF that every cron is listed in the package list so that the user can decide which one to install or AIF brings a separate dialog which asks the user which cron daemon to install with a small or a bit more detailed description of the daemons. Heiko

Am Wed, 6 Apr 2011 16:57:58 -0600 schrieb Thomas S Hatch :

All I want is a good decision to be made and have a crond that is not buggy. Therefore I think that it is foolish not to present the available options in an accurate light.

fcron is absolutely not buggy as far as I can tell. I'm using it since years now and it always did what it should do. I tried dcron when it was adopted by this Arch user, but switched back to fcron pretty soon, because dcron was indeed not reliable. cronie is no option for me because of the lack of integrated anacron features. But all those arguments including not having a buggy crond have been discussed many times before by a lot of users, TUs and devs. But then dcron's new developer said that he wanted to fix those bugs and so dcron was kept as the default. This was the only reason as far as I recall. I understand Sven-Hendriks e-mail just as a reminder of this fact and that dcron's upstream still hasn't fixed the issue. I don't think that Sven-Hendrik wanted to start a new discussion about that even if it started again nevertheless. Heiko

On Wed, Apr 6, 2011 at 7:13 PM, Thomas S Hatch wrote:

cronie has anacron features and I think is a good option.

Unfortunately cronie isn't even in [community] yet. I've been trying to get it there for a while. Also, in what way is another crond + anacron inferior to fcron? --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

On 06/04/11, Thomas S Hatch wrote: | Right, both are viable choices, btw I will be migrating my datacenters away | from dcron in the near future and doing a series of tests on cronie and | fcron, I will post my findings to the list. Here's one reason I stopped using fcron and went to cronie: | 2.2.12. How can I emulate a Vixie cron @reboot entry? | | You should use a line similar to the following one: | | @volatile,first(1) BIG-period /your/command | | This will run /your/command one minute after every reboot. Bizarre. -- Simon Perry (aka Pezz)

On 07/04/11, Heiko Baums wrote: | And this doesn't work in dcron, at least not as reliable as | the equivalent &bootrun of fcron. And that's one point why fcron is | much better than dcron. Are you sure that this is working in cronie? If | yes, are you sure that this works in cronie as reliable as in fcron? It's been a while, but from what I remember bootrun is not equivalent to @reboot. The only way to get @reboot behaviour was using that weird volatile method. @reboot works perfectly in cronie. -- Simon Perry (aka Pezz)

On Thu, Apr 7, 2011 at 2:16 AM, Thomas Bächler wrote:

Am 07.04.2011 04:30, schrieb Thomas S Hatch:

...

Right, both are viable choices, btw I will be migrating my datacenters away from dcron in the near future and doing a series of tests on cronie and fcron, I will post my findings to the list.

I think that will be more valuable than any continuation of this discussion, and it would be very much appreciated.

Right now, cronie looks like a better candidate, although I am still a fan of fcron.

Thanks Thomas, as you know I am very busy, but I will post my findings when I am done. As always, I hope I can help Arch get better!

On Thu, 7 Apr 2011 00:29:36 +0200 Heiko Baums wrote:

...

cronie extends the original vixie cron package so the syntax, core feature set, etc are stable cronie implements advanced security hooks as well and can integrate with SELINUX (I am saving the "include SELINUX support in base for a latter date")

Well, is SELinux really a default? Does SELinux run on Arch at all? Is this really an argument regarding the decision which cron shall be the default.

Only for the stats, this is shown from the fcron configure: --with-selinux=yes|no Use (or not) SELinux (default: yes). Okay, now only the size and the "/etc/cron.d" support is on the list. :) See you, Attila

On Wed, Apr 6, 2011 at 10:19 AM, Corey Johns wrote:

fcron is pretty much the de facto cron of choice for anyone needing a cron without special case needs. A nice general cron program.

I do wonder about the bureaucratic processes in place to facillitate such a switch, though.

The thing to do is contact the package maintainer and present the idea, and ask what needs to be done to make the change. I for one +1 to the move, I like dcron, but when it takes this long to fix bugs upstream we need to unfortunately consider alternatives.