On Thu, Dec 05, 2013 at 15:37:42 +0200, Ohad Levy wrote:
> A) uReports are collected by ABRT server deployed by the
> Upon receiving a report, the ABRT server notifies Foreman (or Foreman
> can periodically ask the ABRT server for new reports). Foreman
> communicates with ABRT server using some kind of REST API.
> * machine authentication has to be handled by ABRT server
> * ABRT server has to provide suitable API
> * not necessary to duplicate ABRT server code in Foreman
Does it make sense to have multiple abrt servers? does it make sense to tie
these into foreman proxies (e.g. when having disconnected networks?)
I don't think it does. One of the main features of the server is
grouping the reports that were probably caused by the same bug. I'd say
it's best to have just one server.
> B) uReports are collected by Foreman, or some kind of proxy
> this purpose. The reports can be browsed in Foreman and can be
> forwarded to ABRT server instance, either automatically or after the
> administrator manually accepts the report. The report can be
> forwarded to ABRT server run by the administrator, or it can be
> forwarded to the instance managed by Fedora/Red Hat/etc.
> * Foreman handles machine authentication
> * administrator can benefit from this without deploying their own ABRT
> * subset of the ABRT server functionality would have to be implemented
> by the Foreman plugin/proxy
Which level of complexity are we talking about here? does it make sense to
rewrite the abrt server? (or is it only a subset of the functionality?)
The server is quite complex as it does e.g. the report clustering or
resolving function names in stacktraces. I don't think rewriting it
entirely is reasonable. However, I can imagine that implementing a tiny
subset that would allow the administrator to see that a crash happened
in program X (from package Y) Z times in some timeframe would still be
> 2. Machine authentication
> uReports were originally designed to allow anonymous reporting, mainly
> for Fedora users. They only contain data that are not considered
> sensitive and we currently have no way to find out where did an uReport
> come from.
> While we could just add an item containing e.g. FQDN to the uReport,
> such information can be easily spoofed. Can we take advantage of the
> fact that there already exists authentication between the managed
> machines and Foreman (or Puppet?)?
I would assume in this case, you would want your systems to be known, we
could utilize the system facts, or uuid to identify it.
I think that without this assumption there wouldn't be many reasons to
integrate abrt server with foreman, as opposed to just running the
standalone abrt server somewhere on the network.
Thanks for the response,