Re: Release of Amanda-3.4.3

[Gene Heskett]

On Friday 03 March 2017 08:50:00 Jean-Louis Martineau wrote:

> Hello,
>
> The Amanda core team is pleased to announce the release of Amanda
> 3.4.3
>
> There is a major issue in 3.4, 3.4.1 and 3.4.2, all users should
> upgrade to 3.4.3 as soon as possible.
>
> This is a bugfix release for Amanda-3.4.2.
>
> Source tarballs are available from
>
>   * http://www.amanda.org
>   * https://sourceforge.net/project/showfiles.php?group_id=120
>
>   Binaries for many systems are available from
>
>   * http://www.zmanda.com/download-amanda.php
>
> Documentation can be found at
>
>   * http://wiki.zmanda.com
>
> Here's a list of the changes for release 3.4.3 (from the NEWS file):
> Look at the ReleaseNotes and ChangeLog file for more details.
>
>   * fix MAJOR issue: amdump can reuse the same tape in the same run
>   * amtape slot
>   o add drive selection
>   * compile/link with libressl
>   * fix portability issue
>   * fix for NetBSD
>   * fix 'Device busy' problem
>   * fix planner crash
>   * fix setregid call
>
>
> Jean-Louis Martineau

Is there any reason to replace the debian supplied clients, which are 
3.4.1 IIRC?

I typed that before a perfunctory amcheck, which upchucked a screenfull 
of this:
HOST coyote ERROR: Can't get realpath of the security 
file '/usr/local/etc/amanda-security.conf': No such file or directory

39 of them.  Looking at the manpage now. Needs way more caffeine than 
I've put in yet this morning. Clear as mud. How do I configure this 
security file to restore normal operation based on the attached 
amanda.conf.  Better yet, is there an option I can put in my config 
driver that makes amanda for me to nuke this. Config driver is:

#!/bin/sh
# since I'm always forgetting to su amanda...
if [ `whoami` != 'amanda' ]; then
echo
echo "!! Warning !!!"
echo "Amanda needs to be configured and built by the"
echo "user amanda, but must be installed by user root."
echo
exit 1
fi
make clean
rm -f config.status config.cache
./configure --with-user=amanda \
--with-group=disk \
--with-owner=amanda \
--with-gnu-ld \
--prefix=/usr/local/ \
--with-debugging=/tmp/amanda-dbg/ \
--with-tape-server=coyote \
--with-bsdtcp-security --with-amandahosts \
--with-configdir=/usr/local/etc/amanda \
--enable-manpage-build  \
--with-readline \
--with-gnutar=/bin/tar
echo "sleeping for reading configures warnings"
echo "a make as amanda will continue after 75 seconds..."
sleep 75
make

After the above make is done, I become root to do the make install.

Same script I've been using, with a minor mod occasionally since 2.5.3 
days. My systems here, 5 of them, are behind a router running dd-wrt, 
and I am the only user here at the coyote.den. The clients are all 
running the debian wheezy issued version which IIRC is 3.4.1.

This seems like overkill paranoia unless its a set once and forget thing.  
There is not an example amanda.security file in the example directory of 
the build, nor does any of the paths the manpage mentions exist after 
the install, so it seems to be an unfinished option. Given the terseness 
of the manpage in regard to updating an existing install, please 
explain.  Aha, finally found the example, in common-src and copied it to 
where amcheck looked, with owner root and 0644 perms like the manpage 
recommends. It contains the howto's. However, amcheck is broken, when 
this file is owned by root:root, readable by group and others, I have 
now tried all combo's from 0600 to 0644, but amcheck errors on all of 
then. At 0644:

HOST coyote ERROR: file/dir '/usr/local/etc' 
(/usr/local/etc/amanda-security.conf) is writable by the group

39 of them.

Any other 0600,0640,0604 replaces the writable message with a no perms 
message. Group is of course root, so of course its writable.  Me 
bumfuzzled.

And it is not, its rw-r--r--  root root so it needs fixed or disabled?

A faint cry for help. And I am being distracted by honeydo's, the Missus 
fell & broke a hip 3 weeks ago.  She is doing well on the replacement 
but I'm still the designated gitme servant.

Thanks.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
#
# amanda.conf - sample Amanda configuration file.  This started off life as
#   the actual config file in use at CS.UMD.EDU.
#
# If your configuration is called, say, "csd", then this file normally goes
# in /usr/local/etc/amanda/csd/amanda.conf.
#
org "The Coyote Den"# your organization name for reports
mailto "g...@coyote.coyote.den"
dumpuser "amanda"   # the user to run dumps under
# printer "HL3170CDW"
inparallel 5 # maximum dumpers that will run in parallel (max 63)
# this maximum can be increased at compile-time,
 

keep specific DLEs in holding disk?

[Stefan G. Weichinger]

(how) can I define this behavior:

for DLEs kvm_host:/my/virt-backup/VM_*

amdump their content to amanda_server:/mnt/amhold

write it to tape but leave the files in the holdingdisk as well until
next amdump-run

I want that behavior for some DLEs only, not for the whole config.
Is there a trick?

Release of Amanda-3.4.3

[Jean-Louis Martineau]

Hello,

The Amanda core team is pleased to announce the release of Amanda 3.4.3

There is a major issue in 3.4, 3.4.1 and 3.4.2, all users should upgrade 
to 3.4.3 as soon as possible.


This is a bugfix release for Amanda-3.4.2.

Source tarballs are available from

 * http://www.amanda.org
 * https://sourceforge.net/project/showfiles.php?group_id=120

 Binaries for many systems are available from

 * http://www.zmanda.com/download-amanda.php

Documentation can be found at

 * http://wiki.zmanda.com

Here's a list of the changes for release 3.4.3 (from the NEWS file):
Look at the ReleaseNotes and ChangeLog file for more details.

 * fix MAJOR issue: amdump can reuse the same tape in the same run
 * amtape slot
 o add drive selection
 * compile/link with libressl
 * fix portability issue
 * fix for NetBSD
 * fix 'Device busy' problem
 * fix planner crash
 * fix setregid call


Jean-Louis Martineau