Hmm. The fact that the error message is reported with JobId 113 is
actually a bug in new code that I implemented in version 9.0.x. I
didn't notice it in my first response, so must admit that yes it is
confusing. The reason for this problem is that error messages are
reported by any currently
Hello,
The error in question is simply because some program other than one
furnished by Bacula or using the Bacula protocol has tried to connect to
Bacula. Bacula reports that and in my view what is reports is very
clear (at least for a technical person).
To alleviate your concerns, I canno
> On Mon, 5 Mar 2018 22:19:14 +, Shawn Rappaport said:
> Content-ID:
>
> On 3/5/18, 2:37 PM, "Josip Deanovic" wrote:
>
> Josip DeanovicOn Monday 2018-03-05 22:23:08 wrote:
> > On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
> > > On 03/05/2018 02:27 PM, Josip Deanovic w
On Monday 2018-03-05 22:19:14 Shawn Rappaport wrote:
> On 3/5/18, 2:37 PM, "Josip Deanovic" wrote:
> > Actually Shawn didn't say that the backup failed.
> > He just said that when he manually started the backup job the next
> > day, it finished successfully, without errors.
> >
> > Shawn, can yo
On 3/5/18, 2:37 PM, "Josip Deanovic" wrote:
Josip DeanovicOn Monday 2018-03-05 22:23:08 wrote:
> On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
> > On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> > > On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> > >> That's not a
On 03/05/2018 03:35 PM, Josip Deanovic wrote:
> Shawn, can you confirm that both backups were successfully completed?
Yes, if an unsuccessful connection attempt kills a running backup, that
would be unpleasant. The log doesn't look like it, though, it seems to
log a "jobid 0" for just the connect
Josip DeanovicOn Monday 2018-03-05 22:23:08 wrote:
> On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
> > On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> > > On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> > >> That's not an error if a security op's workstation is also a backup
> > >> cli
On Monday 2018-03-05 14:38:07 Dimitri Maziuk wrote:
> On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> > On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> >> That's not an error if a security op's workstation is also a backup
> >> client.
> >
> > Yes, and I would like to know if that was the ca
On Monday 2018-03-05 19:41:45 Shawn Rappaport wrote:
> No, 10.32.12.18 is not the IP of the client to be backed up. I’m
> guessing that was the IP of the Nessus scanner.
In that case everything is ok except I don't understand why the
backup failed because some other server tried to open a connecti
On 03/05/2018 02:27 PM, Josip Deanovic wrote:
> On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
>> That's not an error if a security op's workstation is also a backup
>> client.
>
> Yes, and I would like to know if that was the case.
I tend to have a blanket iptables rule allowing local subn
On Monday 2018-03-05 14:16:34 Dimitri Maziuk wrote:
> On 03/05/2018 12:45 PM, Josip Deanovic wrote:
> > The question is: is the IP 10.32.12.18 the IP of the client that had
> > to be backed up?
> >
> >
> >
> > If yes then the vulnerability scan overtook the client's IP.
>
> That's not an error if
On 03/05/2018 12:45 PM, Josip Deanovic wrote:
> The question is: is the IP 10.32.12.18 the IP of the client that had
> to be backed up?
>
> If yes then the vulnerability scan overtook the client's IP.
That's not an error if a security op's workstation is also a backup client.
--
Dimitri Maziuk
No, 10.32.12.18 is not the IP of the client to be backed up. I’m guessing that
was the IP of the Nessus scanner.
--Shawn
On 3/5/18, 11:48 AM, "Josip Deanovic" wrote:
On Monday 2018-03-05 12:32:50 Dimitri Maziuk wrote:
> On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> > On Monday 20
No, I don’t have that configured on my Bacula server.
--Shawn
On 3/5/18, 11:02 AM, "Josip Deanovic" wrote:
On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> Thank you, Patti! You were correct. It turns out there was a
> vulnerability scan run against that network at that time.
On Monday 2018-03-05 12:32:50 Dimitri Maziuk wrote:
> On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> > On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> >> Thank you, Patti! You were correct. It turns out there was a
> >> vulnerability scan run against that network at that time.
> >
> > Did
On 03/05/2018 12:00 PM, Josip Deanovic wrote:
> On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
>> Thank you, Patti! You were correct. It turns out there was a
>> vulnerability scan run against that network at that time.
>
> Did you configure your bacula to use SSL/TLS connection?
> I wonder
On Monday 2018-03-05 17:08:45 Shawn Rappaport wrote:
> Thank you, Patti! You were correct. It turns out there was a
> vulnerability scan run against that network at that time.
Did you configure your bacula to use SSL/TLS connection?
I wonder if that would help in your case.
--
Josip Deanovic
--
sourceforge.net"
Subject: [Bacula-users] Packet size too big errors
I’m running Bacula 9.0.6 on CentOS 7.3. Today I received the following errors
when my catalog was backing up:
03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in
authenticate.c:330 UA Hello from client:10.3
t: [Bacula-users] Packet size too big errors
I’m running Bacula 9.0.6 on CentOS 7.3. Today I received the following errors
when my catalog was backing up:
03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len
I’m running Bacula 9.0.6 on CentOS 7.3. Today I received the following errors
when my catalog was backing up:
03-Mar 12:27 xbacdirector01-lv.internal.shutterfly.com-dir: ERROR in
authenticate.c:330 UA Hello from client:10.32.12.18:9101 is invalid. Len=0
03-Mar 12:27 xbacdirector01-lv.internal.s
20 matches
Mail list logo
