Re: [Bacula-devel] bacula v3.0.1 hang/lockup

2009-05-27 Thread Sven Hartge 
Shad L. Lords wrote:

> I've been seeing bacula hang/lockup for a while now.  It appears to be 
> happening in the SD.  When the condition happens I'm still able to 
> connect to the DIR and issue commands.  However when I try to do a 
> status storage command it will hang on "Used Volume status:".  Also a 
> status director shows jobs that are still running.  

I am seeing this one, too, but with version 2.4.4 from Debian Lenny

I've attached my (sanitized) config-files.

Unfortunately I am not able to provide a backtrace at his time.

Grüße,
Sven.
# $Id: bacula-dir.conf 15181 2009-04-22 12:05:51Z oweh $
# Default Bacula Director Configuration file
#
#  The only thing that MUST be changed is to add one or more
#   file or directory names in the Include directive of the
#   FileSet resource.
#
#  For Bacula release 1.38.9 (02 May 2006) -- debian 3.1
#
#  You might also want to change the default email address
#   from root to your address.  See the "mail" and "operator"
#   directives in the Messages resource.
#

Director {# define myself
  Name = backray-dir
  DIRport = 9101# where we listen for UA connections
  QueryFile = "/etc/bacula/scripts/query.sql"
  WorkingDirectory = "/var/lib/bacula"
  PidDirectory = "/var/run/bacula"
  Maximum Concurrent Jobs = 40
  Password = "THISWASREMOVED" # Console password
  Messages = Daemon
  FD Connect Timeout = 1 min
  SD Connect Timeout = 1 min
}

JobDefs {
  Name = "DefaultJob"
  Type = Backup
  Level = Incremental
  Pool = Full-Pool
  Full Backup Pool = Full-Pool
  Incremental Backup Pool = Inc-Pool
  Differential Backup Pool = Diff-Pool
  FileSet = "Full Set"
  Schedule = "WeeklyCycle"
  Messages = Standard
  Priority = 10
  Spool Data = yes
  Maximum Concurrent Jobs = 30
  Reschedule On Error = yes
  Reschedule Interval = 30 minutes
  Reschedule Times = 5
}

JobDefs {
  Name = "WSJob"
  Type = Backup
  Level = Incremental
  Schedule = "WSWeeklyCycle"
  Messages = Standard
  Pool = Full-Pool
  Full Backup Pool = Full-Pool
  Incremental Backup Pool = Inc-Pool
  Differential Backup Pool = Diff-Pool
  Priority = 15
  Maximum Concurrent Jobs = 30
  Spool Data = yes
  Reschedule On Error = yes
  Reschedule Interval = 30 minutes
  Reschedule Times = 5
}

JobDefs {
  Name = "WSNightJob"
  Type = Backup
  Level = Incremental
  Schedule = "WSWeeklyNightCycle"
  Messages = Standard
  Pool = Full-Pool
  Full Backup Pool = Full-Pool
  Incremental Backup Pool = Inc-Pool
  Differential Backup Pool = Diff-Pool
  Priority = 15
  Maximum Concurrent Jobs = 30
  Spool Data = yes
  Reschedule On Error = yes
  Reschedule Interval = 30 minutes
  Reschedule Times = 5
}

JobDefs {
  Name = "VmwareWSJob"
  Type = Backup
  Level = Incremental
  Schedule = "VMWSWeeklyCycle"
  Messages = Standard
  Pool = Full-Pool
  Full Backup Pool = Full-Pool
  Incremental Backup Pool = Inc-Pool
  Differential Backup Pool = Diff-Pool
  Spool Data = yes
  Priority = 20
  Maximum Concurrent Jobs = 30
  Reschedule On Error = yes
  Reschedule Interval = 30 minutes
  Reschedule Times = 5

}

# Backup the catalog database (after the nightly save)
Job {
  Name = "BackupCatalog"
  JobDefs = "DefaultJob"
  Client = backray-fd
  Level = Full
  FileSet="Catalog"
  Schedule = "WeeklyCycleAfterBackup"
  # This creates an ASCII copy of the catalog
  RunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula 
DBPASSWDHERE"
  # This deletes the copy of the catalog
  RunAfterJob  = "/etc/bacula/scripts/delete_catalog_backup"
  WriteBootstrap = "/var/lib/bacula/MyCatalog.bsr"
  
  Priority = 21   # run after main backup
  Spool Data = yes
}


#Job {
#  Name = "BackupBacksvCatalog"
#  JobDefs = "DefaultJob"
#  Client = backsv-fd
#  FileSet = BacksvCatalog
#  Schedule = "CatalogCycle"
#  Level = Full
#  ClientRunBeforeJob = "/etc/bacula/scripts/make_catalog_backup bacula bacula 
fs?f43ZU!"
#  # This deletes the copy of the catalog
#  ClientRunAfterJob  = "/etc/bacula/scripts/delete_catalog_backup"
#  WriteBootstrap = "/var/lib/bacula/BacksvMyCatalog.bsr"
#
#}


###
# Restore Jobs
###
# Standard Restore template, to be changed by Console program

Job {
  Name = "RestoreTemplate"
  Type = Restore
  Fileset = "Dummy"
  Client = backray-fd
  Pool = Full-Pool
  Messages = Standard
  Where = /tmp/bacula-restores
}

Job {
  Name = "VerifyTemplate"
  Type = Verify
  Fileset = "Dummy"
  Client = backray-fd
  Pool = Full-Pool
  Messages = Standard
  Where = /tmp/bacula-restores
}

###
# Filesets  

###

FileSet {
  Name = "Dummy"
  Include {
Options {
  signature = MD5

compression = GZIP4
}
  }
}

FileSet {
  Name = "BacksvCatalog"
  Include {
Op

Re: [Bacula-devel] Sqlite3 and autoincrement

2009-08-23 Thread Sven Hartge 
Kern Sibbald wrote:

> Based on the information you provided below, I have reopened the bug report 
> and posted my suggested fix.  Sorry that I missed the fact that the Bacula 
> developers added the offending "AUTOINCREMENT".  I would appreciate a 
> confirmation to the bug report whether or not my suggested fix works.

I will be able to test these fixes this Monday.

But since I came to the same conclusion WRT sed as you did (see
), I am
positive this should work as intended.

Grüße,
Sven.


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Sqlite3 and autoincrement

2009-08-24 Thread Sven Hartge 
Sven Hartge wrote:
> Kern Sibbald wrote:
> 
>> Based on the information you provided below, I have reopened the bug report 
>> and posted my suggested fix.  Sorry that I missed the fact that the Bacula 
>> developers added the offending "AUTOINCREMENT".  I would appreciate a 
>> confirmation to the bug report whether or not my suggested fix works.
> 
> I will be able to test these fixes this Monday.
> 
> But since I came to the same conclusion WRT sed as you did (see
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542810#10>), I am
> positive this should work as intended.

I can confirm this to be working.

I rolled my own bacula Debian packages based on the ones from John,
incorporated the updates and fixes from this thread, held my breath and
updated my system.

There where some minor, packaging related problems but the sqlite
upgrade went fine and a test backup and restore have shown no problems
or errors so far.

Grüße,
Sven.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] MySQL indexes

2017-10-02 Thread Sven Hartge 
On 02.10.2017 06:03, Phil Stracchino wrote:

> While answering a user question the other day on identifying files that
> span tape boundaries, I extended one of the indexes on the File table:
> 
> 
> MySQL localhost> alter table File drop index PathId, add index PathId
> (PathId, FilenameId, FileIndex);
> 
> 
> This change has MASSIVELY sped up the 'purge volume' operation.  Purges
> that used to take four or five minutes now complete in 20 to 30 seconds.

Have you checked if this slows down the attribute INSERT operation after
each backup or any other operation?

It may help speed up the purge operation for the tape but it is on the
other hand of no use if it slows down the attribute insertion, which
happens much more often.

See http://bugs.bacula.org/view.php?id=1472#c5261 for an example of
problems with indexes.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

[Bacula-devel] Leftover file bacula/src/lib/lz4.c.orig?

2017-10-28 Thread Sven Hartge 
Hello!

While doing some test builds for Debian I encountered a strange leftover 
file in the 9.0-branch:
http://www.bacula.org/git/cgit.cgi/bacula/tree/bacula/src/lib/lz4.c.orig

Is this some arteface from patch and the orig-file was leftover? The 
commit message from 
http://www.bacula.org/git/cgit.cgi/bacula/commit/bacula/src/lib/lz4.c.orig?id=5980509b538e876a145bdc6afcdb2a10e97dfb63
 
was not very helpful for me to determine why it was there: "Tweak save a 
copy of the original lz4.c"

During package creation it creates a warning, because dpkg-buildpackage 
thinks it is a forgotten temp file from a patch merge and removes it from 
the generated source code tar.

Grüße,
Sven.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Leftover file bacula/src/lib/lz4.c.orig?

2017-10-28 Thread Sven Hartge 
On 28.10.2017 20:45, Kern Sibbald wrote:

> The file you mention was saved in case I had some problems with the new
> version.  I have now removed the file in version 9.0.5 as it is no
> longer needed.
> 
> In the future I will attempt to find some simpler (less bothersome for
> you) way to keep such files.

The problem was the suffix ".orig" here. There is a mechanism to remove
files matching "*.rej" and "*.orig" during source package creation, as
they may be leftovers from failed patching attempts.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Leftover file bacula/src/lib/lz4.c.orig?

2017-10-29 Thread Sven Hartge 
On 29.10.2017 09:13, Kern Sibbald wrote:

> I have now removed that file for release 9.0.5, but if I wanted to do
> something similar in the future, can you confirm that if I use *.old, it
> will not cause you build problems?

It shouldn't, from my understanding of the code.

And it didn't really cause any problems, it was just a warning emitted
by the build system, so changing this is in the upstream source not a
serious priority.

S°



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Qt5 support

2018-02-21 Thread Sven Hartge 
On 07.02.2018 19:57, Phil Stracchino wrote:

> I've identified the build problem, and it is quite simple and fixed by
> the following patch:

Thank you!

I borrowed the patch for Debian, also incorporating the (strange) fix
Gentoo developed for the bat-binary-is-libtool-wrapper problem you
encountered with Qt5.9+.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

[Bacula-devel] [PATCH] Making pkg-config cross-compile safe.

2018-03-04 Thread Sven Hartge 
Hello!

The Debian lintian package checker found a warning about a cross-compile
unsafe way to find pkg-config:
https://lintian.debian.org/tags/autotools-pkg-config-macro-not-cross-compilation-safe.html

The attached Patch 0001 fixes this by using the appropriate
PKG_PROG_PKG_CONFIG macro.

Patches 0002 and 0003 refresh aclocal.m4 to include the needed macros
from pkg.m4 and then refresh the configure script, but it is well
possible this is done at another place during the Bacula release
process. In that case those patches are of course not needed.

I have so far implemented this change in a non-releases branch of the
Debian packaging repository and test-built packages from it. My testing
so far has not revealed any negative changes.

All in all, pkg-config is only used during the building of "bat" so the
impact is low.

Grüße,
Sven.
From 19b5896d1676be0c3055c1410eed2bbee0dbe6c3 Mon Sep 17 00:00:00 2001
From: Sven Hartge 
Date: Sun, 4 Mar 2018 19:36:12 +0100
Subject: [PATCH 1/3] Use PKG_PROG_PKG_CONFIG macro to search for pkg-config
Cc: s...@svenhartge.de

Using AC_PATH_PROG(PKGCONFIG, pkg-config, pkg-config) to search for the
pkg-config binary is not cross-compile safe, it may pick up the wrong
binary, causing libraries being used from the from path.

pkg.m4 provides the macro PKG_PROG_PKG_CONFIG to avoid this problem.

This potential problem was found by the Debian lintian package checker:
https://lintian.debian.org/tags/autotools-pkg-config-macro-not-cross-compilation-safe.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884798

Signed-off-by: Sven Hartge 
---
 bacula/autoconf/configure.in | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bacula/autoconf/configure.in b/bacula/autoconf/configure.in
index 4ddb8269c..29fe732ab 100644
--- a/bacula/autoconf/configure.in
+++ b/bacula/autoconf/configure.in
@@ -138,7 +138,7 @@ AC_PATH_PROG(PYTHON, python, python)
 AC_PATH_PROG(GROWISOFS, growisofs, growisofs)
 AC_PATH_PROG(DVDRWMEDIAINFO, dvd+rw-mediainfo, dvd+rw-mediainfo)
 AC_PATH_PROG(DVDRWFORMAT, dvd+rw-format, dvd+rw-format)
-AC_PATH_PROG(PKGCONFIG, pkg-config, pkg-config)
+PKG_PROG_PKG_CONFIG()
 AC_PATH_PROG(QMAKE, qmake, none)
 AC_PATH_PROG(GMAKE, gmake, none)
 AC_PATH_PROG(PIDOF, pidof, pidof)
@@ -403,13 +403,13 @@ AC_ARG_ENABLE(bat,
 BAT_DIR=
 if test x$support_bat = xyes; then
 dnl look for Qt4
-   abc=`$PKGCONFIG QtGui`
+   abc=`$PKG_CONFIG QtGui`
pkg=$?
if test $pkg = 0; then
   BAT_DIR=src/qt-console
else
 dnl look for Qt5
- abc=`$PKGCONFIG Qt5Gui`
+ abc=`$PKG_CONFIG Qt5Gui`
  pkg=$?
  if test $pkg = 0; then
 	BAT_DIR=src/qt-console
-- 
2.16.2

From 317d53b38839921ce2aecf7a172c5b0f1a7a4f85 Mon Sep 17 00:00:00 2001
From: Sven Hartge 
Date: Sun, 4 Mar 2018 19:37:58 +0100
Subject: [PATCH 2/3] Refresh autoconf/aclocal.m4 after changing configure.in
Cc: s...@svenhartge.de

Signed-off-by: Sven Hartge 
---
 bacula/autoconf/aclocal.m4 | 285 -
 1 file changed, 281 insertions(+), 4 deletions(-)

diff --git a/bacula/autoconf/aclocal.m4 b/bacula/autoconf/aclocal.m4
index de6977dae..684adf2e2 100644
--- a/bacula/autoconf/aclocal.m4
+++ b/bacula/autoconf/aclocal.m4
@@ -1,7 +1,7 @@
-# generated automatically by aclocal 1.9.6 -*- Autoconf -*-
+# generated automatically by aclocal 1.15.1 -*- Autoconf -*-
+
+# Copyright (C) 1996-2017 Free Software Foundation, Inc.
 
-# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
-# 2005  Free Software Foundation, Inc.
 # This file is free software; the Free Software Foundation
 # gives unlimited permission to copy and/or distribute it,
 # with or without modifications, as long as this notice is preserved.
@@ -11,12 +11,289 @@
 # even the implied warranty of MERCHANTABILITY or FITNESS FOR A
 # PARTICULAR PURPOSE.
 
+m4_ifndef([AC_CONFIG_MACRO_DIRS], [m4_defun([_AM_CONFIG_MACRO_DIRS], [])m4_defun([AC_CONFIG_MACRO_DIRS], [_AM_CONFIG_MACRO_DIRS($@)])])
+dnl pkg.m4 - Macros to locate and utilise pkg-config.   -*- Autoconf -*-
+dnl serial 11 (pkg-config-0.29)
+dnl
+dnl Copyright © 2004 Scott James Remnant .
+dnl Copyright © 2012-2015 Dan Nicholson 
+dnl
+dnl This program is free software; you can redistribute it and/or modify
+dnl it under the terms of the GNU General Public License as published by
+dnl the Free Software Foundation; either version 2 of the License, or
+dnl (at your option) any later version.
+dnl
+dnl This program is distributed in the hope that it will be useful, but
+dnl WITHOUT ANY WARRANTY; without even the implied warranty of
+dnl MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+dnl General Public License for more details.
+dnl
+dnl You should have received a copy of the GNU General Public License
+dnl along with this program; if not, write to the Free Software
+dnl Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
+dnl 02111-1307, USA.
+dnl
+dnl As a special exception to the GNU General Public Licen

Re: [Bacula-devel] [PATCH] Making pkg-config cross-compile safe.

2018-04-01 Thread Sven Hartge 
On 01.04.2018 09:06, Kern Sibbald wrote:

> Thanks for your patches.  The first two look fine, but there is a
> problem with the third patch for configure.  The problem is that if
> anyone builds starting from scratch from source, configure will be
> overwritten when "make configure" is called.  This is because configure
> is "compiled" from the file /autoconf/configure.in.  As a
> consequence, any changes made to /configure must only be done by
> modifying the configure.in file.
> 
> Can you come back to me and indicate what changes you would make to
> autoconf/configure.in?

The first patch contains the changes to configure.in and is technically
all that is needed.

The second and third patches are only convenience patches for you, if
you don't want to manually rerun aclocal and autoconf for your release
process.

Grüße,
Sven.





signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] [PATCH] Making pkg-config cross-compile safe.

2018-04-02 Thread Sven Hartge 
On 02.04.2018 09:43, Kern Sibbald wrote:

> Everytime autoconf/configure.in is changed I run "make configure" in the
> main directory, which does the aclocal and autoconf.

Currently the aclocal part is disabled in the Makefile because of problems:

Quote from the Makefile, line 67++:

#  Note, the following is needed in the above if ever any new macro is
added.
#   However, at the current time, the -I libtool causes the
autoconf/aclocal.m4
#   get messed up, so this is commented out
#   cd autoconf && aclocal -I bacula-macros -I gettext-macros -I libtool


Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] [PATCH] Making pkg-config cross-compile safe.

2018-05-27 Thread Sven Hartge 
On 02.04.2018 09:43, Kern Sibbald wrote:

> Oh, sorry, I did not look closely enough at the first patch :-(.
> Everytime autoconf/configure.in is changed I run "make configure" in the
> main directory, which does the aclocal and autoconf.  This way, as a
> convenience to users, I distribute an up to date configure with the
> source code.
> 
> Thanks for fixing this problem and thanks for your submission.

Hi Kern,

just a quick question if you need anything additional from me to get
this change merged.

Grüße,
Sven.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] [PATCH] Making pkg-config cross-compile safe.

2018-05-27 Thread Sven Hartge 
On 27.05.2018 20:10, Kern Sibbald wrote:

> I have been a bit busy lately, and I did apply your patch only to find
> out that it did not work.  I think you had updated some of the autoconf
> files or were using a different one from me, because the new macro call
> that you added to configure.in is not in my autoconf macro files.  In
> the end I had to back out the patch, and since I have not gotten back to
> it.  More specifically, the call to:
> 
> PKG_PROG_PKG_CONFIG()
> 
> failed because it is not defined in the Bacula autoconf directory.  When
> I made the patch, I only applied the one file:
> 
> 0001-Use-PKG_PROG_PKG_CONFIG-macro-to-search-for-pkg-conf.patch
> 
> Was there something else I should have patched?

You need to run the whole aclocal machinery to get the needed bits
included into bacula/autoconf.

If you don't want to do this, you can apply the second patch, which
contains those macros.

You then of course need to regenerate bacula/configure based on the new
contents of bacula/autoconf/*.


Grüße,
Sven.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-19 Thread Sven Hartge 
On 19.12.18 21:55, Sven Hartge wrote:

> Is libs3 in Debian too old or the wrong libs3 to begin with?

To answer my own question: Yes, libs3 in Debian is too old.

Grüße,
Sven



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-19 Thread Sven Hartge 
On 16.12.18 19:06, Kern Sibbald wrote:

> The main new feature is the addition support for using Amazon S3 (and
> other *identical* S3 providers).  Note: Azur, Oracle S3,and Goggle S3
> are not compatible with Amazon S3.

I've been trying to get the cloud-driver with S3 enabled for Debian, but
I hit some roadblocks.

The first one is "configure" never checking for libs3 because the
varible "support_s3" is never set and the checks are just skipped then,
leaving HAVE_LIBS3 unset.

After fixing this (see attached patch), I hit the following error during
compile:

/usr/bin/g++   -c  -Wdate-time -D_FORTIFY_SOURCE=2 -x c++
-fno-strict-aliasing -fno-exceptions -fno-rtti  -I. -I..  -g -O2
-fdebug-prefix-map=/build/bacula-9.4.0=. -fstack-protector-strong
-Wformat -Werror=format-security -x c++ -fno-strict-aliasing
-fno-exceptions -fno-rtti  authenticate.c
s3_driver.c: In member function 'virtual bool s3_driver::init(JCR*,
cloud_dev*, DEVRES*)':
s3_driver.c:561:10: error: 'S3BucketContext' {aka 'struct
S3BucketContext'} has no member named 'authRegion'
s3ctx.authRegion = cloud->region;
  ^~

(Should the formatting break, the full build log is here
https://salsa.debian.org/bacula-team/bacula/-/jobs/95111/raw

Is libs3 in Debian too old or the wrong libs3 to begin with?

Grüße,
Sven.
Description: Add code to check and enable S3 support
Author: Sven Hartge 
Last-Update: 2018-12-19

--- a/autoconf/configure.in
+++ b/autoconf/configure.in
@@ -385,6 +385,7 @@
 support_smartalloc=yes
 support_readline=yes
 support_lzo=yes
+support_s3=yes
 support_conio=yes
 support_bat=no
 support_tls=no
@@ -1896,6 +1897,20 @@
 
 AC_CHECK_FUNC(accept4, [AC_DEFINE(HAVE_ACCEPT4, 1, [Define to 1 if you have 
the 'accept4' function.])])
 
+dnl ---
+dnl Check for S3 support/directory (default on)
+dnl ---
+dnl this allows you to turn it completely off
+
+AC_ARG_ENABLE(s3,
+   AC_HELP_STRING([--disable-s3], [disable S3 support @<:@default=yes@:>@]),
+   [
+   if test x$enableval = xno; then
+ support_s3=no
+   fi
+   ]
+)
+
 S3_INC=
 S3_LIBS=
 S3_LDFLAGS=
@@ -3641,6 +3656,7 @@
Encryption support:  ${support_crypto}
ZLIB support:${have_zlib}
LZO support: ${have_lzo}
+   S3 support:   ${have_libs3}
enable-smartalloc:   ${support_smartalloc}
enable-lockmgr:  ${support_lockmgr}
bat support: ${support_bat}


signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-19 Thread Sven Hartge 
On 19.12.18 22:05, Sven Hartge wrote:
> On 19.12.18 21:55, Sven Hartge wrote:
> 
>> Is libs3 in Debian too old or the wrong libs3 to begin with?
> 
> To answer my own question: Yes, libs3 in Debian is too old.

Using the current libs3-HEAD from https://github.com/bji/libs3 results
in different errors, see attached build log for the s3_driver.o using
gcc-8.2.0.

Which version of libs3 do I have to use to get the cloud-driver compiled?


Grüße,
Sven
LT Compiling s3_driver.c
/home/oweh/salsa/bacula/libtool --tag=CXX --mode=compile /usr/bin/g++   -c  -x 
c++ -fno-strict-aliasing -fno-exceptions -fno-rtti-I. -I..  -g -O2 -Wall -x 
c++ -fno-strict-aliasing -fno-exceptions -fno-rtti  s3_driver.c
libtool: compile:  /usr/bin/g++ -c -x c++ -fno-strict-aliasing -fno-exceptions 
-fno-rtti -I. -I.. -g -O2 -Wall -x c++ -fno-strict-aliasing -fno-exceptions 
-fno-rtti s3_driver.c  -fPIC -DPIC -o .libs/s3_driver.o


signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-19 Thread Sven Hartge 
On 19.12.18 22:56, Sven Hartge wrote:
> On 19.12.18 22:05, Sven Hartge wrote:
>> On 19.12.18 21:55, Sven Hartge wrote:
>>
>>> Is libs3 in Debian too old or the wrong libs3 to begin with?
>>
>> To answer my own question: Yes, libs3 in Debian is too old.
> 
> Using the current libs3-HEAD from https://github.com/bji/libs3 results
> in different errors, see attached build log for the s3_driver.o using
> gcc-8.2.0.

Sorry, foiled again by STDERR. Here is the complete build log with all
errors this time.

Grüße,
Sven.
Compiling s3_driver.c
/usr/bin/g++   -c  -x c++ -fno-strict-aliasing -fno-exceptions -fno-rtti  -I. 
-I..  -g -O2 -Wall -x c++ -fno-strict-aliasing -fno-exceptions -fno-rtti  
s3_driver.c
s3_driver.c: In member function ‘S3Status s3_driver::put_object(transfer*, 
const char*, const char*)’:
s3_driver.c:349:16: error: invalid conversion from ‘S3PutObjectHandler*’ to 
‘int’ [-fpermissive]
&putObjectHandler, &ctx);
^
s3_driver.c:349:35: error: cannot convert ‘bacula_ctx*’ to ‘const 
S3PutObjectHandler*’
&putObjectHandler, &ctx);
   ^~~~
In file included from s3_driver.h:32,
 from s3_driver.c:28:
/usr/include/libs3.h:2050:46: note:   initializing argument 7 of ‘void 
S3_put_object(const S3BucketContext*, const char*, u_int64_t, const 
S3PutProperties*, S3RequestContext*, int, const S3PutObjectHandler*, void*)’
const S3PutObjectHandler *handler, void *callbackData);
~~^~~
s3_driver.c: In member function ‘bool s3_driver::get_cloud_object(transfer*, 
const char*, const char*)’:
s3_driver.c:445:32: error: invalid conversion from ‘S3GetObjectHandler*’ to 
‘int’ [-fpermissive]
  byteCount, 0, &getObjectHandler, &ctx);
^
s3_driver.c:445:51: error: cannot convert ‘bacula_ctx*’ to ‘const 
S3GetObjectHandler*’
  byteCount, 0, &getObjectHandler, &ctx);
   ^~~~
In file included from s3_driver.h:32,
 from s3_driver.c:28:
/usr/include/libs3.h:2178:46: note:   initializing argument 8 of ‘void 
S3_get_object(const S3BucketContext*, const char*, const S3GetConditions*, 
u_int64_t, u_int64_t, S3RequestContext*, int, const S3GetObjectHandler*, void*)’
const S3GetObjectHandler *handler, void *callbackData);
~~^~~
s3_driver.c: In member function ‘virtual bool 
s3_driver::truncate_cloud_volume(DCR*, const char*, ilist*, POOLMEM*&)’:
s3_driver.c:481:48: error: invalid conversion from ‘S3ResponseHandler*’ to 
‘int’ [-fpermissive]
   S3_delete_object(&s3ctx, cloud_fname, 0, &responseHandler, &ctx);
^~~~
s3_driver.c:481:66: error: cannot convert ‘bacula_ctx*’ to ‘const 
S3ResponseHandler*’
   S3_delete_object(&s3ctx, cloud_fname, 0, &responseHandler, &ctx);
  ^~~~
In file included from s3_driver.h:32,
 from s3_driver.c:28:
/usr/include/libs3.h:2219:48: note:   initializing argument 5 of ‘void 
S3_delete_object(const S3BucketContext*, const char*, S3RequestContext*, int, 
const S3ResponseHandler*, void*)’
   const S3ResponseHandler *handler, void *callbackData);
   ~^~~
s3_driver.c: In member function ‘virtual bool 
s3_driver::get_cloud_volume_parts_list(DCR*, const char*, ilist*, POOLMEM*&)’:
s3_driver.c:669:22: error: invalid conversion from ‘S3ListBucketHandler*’ to 
‘int’ [-fpermissive]
  &partslistBucketHandler, &ctx);
  ^~~
s3_driver.c:669:47: error: cannot convert ‘bacula_ctx*’ to ‘const 
S3ListBucketHandler*’
  &partslistBucketHandler, &ctx);
   ^~~~
In file included from s3_driver.h:32,
 from s3_driver.c:28:
/usr/include/libs3.h:2017:48: note:   initializing argument 8 of ‘void 
S3_list_bucket(const S3BucketContext*, const char*, const char*, const char*, 
int, S3RequestContext*, int, const S3ListBucketHandler*, void*)’
 const S3ListBucketHandler *handler, void *callbackData);
 ~~~^~~
s3_driver.c: In member function ‘virtual bool 
s3_driver::get_cloud_volumes_list(DCR*, alist*, POOLMEM*&)’:
s3_driver.c:742:22: error: invalid conversion from ‘S3ListBucketHandler*’ to 
‘int’ [-fpermissive]
  &volumeslistBucketHandler, &ctx);
  ^
s3_driver.c:742:49: error: cannot convert ‘bacula_ctx*’ to ‘const 
S3ListBucketHandler*’

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-20 Thread Sven Hartge 
On 20.12.18 10:07, Kern Sibbald wrote:
> Hello Sven,
> 
> Sorry you had problems.
> 
> On my system, once libs3 is installed on the system, building Bacula
> automatically picks it up.

Does it? Looking really really hard at the shell code in configure tells
me: It doesn't.

This line
https://bacula.org/git/cgit.cgi/bacula/tree/bacula/configure?h=Branch-9.4#n27135
always evaluates to false and then the whole section until
https://bacula.org/git/cgit.cgi/bacula/tree/bacula/configure?h=Branch-9.4#n27234
is skipped, disabling S3 support.

The cloud-driver will still be compiled, but without the S3 backend and
just the (dummy?) File backend in place.

Once you just add "support_s3=yes", for example in this block here
https://bacula.org/git/cgit.cgi/bacula/tree/bacula/configure?h=Branch-9.4#n21810
(or apply my patch to configure.in and rerun aclocal) you will get the
same error as me, missing "authRegion", because that code was only added
to libs3 in November 2016.

> Yes the original libs3 package is a bit old as the author stopped
> updating it.
> 
> I am reasonably sure I am building and running on Ubuntu 18.04 and using
> the installed packages libs3-2 and libs3-dev.  dpkg says that it is
> version 2.0-3

Ubuntu just imports the version from Debian and does nothing special.

> In the mean time, I hope that our rpm/debs packager will release some
> binaries.

I am trying to get the official Debian packages ready for Debian Buster,
together with Carsten Leonhardt, so upstream binaries won't help much
other than as an inspiration.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-20 Thread Sven Hartge 
On 20.12.18 11:35, Kern Sibbald wrote:
> Sven,
> 
> Hmm.  Maybe I forgot to include some code in configure.in that detects
> libs3,
> since HAVE_LIBS3 seems to be undefined here too.
> 
> Sorry for the inconvenience.  I will have to look into why the libs3
> detection is not working.
> 
> I just manually added
> 
> #define HAVE_LIBS3 1
> 
> to my config.h file, and Bacula builds fine on my Ubuntu 18.04.


Could you please do a "grep authRegion /usr/include/libs3.h" for me?

In Debian this returns nothing, resulting in the first error I got:

s3_driver.c: In member function 'virtual bool s3_driver::init(JCR*,
cloud_dev*, DEVRES*)':
s3_driver.c:561:10: error: 'S3BucketContext' {aka 'struct
S3BucketContext'} has no member named 'authRegion'
s3ctx.authRegion = cloud->region;

Since Ubuntu has the same old version, you should see this as well,
unless s3_driver.c is never compiled.

But I will check if Ubuntu somehow has some local patches in their libs3
I missed.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-20 Thread Sven Hartge 
On 20.12.18 12:08, Kern Sibbald wrote:

> I wrote this code about 2 years ago, so I think I had forgotten a
> few things that are starting to come back. I do remember having to
> patch libs3 to bring it more up to date, but what I did not remember
> was that apparently I installed it in /usr/local.
> 
> It appears that I downloaded libs3-20161222 from github and
> installed it.  This is what I have in my /depkgs directory.
> However, there might be a newer version.

I see.

I threw together a version based on libs3-20161214.06a4683 from Github,
adding two patches to be able to compile with a newer libcurl and to fix
some buffer overflows.

You can find my work here: https://salsa.debian.org/hartge-guest/libs3/

This version allows the cloud-driver to compile and link but I have not
idea if it works or is safe to use. This is just a proof of concept at
the current moment.

The real shame is the upstream developer of libs3 stopped doing releases
in 2011 and now one has to guess which commit to use.

Red Hat seem to have just arbitrarily used the HEAD state of the master
branch in 2016 and based their version of the libs3 package on that,
same as you did, apparently. Which is why I used those commits for my
version as well.

Problem is: if the version one uses is too new, it again stops working.
It all is a real mess, IMHO.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-20 Thread Sven Hartge 
On 20.12.18 12:47, Kern Sibbald wrote:

> I will download the very latest version they are using (probably 
> patched), and post it on bacula.org.  The version I have no longer
> even compiles :-(

I guess you need both patches from here
https://salsa.debian.org/hartge-guest/libs3/tree/master/debian/patches
to compile with a newer libcurl and a newer GCC.

> I am sure that the Bacula Systems version works well with the code
> since there are a good number of customers using it.

That would be very nice, at least *a* somewhat proven version we may be
able to standardize on.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-20 Thread Sven Hartge 
On 20.12.18 15:41, Kern Sibbald wrote:

> I have also put the latest version of the Bacula libs3 source code into
> 
> https://blog.bacula.org/downloads/libs3-20181010.tar.gz
> 
> This source does not contain the latest patches that you mention below
> to make it work with a newer libcurl and gcc.

Please be extremely careful with the fix-buffer-sizes.patch to request.c.

I just know enough C to be dangerous and hastily threw those fixes
together as a PoC, adapting 4f2db1eb from upstream as best as I could to
the older codebase.

The result is either broken or totally insecure, most probably both!

You better throw away my version of the change and directly base your
changes on upstream commit 4f2db1eb.

Grüße,
Sven.




signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-20 Thread Sven Hartge 
On 20.12.18 15:56, Sven Hartge wrote:

> You better throw away my version of the change and directly base your
> changes on upstream commit 4f2db1eb.

Scratch that comment from me, I should have looked at the version you
uploaded before.

The date in the filename says 2018-10-10, but inside it is the same
version from 2016-12-14 I ended up with.

So my patch *will* apply, but needs a really really *really* good check
from someone who knows what they are doing (i.e. not me).

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Bacula Release 9.4.0

2018-12-20 Thread Sven Hartge 
On 20.12.18 17:07, Kern Sibbald wrote:
> Many thanks for the heads up ...

In fact, the main difference is this here:

--- libs3-2.0+20161214git06a4683/GNUmakefile2016-12-14
19:13:34.0 +0100
+++ libs3-20181010/GNUmakefile  2018-10-11 09:29:33.0 +0200
@@ -136,7 +136,7 @@
 endif
 endif

-CFLAGS += -Wall -Werror -Wshadow -Wextra -Iinc \
+CFLAGS += -Wall -Werror -Wshadow -Wextra -Wno-format-truncation -Iinc \
   $(CURL_CFLAGS) $(LIBXML2_CFLAGS) \
   -DLIBS3_VER_MAJOR=\"$(LIBS3_VER_MAJOR)\" \
   -DLIBS3_VER_MINOR=\"$(LIBS3_VER_MINOR)\" \



This change gets rid of the errors GCC throws by disabling the warning,
while the patch I cooked up tries do address them by changing the way
strncat is used.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] bat and qt4

2019-03-16 Thread Sven Hartge 
On 16.03.19 16:04, Dan Langille wrote:
> I am the FreeBSD maintainer for bat.
> 
> At present, the FreeBSD port depends upon qt4.  Is qt4 still a requirement 
> for bat?
> 
> I ask because:
> 
> * qt4 has been deprecated since December 2015 (i.e. > 3 years)
> * bacula9 bat will be removed from the FreeBSD ports tree today because of 
> that deprecation
> * My attempts today to compile without qt4 fail

bat compiles with Qt5, but you may need to resort to some trickery to
get it to work.

See the following links about the stuff we need to do to get it working
for Debian (and Gentoo):

https://salsa.debian.org/bacula-team/bacula/blob/master/debian/control#L26
https://salsa.debian.org/bacula-team/bacula/blob/master/debian/rules#L14
https://salsa.debian.org/bacula-team/bacula/blob/master/debian/rules#L185
https://salsa.debian.org/bacula-team/bacula/blob/master/debian/patches/debian/fix-qmake-binary-source-path

Not all of that may or may not be applicable to FreeBSD.

Grüße,
Sven.


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

Re: [Bacula-devel] bat and qt4

2019-03-23 Thread Sven Hartge 
On 23.03.19 18:20, Kern Sibbald wrote:

> These links seem to be debian specific issues and are with Bacula 9.0
> and involve the tray-monitor.

No, they involve Qt5.9+ and also happen on Gentoo, for example. They
involve both bat and the tray-monitor. But those problems seem to be
more of a genuine Qt5 issue and not a Bacula issue.

The changes we made for Debian where inspired by the work-arounds Gentoo
carries in their package repository:

https://gitweb.gentoo.org/repo/gentoo.git/tree/app-backup/bacula/bacula-9.0.6-r2.ebuild?id=9b8f311cb9d88f02bebc4bfb51282db4457f87d7#n163

https://gitweb.gentoo.org/repo/gentoo.git/tree/app-backup/bacula/bacula-9.4.2.ebuild#n165

https://bugs.gentoo.org/644566

Grüße,
Sven



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Failed to compile Bacula 9.6.0 and problem with documentation encoding

2020-02-24 Thread Sven Hartge 
On 24.02.20 12:34, Wanderlei Huttel wrote:

> I've tried to to compile, bu I've receiving an error message in console.c.
> =
> Compiling console.c
> /usr/src/bacula/bacula/libtool --silent --tag=CXX --mode=link
> /usr/bin/g++  -L/usr/include/readline -L../lib -L../cats -o bbconsjson
> bbconsjson.o console_conf.o \
>        -lreadline -lhistory  -lbaccfg -lbac -lm -lpthread -ldl -ldl   \
>       -lssl -lcrypto
> In file included from ../bacula.h:165:0,
>                  from console.c:27:
> console.c: In function ‘int console_update_history(const char*)’:
> console.c:948:21: error: ‘histfile_size’ was not declared in this scope
>     int nlines = MAX(histfile_size - history_lines_added, 0);
>                      ^
> ../bc_types.h:246:21: note: in definition of macro ‘MAX’
>  #define MAX(a, b) ((a) > (b) ? (a) : (b))
>                      ^
> Makefile:144: recipe for target 'console.o' failed
> make[1]: *** [console.o] Error 1
> make[1]: Leaving directory '/usr/src/bacula/bacula/src/console'
> 
> 
>   == Error in /usr/src/bacula/bacula/src/console ==
>   =  

I confirm the error, I see the same in my Debian buildroots.

https://salsa.debian.org/bacula-team/bacula/-/jobs/578812#L2750

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Failed to compile Bacula 9.6.0 and problem with documentation encoding

2020-02-24 Thread Sven Hartge 
On 24.02.20 12:34, Wanderlei Huttel wrote:

> console.c: In function ‘int console_update_history(const char*)’:
> console.c:948:21: error: ‘histfile_size’ was not declared in this scope
>     int nlines = MAX(histfile_size - history_lines_added, 0);

I think the fix for #5944 via 8135b9d21d is incomplete, causing the error.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] 9.6.0 compile errors

2020-02-24 Thread Sven Hartge 
On 24.02.20 18:35, Dan Langille wrote:
> I noticed the 9.6.0 tarballs today and tried building them.
> 
> I'm getting:
> 
> console.c:950:20: error: use of undeclared identifier 'histfile_size'
> 4 errors generated.
> *** [console.o] Error code 1

Yeah, compilation is broken with libreadline at the moment.

Grüße,
Sven


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

[Bacula-devel] Possible GPL licence violation via docker/baculatar/tar binary

2020-02-26 Thread Sven Hartge 
Hi!

I (or more lintian from Debian) just noticed there is a pre-compiled
UPX-compressed binary GNU tar 1.29 in
"bacula/src/plugins/fd/docker/baculatar" without sources.

I don't think this is a wise idea, because now the sources as they are
are not redistributable (as far as my understanding of the GPL goes) and
because the binary is AMD64-only it will be useless for any other
architecture where Docker is available.

Because there is a script (createimage.sh) available which will build a
static tar on demand, I suggest removing the precompiled binary from the
sources, avoiding any problems resulting from its inclusion.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Possible GPL licence violation via docker/baculatar/tar binary

2020-02-26 Thread Sven Hartge 
On 26.02.20 19:47, kern wrote:

> I am not the developer of the plugin, but I can assure you that my plan
> was to release the full source code.
> 
> I will look into this and get back to you hopefully tomorrow.

The createimage.sh script pulls the needed sources from GitHub and
(re)builds the needed static tar, there should be no need to ship a
precompiled binary inside the Bacula sources.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Possible GPL licence violation via docker/baculatar/tar binary

2020-02-27 Thread Sven Hartge 
On 27.02.20 14:26, Kern Sibbald wrote:

> As far as I can tell there is no GPL violation because all the source
> files needed to build that binary have been released, it is simply a
> matter of deleting the binary prior to re-distribution.

This will suffice, I concur with the analysis of the situation by Radosław.

We (Debian) will still need to sanitise the tar archive by repacking it
before distributing it, because the source code must be self-contained.

This also means we cannot easily ship the Docker plugin because during
the build stage no network access is allowed.

But that is a minor issue and does not concern you as upstream.

Grüße,
Sven.


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

Re: [Bacula-devel] Possible GPL licence violation via docker/baculatar/tar binary

2020-02-27 Thread Sven Hartge 
On 27.02.20 14:44, Radosław Korzeniewski wrote:
> Hello,
> 
> czw., 27 lut 2020 o 14:34 Sven Hartge  <mailto:s...@svenhartge.de>> napisał(a):
> 
> On 27.02.20 14:26, Kern Sibbald wrote:
> 
> > As far as I can tell there is no GPL violation because all the source
> > files needed to build that binary have been released, it is simply a
> > matter of deleting the binary prior to re-distribution.
> 
> This will suffice, I concur with the analysis of the situation by
> Radosław.
> 
> We (Debian) will still need to sanitise the tar archive by repacking it
> before distributing it, because the source code must be self-contained.
> 
> 
> Sure, which does not mean any GPL binary distribution was violated, right?

No, my assessment was a bit overly hasty, I apologize.

> This also means we cannot easily ship the Docker plugin because during
> the build stage no network access is allowed.

> The baculatar is not part of Bacula or Bacula Docker Plugin but it is a
> separate Docker container image. Bacula Docker Plugin does not require
> baculatar Docker image to run. It extends plugin features executing this
> container during Docker volume backup. In Bacula Enterprise it is
> distributed as a separate package.

I think the best action for any distribution would be ship the
baculatar-part as example for the local admin who wishes to create the
needed container image themselves instead of trying to ship anything
inside the packages.

I have to meditate a bit over this and conference with my Co-Mainainer
Carsten on that issue.

Grüße,
Sven.


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

Re: [Bacula-devel] Possible GPL licence violation via docker/baculatar/tar binary

2020-02-27 Thread Sven Hartge 
On 27.02.20 15:02, Radosław Korzeniewski wrote:

> The required Docker container image should be built with
> supplied createimage.sh script.

The problem here is that Debian does not allow *any* network access
during the build-phase.

So checking out musl and tar from GitHub and building it is right out of
the question.

Grüße,
Sven.


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

Re: [Bacula-devel] Hung jobs: continued diagnosis

2020-07-12 Thread Sven Hartge 
On 12.07.20 17:38, Phil Stracchino wrote:

> This problem is very clearly tied to the 9.6.5 Director as a regression
> from 9.6.3, and there are strong hints that it has to do with how the
> Director is talking to the database.

I can throw one datapoint at you:

Before 9.6.5 the director never consumed more that 150 default database
connections (I don't have the exact number from before the update).

With 9.6.5 it suddenly hit the 150 connection limit and I had to up this
to 500, with now 282 used max connections, which is one connection less
then the amount of clients currently configured (283).

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] Hung jobs: continued diagnosis

2020-07-14 Thread Sven Hartge 

On 15.07.20 00:05, Phil Stracchino wrote:


1.  The triggering condition is when a DB record insertion fails for any
reason, *including recoverable failures* such as InnoDB rollbacks.
(MySQL uses rollbacks to notify the application of any of several types
of transient error, including deadlocks or lock wait time exceeded
during a transaction.  Galera *additionally* uses InnoDB rollbacks to
notify the application of a local commit conflict between nodes.)

2.  The correct action in the case of receiving a rollback from a
MySQL-compatible DB, either standalone *or* a Galera cluster, is to make
at least one attempt to resubmit the transaction.  Instead, Bacula's
MySQL driver is regarding all errors as fatal and immediately aborting
the entire job without retrying the insert.

3.  When the job is aborted because of a DB insertion error, the job is
marked as having a fatal error, but is not properly terminated, and
hangs indefinitely, potentially blocking other jobs with lower
priorities or waiting for the resources the hung job is using.

4.  The fatal error status is correctly reported in bconsole by 'status
dir', but the jobs list in BAT shows the job as still running because it
has not terminated.

5.  The failed job CAN be cancelled, but to complete the termination of
the job takes a long time, and if a second job is cancelled before the
first cancellation has completed, there is an extremely high likelihood
that the Director will crash.

6.  The bug manifests only in 9.6.5.


Looking at my logs, I have seen the same in my 9.6.5 installation on 
Debian 10:


Excerpts from Error/Canceled-Mails:

-

24-Jun 00:02 back-dir JobId 585301: Error: bdb.h:140 bdb.h:140 update 
UPDATE Job SET JobStatus='R',Level='I',StartTime='2020-06-24 
00:02:58',ClientId=73,JobTDate=1592949778,PoolId=7,FileSetId=427 WHERE 
JobId=585301 failed:

Deadlock found when trying to get lock; try restarting transaction

24-Jun 00:02 back-dir JobId 585301: Fatal error: bdb.h:140 update UPDATE 
Job SET JobStatus='R',Level='I',StartTime='2020-06-24 
00:02:58',ClientId=73,JobTDate=1592949778,PoolId=7,FileSetId=427 WHERE 
JobId=585301 failed:

Deadlock found when trying to get lock; try restarting transaction

-

28-Jun 00:02 back-dir JobId 586375: Error: bdb.h:140 bdb.h:140 update 
UPDATE Job SET JobStatus='R',Level='I',StartTime='2020-06-28 
00:02:24',ClientId=149,JobTDate=1593295344,PoolId=7,FileSetId=153 WHERE 
JobId=586375 failed:

Deadlock found when trying to get lock; try restarting transaction

28-Jun 00:02 back-dir JobId 586375: Fatal error: bdb.h:140 update UPDATE 
Job SET JobStatus='R',Level='I',StartTime='2020-06-28 
00:02:24',ClientId=149,JobTDate=1593295344,PoolId=7,FileSetId=153 WHERE 
JobId=586375 failed:

Deadlock found when trying to get lock; try restarting transaction

-

09-Jul 00:04 back-dir JobId 589511: Error: bdb.h:140 bdb.h:140 update 
UPDATE Job SET JobStatus='R',Level='I',StartTime='2020-07-09 
00:04:16',ClientId=255,JobTDate=1594245856,PoolId=7,FileSetId=408 WHERE 
JobId=589511 failed:

Deadlock found when trying to get lock; try restarting transaction

09-Jul 00:04 back-dir JobId 589511: Fatal error: bdb.h:140 update UPDATE 
Job SET JobStatus='R',Level='I',StartTime='2020-07-09 
00:04:16',ClientId=255,JobTDate=1594245856,PoolId=7,FileSetId=408 WHERE 
JobId=589511 failed:

Deadlock found when trying to get lock; try restarting transaction

-

This is with a remote MariaDB 10.3 server, i.e. the database is not on 
the same server but exclusive for Bacula.


Grüße,
Sven.


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

[Bacula-devel] Bacula and OpenSSL3.0

2020-09-02 Thread Sven Hartge 
Hi .*,

Just FYI, in case it is not on your radar: OpenSSL3.0 is nearing its
completion and again deprecates a number of API, some of which are used by
Bacula:

[...]
Compiling crypto.c
/build/bacula-9.6.5/libtool --tag=CXX --mode=compile /usr/bin/g++   -c  
-Wdate-time -D_FORTIFY_SOURCE=2 -x c++ -fno-strict-aliasing -fno-exceptions 
-fno-rtti  -I. -I..  -g -O2 -fdebu
g-prefix-map=/build/bacula-9.6.5=. -fstack-protector-strong -Wformat 
-Werror=format-security -x c++ -fno-strict-aliasing -fno-exceptions -fno-rtti  
crypto.c
libtool: compile:  /usr/bin/g++ -c -Wdate-time -D_FORTIFY_SOURCE=2 -x c++ 
-fno-strict-aliasing -fno-exceptions -fno-rtti -I. -I.. -g -O2 
-fdebug-prefix-map=/build/bacula-9.6.5=. -fst
ack-protector-strong -Wformat -Werror=format-security -x c++ 
-fno-strict-aliasing -fno-exceptions -fno-rtti crypto.c  -fPIC -DPIC -o 
.libs/crypto.o
crypto.c: In function 'CRYPTO_SESSION* crypto_session_new(crypto_cipher_t, 
alist*)':
crypto.c:1095:99: warning: 'int EVP_PKEY_encrypt_old(unsigned char*, const 
unsigned char*, int, EVP_PKEY*)' is deprecated [-Wdeprecated-declarations]
 1095 |   if ((ekey_len = EVP_PKEY_encrypt(ekey, cs->session_key, 
cs->session_key_len, keypair->pubkey)) <= 0) {
  | 
  ^
In file included from /usr/include/openssl/opensslv.h:109,
 from /usr/include/openssl/macros.h:11,
 from /usr/include/x86_64-linux-gnu/openssl/opensslconf.h:14,
 from /usr/include/openssl/macros.h:10,
 from /usr/include/openssl/ssl.h:16,
 from ../bacula.h:147,
 from crypto.c:37:
/usr/include/openssl/evp.h:1132:1: note: declared here
 1132 | DEPRECATEDIN_3_0(int EVP_PKEY_encrypt_old(unsigned char *enc_key,
  | ^~~~
crypto.c: In function 'crypto_error_t crypto_session_decode(const u_int8_t*, 
u_int32_t, alist*, CRYPTO_SESSION**)':
crypto.c:1215:89: warning: 'int EVP_PKEY_decrypt_old(unsigned char*, const 
unsigned char*, int, EVP_PKEY*)' is deprecated [-Wdeprecated-declarations]
 1215 |   ASN1_STRING_length(ri->encryptedKey), 
keypair->privkey);
  | 
^
In file included from /usr/include/openssl/opensslv.h:109,
 from /usr/include/openssl/macros.h:11,
 from /usr/include/x86_64-linux-gnu/openssl/opensslconf.h:14,
 from /usr/include/openssl/macros.h:10,
 from /usr/include/openssl/ssl.h:16,
 from ../bacula.h:147,
 from crypto.c:37:
/usr/include/openssl/evp.h:1128:1: note: declared here
 1128 | DEPRECATEDIN_3_0(int EVP_PKEY_decrypt_old(unsigned char *dec_key,
  | ^~~~
[...]

Grüße,
Sven.


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

Re: [Bacula-devel] Bacula Release 9.6.6

2020-09-24 Thread Sven Hartge 
Um 14:42 Uhr am 24.09.20 schrieb Kern Sibbald:

> Unless there is some new major bug found, this will be the last of the 
> 9.6.x releases. The next release major release (a really big one) is 
> currently scheduled for December.

During compilation on 32bit Debian Sid with gcc (Debian 10.2.0-9) 10.2.0
the following happened:

fstype.c: In function 'bool fstype(FF_PKT*, char*, int)':
fstype.c:207:12: error: narrowing conversion of '4283649346' from 'unsigned 
int' to 'int' [-Wnarrowing]
  207 |   case 0xFF534D42: fstype = "cifs"; break;  /* 
CIFS_MAGIC_NUMBER */
  |^~
fstype.c:216:12: error: narrowing conversion of '4187351113' from 'unsigned 
int' to 'int' [-Wnarrowing]
  216 |   case 0xf995e849: fstype = "hpfs"; break;  /* 
HPFS_SUPER_MAGIC */
  |^~
fstype.c:217:12: error: narrowing conversion of '2508478710' from 'unsigned 
int' to 'int' [-Wnarrowing]
  217 |   case 0x958458f6: fstype = "hugetlbfs"; break; /* 
HUGETLBFS_MAGIC */
  |^~
fstype.c:234:12: error: narrowing conversion of '2768370933' from 'unsigned 
int' to 'int' [-Wnarrowing]
  234 |   case 0xa501FCF5: fstype = "vxfs"; break;
  |^~
fstype.c:237:12: error: narrowing conversion of '2435016766' from 'unsigned 
int' to 'int' [-Wnarrowing]
  237 |   case 0x9123683e: fstype = "btrfs"; break;
  |^~
make[3]: *** [Makefile:150: fstype.lo] Error 1
make[3]: *** Waiting for unfinished jobs
make[3]: Leaving directory '/build/bacula-9.6.6/src/findlib'

The full build log is available at 
https://salsa.debian.org/bacula-team/bacula/-/jobs/1023910

Applying the following change fixes this problem:

--- a/src/findlib/fstype.c
+++ b/src/findlib/fstype.c
@@ -188,7 +188,7 @@
*
*$ grep -r SUPER_MAGIC /usr/include/linux
*/
-  switch (st.f_type) {
+  switch ((unsigned int)st.f_type) {
   /* Known good values */
   /* ext2, ext3, and ext4 have the same code */
   case 0xef53: fstype = "ext2"; break;  /* 
EXT2_SUPER_MAGIC */

The documentation of statfs(2) says:

,
| The __fsword_t type used for various fields in the statfs structure
| definition is a glibc internal type, not intended for public use.  This
| leaves the programmer in a  bit  of  a conundrum when trying to copy or
| compare these fields to local variables in a program.  Using unsigned int
| for such variables suffices on most systems.
`

Which explains why st.f_type is architecture dependent and fails on the
stricter GCC10.

Grüße,
Sven.


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

Re: [Bacula-devel] git repository for docs seems mangled

2020-09-25 Thread Sven Hartge 
On 25.09.20 23:35, Kern Sibbald wrote:

> Since quite some time, there has been a problem with cgit on 
> bacula.org.  The only repo that it properly handles is bacula.git.
> The two other repos libs3.git and docs.git do not work. I have spent
> a lot of time on this problem, but have not yet solved it. Note: docs
> has been on bacula.org for years, but has never worked.  libs3 is
> relatively new (a few months) but it does not work either. Both repos
> are there and working, but making them public via cgit just does not
> work.

I have both the source and the docs GIT cloned to my workstation and the
docs remoted stopped working some time ago:

host:~/git/bacula-docs (Branch-9.4)$ git pull --all
Fetching origin
fatal: repository 'http://git.bacula.org/docs.git/' not found
error: Could not fetch origin
host:~/git/bacula-docs (Branch-9.4)$ git remote -v
origin  http://git.bacula.org/docs.git (fetch)
origin  http://git.bacula.org/docs.git (push)

bacula.git on the other hand works, though.

Clearyl something more than just cgit is broken here.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature
___
Bacula-devel mailing list
Bacula-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Re: [Bacula-devel] git repository for docs seems mangled

2020-09-28 Thread Sven Hartge 
Um 19:49 Uhr am 28.09.20 schrieb Kern Sibbald:

> Can you tell me why the version at xdocs.git works and
> the one at docs.git does not work.  Note: the one at xdocs.git
> was deleted a few days ago by me since it was out of date.
> 
> I believe that I have now fixed the web interface to the three
> repos (bacula.git, docs.git, and libs3.git) but only bacula.git
> can be checked out.  I still do not know why the other two
> fail.

Adding some tracing to git shows this:

oweh@host:/tmp$ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone 
http://git.bacula.org/docs.git
20:55:19.999684 git.c:444   trace: built-in: git clone 
http://git.bacula.org/docs.git
Cloning into 'docs'...
20:55:20.001167 run-command.c:663   trace: run_command: git-remote-http 
origin http://git.bacula.org/docs.git
20:55:20.009944 http.c:756  == Info: Couldn't find host 
git.bacula.org in the .netrc file; using defaults
20:55:20.012961 http.c:756  == Info:   Trying 80.244.178.6:80...
20:55:20.047773 http.c:756  == Info: Connected to git.bacula.org 
(80.244.178.6) port 80 (#0)
20:55:20.047882 http.c:703  => Send header, 000206 bytes 
(0x00ce)
20:55:20.047893 http.c:715  => Send header: GET 
/docs.git/info/refs?service=git-upload-pack HTTP/1.1
20:55:20.047912 http.c:715  => Send header: Host: git.bacula.org
20:55:20.047923 http.c:715  => Send header: User-Agent: git/2.28.0
20:55:20.047934 http.c:715  => Send header: Accept: */*
20:55:20.047944 http.c:715  => Send header: Accept-Encoding: 
deflate, gzip, br
20:55:20.047953 http.c:715  => Send header: Accept-Language: en-US, 
*;q=0.9
20:55:20.047962 http.c:715  => Send header: Pragma: no-cache
20:55:20.047972 http.c:715  => Send header:
20:55:20.076289 http.c:756  == Info: Mark bundle as not supporting 
multiuse
20:55:20.076320 http.c:703  <= Recv header, 24 bytes 
(0x0018)
20:55:20.076331 http.c:715  <= Recv header: HTTP/1.1 404 Not Found
20:55:20.076340 http.c:703  <= Recv header, 37 bytes 
(0x0025)
20:55:20.076346 http.c:715  <= Recv header: Date: Mon, 28 Sep 2020 
18:55:20 GMT
20:55:20.076353 http.c:703  <= Recv header, 32 bytes 
(0x0020)
20:55:20.076360 http.c:715  <= Recv header: Server: Apache/2.4.18 
(Ubuntu)
20:55:20.076369 http.c:703  <= Recv header, 21 bytes 
(0x0015)
20:55:20.076375 http.c:715  <= Recv header: Content-Length: 276
20:55:20.076383 http.c:703  <= Recv header, 19 bytes 
(0x0013)
20:55:20.076389 http.c:715  <= Recv header: Connection: close
20:55:20.076397 http.c:703  <= Recv header, 45 bytes 
(0x002d)
20:55:20.076403 http.c:715  <= Recv header: Content-Type: 
text/html; charset=iso-8859-1
20:55:20.076411 http.c:703  <= Recv header, 02 bytes 
(0x0002)
20:55:20.076417 http.c:715  <= Recv header:
20:55:20.076437 http.c:756  == Info: Closing connection 0
fatal: repository 'http://git.bacula.org/docs.git/' not found

Which is correct, there is no http://git.bacula.org/docs.git/info/refs,
while it *is* present in the bacula.git repository:

oweh@host:/tmp$ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone 
http://git.bacula.org/bacula.git
20:54:16.295863 git.c:444   trace: built-in: git clone 
http://git.bacula.org/bacula.git
Cloning into 'bacula'...
20:54:16.298342 run-command.c:663   trace: run_command: git-remote-http 
origin http://git.bacula.org/bacula.git
20:54:16.306929 http.c:756  == Info: Couldn't find host 
git.bacula.org in the .netrc file; using defaults
20:54:16.309534 http.c:756  == Info:   Trying 80.244.178.6:80...
20:54:16.336949 http.c:756  == Info: Connected to git.bacula.org 
(80.244.178.6) port 80 (#0)
20:54:16.337081 http.c:703  => Send header, 000208 bytes 
(0x00d0)
20:54:16.337105 http.c:715  => Send header: GET 
/bacula.git/info/refs?service=git-upload-pack HTTP/1.1
20:54:16.337129 http.c:715  => Send header: Host: git.bacula.org
20:54:16.337137 http.c:715  => Send header: User-Agent: git/2.28.0
20:54:16.337144 http.c:715  => Send header: Accept: */*
20:54:16.337151 http.c:715  => Send header: Accept-Encoding: 
deflate, gzip, br
20:54:16.337157 http.c:715  => Send header: Accept-Language: en-US, 
*;q=0.9
20:54:16.337164 http.c:715  => Send header: Pragma: no-cache
20:54:16.337168 http.c:715  => Send header:
20:54:16.367859 http.c:756  == Info: Mark bundle as not supporting 
multiuse
20:54:16.367897 http.c:703  <= Recv header, 17 bytes 
(0x0011)
20:54:16.367912 http.c:715  <= Recv header: HTTP/1.1 200 OK
20:54:16.367925 h

Re: [Bacula-devel] git repository for docs seems mangled

2020-09-29 Thread Sven Hartge 
On 29.09.20 16:54, Wanderlei Huttel wrote:

> Have you think about migrate  bacula community source code to github
> instead using an git page exlusive from Bacula?

Or GitLab, if Github is too much Microsoft.

Or switch to an self-hosted Gitea instance, like I do for my private
projects (and internally at my employer).

Grüße,
Sven.



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

Re: [Bacula-devel] git repository for docs seems mangled

2020-09-30 Thread Sven Hartge 
On 30.09.20 09:57, Kern Sibbald wrote:

> Oh, there seem to be plenty of articles about self-hosting gitea,
> so you can ignore my request -- however, if you have some special
> tips, I would appreciate hearing them.

It really is quite straight-forward. Configuring the ini-file, starting
the service, configuring Apache/Nginx to do the pass-through, done.

I guess you may want to disable the integrated issue tracker and wiki
because you have external solutions for this.

Also disabling the self-registration of users may be wise in your context.

And unless you want to add hundreds of users to the instance you can
even keep the default SQLite database backend.

Grüße,
Sven.


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

Re: [Bacula-devel] git repository for docs seems mangled

2020-09-30 Thread Sven Hartge 
On 30.09.20 09:53, Kern Sibbald wrote:

> Even if I resolve that problem, I am not 100% sure that I want to keep
> it on github, because
> the repo is already on bacula.org, so having one more place to push it
> is just extra work.

You can configure the Github repository to be a read-only mirror of your
own git repository. Disable the wiki and issue tracker on Github to
avoid anyone using that instead of the existing ones.

Then you have at least a second official backup mirror if something goes
sideways on the main host.

Grüße,
Sven.


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

Re: [Bacula-devel] git repository for docs seems mangled

2020-09-30 Thread Sven Hartge 
Um 10:04 Uhr am 30.09.20 schrieb Sven Hartge:

> On 30.09.20 09:57, Kern Sibbald wrote:
> 
> > Oh, there seem to be plenty of articles about self-hosting gitea,
> > so you can ignore my request -- however, if you have some special
> > tips, I would appreciate hearing them.
> 
> It really is quite straight-forward. Configuring the ini-file, starting
> the service, configuring Apache/Nginx to do the pass-through, done.

As reference from my "git.employer.domain" host:



[... other stuff ...]

AllowEncodedSlashes NoDecode

ProxyPreserveHost On
AllowEncodedSlashes NoDecode
ProxyPass / http://localhost:3000/ nocanon
ProxyPassReverse / http://localhost:3000/

[... other stuff ...]



(The "AllowEncodedSlashes NoDecode" is the only real pitfall here. Things 
can get wonky if it is missing.)
 
Grüße,
Sven.


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

Re: [Bacula-devel] Problem in git bacula

2020-10-26 Thread Sven Hartge 

On 26.10.20 19:46, Wanderlei Huttel wrote:


Following the link with screenshot:
https://imgur.com/a/ZCqOa0M 


I can confirm, it is as broken for me. Browser Debug console confirms 
https://www.bacula.org/cgit.css is 404.




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

[Bacula-devel] Bug#2584: MySQL schema broken for MariaDB 10.5

2020-11-28 Thread Sven Hartge 
Hallo .*,

This references https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975970
and https://bugs.bacula.org/view.php?id=2584, both filed by Radoslav Bodó,
the latter on my request.

It seems MariaDB 10.5 has stricter schema checking when using foreign keys
and references.

(Yes, I know, MariaDB is not officially supported, but I think the same 
strictness applies to newer MySQL versions as well. Also all major Linux 
distributions now ship MariaDB as their default SQL server, so having a 
working schema would be a low hanging fruit.)

This uncovers some problems with the current MySQL schema in 9.6.6:

1) Tables need to be created before they can be referenced.

For example Job.PoolId references Pool.PoolId which fails
because Pool is created later. One may be able to fix this by reordering
the tables in the schema file. But I am under the unverified impression
that some references are circular. In that case one needs to disable the
foreign key checks before being able to import the schema.

2) Column definition must be exact.

This is wrong for ClientId which is sometimes defined as "INTEGER" and
sometimes as "INTEGER UNSIGNED". Those need to be identical.

3) Referenced Columns need to exist.

BaseFiles.BaseJobId REFERENCES Job, but table Job does not contain
BaseJobId, so this fails as well.

4) Constraints seem to fail and may even not be needed.

As Radoslav Bodó mentions in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975970#20
the foreign key constraints fail and may even not be needed, compared to
the Postgres schema.

More input here would be nice.

Debian freezes in the not so far future and it would really be a shame if
we need to remove Bacula from it or abandon the MySQL version because of
this.

Grüße,
Sven.



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

Re: [Bacula-devel] Bug#2584: MySQL schema broken for MariaDB 10.5

2020-11-30 Thread Sven Hartge 

On 30.11.20 09:16, Eric Bollengier via Bacula-devel wrote:


Thanks for the suggestions, we will fix the schema file following your
tips, MySQL was not very strict in the past, now it is painful and
difficult to get back on track. I guess many programs will have the same
kind of issues with such migration.


Please also follow what Radoslav Bodó wroe, he is the one noticing the 
defect and doing most of the legwork here. Any credit should go to him.


Grüße,
Sven.





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

Re: [Bacula-devel] Bug#2584: MySQL schema broken for MariaDB 10.5

2020-11-30 Thread Sven Hartge 

On 30.11.20 09:16, Eric Bollengier via Bacula-devel wrote:


Thanks for the suggestions, we will fix the schema file following your
tips, MySQL was not very strict in the past, now it is painful and
difficult to get back on track. I guess many programs will have the same
kind of issues with such migration.


Are there any plans for a timely 9.6.x maintenance release to publish 
the changes you made today?


If not I will pull those as separate patches into the Debian package to 
keep Bacula fit for release.


Grüße,
Sven.


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

Re: [Bacula-devel] Bug#2584: MySQL schema broken for MariaDB 10.5

2020-11-30 Thread Sven Hartge 

On 30.11.20 13:04, Eric Bollengier via Bacula-devel wrote:

On 2020-11-30 12:55, Sven Hartge wrote:



Are there any plans for a timely 9.6.x maintenance release to publish
the changes you made today?



If not I will pull those as separate patches into the Debian package to
keep Bacula fit for release.



I'm planing to do a new major release this week (11.0.0), and we can
probably release a minor version for 9.6 as the same time. We still have
a couple of issues with patches to review in the bug tracker.


There is still ample time to get 11.x into Debian, so if you want to 
focus on that, this is fine.


Grüße,
Sven.


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

Re: [Bacula-devel] Bug#2584: MySQL schema broken for MariaDB 10.5

2020-11-30 Thread Sven Hartge 

On 30.11.20 13:04, Eric Bollengier via Bacula-devel wrote:


I'm planing to do a new major release this week (11.0.0), and we can
probably release a minor version for 9.6 as the same time. We still have
a couple of issues with patches to review in the bug tracker.


Please forgive me for speaking out of line, but the last Bacula .0 
releases haven't been as polished as they could have been. Quite some 
bugs where found by the different distribution developers and 
integrators, making it necessary for a .1 or .2 release soon after.


I think it would be helpful to put put a RC pre-release, so other people 
outside of Bacula are able to test the code before committing to a final 
release.


Grüße,
Sven.


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

Re: [Bacula-devel] Bug#2584: MySQL schema broken for MariaDB 10.5

2020-12-02 Thread Sven Hartge 

On 30.11.20 13:14, Sven Hartge wrote:

There is still ample time to get 11.x into Debian, so if you want to 
focus on that, this is fine.


And by "ample time" I mean: It has to be in Unstable no later than 
2021-01-11, when the first stage of the Release Freeze for Bullseye begins.


After that we can no longer upload new large upstream versions. Bug 
fixes will still be possible, though.


Grüße,
Sven.


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

[Bacula-devel] Release 11.0.0 not signed by correct key

2020-12-06 Thread Sven Hartge 
Hello!

When trying to import the new 11.0.0 release into Debian our tooling 
complains about it not being signed by the correct key.

Until now, every release was signed by the key from 
https://blog.bacula.org/downloads/Bacula-4096-Distribution-Verification-key.asc 
with the ID 5235F5B668D81DB61704A82DC0BE2A5FE9DF3643:

pub   rsa4096 2018-09-03 [SC]
  5235F5B668D81DB61704A82DC0BE2A5FE9DF3643
uid   Bacula 4096 Distribution Verification Key (www.bacula.org) 


The new release is signed by

gpgv: Signature made Do 03 Dez 2020 20:25:53 CET
gpgv:using RSA key 
270AC5018ED80662804BE9E97E73F0869FEC1047
gpgv:issuer "techt...@baculasystems.com"

but I am not able to find any official statement about this new key.

Grüße,
Sven.


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

Re: [Bacula-devel] Release 11.0.0 not signed by correct key

2020-12-07 Thread Sven Hartge 

On 07.12.20 09:10, Eric Bollengier via Bacula-devel wrote:


You are a little bit too fast, and I'm a little bit too slow :-) I hope
it will be solved in the next days.


The Debian Tracker for Bacula warned me, that a new relese was ... 
released and thus I started the packaging process, hitting the signature 
wall.


As long as you already aware of the issue, everything is OK.

I already did a cursory glance over the diff between 9.6.6 and 11.0.0 
and I found some stuff I will send a separate mail about. Things like 
copyright dates changed into the past and missing changes from the 
Changelog.


Grüße,
Sven.


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

Re: [Bacula-devel] Release 11.0.0 not signed by correct key

2020-12-07 Thread Sven Hartge 

On 07.12.20 16:15, Phil Stracchino wrote:


So I presume it safe to infer that 11.0 is a MAJOR update?


Yes, it is.

Grüße,
Sven.


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

Re: [Bacula-devel] Release 11.0.0 not signed by correct key

2020-12-07 Thread Sven Hartge 

On 07.12.20 16:23, Phil Stracchino wrote:

On 12/7/20 10:15 AM, Phil Stracchino wrote:

So I presume it safe to infer that 11.0 is a MAJOR update?



I'll pull it and do a test build on Solaris 11.


...except I need to pull from a different target, right?  Someone wnat
to give me a pointer here?


Well, 11.0.0 *was* available from 
https://sourceforge.net/projects/bacula/files/ but it seems to have been 
pulled, I guess because of the problems with the GPG signature I mentioned.


Grüße,
Sven.


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

Re: [Bacula-devel] Bacula Release 9.6.7

2020-12-10 Thread Sven Hartge 
Um 16:43 Uhr am 10.12.20 schrieb Eric Bollengier via Bacula-devel:

> We are pleased to announce the release of Bacula version 9.6.7. This is
> a minor bug fix release among other things the MySQL/MariaDB
> schemas.

I am really sorry to be this pedantic about this, but the signature is again
not made by the key verifiable via the pubkey from
https://www.bacula.org/bacula-distribution-verification-public-keys/

gpg: Signature made Do 10 Dez 2020 14:59:56 CET
gpg:using RSA key 16FCF91DCBDA197436ACA721CAA7F07F2911863C
gpg:issuer "k...@bacula.org"
gpg: Good signature from "Bacula 4096 Distribution Verification Key 
(www.bacula.org) " [unknown]
Primary key fingerprint: 8626 0C02 E82A 8FC5 CA5F  B063 8363 575E FBD8 D142
 Subkey fingerprint: 16FC F91D CBDA 1974 36AC  A721 CAA7 F07F 2911 863C

The key used is:

pub   rsa4096 2017-07-05 [SCEA]
  86260C02E82A8FC5CA5FB0638363575EFBD8D142
uid   Bacula 4096 Distribution Verification Key (www.bacula.org) 

sub   rsa4096 2017-07-05 [SEA]

But the key from the page is:

pub   rsa4096 2018-09-03 [SC]
  5235F5B668D81DB61704A82DC0BE2A5FE9DF3643
uid   Bacula 4096 Distribution Verification Key (www.bacula.org) 

sub   rsa4096 2018-09-03 [E]

This means I can't import the sources into Debian right now.

Grüße,
Sven.


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

Re: [Bacula-devel] Signing keys

2020-12-11 Thread Sven Hartge 

On 11.12.20 10:17, Kern Sibbald wrote:


If you find any additional problems, please let me know.


One nitpick is that the signatures are bundled into the 
bacula-sigs-9.6.7.tar.gz, but at least the Debian system for downloading 
and verifying upstream releases cannot use this (to my knowledge), as it 
expects the signature file to be available as tarbal-name.sig


If you could just replace the already existing bacula-*.tar.gz.sig 
files, this would help us tremendously.


Other that that, by manually extracting the correct signature file, I 
can confirm it now verifies correctly with the pubkey from the website.


Grüße,
Sven.


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

Re: [Bacula-devel] Signing keys

2020-12-11 Thread Sven Hartge 

On 11.12.20 16:13, Kern Sibbald wrote:

The individual .sig files are all available in the download area 
directly.  The bacula-sig tar file is for convenience, and is the only one
that is listed in the WordPress download area.  We have been doing it 
that way for years.  Perhaps you misunderstood my email -- I have

replaced all the .sig files with the correct version.


Hmm, then the SF:net system lied to you, because when I look at 
https://sourceforge.net/projects/bacula/files/bacula/9.6.7/ the only 
changed file is bacula-sigs-9.6.7.tar.gz.


https://sourceforge.net/projects/bacula/files/bacula/9.6.7/bacula-9.6.7.tar.gz.sig 
is still the same as before, containing the signature made with 
16FCF91DCBDA197436ACA721CAA7F07F2911863C


And thus, uscan (the tool to download and verify upstream releases) 
correctly complains about this:


uscan:  => Newer package available from:
=> https://qa.debian.org/watch/sf.php/bacula/bacula-9.6.7.tar.gz
uscan info: Downloading upstream package: bacula-9.6.7.tar.gz
uscan info: Requesting URL:
   https://qa.debian.org/watch/sf.php/bacula/bacula-9.6.7.tar.gz
uscan info: Successfully downloaded package: bacula-9.6.7.tar.gz
uscan info: Downloading OpenPGP signature from:
   https://qa.debian.org/watch/sf.php/bacula/bacula-9.6.7.tar.gz.sig 
(pgpsigurlmangled)

   as bacula-9.6.7.tar.gz.sig
uscan info: Requesting URL:
   https://qa.debian.org/watch/sf.php/bacula/bacula-9.6.7.tar.gz.sig
uscan info: Verifying OpenPGP signature ../bacula-9.6.7.tar.gz.sig for 
../bacula-9.6.7.tar.gz

gpgv: Signature made Do 10 Dez 2020 14:59:56 CET
gpgv:using RSA key 16FCF91DCBDA197436ACA721CAA7F07F2911863C
gpgv:issuer "k...@bacula.org"
gpgv: Can't check signature: No public key
uscan die: OpenPGP signature did not verify. at 
/usr/share/perl5/Devscripts/Uscan/Output.pm line 60.


Grüße,
Sven


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

Re: [Bacula-devel] Signing keys

2020-12-11 Thread Sven Hartge 

On 11.12.20 23:10, Kern Sibbald wrote:


I am talking about the public download area on www.bacula.org.

Eric is handling the details of the release on Source Forge.  If there 
are problems there, he will help you.


Ah, that was a misunderstanding then.

The Debian (and I think those of other distributions) mechanism only 
looks at Sourceforge, mainly because the bacula.org download page is not 
really parser friendly.


If Eric could update the sig files in the sf.net download area, this 
would really be appreciated.


Grüße,
Sven.


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

Re: [Bacula-devel] Signing keys

2020-12-12 Thread Sven Hartge 

On 12.12.20 15:39, Eric Bollengier via Bacula-devel wrote:


I believe that it's fixed now.


I can confirm this all checks out now:

uscan:  => Newer package available from:
=> https://qa.debian.org/watch/sf.php/bacula/bacula-9.6.7.tar.gz
uscan info: Downloading upstream package: bacula-9.6.7.tar.gz
uscan info: Requesting URL:
   https://qa.debian.org/watch/sf.php/bacula/bacula-9.6.7.tar.gz
uscan info: Successfully downloaded package: bacula-9.6.7.tar.gz
uscan info: Downloading OpenPGP signature from:
   https://qa.debian.org/watch/sf.php/bacula/bacula-9.6.7.tar.gz.sig 
(pgpsigurlmangled)

   as bacula-9.6.7.tar.gz.sig
uscan info: Requesting URL:
   https://qa.debian.org/watch/sf.php/bacula/bacula-9.6.7.tar.gz.sig
uscan info: Verifying OpenPGP signature ../bacula-9.6.7.tar.gz.sig for 
../bacula-9.6.7.tar.gz

gpgv: Signature made Fr 11 Dez 2020 09:24:28 CET
gpgv:using RSA key 5235F5B668D81DB61704A82DC0BE2A5FE9DF3643
gpgv: Good signature from "Bacula 4096 Distribution Verification Key 
(www.bacula.org) "

uscan info: New orig.tar.* tarball version (oversionmangled): 9.6.7

Grüße,
Sven.


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

Re: [Bacula-devel] Bacula Release 11.0.0 (beta)

2020-12-15 Thread Sven Hartge 

On 15.12.20 10:00, Eric Bollengier via Bacula-devel wrote:


This release of Bacula uses a new catalog format.  We provide a set of
scripts that permit to convert a 9.x and earlier versions to the new
11.0.0 format (1023).  Normally, it is automatic, though this is a big
change that takes longer than usual. The upgrade process will require
more or less twice the size of the actual database on disk.


One thing I can directly see is that the SQlite catalog upgrade is 
broken for DB versions 15 and 16.


The update_sqlite3_tables.in script only accounts for DBVERSION up to 14 
which means upgrades from Bacula 7 and Bacula 9 to Bacula 11 with 
SQLite3 would not be possible.


Grüße,
Sven.



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

Re: [Bacula-devel] Bacula Release 11.0.0 (beta)

2020-12-15 Thread Sven Hartge 

On 15.12.20 10:33, Sven Hartge wrote:

On 15.12.20 10:00, Eric Bollengier via Bacula-devel wrote:



This release of Bacula uses a new catalog format.  We provide a set of
scripts that permit to convert a 9.x and earlier versions to the new
11.0.0 format (1023).  Normally, it is automatic, though this is a big
change that takes longer than usual. The upgrade process will require
more or less twice the size of the actual database on disk.


One thing I can directly see is that the SQlite catalog upgrade is 
broken for DB versions 15 and 16.


With "broken" I mean: non-existent.

Grüße,
Sven.


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

Re: [Bacula-devel] Bacula Release 11.0.0 (beta)

2020-12-15 Thread Sven Hartge 

On 15.12.20 12:46, Gary R. Schmidt wrote:

On 15/12/2020 20:41, Sven Hartge wrote:

On 15.12.20 10:33, Sven Hartge wrote:

On 15.12.20 10:00, Eric Bollengier via Bacula-devel wrote:



This release of Bacula uses a new catalog format.  We provide a set of
scripts that permit to convert a 9.x and earlier versions to the new
11.0.0 format (1023).  Normally, it is automatic, though this is a big
change that takes longer than usual. The upgrade process will require
more or less twice the size of the actual database on disk.


One thing I can directly see is that the SQlite catalog upgrade is 
broken for DB versions 15 and 16.


With "broken" I mean: non-existent.

SQLite for Bacula was deprecated years and years ago, anyone who is 
still using it has had more than enough time to update.


I presume that the chance to remove it completely as part of the 11 
re-write was so obvious that not doing it would have been foolish.


This is all known and well, but the sqlite3-update script *has* been 
updated to the current DB version 1023, so it was clearly adapted.


But it is missing the upgrade path from Bacula 7.0.0 and 9.0.0, as if 
something went wrong during the merge from or to BEE.


Grüße,
Sven.


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

Re: [Bacula-devel] Bacula Release 11.0.0 (beta)

2020-12-15 Thread Sven Hartge 

On 15.12.20 15:10, Eric Bollengier via Bacula-devel wrote:

On 2020-12-15 13:23, Sven Hartge wrote:



This is all known and well, but the sqlite3-update script *has* been
updated to the current DB version 1023, so it was clearly adapted.

But it is missing the upgrade path from Bacula 7.0.0 and 9.0.0, as if
something went wrong during the merge from or to BEE.


SQLite is deprecated, it means that the support and the testing are not
at the level of PostgreSQL for example. I would not recommend to start a
production system based on it. (quick testing is probably OK).


This is dcoumented in Debian for a long long time and the default 
dependencies are adjusted to make that even more clear.


But as you said, for a quick test inside the CI it is still quite useful.


I have pushed a fix for the script in the git repository, but I have not
tested it with a lot of data.


Thank you, I will pull this into a local patch to test your changes.

Grüße,
Sven.



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

Re: [Bacula-devel] Something amiss in bacula-9.6.7: Possible race condition

2021-01-19 Thread Sven Hartge 

On 19.01.21 19:40, Martin Simmons wrote:


I say "in theory" because it looks like Bacula 9.6.4 broke this!

What is the output of "show catalog" in bconsole?  My guess is that you will
see db_driver=MySQ i.e. missing the final "L" of MySQL.  This will prevent it
from reusing the BDB object, leading to unexpected concurrency.

The bug is caused by this change:

diff --git a/bacula/src/dird/dird.c b/bacula/src/dird/dird.c
index fdb1d97bf9..11c4406ea7 100644
--- a/bacula/src/dird/dird.c
+++ b/bacula/src/dird/dird.c
@@ -1265,7 +1265,7 @@ static bool check_catalog(cat_op mode)
 /* To copy dbdriver field into "CAT" catalog resource class (local)
  * from dbdriver in "BDB" catalog DB Interface class (global)
  */
-strncpy(catalog->db_driver, BDB_db_driver, db_driver_len);
+bstrncpy(catalog->db_driver, BDB_db_driver, db_driver_len);
   }
}

which was part of 9.6.4.

To fix it, replace db_driver_len with db_driver_len+1 in this call to
bstrncpy.  This has been fixed in Bacula 11 because the seemingly minor
problem with "status catalog" was reported in
https://bugs.bacula.org/view.php?id=2551 but it looks like the significance of
it wasn't realized.


This is so very amazing! I think this may also explain and cure the 
deadlock problems we have been seeing since 9.6.4.


And also me wondering why suddenly Bacula needed so many more database 
connections since 9.6.4 in contrast to before.


Phil, I am pulling your patch for Gentoo for Debian to get this fix into 
Bullseye ASAP.


Grüße,
Sven.


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

Re: [Bacula-devel] Release 11.0.1

2021-02-08 Thread Sven Hartge 

On 08.02.21 15:17, Gary R. Schmidt wrote:

I can't see the fix for the short strcpy() problem that vexed Phil, and 
has kept me from updating for a few versions.


Has that mistake been totally rolled back, only partially applied, or 
forgotten?


That one was already present in 11.0 but missing from 9.6.

If you are on 9.6 and compiling from source, I suggest to get the latest 
git HEAD from the Branch-9.6 for all the unreleased last-minute fixes.


(Shameless plug: Or, when using Debian, try the packages from 
buster-backports which contain all those changes as well.)


Grüße,
Sven


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

Re: [Bacula-devel] Bacula Release 13.0.0

2022-08-20 Thread Sven Hartge 
Um 19:59 Uhr am 04.07.22 schrieb Eric Bollengier via Bacula-devel:

> We are pleased to announce the release of Bacula version 13.0.0. This is
> a major release of the new stable version.

Trying to verify the signature on the release tar balls I get:

gpgv: Signature made Fr 05 Aug 2022 17:19:18 CEST
gpgv:using RSA key 
270AC5018ED80662804BE9E97E73F0869FEC1047
gpgv: Can't check signature: No public key

I redownloaded the old and new public keys from 
https://www.bacula.org/bacula-distribution-verification-public-keys/ and 
from 
https://sourceforge.net/projects/bacula/files/Bacula%20Public%20Key/ but 
those are the keys I already had in my keyring.

Same thing happened in December 2020 and back then the files got pulled 
and resigned with the correct distribution key.

Grüße,
Sven.


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