Re: [Bacula-users] Bugs/Problems with ConnectToDirector

[Justin Case]

Dear Bacula developers,

This chapter goes further. It seems there is not merely a problem with 
bacula-dir crashing if an FD is aggressively connecting, also the FD connection 
scheduling and connection aggressivity seems to need some more thought.

Today the bacula-dir crashed again. This time the other FD (this is Debian) 
went rampant, no apparent reason. It just connected to the dir like crazy.

Something that also seems to need more adjustment is the connection scheduling.

When an FD is running before the schedule starts, it will start connecting as 
scheduled, but it will never stop. I think it should stop when the schedule 
ends.

When an FD is started during the schedule window, it will NOT start connecting 
to the director. This is clearly now what one would want. An started after the 
start time point and during the scheduled duration should connect to the 
director. Only if started before the scheduled time and after the duration of 
the schedule the FD shold not connect to the director.

The director needs to be fixed so that it does not crash if an FD is 
reconnecting very aggressively. And FDs should be more limited in the 
connection frequency (this does not mean the parameter ReconnectionTime, but 
the time wait before initiating another connection after unsuccessful 
connection trial).

All the best,
 J/C



> On 2. Aug 2022, at 22:42, Justin Case  wrote:
> 
> This chapter was not yet closed and I have interesting further results 
> (actually a bug report).
> I opened another thread here where bacula-dir was crashing. Today I found the 
> cause.
> 
> A macOS FD was earlier using normal connection from bacula-dir, but later I 
> adapted it to connect to bacula-dir on its own. So far so good? No. Hang on, 
> I am coming to it.
> 
> Under macOS I am using homebrew bacula-fd and in the meanwhile there was an 
> upgrade from 11 to 13. And at that point I made a subtle mistake: I copied 
> bacula-fd.conf from the 11 install to the 13 install. The problem with this 
> is that I overlooked this directive:
> 
>   Plugin Directory = /usr/local/Cellar/bacula-fd/11.0.6/lib
> 
> I guess you immediately see where the problem is, the 13.0.0 bacula-fd binary 
> is using bpipe plugin 11.0.6 binary.
> 
> The result of this seems to be that bacula-fd connects a lot more 
> aggressively to bacula-dir (don’t ask me why, I don’t know it).
> 
> In an ideal world this shouldn’t pose a problem, but in the container for 
> bacula-dir 11 that I am using it caused bacula-dir to crash with a 
> segmentation violation.
> 
> This is why I am reporting this.
> 
> Since I corrected the library path I don’t see the crashes any more and no 
> aggressive quick and numerous connections from the fd to the dir.
> 
> But! It is still the same director binary and there must be some bug if a 
> misbehaving FD can actually make the director crash. This is a security 
> problem, as someone could incapacitate the backups when they run and stop 
> doing that during the phase when backups are not running, so it would be hard 
> to troubleshoot. One could argue it is my own fault if I use v13 FDs with v11 
> diriectors. From a security perspective it is a problem with the 
> implementation. As long as a v11 director accepts v13 clients, it must not 
> crash. 
> 
> I don’t know how to better report this, but some developer would probably 
> take a look where the problem is with bacula-dir crashing if it gets a lot of 
> FD connections quickly over a longer time. I have only tried it with v13 FDs, 
> but I suspect it would also happen with v11 FDs.
> 
> All the best
>  J/C
> 
>> On 25. Jul 2022, at 22:33, Justin Case > > wrote:
>> 
>> I think it is great support here from  you people!
>> 
>> Today I think I might have understood what is happening, and Bill’s 
>> explanations about what might be going on were probably correct in the core, 
>> but not in the details.
>> 
>> Let me try to lay out what I think is going on and where I had my problem 
>> understanding it in the first place:
>> 
>> After an update of syslog-ng the syslogging of the FD client host started to 
>> work (it was configured a long time ago but somehow it never worked before 
>> the update for the syslog-ng server that came in the last days) I began to 
>> see where and WHEN(!) the error messages originated.
>> 
>> It is - as you guys are saying - the FD generating these errors, which are 
>> logged without delay in my central syslog-ng server:
>> 
>> 2022-07-25 12:57:30  
>> bsockcore.c:265 Unable to connect to Director daemon on 
>> bacula-dir.lan.net:9101 . ERR=Connection 
>> refused
>> 
>> The eye-opener were the timestamps, which explained what is happening (more 
>> on that later).
>> My problem so far was that the error messages shown in Baculum had the 
>> timestamp of the Director when the Director sees the error messages, not 
>> when they happened!
>> 
>> 25-Jul 22:00 bacula-dir JobId 1725: 

[Bacula-users] Ubuntu 20.04, Bacula, and MariaDB

[Daniel Rich]

I asked a very similar question nearly 2 years ago 
(https://sourceforge.net/p/bacula/mailman/bacula-users/thread/4ef25e47-7fc9-49c9-9d8b-c8b73414c9a3@Spark/)
 — is there any hope of getting Debian packages for Bacula built with MariaDB 
in addition to MySQL? Virtually everything else I use is built with the MariaDB 
dependencies these days, and I can’t upgrade to Bacula 9.6 w/o building my own 
packages at this point.

I was hoping to migrate from local disk to s3 storage, but that can’t happen 
w/o a newer version of bacula that what comes with Ubuntu. And even the 
debian.org packages are still mysql-only.

Dan Rich 
http://www.employees.org/~drich/
"Step up to red alert!" "Are you sure, sir?
It means changing the bulb in the sign..."
- Red Dwarf (BBC)
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Re: [Bacula-users] running Bacula client on Synology

[Andrea Venturoli]

On 8/2/22 21:00, Phil Stracchino wrote:

Huh.  Now I'm curious about how you set up the QNAP cross-compiler and 
development environment.  I couldn't find any useful information on that 
and QNAP support flatly refused to provide any.


It all stated from here:

https://sourceforge.net/p/bacula/mailman/message/36443243/

Since I'm normally using FreeBSD, I created a Slackware VM in VirtualBox 
just for this.




(Starting with manage it in any sensible way beyond pushing 
buttons in its point-and-drool web management interface, which I quickly 
found to be full of You Can't Do That.)


Can't comment on that.
After I put Bacula-SD on the NASes, usually my work is done.
Occasionally I use SSH to check/delete some volumes.



 bye
av.


___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users