On 03/03/17 11:30 AM, Gene Heskett wrote: > 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 Did you read the ReleaseNotes file for 3.4.2? * configure - amanda-security.conf is now in $sysconfdir
So amanda expect it in a different location that 3.4.1 (because you do not use the default sysconfdir) Since it is a security file, only root can have permission to write to it (including the path to the file). Either you change the permission of the path to /usr/local/etc/amanda-security.conf and create the file there. Or you configure amanda with --with-security-file=/etc/amanda-security.conf > > 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 It say /usr/local/etc is writable by the group, which is not allowed for /usr/local/etc/amanda-security.conf > > 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 This message is the property of CARBONITE, INC. and may contain confidential or privileged information. If this message has been delivered to you by mistake, then do not copy or deliver this message to anyone. Instead, destroy it and notify me by reply e-mail.
