Darkserver is a service written to help people finding details of build-id(s). People will be able query the service based on build-id(s) or rpm package names. The service will provide output in JSON format as it will be easier for other tools to parse the output.
The whole idea is based on a feature of BUILD-ID which was completed in Fedora 8 time, you can read about it here.
Source Code
Source code is under github and can be found here.
Why we need the service?
To enable developer tools to identify exact package builds from which process images (e.g. core dumps) come. This can enable their analysis, debugging profiling, by finding out where the rpm / elf / dwarf files may be found, so they can download them. (This is even better than abrt-action-install-debuginfo-to-abrt-cache because that apparently cannot query files no longer indexed by repodata.)
darkclient may look like the same what can be done with repoquery:
$ repoquery -q --enablerepo='*-debuginfo' -f /usr/lib/debug/.build-id/0d/aa18d6291a5d0d174556c8c46f1345eba61a65 bash-debuginfo-0:4.2.10-5.fc16.x86_64
Just with repoquery one has only available:
- GA release from repository fedora
- the very latest update from repository updates
- possibly the very latest update from repository updates-testing
One does not have available:
- any update which has been already obsoleted by a more recent update
- any release from Koji not submitted to Bodhi
This is a real problem making bugreports investigations difficult or even lost in some cases:
- https://bugzilla.redhat.com/show_bug.cgi?id=629966#c4
- https://bugzilla.redhat.com/show_bug.cgi?id=556227#c2
- RHEL Bug 739685 - not public
It is more common but I have spent more time searching for it.
Also the repoquery -qf way is too slow as it has to download *-filelists.sqlite.bz2 files for all the repositories first.
Requests for this feature of build-id to NVRA queries implemented some other ways have been declined before:
Populating the database
The database needs to contain very every build that may be in use, to be useful at all. There are multiple possible sources of this info. Populating the database should be based on a push (not pull) technology, with some hook at Koji/Bodhi executed after a new build.
- Bodhi - but people commonly download and use Koji build n fixing their submitted Bug while Bodhi gets only later build n+1 containing also other fix(es).
- Koji real (non-scratch) builds - this is the recommended hook place.
- Koji incl. the scratch builds - I do not think it is worth it, NVRA of such database would be no longer unique, scratch builds are AFAIK never distributed among more uses, URLs to Koji are special and after all the lifetime of scratch builds is very limited (two weeks).
Architecture of the project
View this image.
Requirements
- Django >= 1.2.5
- MySQL server
The web service does not need any authentication. It will require read only access to the database, the users will only require to query the service.
The information on the database will be filled up by darkserver-import command, which will only execute through bodhi on every update pushed through.
How to setup?
Install the darkserver and darkserver-import rpms. Run the createtable.sql under /usr/share/darkserver to create table structure in the database.
$ mysql -u user -p -Ddatabasename < /usr/share/darkserver/createtable.sql
Edit the configuration file at /etc/darkserver/darkserverweb.conf as
[darkserverweb] host=MySQL host name user=MySQL user (read only access) password=password database=database name
Remember that the webserver only requires read only access to MySQL.
To use the darkserver-import tool you will have to fill up /etc/darkserver/darkserver.conf in the same way.
[darkserver] host=MySQL host name user=MySQL user (read/write access) password=password database=database name