Re: [foreman-dev] ABRT plugin, part 2
by Martin Milata
On Thu, Jan 23, 2014 at 15:35:41 +0100, Lukas Zapletal wrote:
> > +---------+ +-----+
> > | foreman | | FAF |
> > +---------+ +-----+
> > ^ ^
> > \ /
> > \ /
> > \ /
> > \ /
> > +-------------+
> > | smart proxy |
> > +-------------+
> > ^
> > |
> > |
> > +------+
> > | host |
> > +------+
>
> I havent attended the discussion, but why the host cannot talk to the
> FAF directly?
>
> the host ---> FAF <----> smart proxy <-----> foreman
>
> I assume that would be scenario A) in your former proposal. We kinda
> discussed both A and B options and I have to admit I leaned towards B
> option (the picture above), after reading this:
>
> > 4) The smart proxy formats the report to the same format as Puppet uses
> > and sends it to Foreman. It probably always shouldn't do so immediatelly
> > as that could DOS the Foreman in case a lot of hosts will be sending
> > crash reports very often. It should store the reports in memory and
> > aggregate them according to the their identifier (a.k.a. hash). The
> > hash can be computed by the satyr library [2].
>
> I am not so sure now. I am late on emails today, but I haven't seen any
> pros/cons or wider discussion why we should integrate like that.
The reason is that we'd like to make use of the reports without the need
to install FAF, as:
- FAF is rather heavyweight piece of software that has lots of
dependencies, needs SQL database, etc.
- Its features are mostly targeted at developers of the software for
which the reports are generated. I assume that it wouldn't be actually
that useful for typical foreman user.
The architecture in the picture allows you to be informed about crashes
on your managed hosts. Optionally, you can deploy your own FAF instance
for better crash statistics and more crash data, or send the reports to
FAF instance of your software supplier (e.g. Red Hat).
10 years, 2 months
ABRT plugin, part 2
by Martin Milata
Hi,
here's what we talked about today in Brno. The goal is for the Foreman
to be able to display the information that program X crashed on host Y
at time Z. The workflow(bugflow?) will be as follows:
+---------+ +-----+
| foreman | | FAF |
+---------+ +-----+
^ ^
\ /
\ /
\ /
\ /
+-------------+
| smart proxy |
+-------------+
^
|
|
+------+
| host |
+------+
1) Whenever a crash happens on host, it sends the report to the smart
proxy. The report is JSON formatted [1] and is sent through https
connection which uses the Puppet certificate for client authentication.
2) The smart proxy receives the report, verifies the https connection
against Puppet CA certificate and remembers the common name from the
certificate in order to identify the host.
3) The smart proxy optionaly forwards the report to the ABRT server
(a.k.a. FAF).
4) The smart proxy formats the report to the same format as Puppet uses
and sends it to Foreman. It probably always shouldn't do so immediatelly
as that could DOS the Foreman in case a lot of hosts will be sending
crash reports very often. It should store the reports in memory and
aggregate them according to the their identifier (a.k.a. hash). The
hash can be computed by the satyr library [2].
5) Foreman receives the report and displays it in some list, associated
with the host it came from.
TODO:
- ABRT people will provide Ruby bindings for satyr
- Foreman people will start working on the smart proxy support once
their current sprint is over
Please correct me if I got anything wrong or forgot something.
Thanks!
Martin
[1] https://github.com/abrt/faf/wiki/uReport#ureport2
[2] https://github.com/abrt/satyr
10 years, 2 months
Re: [foreman-dev] ABRT plugin for Foreman
by Martin Milata
On Thu, Dec 05, 2013 at 12:24:17 +0100, Lukas Zapletal wrote:
> > Hi!
> Hey,
>
> > A) uReports are collected by ABRT server deployed by the administrator.
> > 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.
>
> We have nice Puppet based installer, so this looks like viable option to
> me as we can setup another component.
>
> > B) uReports are collected by Foreman, or some kind of proxy written for
>
> I prefer A, this is solely my opinion.
>
> > 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?)?
>
> Someone correct me if I am wrong, but we are deploying Puppet client
> certificate during provisioning phase which is being signed by Puppet CA
> authority. That means each Foreman-managed machine has a client
> certificate which could be re-used for other things. It should not be
> a problem to use Puppet CA to validate client certificates during ABRT
> upload.
>
> The key is to make sure ABRT server has access to the Puppet CA
> certificate (and key).
I wonder if it would be possible to use these certificates without major
changes to Puppet. Or, whether the benefits of having authenticated
problem reports outweigh the risks of sharing the puppet certificates
with another component.
Thanks for the reply,
Martin
10 years, 3 months