| Summary: | sys-process/fcron: triple divergence regarding the location of fcron.conf | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Benjamin Lamowski <ben-bugs> |
| Component: | [OLD] Core system | Assignee: | Wolfram Schlich (RETIRED) <wschlich> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | ben-bugs, cron-bugs+disabled, flameeyes, kamil, pacho |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Benjamin Lamowski
2008-04-06 01:06:23 UTC
(In reply to comment #0) > First of all, the manpages state the location of the fcron configuration files > as "/usr/local/etc", that's a trivial issue. Thanks, I'll fix that. > Second, in my opinion fcron.allow and fcron.deny should be left out since > gentoo has the "cron"-group and fcron.conf should be placed it its standard > location in /etc. Whoever wishes to use this feature needs to write his own > files anyway so why have them in the first place? > I know this issue is a matter of taste but IMHO gentoo should be clean & > simple. /etc/fcron/fcron.conf: It has been that way on Gentoo for a long time and I'm not going to bother users with a completely useless change they'd have to take care of on an update. /etc/fcron/fcron.{allow,deny}: fcron has a different security model compared to vixie-cron. If you don't like it then don't use it or talk to upstream. > Third, please do do not hard-code the /etc/fcron/-directory. It is already > changed in the initscript and I don't want to feel like I'm running SuSE. Hard-code? Where? You should actually *mention* what you are talking about. Thanks. > By the way: Why does the standard initscript need support for running several > fcrons in parallel but all as root? /etc/init.d/ scripts are for system (not user) instances of services/daemons and those are usually run as root. If you don't need multiple instances of fcron then just don't use that feature. > It has been that way on Gentoo for a long time and I'm not > going to bother users with a completely useless change they'd > have to take care of on an update. I'm aware that reverting this non-standard location is probably not worth the trouble. As I said, this is a matter of taste. > Hard-code? Where? You should actually *mention* what you are talking about. > Thanks See original description. Since --sysconfdir=/etc/fcron is used as option to ./configure, one ends up having /etc/fcron/ compiled in as standard location for fcron.conf and friends while the documentation states otherwise. Although I'd like it better to be /etc/fcron.{conf|allow|deny}, I fear it's easier and cleaner to patch the manpages than to introduce two different ETC variables for compiling and installing. > If you don't need multiple instances of fcron then just don't use that > feature. As far as I can see, this is only useful for a weird chroot-setup and shouldn't be in a default initscript (there's a reason why gentoo boots so slow...) but I know that you won't remove it after all the time. (In reply to comment #2) > > Hard-code? Where? You should actually *mention* what you are talking about. > > Thanks > > See original description. Since --sysconfdir=/etc/fcron is used as option to > ./configure, one ends up having /etc/fcron/ compiled in as standard location > for fcron.conf and friends while the documentation states otherwise. As I said, I'll fix the *manpages*, as they are the part which is wrong, not the rest. > Although I'd like it better to be /etc/fcron.{conf|allow|deny}, I fear it's > easier and cleaner to patch the manpages than to introduce two different ETC > variables for compiling and installing. Whatever... > > If you don't need multiple instances of fcron then just don't use that > > feature. > > As far as I can see, this is only useful for a weird chroot-setup and > shouldn't be in a default initscript No, there are other reasons for which one may want to be able to use different instances (think of different softlevels). > (there's a reason why gentoo boots > so slow...) but I know that you won't remove it after all the time. You want to tell me that multiple instances support of /etc/init.d/fcron slows down the boot process due to 2x grep+sed? Come on! > No, there are other reasons for which one may want to be able to use > different instances (think of different softlevels). You're right, this laptop runlevel thing comes to mind... > You want to tell me that multiple instances support of /etc/init.d/fcron > slows down the boot process due to 2x grep+sed? Come on! No, it's just a small part of the huge mess of sys-v-init shellcode. Gentoo init is a slow by design and it gets even worse because everyone checks for every possible error. While this has some benefits for beginners, I personally like minit[1] much better, it is magnitudes faster and on a server you can't see pretty output anyway. But that's not the subject now, thank you for your time. [1] http://www.fefe.de/minit/ *** Bug 264201 has been marked as a duplicate of this bug. *** Documentation now is updated for the correct installation paths. |
