Hi,
we have made (together with Karel) some todo list for retrace server. If
you find any part interesting, let us know, but you are basically free
to go :).
At the moment, I'm working on:
Task cleanup
Reporting statistics
Incomplete backtraces - a little
HTTPS certificates
In the future, I'd like to work on remote GDB sessions.
Michal
Here's the list:
--- What NEEDS to be done for F15 ---
* CLI - Command line tool providing retrace client functionality: create
new task, ask about status, log, backtrace.
* GUI - Integrate retrace server with ABRT GUI.
* Task cleanup - A tool cleaning /var/spool/abrt-retrace directory from
tasks older than some threshold (5 days?). Periodically called from cron.
* Trusted HTTPS certificates - Get trusted HTTPS certificates from
Fedora infrastructure.
* Incomplete backtraces - Find out why some packages do not generate
full backtraces and deal with the differences between backtraces
generated on F14 and RHEL6 hosts.
* Reporting statistics - Retrace worker should save some statistics.
What information exactly do we want to save? (package name, duration,
version, parallel tasks?)
* Manual - Convert design document to manual.
* Security audit - Look the code for possible security holes - running
file contents in shell etc. :).
--- What SHOULD be done in the future ---
* Only use coredump - Do not require additional files (architecture,
package etc.), coredump should contain all necessary information.
* Support different archive formats - Accept gz, bz2 (...?) comressed
archives and also archives with no compression - fastest on LAN.
* Calculate estimated time - When enough statistics are gathered, try to
estimate retrace duration and send it to the client. Client does not
need to ask about status before.
* Support keep-alive HTTP connection - Status script should not close
HTTP connection, but send task status to the client every ~10 seconds.
The connection is closed once retrace job is complete.
* Handle specific crashes (gdb, libc etc.) - Handle crashes from
binaries and libraries required by the retrace server itself.
* Coredump stripping - Only send some smaller part of (possibly large)
coredump, the one really required by GDB.
* Write SELinux policy - Do we really need it?
* Support rawhide - Deal with the problem of enormous number of packages.
* User authentication - Mostly for corporate use, every retrace job has
an owner, who is able to re-run, delete, modify... it. Impossible in Fedora.
* Multiarch support - Support multiple architectures (i386, x86_64, ppc,
ppc64 etc.) on the same machine.
* Providing GDB debugging sessions - Allow users to debug their crashes
remotely.
* Statistics cleanup - Delete old statistics from stats database. Do we
really need it?
* 3rd party packages support - Allow users to add their own packages and
debuginfos to the retrace request. Allow also to process non-official
repositories like rpmfusion?
* WebUI - Provide the statistics and even the possibility of uploading
coredump from web browser. Do we really need it?
* Speed optimizations:
** RPM package stripping - Discard all unnecessary information from
RPMs. Store only binaries, libraries and debuginfos. Would be very useful.
** Jobs planning - Change the priority of retrace jobs to gain better
efficiency.
** Updates-testing cleanup - Do not store packages in updates and
updates-testing repositories twice.
** Integrate with DebuginfoFS - Once DebuginfoFS is complete.