On 09/23/2009 12:42 PM, Denys Vlasenko wrote:
On Tue, 2009-09-22 at 14:59 +0200, Jiri Moskovcak wrote:
> Hi, this is my "brain dump" of ABRT development plan, I hope you'll
add
> some of yours and then we can discuss this later.
>
> Jirka
>
> >> Urgent<<
> daemon can't read/write config from home dir
> - we need to move this to client (gui, applet)
>
> >> Minor<<
> finish saving the global settings from gui
> improve the GUI:
> - I'd like the gui to be more like wizard
>
> improve the dbus methods return values
> - all methods should return some value to let client know how it end
> - e.g. {Re,Unre}gister plugin doesn't return anything, so GUI
> doesn't know how did it go
>
>>> Long term features<<
We need to take a closer look at the design of abrt.
Better to deal with design problems now that carry them with us
for years.
+1 for some brainstorm how to improve the design
One evidence of a design problem is that /var/cache/abrt/
must be writable by everyone.
This is needed because python crash info is stored there
by the crashed program itself, still running under whatever
uid it was running.
I don't see immediate way how to make it possible
for python crash dumper to write data there (setuid helper binary?).
wouldn't setuid helper require user to enter the root password??
I think more appropriate approach here would be to ask
ourself "why do we want to dump python user's crashes
in a centralized directory in the first place?"
Is it a right design? I am not sure of it.
The problem here is, that we run the daemon which does all the work with
root privileges and such daemon shouldn't read anything from users $HOME
directory, so if we store it in $HOME we'll have to run the backend with
the current user privileges. So that mean will need:
frontend (gui, applet, etc ..)
backend (does the reporting and the magic with plugins)
privileged backend (does all the privileged stuff)
Our goal is not to dump crash data into a crash dump directory,
so that the daemon will pick it up.
It's our *current *implementation* of the real goal. The goal is:
automated and configurable collection and reporting of crashes.
I will try to pretend for a moment that abrt does not exist,
and will think how this could be done. This is not meant to say
that current design of abrt is stupid. I am first to admit I'm
not very good at design...
So, here I did some brain-storming:
<brainstorm>
We have different kinds of crashes:
* kernel crashes
* binary application crashes
* interpreted language crashes (currently Python)
They have different mechanisms how crashes are detected.
So far only kernel crashes require polling to detect them.
Binary crashes are caught by crash dump kernel hook.
Python crashes are detected by Python internal hook.
Anyway, we hook in one way or another into it and collect
primary, minimalistic crash data. Configurability at this step
is pretty minimal: "do we want to collect this type of crashes?",
and "do we want to collect crash dump element XYZ?"
Next step: post-processing of crash data and reporting.
Configuration here can be complex. Do we want GUI popup or not?
Do we want to create a bug in bugzilla or send everything
to a server, so that production machines are not burdened by crash
processing? etc...
Maybe we can make it configurable via scripts, they are more
flexible than table-driven design? A-la:
/etc/abrt/python_crash.sh
/etc/abrt/kernel_crash.sh
/etc/abrt/binary_crash.sh
In "binary application crash" case we may need to download
debuginfos, which is a privileged operation. (Is it the only
privileged operation we need?). Python and kernel so far
does not require any such privileged op.
We can do privileged ops by calling a server which does this.
If it can be done from shell script, it's more flexible:
if we later decide to rework this part, it's not tightly
integrated with the rest of abrt - easier to replace
without disturbing the rest.
How to call a server from shell? Examples:
dbus-send utility, wget, dedicated command-line helper
if all else fails.
I do not see the reason why we need to have a permanently
running privileged server, though. At least, not as big one
as we currently have.
</brainstorm>
What I would like to try first is to not run abrtd all the time.
How?
(1) Configure dbus so that "com.redhat.abrt" can be started on demand
on system bus. Thus, abrt-gui will cause it to start.
Let's call this server abrt-dbus. It will do most of the things
abrtd currently does.
(2) make binary crash handler (hookCCpp) spawn abrt-dbus after dump is
done. This will allow abrt-dbus to process new crash. Maybe
make its work easier by -d<dir_to_process> parameter?
(1) + (2) this was the plan, but it has been (somehow) forgotten :)
(3) rework abrtd so that it only installs core_pattern hook,
then waits for new oopses, dumps them, and spawns abrt-dbus.
it doesn't have to be abrtd work, it can be done in init script.
Later, maybe:
(4) python crash handler dumps into _user's_ (not system) dir,
runs abrt-dbus (?) under user's uid, making it process user dump.
This eliminates the problem of user-writable /var/cache/abrt.
As I wrote earlier this would require to split the daemon (not necessary
into separate daemons, but at least to make it run in 2 modes
with/without root privs)
--
vda
Jirka