Hallo Michael,
I tried using git send-email with the previous patch and I couldn't get it to work so I used git format-patch and copied the output to an email from Thunderbird.
I had set it up using the settings in the IPFire wiki for Thunderbird but it looks like not everything is okay.
I will have another go with getting git send-email to work. I may come back with questions depending how things go.
As you are merging my patch then I have provided my answers to your questions below.
All the best
Adolf.
On 16/06/2020 12:28, Michael Tremer wrote:
Hello,
Turns out the patch won’t merge because it got corrupted.
Did you use git send-email to send it or some other mail agent?
root@michael:/build/ipfire-2.x# pwclient git-am -s 3204 Applying patch #3204 using u'git am -s' Description: bacula: Update to 9.6.5 warning: Patch sent with format=flowed; space at the end of lines might be lost. Applying: bacula: Update to 9.6.5 error: corrupt patch at line 25 Patch failed at 0001 bacula: Update to 9.6.5 hint: Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". 'git am' failed with exit status 128
Best, -Michael
On 16 Jun 2020, at 10:07, Michael Tremer michael.tremer@ipfire.org wrote:
Good morning Adolf,
On 16 Jun 2020, at 09:21, Adolf Belka ahb.ipfire@gmail.com wrote:
Hallo Michael,
I wasn't sure how to add additional comments to a patch that weren't intended to go into the git repository. So I sent a separate e-mail with subject "bacula add-on". Sorry for probably causing confusion.
No worries. I guess we are all trying to understand what everyone is doing.
Patchwork is really messy at the moment. We are shipping big releases, and many of patches remain in there because they do not fit into the releases any more - simply because of disk space. With the next release turn, there might already be more urgent things that have lined up… This time another wonderful CPU vulnerability presented by Intel.
This patch is an update from 9.0.6 to 9.6.5 and as the patch from 9.0.6 had not yet been merged I mentioned in the other email that the previous patch should be removed from patchwork and this one used.
Ideally submit another release as an extra patch that then can only be merged when the first one was matched. That makes it easier to review individual changes instead of reviewing one large patch that is growing larger and larger.
Since then Jan Lentfer responded to my email and highlighted a situation that could occur if people have an earlier version of the bacula director/storage daemons running. This can happen for example with distros that are slow to upgrade to newer versions or that aim to have very stable unchanging packages.
I think that email did not make it to the list - or I have missed it.
I checked and Jan's email did not make it to the list. However my reply to him is on the list. It is the second email in the thread entitled "bacula add-on".
Bacula will usually (though they do not guarantee it) work with an older File daemon package but not with a newer version. So with my patch to bring bacula in IPFire up-to-date then there could be people whose systems would stop working with the File daemon on IPFire as their backup server has an earlier version of the director/storage daemons.
After thinking about it for a while I have concluded that the best thing is to leave IPFire with version 9.0.6 of the File daemon, i.e. the status quo, and remove all my bacula patches from patchwork. Looking through the bacula release history it looks like 9.0.6 is expected to work with the current released director/storage daemons. If that ever changes then we can decide what to do with it at that time.
If the upstream project decides to break compatibility there is nothing we can do about it. We can delay shipping a broken version for a brief while, but we cannot remain on an unmaintained release for years.
Hence I will merge your last patch and mark the others as superseded. They are no longer needed.
I still have no idea what you are trying to do in the scripts, but I guess we can hope for the best :)
I will continue installing the latest version of bacula as a locally built add-on as I have been doing for some time as all my bacula systems are built from source so I can easily keep them aligned. I will also keep an eye out for if a release indicates that a file daemon update is required.
So my proposal now is to remove, or reject all of my bacula patches that are in patchwork.
I would rather prefer that you keep sending those patches when you are updating the software. Nobody else is taking care of this package right now and the only other option would be to remove it then, which I wouldn’t really want.
Best, -Michael
All the best,
Adolf.
On 15/06/2020 12:36, Michael Tremer wrote:
Hello Adolf,
Thank you very much for submitting this patch.
I am slightly losing track of all the bacula patches, so please help me to understand.
The last patch that was sent was n update to 9.6.3, v2:
https://lists.ipfire.org/pipermail/development/2020-May/007779.html
What has changed since then? Is this just an update from 9.6.3 to 9.6.5? This won’t merge then if the previous patch is being merged.
On 13 Jun 2020, at 14:43, Adolf Belka ahb.ipfire@gmail.com wrote:
- Update bacula from 9.0.6 to 9.6.5
- Current version of bacula in ipfire is 9.0.6 and is over two and a half years old.
- Update config options in lfs to include bacula recommended smartalloc option.
- Add install, uninstall and update files in src/paks/bacula
- Updated backup/includes to only backup the config file.
You are saying what you have changed, but not why. Please see my questions below.
Signed-off-by: Adolf Belkaahb.ipfire@gmail.com
config/backup/includes/bacula | 2 +- config/rootfiles/packages/bacula | 17 +++++++------- lfs/bacula | 11 ++++----- src/paks/bacula/install.sh | 38 ++++++++++++++++++++++++++++++++ src/paks/bacula/uninstall.sh | 33 +++++++++++++++++++++++++++ src/paks/bacula/update.sh | 26 ++++++++++++++++++++++ 6 files changed, 113 insertions(+), 14 deletions(-) create mode 100644 src/paks/bacula/install.sh create mode 100644 src/paks/bacula/uninstall.sh create mode 100644 src/paks/bacula/update.sh
diff --git a/config/backup/includes/bacula b/config/backup/includes/bacula index 8d5c119f9..0da11db7d 100644 --- a/config/backup/includes/bacula +++ b/config/backup/includes/bacula @@ -1 +1 @@ -/etc/bacula/ +/etc/bacula/bacula-fd.conf diff --git a/config/rootfiles/packages/bacula b/config/rootfiles/packages/bacula index 64fb0d2ca..4ee408fc4 100644 --- a/config/rootfiles/packages/bacula +++ b/config/rootfiles/packages/bacula @@ -13,22 +13,23 @@ etc/bacula/bacula-fd.conf #etc/bacula/btraceback.gdb #etc/bacula/btraceback.mdb #etc/bacula/disk-changer +#etc/bacula/isworm #etc/bacula/mtx-changer #etc/bacula/mtx-changer.conf #etc/bacula/tapealert etc/rc.d/init.d/bacula #opt/bacula #opt/bacula/log -usr/lib/bpipe-fd.so -usr/lib/libbac-9.0.6.so +#usr/lib/bpipe-fd.so +usr/lib/libbac-9.6.5.so #usr/lib/libbac.la -#usr/lib/libbac.so -usr/lib/libbaccfg-9.0.6.so +usr/lib/libbac.so +usr/lib/libbaccfg-9.6.5.so #usr/lib/libbaccfg.la -#usr/lib/libbaccfg.so -usr/lib/libbacfind-9.0.6.so +usr/lib/libbaccfg.so +usr/lib/libbacfind-9.6.5.so #usr/lib/libbacfind.la -#usr/lib/libbacfind.so +usr/lib/libbacfind.so #usr/sbin/bacula usr/sbin/bacula-fd #usr/sbin/bbconsjson
Bacula is using a horrible method to version their libraries...
I am not sure I can help on that.
@@ -61,4 +62,4 @@ usr/sbin/bacula-fd #usr/share/man/man8/bwild.8.gz #usr/share/man/man8/dbcheck.8.gz #var/bacula -var/bacula/working +#var/bacula/working diff --git a/lfs/bacula b/lfs/bacula index 8c96c7ba1..b6b0d9cbf 100644 --- a/lfs/bacula +++ b/lfs/bacula @@ -24,15 +24,15 @@
include Config
-VER = 9.0.6 +VER = 9.6.5
THISAPP = bacula-$(VER) DL_FILE = $(THISAPP).tar.gz -DL_FROM = $(URL_IPFIRE) +DL_FROM = https://sourceforge.net/projects/bacula/files/bacula/9.6.5/bacula-9.6.5.tar.... DIR_APP = $(DIR_SRC)/$(THISAPP) TARGET = $(DIR_INFO)/$(THISAPP) PROG = bacula -PAK_VER = 4 +PAK_VER = 5
DEPS =
@@ -44,7 +44,7 @@ objects = $(DL_FILE)
$(DL_FILE) = $(DL_FROM)/$(DL_FILE)
-$(DL_FILE)_MD5 = 9168e398808c42bf290515f60892f643 +$(DL_FILE)_MD5 = e58eb531483de98d0410b33e3ec3d96a
install : $(TARGET)
@@ -80,12 +80,13 @@ $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) $(UPDATE_AUTOMAKE) cd $(DIR_APP) && ./configure \ --prefix=/usr \
--enable-smartalloc \What does this do?
Here is what the bacula manual says about this:-
--enable-smartalloc This enables the inclusion of the Smartalloc orphaned buffer detection code. This option is highly recommended. Because we never build without this option, you may experience problems if it is not enabled. In this case, simply re-enable the option. We strongly recommend keeping this option enabled as it helps detect memory leaks. This configuration parameter is used while building Bacula
So based on that I use it and all the suggested config scripts in the bacula manual have this listed.
--sysconfdir=/etc/bacula \ --with-working-dir=/var/bacula/working \ --enable-client-only cd $(DIR_APP) && make $(MAKETUNING) cd $(DIR_APP) && make install
- ln -s /etc/bacula/bacula-ctl-fd /etc/rc.d/init.d/bacula
- ln -sf /etc/bacula/bacula-ctl-fd /etc/rc.d/init.d/bacula rm -f /root/.rnd @rm -rf $(DIR_APP) @$(POSTBUILD)
diff --git a/src/paks/bacula/install.sh b/src/paks/bacula/install.sh new file mode 100644 index 000000000..49aef9379 --- /dev/null +++ b/src/paks/bacula/install.sh @@ -0,0 +1,38 @@ +#!/bin/bash +############################################################################ +# # +# This file is part of the IPFire Firewall. # +# # +# IPFire is free software; you can redistribute it and/or modify # +# it under the terms of the GNU General Public License as published by # +# the Free Software Foundation; either version 2 of the License, or # +# (at your option) any later version. # +# # +# IPFire is distributed in the hope that it will be useful, # +# but WITHOUT ANY WARRANTY; without even the implied warranty of # +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # +# GNU General Public License for more details. # +# # +# You should have received a copy of the GNU General Public License # +# along with IPFire; if not, write to the Free Software # +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # +# # +# Copyright (C) 2007 IPFire-Team info@ipfire.org. # +# # +############################################################################ +# +. /opt/pakfire/lib/functions.sh +extract_files +if [ -f /etc/bacula/bacula-fd.conf ]; then
- cp /etc/bacula/bacula-fd.conf /etc/bacula/bacula-fd.conf.new
+fi
I thought I have asked this before:
Why is this file being moved? We should have a backup taking care of backing up configuration files.
This line is not creating a backup copy. After running extract_files the new default version of bacula-fd.conf is stored here. This line just copies this file to bacula-fd.conf.new to indicate it is from the new installation. This is done so that if there are any new options listed in the conf file you can review and decide if you want to update your own file. In a direct install of bacula, if bacula-fd.conf exists then the install puts the new default conf file to bacula-fd.con.new. So I am following the same approach. A few lines further on the restore replaces the default bacula-fd.conf with the one that was backed up in the uninstall script, assuming that it is not the first install.
However, when I think about it, the default bacula-fd.conf file has never had any major changes done to it. So I could remove this and then there would just be the bacula-fd.conf default file from the installation which would be overwritten by the backed up version if it is an update.
I will probably do that as the default file cannot be easily used without changes as it presumes that the File daemon is being installed on the same machine as the director and storage daemons and that is not the case here.
+if [ ! -d /var/bacula/working ]; then
- mkdir -p /var/bacula/working
+fi +restore_backup ${NAME} +# create startlinks +ln -sf ../init.d/bacula /etc/rc.d/rc0.d/K35bacula +ln -sf ../init.d/bacula /etc/rc.d/rc3.d/S65bacula +ln -sf ../init.d/bacula /etc/rc.d/rc6.d/K35bacula +start_service ${NAME} +exit 0 diff --git a/src/paks/bacula/uninstall.sh b/src/paks/bacula/uninstall.sh new file mode 100644 index 000000000..762bb103c --- /dev/null +++ b/src/paks/bacula/uninstall.sh @@ -0,0 +1,33 @@ +#!/bin/bash +############################################################################ +# # +# This file is part of the IPFire Firewall. # +# # +# IPFire is free software; you can redistribute it and/or modify # +# it under the terms of the GNU General Public License as published by # +# the Free Software Foundation; either version 2 of the License, or # +# (at your option) any later version. # +# # +# IPFire is distributed in the hope that it will be useful, # +# but WITHOUT ANY WARRANTY; without even the implied warranty of # +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # +# GNU General Public License for more details. # +# # +# You should have received a copy of the GNU General Public License # +# along with IPFire; if not, write to the Free Software # +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # +# # +# Copyright (C) 2007 IPFire-Team info@ipfire.org. # +# # +############################################################################ +# +. /opt/pakfire/lib/functions.sh +stop_service ${NAME} +make_backup ${NAME} +# Remove bacula-fd.conf.new file and /var/bacula/ directory +rm -rf /etc/bacula/bacula-fd.conf.new +rm -r /var/bacula
I suppose this is all related to above.
Yes. If I don't use bacula-fd.conf.new then this removal is no longer needed.
Why is /var/bacula being deleted? What would be in that directory?
This is where bacula stores its state file which provides a summary of previous jobs run in the status command output on the director machine or any other that can run bconsole or BAT (command line and GUI status programmes for bacula).
I delete it when doing an uninstall as otherwise it would stay there and my approach is to clear up everything when uninstalling. In IPFire an upgrade is the uninstall script followed by the install script. So this directory will be deleted and then recreated. This does mean that when an upgrade is done that the state file is lost and so there is no history of what jobs have been run, although that can be found from the bacula logs on the machine that the director daemon runs on.
Thinking about this I could also do a backup of the state file so that the history is not lost.
+remove_files +# Remove all start links. +rm -rf /etc/rc.d/rc*.d/*bacula +exit 0 diff --git a/src/paks/bacula/update.sh b/src/paks/bacula/update.sh new file mode 100644 index 000000000..89c40d0d7 --- /dev/null +++ b/src/paks/bacula/update.sh @@ -0,0 +1,26 @@ +#!/bin/bash +############################################################################ +# # +# This file is part of the IPFire Firewall. # +# # +# IPFire is free software; you can redistribute it and/or modify # +# it under the terms of the GNU General Public License as published by # +# the Free Software Foundation; either version 2 of the License, or # +# (at your option) any later version. # +# # +# IPFire is distributed in the hope that it will be useful, # +# but WITHOUT ANY WARRANTY; without even the implied warranty of # +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # +# GNU General Public License for more details. # +# # +# You should have received a copy of the GNU General Public License # +# along with IPFire; if not, write to the Free Software # +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # +# # +# Copyright (C) 2007 IPFire-Team info@ipfire.org. # +# # +############################################################################ +# +. /opt/pakfire/lib/functions.sh +./uninstall.sh
+./install.sh
2.27.0
I am looking forward to be able to merge this soon and I am happy that you are taking care of this add-on which has been neglected.
:)
My pleasure.
Best, -Michael