Alexander E. Fischer <aef <at> raxys.net> writes:

> 
> It seems that the Bareos daemons neither try to reread configured X.509
> CRLs from file system if they expire nor if the daemon receives a
> SIGHUP. For example when a file daemon's CRL expired and the director
> tries to connect, the following messages are displayed at the director
> (which by the way do not describe the problem at hand very accurately):
> 
>         26-Apr 20:52 alpha-dir JobId 0: Fatal error: TLS negotiation
>         failed with FD at "beta.example.com:9102".
>         26-Apr 20:53 alpha-dir JobId 0: Error: crypto_openssl.c:1475
>         Connect failure: ERR=error:14094415:SSL
>         routines:SSL3_READ_BYTES:sslv3 alert certificate expired
> 
The printed errors are from ERR_error_string_n() so if it prints
that the certificate is expired its probably the only thing it can
determine remotely. The CRL handling is indeed somewhat clumsy but
at least we do check CRLs which was missing in the project we forked.


> After placing an updated CRL on the expected file system location and
> restarting the file daemon the connection can be successfully
> established again.
> 
So at least there is a workaround I admit not very clean but I scanned
the web last night and there is not very much implemented in that sense.
>From what I understand even Apache etc don't reload CRLs automatically.

> Now my question is if there is a way other than restarting the daemon to
> force it to reread the CRL from file system. Because having to restart
> the daemons daily is quite annoying and could also break running jobs if
> not planned very well.
> 
Short answer NO. Only the DIR implements reloading the SD and FD have
no signal handler at all. As you already say its also rather difficult
to implement things cleanly and robust due to running Jobs etc. The DIR
has some logic which seems to work good enough then again its not nice
to reload things to often I admin. That is also one of the reasons why
we eventually want to have the config interactive in the DIR so you don't
need to reload that config either but can just extend the existing config
via an interactive config parser.

> On the other hand I'd like to recommend to let the daemons automatically
> reread the CRLs if they expire or if the expected file changed or at
> least on a manual SIGHUP.
> 
I must say that I'm not myself very much into the inner works of
CRLs, currently only the director supports reloading and the SD and FD
are normally just restarted completely. I created a feature request in
Mantis to keep track of this issue. There is some example code floating
around the web which we could base our implementation on but like I said
that has to be community effort. I can attach a proposed patch I wrote
last night but its not much more then a first try that probably needs
some work.

https://bugs.bareos.org/view.php?id=289

If we want to discuss this in more details I also think it should
happen on the bareos-devel mailinglist.

-- 
Marco van Wieringen                   [email protected]
Bareos GmbH & Co. KG                  Phone: +49-221-63069389
http://www.bareos.com                     

Sitz der Gesellschaft: Köln | Amtsgericht Köln: HRA 29646
Komplementär: Bareos Verwaltungs-GmbH
Geschäftsführer: Stephan Dühr, M. Außendorf, J. Steffens,
                 P. Storz, M. v. Wieringen


-- 
You received this message because you are subscribed to the Google Groups 
"bareos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to