1:59 p.m.
Hello,
I think that fcron should be the default scheduler in fedora.
fcron, with the service fcron_watch_config activated should now be
100% compatible with vixie-cron (cronie). The fcron_watch_config stuff
is a bit convoluted (3 scripts and one C program...) but should work.
The advantages over cronie are the following:
* it also does what anacron does
* it has more features
* instead of waking up every minutes to look at config files, like
cronie do, it uses inotify to watch the config. This should lead to
less awaking and certainly be interesting for power saving in some
situations
I won't push this more, somebody else has to volunteer to make this
happen. I think it could be done in F11 and it should be a feature.
--
Pat
2:05 p.m.
On Fri, 2008-12-05 at 20:59 +0100, Patrice Dumas wrote:
I won't push this more, somebody else has to volunteer to make
this
happen. I think it could be done in F11 and it should be a feature.
What are the deplists comparatively?
Has fcron had a security audit recently?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:10 p.m.
Jesse Keating (jkeating(a)redhat.com) said:
On Fri, 2008-12-05 at 20:59 +0100, Patrice Dumas wrote:
> I won't push this more, somebody else has to volunteer to make this
> happen. I think it could be done in F11 and it should be a feature.
What are the deplists comparatively?
Shorter than cronie, actually. It doesn't rely on the audit libs.
(That being said, the audit folks may want to look into that, as they
like to audit things.)
Has fcron had a security audit recently?
Not sure. It did support SELinux before vixie-cron and derivatives did.
Bill
2:16 p.m.
On Fri, Dec 05, 2008 at 12:05:30PM -0800, Jesse Keating wrote:
On Fri, 2008-12-05 at 20:59 +0100, Patrice Dumas wrote:
> I won't push this more, somebody else has to volunteer to make this
> happen. I think it could be done in F11 and it should be a feature.
What are the deplists comparatively?
fcron has additionally
vim-minimal
But I think that this is also a cronie dep that is missing (I think
/usr/bin/crontab defaults to use it).
fcron also uses /usr/bin/setsid. I don't think this is annoying, and to
avoid it trivial C code could be used.
Has fcron had a security audit recently?
What exactly do you mean here? Are you referring to an audit done by
some specific people, or using some methodology? Or a security audit in
a vague sense?
--
Pat
3:04 p.m.
On Fri, 2008-12-05 at 21:16 +0100, Patrice Dumas wrote:
What exactly do you mean here? Are you referring to an audit done by
some specific people, or using some methodology? Or a security audit in
a vague sense?
Any of the above really.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:18 a.m.
Patrice Dumas wrote:
On Fri, Dec 05, 2008 at 12:05:30PM -0800, Jesse Keating wrote:
> On Fri, 2008-12-05 at 20:59 +0100, Patrice Dumas wrote:
>> I won't push this more, somebody else has to volunteer to make this
>> happen. I think it could be done in F11 and it should be a feature.
> What are the deplists comparatively?
fcron has additionally
vim-minimal
But I think that this is also a cronie dep that is missing (I think
/usr/bin/crontab defaults to use it).
cronie isn't missing vim. It uses default
text editor.
fcron also uses /usr/bin/setsid. I don't think this is annoying, and to
avoid it trivial C code could be used.
> Has fcron had a security audit recently?
What exactly do you mean here? Are you referring to an audit done by
some specific people, or using some methodology? Or a security audit in
a vague sense?
--
Pat
--
Marcela Mašláňová
BaseOS team Brno
5:12 a.m.
On Mon, Dec 08, 2008 at 09:18:23AM +0100, Marcela Maslanova wrote:
cronie isn't missing vim. It uses default text editor.
If there is none, it uses /bin/vi. In fact I have sone a bit of
investigations and it uses, in pathnames.h _PATH_VI which is defined in
/usr/invlude/paths.h.
So it is a missing dependency, in my opinion.
--
Pat
2:32 p.m.
Patrice Dumas wrote:
If there is none, it uses /bin/vi. In fact I have sone a bit of
investigations and it uses, in pathnames.h _PATH_VI which is defined in
/usr/invlude/paths.h.
So it is a missing dependency, in my opinion.
No it's not. People may want to use an actually usable editor and not have
their system polluted with this relict of history.
I guess I should file bugs against cvs, sudo and fcron which all have
unnecessary Requires on vim-minimal.
Kevin Kofler
2:54 p.m.
Kevin Kofler wrote:
Patrice Dumas wrote:
> If there is none, it uses /bin/vi. In fact I have sone a bit of
> investigations and it uses, in pathnames.h _PATH_VI which is defined in
> /usr/invlude/paths.h.
>
> So it is a missing dependency, in my opinion.
No it's not. People may want to use an actually usable editor and not have
their system polluted with this relict of history.
I guess I should file bugs against cvs, sudo and fcron which all have
unnecessary Requires on vim-minimal.
I'd argue that vi should be a requirement on any unix-like system, just
in case it is visted by a unix administrator that is also a relic of
history.
--
Les Mikesell
lesmikesell(a)gmail.com
3:10 p.m.
Kevin Kofler wrote:
Patrice Dumas wrote:
> If there is none, it uses /bin/vi. In fact I have sone a bit of
> investigations and it uses, in pathnames.h _PATH_VI which is defined in
> /usr/invlude/paths.h.
>
> So it is a missing dependency, in my opinion.
No it's not. People may want to use an actually usable editor and not have
their system polluted with this relict of history.
I use, exclusively, kate-based editors (usually kwrite, but also Kate
and KDevelop), and... <drumroll please> vim. Granted I just went and dug
up vim-enhanced last night (not installed by the KDE spin by default,
bleh), but I object to the classification of /bin/vi as a "relic of
history" and not "an actually usable editor". (vim-minimal is perfect
for most editing of things in /etc, thank you very much! Including
crontabs...)
I guess I should file bugs against cvs, sudo and fcron which all
have
unnecessary Requires on vim-minimal.
I'd consider a system with no 'vi' to be broken :-). /bin/vi seems to be
the lowest common denominator for a TUI editor on *nix systems.
Obviously, /bin/vi isn't necessarily Bram Moolenaar's VIM, but it's
always close enough to be more-or-less usable (where the "more-or-less"
almost invariably relates to how well it handles the arrow keys).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
"Do you do windows as well?"
"Only when I'm forced to deal with Microsoft..."
-- from a story by Feech
3:35 p.m.
On 12/08/2008 09:32 PM, Kevin Kofler wrote:
Patrice Dumas wrote:
> If there is none, it uses /bin/vi. In fact I have sone a bit of
> investigations and it uses, in pathnames.h _PATH_VI which is defined in
> /usr/invlude/paths.h.
>
> So it is a missing dependency, in my opinion.
No it's not. People may want to use an actually usable editor and not have
their system polluted with this relict of history.
I guess I should file bugs against cvs, sudo and fcron which all have
unnecessary Requires on vim-minimal.
That's probably a good idea not so much because vi is a "relic of history"
but simply because it's not a good idea to require a specific editor simply
because the package contains a config file. Virtually every app out there
contains config files so imagine if all of them depended on the editor of
the package maintainers choice. If at all then the dependency should be a
virtual one so the user can choose to install his/her prefered editor.
Regards,
Dennis
3:42 p.m.
On Mon, Dec 08, 2008 at 10:35:13PM +0100, Dennis J. wrote:
On 12/08/2008 09:32 PM, Kevin Kofler wrote:
> Patrice Dumas wrote:
>> If there is none, it uses /bin/vi. In fact I have sone a bit of
>> investigations and it uses, in pathnames.h _PATH_VI which is defined in
>> /usr/invlude/paths.h.
>>
>> So it is a missing dependency, in my opinion.
>
> No it's not. People may want to use an actually usable editor and not have
> their system polluted with this relict of history.
>
> I guess I should file bugs against cvs, sudo and fcron which all have
> unnecessary Requires on vim-minimal.
That's probably a good idea not so much because vi is a "relic of
history" but simply because it's not a good idea to require a specific
editor simply because the package contains a config file. Virtually every
app out there contains config files so imagine if all of them depended on
the editor of the package maintainers choice. If at all then the
dependency should be a virtual one so the user can choose to install
his/her prefered editor.
Those application have vi as a fallback default because they call it
somehow (at least fcrontab in fcron). I guess it is also the case of
sudoedit, and I also guess that it is the fallback for cvs commit
messages too. So those packages doesn't 'require a specific editor
simply because the package contains a config file'. They call, at
runtime an editor specified by the EDITOR env variable and fallback to
vi.
--
Pat
3:38 p.m.
On Mon, Dec 08, 2008 at 09:32:22PM +0100, Kevin Kofler wrote:
No it's not. People may want to use an actually usable editor and not have
their system polluted with this relict of history.
I guess I should file bugs against cvs, sudo and fcron which all have
unnecessary Requires on vim-minimal.
This is in order to always have a fallback. Anybody can use anything as
EDITOR, but one has to have a default. vi is not a bad choice, it is
POSIX, unless I am not recalling correctly, and it is small.
--
Pat
5:12 p.m.
On Mon, Dec 8, 2008 at 12:38 PM, Patrice Dumas <pertusus(a)free.fr> wrote:
This is in order to always have a fallback. Anybody can use anything
as
EDITOR, but one has to have a default. vi is not a bad choice, it is
POSIX, unless I am not recalling correctly, and it is small.
Should all possible fallbacks be hard requirements? Isn't it better to
have a number of competing packages provide an editor and provide a
virtual editor provides, have one of those installed editors set as
the default system editor via the EDITOR variable and then have all
packages which need an editor require the virtual editor provides
instead of a specific editor?
That way anyone can build a spin or do an install using any
appropriate available editor package which provides the editor virtual
provides as policy and tastes dictate.
-jef
5:20 p.m.
On Mon, Dec 08, 2008 at 02:12:57PM -0900, Jeff Spaleta wrote:
On Mon, Dec 8, 2008 at 12:38 PM, Patrice Dumas
<pertusus(a)free.fr> wrote:
> This is in order to always have a fallback. Anybody can use anything as
> EDITOR, but one has to have a default. vi is not a bad choice, it is
> POSIX, unless I am not recalling correctly, and it is small.
Should all possible fallbacks be hard requirements? Isn't it better to
No, the rule should just be about things working, as a rule of thumb,
and depending on the package, either in a chroot, or together with
@core (with exception for package that have too much possible
requirements, like fonts needed by some packages).
have a number of competing packages provide an editor and provide a
virtual editor provides, have one of those installed editors set as
the default system editor via the EDITOR variable and then have all
packages which need an editor require the virtual editor provides
instead of a specific editor?
That way anyone can build a spin or do an install using any
appropriate available editor package which provides the editor virtual
provides as policy and tastes dictate.
Indeed, this would be possible, and certainly preferrable. Though in
general using the environment like is asking for trouble, this is what
is in upstream currently.
--
Pat
8:13 p.m.
On Mon, Dec 8, 2008 at 5:12 PM, Jeff Spaleta <jspaleta(a)gmail.com> wrote:
On Mon, Dec 8, 2008 at 12:38 PM, Patrice Dumas
<pertusus(a)free.fr> wrote:
> This is in order to always have a fallback. Anybody can use anything as
> EDITOR, but one has to have a default. vi is not a bad choice, it is
> POSIX, unless I am not recalling correctly, and it is small.
Should all possible fallbacks be hard requirements? Isn't it better to
have a number of competing packages provide an editor and provide a
virtual editor provides, have one of those installed editors set as
the default system editor via the EDITOR variable and then have all
packages which need an editor require the virtual editor provides
instead of a specific editor?
That way anyone can build a spin or do an install using any
appropriate available editor package which provides the editor virtual
provides as policy and tastes dictate.
-jef
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Hmm, sounds familiar... oh, right, the alternatives man page.
It is possible for several programs fulfilling the same or similar
functions to be installed on a single system at the same time. For
example, many systems have several text editors installed at once.
This gives choice to the users of a system, allowing each to use a dif-
ferent editor, if desired, but makes it difficult for a program to make
a good choice of editor to invoke if the user has not specified a par-
ticular preference.
The alternatives system aims to solve this problem.
jerry
--
Store in cool, dry place. Rotate stock.
2:54 a.m.
On Mon, Dec 08, 2008 at 08:13:10PM -0600, Jerry Amundson wrote:
>
Hmm, sounds familiar... oh, right, the alternatives man page.
It is possible for several programs fulfilling the same or similar
functions to be installed on a single system at the same time. For
example, many systems have several text editors installed at once.
This gives choice to the users of a system, allowing each to use a dif-
ferent editor, if desired, but makes it difficult for a program to make
a good choice of editor to invoke if the user has not specified a par-
ticular preference.
The alternatives system aims to solve this problem.
Not really. The alternatives system is useful if
* the different applications have compatible command line options
* the setting makes sense as a system-wide setting, not as a user
setting.
--
Pat
3 a.m.
2008/12/9 Jerry Amundson <jamundso(a)gmail.com>:
On Mon, Dec 8, 2008 at 5:12 PM, Jeff Spaleta
<jspaleta(a)gmail.com> wrote:
> On Mon, Dec 8, 2008 at 12:38 PM, Patrice Dumas <pertusus(a)free.fr> wrote:
>> This is in order to always have a fallback. Anybody can use anything as
>> EDITOR, but one has to have a default. vi is not a bad choice, it is
>> POSIX, unless I am not recalling correctly, and it is small.
>
>
> Should all possible fallbacks be hard requirements? Isn't it better to
> have a number of competing packages provide an editor and provide a
> virtual editor provides, have one of those installed editors set as
> the default system editor via the EDITOR variable and then have all
> packages which need an editor require the virtual editor provides
> instead of a specific editor?
>
> That way anyone can build a spin or do an install using any
> appropriate available editor package which provides the editor virtual
> provides as policy and tastes dictate.
>
> -jef
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
Hmm, sounds familiar... oh, right, the alternatives man page.
It is possible for several programs fulfilling the same or similar
functions to be installed on a single system at the same time. For
example, many systems have several text editors installed at once.
This gives choice to the users of a system, allowing each to use a dif-
ferent editor, if desired, but makes it difficult for a program to make
a good choice of editor to invoke if the user has not specified a par-
ticular preference.
The alternatives system aims to solve this problem.
jerry
--
Store in cool, dry place. Rotate stock.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
I really don't understand whats the problem with vi. It works, it's
small and it's the most common editor(in terms of availability not
usage). Even busybox has vi(or something that behaves like vi). It's
not like it's eating your precious hard disk or baby koalas. Vi is
also good for your health. You can always depend on vi to be there and
to work. It's not that I'm starting some "my editor is the best
flamewar". I'm just saying use whatever you want, but leave vi alone.
It likes to be the standard editor.
Best Regards,
Nikolay Vladimirov
9:12 a.m.
Jerry Amundson (jamundso(a)gmail.com) said:
It is possible for several programs fulfilling the same or
similar
functions to be installed on a single system at the same time. For
example, many systems have several text editors installed at once.
This gives choice to the users of a system, allowing each to use a dif-
ferent editor, if desired, but makes it difficult for a program to make
a good choice of editor to invoke if the user has not specified a par-
ticular preference.
The alternatives system aims to solve this problem.
Not for something like $EDITOR, which is a per-user setting anyway.
I'm not sure why a dependency on vim-minimal is truly that bad.
Bill
9:19 a.m.
On Tue, Dec 9, 2008 at 9:12 AM, Bill Nottingham <notting(a)redhat.com> wrote:
Jerry Amundson (jamundso(a)gmail.com) said:
> It is possible for several programs fulfilling the same or similar
> functions to be installed on a single system at the same time. For
> example, many systems have several text editors installed at once.
> This gives choice to the users of a system, allowing each to use a dif-
> ferent editor, if desired, but makes it difficult for a program to make
> a good choice of editor to invoke if the user has not specified a par-
> ticular preference.
>
> The alternatives system aims to solve this problem.
Not for something like $EDITOR, which is a per-user setting anyway.
Good point.
I'm not sure why a dependency on vim-minimal is truly that bad.
Me neither. I love vi.
jerry
--
Store in cool, dry place. Rotate stock.
10:29 a.m.
Bill Nottingham <notting(a)redhat.com> writes:
I'm not sure why a dependency on vim-minimal is truly that bad.
Because this kind of dependencies (features which do not belong to
package's core functionality) are always bad. Cron can be used
completely without any kind of editor; e.g. when jobs are installed
by cfengine.
Perhaps we should add 'Requires: cfengine' instead of? ;)
Enrico
11:34 a.m.
On Tue, 2008-12-09 at 17:29 +0100, Enrico Scholz wrote:
Because this kind of dependencies (features which do not belong to
package's core functionality) are always bad. Cron can be used
completely without any kind of editor; e.g. when jobs are installed
by cfengine.
Perhaps we should add 'Requires: cfengine' instead of? ;)
It works just fine until you try to use the functionality that looks up
$EDITOR, finds none and tries to fall back to vi, and doesn't find it
and crashes.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:01 p.m.
Jesse Keating <jkeating(a)redhat.com> writes:
> Because this kind of dependencies (features which do not belong
to
> package's core functionality) are always bad. Cron can be used
> completely without any kind of editor; e.g. when jobs are installed
> by cfengine.
It works just fine until you try to use the functionality that looks up
$EDITOR, finds none and tries to fall back to vi, and doesn't find it
and crashes.
Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
installed a proper behavior.
Enrico
12:07 p.m.
On Tue, 2008-12-09 at 19:01 +0100, Enrico Scholz wrote:
Crashing is a bug; a message that $EDITOR should be set and/or
'vi' be
installed a proper behavior.
I don't disagree, but until the package does that, it should require
vim-minimal to avoid the crash.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:17 p.m.
On Tue, 2008-12-09 at 10:07 -0800, Jesse Keating wrote:
On Tue, 2008-12-09 at 19:01 +0100, Enrico Scholz wrote:
> Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
> installed a proper behavior.
I don't disagree, but until the package does that, it should require
vim-minimal to avoid the crash.
$ crontab -e
/bin/sh: /bin/vi: No such file or directory
crontab: "/bin/vi" exited with status 127
Is this unacceptable behavior? I don't think so. But of course the
message could be even improved. Much better than making cronie depending
on any editor.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
12:28 p.m.
On Tue, 2008-12-09 at 19:17 +0100, Tomas Mraz wrote:
$ crontab -e
/bin/sh: /bin/vi: No such file or directory
crontab: "/bin/vi" exited with status 127
Is this unacceptable behavior? I don't think so. But of course the
message could be even improved. Much better than making cronie
depending
on any editor.
That looks like a crash to me. My immediate response would be "If you
need vi, why the hell didn't you require vi?!" Imagine the case where
the user running this isn't the admin of the system. What can they do
now? Nothing. Dead in the water.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:12 p.m.
Enrico Scholz wrote:
Jesse Keating <jkeating(a)redhat.com> writes:
>> Because this kind of dependencies (features which do not belong to
>> package's core functionality) are always bad. Cron can be used
>> completely without any kind of editor; e.g. when jobs are installed
>> by cfengine.
> It works just fine until you try to use the functionality that looks up
> $EDITOR, finds none and tries to fall back to vi, and doesn't find it
> and crashes.
Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
installed a proper behavior.
Doesn't ubunutu have a scheme where trying to execute a missing program
suggests the package you need to install to get it? That's even better
behavior.
--
Les Mikesell
lesmikesell(a)gmail.com
12:25 p.m.
Les Mikesell wrote:
Enrico Scholz wrote:
> Jesse Keating <jkeating(a)redhat.com> writes:
>
>>> Because this kind of dependencies (features which do not belong to
>>> package's core functionality) are always bad. Cron can be used
>>> completely without any kind of editor; e.g. when jobs are installed
>>> by cfengine.
>> It works just fine until you try to use the functionality that looks up
>> $EDITOR, finds none and tries to fall back to vi, and doesn't find it
>> and crashes.
>
> Crashing is a bug; a message that $EDITOR should be set and/or 'vi' be
> installed a proper behavior.
Doesn't ubunutu have a scheme where trying to execute a missing program
suggests the package you need to install to get it? That's even better
behavior.
That only works in a shell. Not in all programs. However this has been
implemented already in PackageKit and the patches send upstream so
everybody can take advantage of it.
http://blogs.gnome.org/hughsie/2008/12/05/command-not-found/
Rahul
8:19 p.m.
On Tue, Dec 9, 2008 at 6:12 AM, Bill Nottingham <notting(a)redhat.com> wrote:
I'm not sure why a dependency on vim-minimal is truly that bad.
Is this a requirement on vim-minimal or just a requirement for a posix
compliant editor to be available?
Or let me ask it this way. Right now in the entire repository is
vim-minimal the only editor which is being explicitly required to
filling this fallback role? If it is, enshrine that as policy before I
get a chance to submit a package which falls back to nano. If its not
the only editor being used as a fallback in the repository, then some
compromise needs to be worked out so don't have people dragging in
multiple editors to fill the fallback capacity.
-jef
11:02 p.m.
On Thu, 2008-12-11 at 17:19 -0900, Jeff Spaleta wrote:
Or let me ask it this way. Right now in the entire repository is
vim-minimal the only editor which is being explicitly required to
filling this fallback role? If it is, enshrine that as policy before I
get a chance to submit a package which falls back to nano. If its not
the only editor being used as a fallback in the repository, then some
compromise needs to be worked out so don't have people dragging in
multiple editors to fill the fallback capacity.
calm down a bit here. The only reason it would have a hard requires on
'vi' would be if the software itself, without any options for $EDITOR,
falls back to calling the hard path of /bin/vi.
If your software does the same, but is hard coded to fall back
to /usr/bin/nano, then that's fine, you'll have a requirement on nano.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:50 p.m.
2008/12/11 Jesse Keating <jkeating(a)redhat.com>:
If your software does the same, but is hard coded to fall back
to /usr/bin/nano, then that's fine, you'll have a requirement on nano.
My point is...if its arbitrary and the call out is really just for any
editor...why not just have all the same default fallbacks so all the
proggies can share the same fallback.
If the upstreams really really cared about vi being there
specifically, there'd be a build time check.
-jef
10:29 a.m.
On Thu, 2008-12-11 at 20:50 -0900, Jeff Spaleta wrote:
My point is...if its arbitrary and the call out is really just for
any
editor...why not just have all the same default fallbacks so all the
proggies can share the same fallback.
If the upstreams really really cared about vi being there
specifically, there'd be a build time check.
I really don't get your point. Do you want our maintainers to patch out
the strict fallback to vi? That's not something we should be doing in
dist-cvs, that's something that should be discussed with the relevant
upstreams.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:34 a.m.
On Thu, Dec 11, 2008 at 05:19:44PM -0900, Jeff Spaleta wrote:
Is this a requirement on vim-minimal or just a requirement for a posix
compliant editor to be available?
On /bin/vi. More precisely fcron has a build time check, with a
configure flag --with-editor, that defaults to
AC_PATH_PROG(FOUND_FCRON_EDITOR, vi. And cronie uses _PATH_VI from
paths.h. I don't think there is a posix compliance needed as all.
The posix compliance argument, is here to justify vim-minimal as 'not
a bad choice for a default editor'. But once again if you have an idea
for a better default editor choice, just do the infrastructure, then
provide patches for packages that need a default editor and be done.
Or let me ask it this way. Right now in the entire repository is
vim-minimal the only editor which is being explicitly required to
filling this fallback role? If it is, enshrine that as policy before I
Why do we need a policy here?
get a chance to submit a package which falls back to nano. If its
not
the only editor being used as a fallback in the repository, then some
compromise needs to be worked out so don't have people dragging in
multiple editors to fill the fallback capacity.
I am not sure a compromise is needed. Just let the packagers do what
they prefer, in the constraints of upstream choices. If somebody is
interested in modularizing better the default editor handling, for example
with something built around xdg-open, or around xdg-edit no problem, I
think that all the packagers will gladly accept the change.
When pointed to it, all the packagers of packages I reviewed accepted to
use htmlview, and everybody accepted to switch to xdg-open when Ville
filled bugs with patches.
There was a thread about how to choose a default editor on the packaging
list some time ago, I don't remember exactly what was the conclusion,
but I pointed out that using xdg-open was dangerous, because it is not
clear what xdg-open applie to a text file means, because it may mean
editing it, viewing it, and maybe other action.
Of course finding out packages that need a default editor will require
some research, but I think that a mail on devel list should be enough.
There is another package which needs a default editor, grace, and we
used nedit for the lack of anything better, given that grace (and nedit)
use Motif.
--
Pat
4:39 p.m.
Jeff Spaleta (jspaleta(a)gmail.com) said:
On Tue, Dec 9, 2008 at 6:12 AM, Bill Nottingham
<notting(a)redhat.com> wrote:
> I'm not sure why a dependency on vim-minimal is truly that bad.
Is this a requirement on vim-minimal or just a requirement for a posix
compliant editor to be available?
It's a requirement on whatever provides _PATH_VI, as defined by
glibc's /usr/include/paths.h.
Bill
3:54 p.m.
> I won't push this more, somebody else has to volunteer to
make this
> happen. I think it could be done in F11 and it should be a feature.
Does fcron have the selinux context support that was added to cronie?
joe
I just checked...
1) it does not support polyinstantiation.
2) It also does not send audit events based on denying a cron job.
3) Its pam settings do not support the audit system out of the box.
4) Its default pam settings need alignment with vixie-cron in general.
My guess is that fcron needs work to be able to use it in high security
environments.
-Steve
5:10 p.m.
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Patrice Dumas wrote:
> If there is none, it uses /bin/vi. In fact I have sone a bit of
> investigations and it uses, in pathnames.h _PATH_VI which is defined in
> /usr/invlude/paths.h.
>
> So it is a missing dependency, in my opinion.
No it's not. People may want to use an actually usable editor and not have
their system polluted with this relict of history.
Flamewar alert!
[vi(1) is actually a /very/ usable editor. I believe some standard or other
requires its presence; in fact, it is one of the things you can depend on
finding on any Unixy system.]
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000 Fax: +56 32 2797513
2:07 p.m.
On Dec 5, 2008, at 1:59 PM, Patrice Dumas wrote:
Hello,
I think that fcron should be the default scheduler in fedora.
fcron, with the service fcron_watch_config activated should now be
100% compatible with vixie-cron (cronie). The fcron_watch_config stuff
is a bit convoluted (3 scripts and one C program...) but should work.
The advantages over cronie are the following:
* it also does what anacron does
* it has more features
* instead of waking up every minutes to look at config files, like
cronie do, it uses inotify to watch the config. This should lead to
less awaking and certainly be interesting for power saving in some
situations
I won't push this more, somebody else has to volunteer to make this
happen. I think it could be done in F11 and it should be a feature.
Does fcron have the selinux context support that was added to cronie?
joe
2:26 a.m.
Patrice Dumas wrote:
Hello,
I think that fcron should be the default scheduler in fedora.
fcron, with the service fcron_watch_config activated should now be
100% compatible with vixie-cron (cronie). The fcron_watch_config stuff
is a bit convoluted (3 scripts and one C program...) but should work.
The advantages over cronie are the following:
* it also does what anacron does
* it has more features
* instead of waking up every minutes to look at config files, like
cronie do, it uses inotify to watch the config. This should lead to
less awaking and certainly be interesting for power saving in some
situations
cronie is also using inotify, longer than fcron ;-) So this is not
advantage.
I won't push this more, somebody else has to volunteer to make this
happen. I think it could be done in F11 and it should be a feature.
--
Pat
--
Marcela Mašláňová
BaseOS team Brno
4:57 a.m.
On Mon, Dec 08, 2008 at 09:26:24AM +0100, Marcela Maslanova wrote:
cronie is also using inotify, longer than fcron ;-) So this is not
advantage.
There is something strange, then it seemed to me that it accessed config
file and directories every minutes. I'll have a look at the code.
--
Pat
5:29 a.m.
On Mon, Dec 08, 2008 at 09:26:24AM +0100, Marcela Maslanova wrote:
cronie is also using inotify, longer than fcron ;-) So this is not
advantage.
Indeed. (As a side note, since fcron didn't watched at all for those
files and directories, 'longer than fcron' has not a well defined
meaning ;-).
I haven't fully understood the code, but it seems to me that cronie will
miss the creation of /etc/crontab if it didn't exist when the select in
check_inotify_database is entered? And does it watch modifications of
files in RH_CROND_DIR?
In any case you may have a look at
http://cvs.fedoraproject.org/viewvc/rpms/fcron/devel/fcron_config_modifie...
though it is not exactly the same context (it is called from a shell
script and if it exits with exit code 0 the configuration is reread by
another shell script), here I also watch /etc in case crontab wasn't
there already, to watch for its creation.
--
Pat
6:43 a.m.
Patrice Dumas wrote:
On Mon, Dec 08, 2008 at 09:26:24AM +0100, Marcela Maslanova wrote:
> cronie is also using inotify, longer than fcron ;-) So this is not
> advantage.
Indeed. (As a side note, since fcron didn't watched at all for those
files and directories, 'longer than fcron' has not a well defined
meaning ;-).
I haven't fully understood the code, but it seems to me that cronie will
miss the creation of /etc/crontab if it didn't exist when the select in
check_inotify_database is entered? And does it watch modifications of
files in RH_CROND_DIR?
No, inotify is set to watch /etc/crontab even in case it's created after
start of daemon.
Yes, I set watch on /etc/cron.d/, so it's checking all changes in this
directory.
In any case you may have a look at
http://cvs.fedoraproject.org/viewvc/rpms/fcron/devel/fcron_config_modifie...
though it is not exactly the same context (it is called from a shell
script and if it exits with exit code 0 the configuration is reread by
another shell script), here I also watch /etc in case crontab wasn't
there already, to watch for its creation.
How many times is lstat touching the disc? I suppose you are lstat'ing,
only when you are creating the watch?
--
Pat
--
Marcela Mašláňová
BaseOS team Brno
7:13 a.m.
On Mon, Dec 08, 2008 at 01:43:14PM +0100, Marcela Maslanova wrote:
>
No, inotify is set to watch /etc/crontab even in case it's created after
start of daemon.
But without watching /etc with inotify, how do you do it? In my
experiments if a file doesn't exist, inotify_add_watch errors out.
Yes, I set watch on /etc/cron.d/, so it's checking all changes in
this
directory.
Indeed. Seems that I was fooled by the doc, IN_CLOSE_WRITE seems to also
watch for files closed inside a directory. I'll be able to simplify
the fcron watch code, then, thanks.
How many times is lstat touching the disc? I suppose you are
lstat'ing,
only when you are creating the watch?
Yes. But the watch are recreated everytime the program is rerun, which
is done everytime something changes. If the C program was integrated
in a bigger C program instead of being launched from a shell script
(that also relaunches the configuration), previous watches could be
reused. In any case fcron is different from cronie, since (in the current
state) all the config is recreated even if only one file change. Maybe
cronie may have something more fine grained.
--
Pat
7:20 a.m.
Patrice Dumas wrote:
On Mon, Dec 08, 2008 at 01:43:14PM +0100, Marcela Maslanova wrote:
> No, inotify is set to watch /etc/crontab even in case it's created after
> start of daemon.
But without watching /etc with inotify, how do you do it? In my
experiments if a file doesn't exist, inotify_add_watch errors out.
But inotify can watch files or directories. The watch is set on
/etc/crontab = SYSCRONTAB.
> Yes, I set watch on /etc/cron.d/, so it's checking all
changes in this
> directory.
Indeed. Seems that I was fooled by the doc, IN_CLOSE_WRITE seems to also
watch for files closed inside a directory. I'll be able to simplify
the fcron watch code, then, thanks.
> How many times is lstat touching the disc? I suppose you are lstat'ing,
> only when you are creating the watch?
Yes. But the watch are recreated everytime the program is rerun, which
is done everytime something changes. If the C program was integrated
in a bigger C program instead of being launched from a shell script
(that also relaunches the configuration), previous watches could be
reused. In any case fcron is different from cronie, since (in the current
state) all the config is recreated even if only one file change. Maybe
cronie may have something more fine grained.
In this case is using lstat ok.
--
Pat
--
Marcela Mašláňová
BaseOS team Brno
8:04 a.m.
On Mon, Dec 08, 2008 at 02:20:37PM +0100, Marcela Maslanova wrote:
>
But inotify can watch files or directories. The watch is set on
/etc/crontab = SYSCRONTAB.
Sure, but in case it doesn't exist, inotify_add_watch will error out.
My guess is that if /etc/crontab doesn't exist, cronie reverts to
inotify_enabled = 0, and that's why I saw cronie looking every minute at
/etc/cron.d.
I have simplified the program and used the same masks than cronie at
http://cvs.fedoraproject.org/viewvc/rpms/fcron/devel/fcron_config_modifie...
Maybe you could implement SYSCONFDIR watching like I did to enable
inotify even if /etc/crontab or /etc/cron.d is missing and watch for
their creation by watching /etc.
In fedora, not having /etc/crontab or /etc/cron.d present should
be very rare, but in other setups this may happen.
If I have time, I'll try to see logs when /etc/crontab or /etc/cron.d
are not present, since cronie should state it in that case.
--
Pat
8:13 a.m.
Hi,
Le vendredi 5 décembre 2008 à 20:59, Patrice Dumas a écrit :
Hello,
I think that fcron should be the default scheduler in fedora.
fcron, with the service fcron_watch_config activated should now be
100% compatible with vixie-cron (cronie). The fcron_watch_config stuff
is a bit convoluted (3 scripts and one C program...) but should work.
The advantages over cronie are the following:
* it also does what anacron does
* it has more features
* instead of waking up every minutes to look at config files, like
cronie do, it uses inotify to watch the config. This should lead to
less awaking and certainly be interesting for power saving in some
situations
I won't push this more, somebody else has to volunteer to make this
happen. I think it could be done in F11 and it should be a feature.
Do you intend to package fcron for EPEL?
Regards,
Alain
--
La version française des pages de manuel Linux
http://manpagesfr.free.fr
9:22 a.m.
Le lundi 22 décembre 2008 à 15:15, Patrice Dumas a écrit :
On Mon, Dec 22, 2008 at 03:13:05PM +0100, Alain PORTAL wrote:
> Do you intend to package fcron for EPEL?
I think so. But not immediately.
There is no emergency.
You can do it if you want to.
For the moment, I can't because old problem of cvs access.
And I'm not sure I'll keep a box under Fedora, I intend to switch to Centos.
--
La version française des pages de manuel Linux
http://manpagesfr.free.fr
9:35 a.m.
On Mon, Dec 22, 2008 at 04:22:13PM +0100, Alain PORTAL wrote:
For the moment, I can't because old problem of cvs access.
And I'm not sure I'll keep a box under Fedora, I intend to switch to Centos.
You can still contribute to EPEL even if you don't run a fedora box.
In fact I still contribute to EPEL though I have left fedora, and
right now I use a debian testing to submit the EPEL jobs with plague,
works fine.
--
Pat
8:45 a.m.
On Monday 22 December 2008 09:13:05 am Alain PORTAL wrote:
> I think that fcron should be the default scheduler in fedora.
> fcron, with the service fcron_watch_config activated should now be
> 100% compatible with vixie-cron (cronie). The fcron_watch_config stuff
> is a bit convoluted (3 scripts and one C program...) but should work.
>
> The advantages over cronie are the following:
> * it also does what anacron does
> * it has more features
> * instead of waking up every minutes to look at config files, like
> cronie do, it uses inotify to watch the config. This should lead to
> less awaking and certainly be interesting for power saving in some
> situations
There are some disadvantages, too.
1) it does not support polyinstantiation - needed for MLS
2) It also does not send audit events based on denying a cron job.
3) Its pam settings do not support the audit system out of the box.
4) Its default pam settings need alignment with vixie-cron in general.
It would appear to not have had security reviews like vixie-cron has. In a few
minutes I found what appears to be a potentially serious security problem.
I've reported it upstream last week and no reply at all. I have not done a
full code review like I would for our cert efforts, so there may be more
problems waiting.
Do you intend to package fcron for EPEL?
You have to be careful switching out core pieces of software that performs a
security sensitive role. The lack of attacks on most of Fedora is due to
years of review and feedback on code.
-Steve
9:54 a.m.
On Tue, Dec 23, 2008 at 09:45:54AM -0500, Steve Grubb wrote:
There are some disadvantages, too.
1) it does not support polyinstantiation - needed for MLS
Is there something explaining polyinstantiation in the context of
a cron scheduler?
2) It also does not send audit events based on denying a cron job.
Right. I'll have a look at what cronie does and contact upstream on
that, but I don't expect to be able to do that soon.
3) Its pam settings do not support the audit system out of the box.
4) Its default pam settings need alignment with vixie-cron in general.
I had a look at the pam crond file, and indeed it looks good
while the fcron one is quite bad. I won't be able to change it,
though for I don't have a fedora anymore.
I think it would be nice to have examples of pam files for fedora
for the different types of applications. Last time I had a look
there was a complete lack of consistency.
It would appear to not have had security reviews like vixie-cron has.
In a few
minutes I found what appears to be a potentially serious security problem.
I've reported it upstream last week and no reply at all. I have not done a
full code review like I would for our cert efforts, so there may be more
problems waiting.
In general upstream is rather reactive...
It looks like there was some security audit in 2004 since 4 vulnerabilities
were discovered.
You have to be careful switching out core pieces of software that
performs a
security sensitive role. The lack of attacks on most of Fedora is due to
years of review and feedback on code.
Is it a general statement or a statement about the cron scheduler?
It seems to me that some part of fedora are very young (though maybe
they were audited a lot), like dbus, consolekit, hald, and have system-wide
security implications that are certainly as problematic as those of
a cron scheduler.
In any case I can do some work on those issues, but so far nobody
took fcron when I orphaned it. A maintainer in fedora would be a
prerequisite for moving that issue along.
--
Pat
5601
days inactive
5619
days old
53 comments
19 participants
participants (19)
-
Alain PORTAL -
Bill Nottingham -
Dennis Jacobfeuerborn -
Enrico Scholz -
Horst H. von Brand -
Jef Spaleta -
Jerry Amundson -
Jesse Keating -
Joe Nall -
Kevin Kofler -
Les Mikesell -
Marcela Mašláňová -
Matej Cepl -
Matthew Woehlke -
Nikolay Vladimirov -
Patrice Dumas -
Rahul Sundaram -
Steve Grubb -
Tomas Mraz