On 7/11/21 5:10 PM, Josip Deanovic wrote:
On Sunday 2021-07-11 18:31:24 Kern Sibbald wrote:
Hello Sven,
Yes, I am aware of the FHS policy, which is perfectly fine for 99.9% of
all installed programs, but not ideal for Bacula.
Hello,
There is nothing special about Bacula in that regard.
I disagree. Yes, in its day-to-day operation it's requirements are the
same as many other apps, storage for binaries and configuration and also
uses temp/spool storage. However, because of its role in disaster
recovery, simplicity and speed of deployment is much more critical for
Bacula than for most apps. It indeed is special in that regard, and a
/opt install is simpler and faster to deploy when restoring Bacula
services to bare metal in a disaster recovery scenario.
Many (if not most) programs require modifications to conform to a specific
standard unless the program is following particular rules from the very
beginning.
Many programs are modified by package maintainers who sometimes have to
come up with patches for programs to work as expected because authors
sometimes chose to hardcode paths and other options which should be
configurable.
We are dealing here with two opposite opinions and two different points
of view because two types of people are involved here: developers and
sysadmins.
For a developer the easiest solution is to keep everything under a single
directory and to ship a bunch of libraries with the program distribution.
This keeps program more predictive and the deployment less complicated.
Developers usually don't have to bother with the software deployment and
the service maintenance.
Every bit of work they manage to spare during the application development
by keeping their environment simple will usually get payed by a sysadmin
during the deployment and service maintenance.
On Unix (and Linux) /opt directory used to be a directory which usually
contained optional software distributions provided by a third party
companies or vendors.
It is rarely used by OpenSource tools or applications.
Unless there is no other way (e.g. there is a commercial software
distribution with a specific requirements), /opt shouldn't be used
by a software distribution. Using /opt is usually a sign of a bad
support (e.g. packaging and testing) for a specific system.
Note that I am talking in general, not about Bacula specifically.
Software that tend to use /opt for its installation usually brings
several commonly available libraries locked to a specific version.
Providing commonly available libraries already available on the system
with the particular software distribution and linking programs with
such libraries makes it good thing for the application stability and
simplicity of its deployment and ultimately vendor support.
However, from a non-developer view there are no visible benefits.
From sysadmin view, it looks like yet another nonstandard software
installation with an unusual update procedure which usually turns out
to be more of a migration and less of a simple minor version update.
Another problem is that it is most likely that libraries shipped with
a third-party software will receive their security and bugfix updates
far too slow or more commonly, will not receive any updates at all
which adds to an overall potential system vulnerability footprint.
Also, shipping such common libraries will duplicate the code used on
the system.
Putting software under /opt could also complicate a diskless setup a bit.
Now imagine the horror on the system if most of the services on the
system would follow such practice. Such system would be very hard
to maintain and the code sharing in memory would be pretty low.
Directory structure on Linux systems is the only thing that was
relatively well standardized throughout the Linux distributions since
the earliest days of Linux and it is interesting to see that what is
considered to be a properly packaged software for one person could
at the same time be described as "spreading it all over the filesystem"
for somebody else.
Regards!
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
