[pkg-bacula-devel] Contribution

[Mario Pranjic]

On 9/14/20 9:16 PM, Sven Hartge wrote:
> [Please don't top post. Thank you.]

Sorry about that. Years in corporations and opposite email etiquette
took it's toll. :)
Have to remember it from time to time.

> libs3 originates from https://github.com/bji/libs3 and is a third party
> library for Amazon S3 acccess. Bacula Systems originally used the libs3
> git HEAD version from December 2016 when then developed the (then)
> proprietary cloud driver for Bacula Enterprise.
>
> 3 years later the cloud driver is fully open-sourced and integrated into
> the Bacula community version.
>
> It was soon discovered that libs3 is a bit of a mess, because it never
> really got a stable API and even slightly different versions are
> incompatible with each other, making using and packaging it very
> difficult. In addition to that the last offical release of libs3 was in
> 2011, which is the version currently in Debian.
>
> Unfortunately libs3 is very much abandoned by its authors and does not
> even compile without errors with anything newer than GCC8 without heavy
> patching. (And my personal opinion is that libs3 is a security breach
> wating to happen.)

Hm. What you just wrote is disturbing.
I was led to believe that Bacula Enterprise from time to time makes
parts of code, such as drivers, available to community version.
Or that community is working on more-less similar code base (somewhat
how RedHat Linux is established).

When I contacted Bacula Enterprise this summer and arranging PoC, there
was a guy who explained that Bacula Enterprise cloud driver supports
different cloud providers, while community version supports only AWS S3.
I had (hopefully still have when time comes) use-case where requirement
was to use Object Storage in Oracle cloud (long story related to Oracle
licensing in cloud and why that obscure choice was made).
So company decided to stop the whole pilot and go for something else.

But, point being, if Bacula Enterprise have a working driver for
multiple cloud  providers, while we here sit with 2011 code not even
maintained, it is a good question indeed why would we pack it in the
first place.

In that sense, I still don't understand relationship between Bacula
Enterprise and community.

> This is all well and good but as said above, there is already a different
> version of libs3 in Debian. The one for Bacula can't be concurrently
> installed with the existing one and also because of the problems with the
> API stability lined out above, it shouldn't.
>
> The only possibility of getting Baculas own libs3-fork into Debian is by
> making it a private library, in contrast to the public system library you
> created above.
>
> Which means
>
> 1) installing into /usr/lib/bacula and /usr/include/bacula
> 2) changing the library name from libs3 to something different so the
> dynamic linker does not get confused
>
> or
>
> 2) changing it to a static library that is linked into the cloud-driver at
> compile time.

Fully understandable.
In fact, I am surprised why is that driver called only "s3", but I
guess, that goes to not being properly maintained over time.


> Please explain.
>
Well. If cloud driver is related to Bacula ans Bacula alone, I find it
very weird  - you build it for Bacula and then the output is not even
called as Bacula expect it to be called.

If, on the other hand, this cloud driver is actually "general purpose"
piece of code to communicate with AWS S3 bucket and it suppose to be
used by Bacula "as is", then it makes more sense.

But then again, why this one is needed if one already exists in repository:
libs3-2/stable,stable 2.0-3 amd64
  C Library and Tools for Amazon S3 Access

libs3-dev/stable,stable 2.0-3 amd64
  C Development Library for Amazon S3 Access


Sorry for so many questions.


Mario.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-bacula-devel/attachments/20200914/414c8187/attachment.sig>