Re: what leads to a "new disk" ?
On Mon, Dec 05, 2022 at 03:20:08PM +0100, Stefan G. Weichinger wrote: > Am 05.12.22 um 15:03 schrieb Jose M Calhariz: > > On Thu, Dec 01, 2022 at 10:18:03AM +0100, Stefan G. Weichinger wrote: > > > > > > I have an installation where I didn't add or remove DLEs for a long time. > > > > > > But now an then amanda seems to "forget" a DLE and come up with something > > > like: > > > > > > samba.intra rootfs lev 0 FAILED [dumps too big, 42606931 KB, but cannot > > > incremental dump new disk] > > > > > > The DLE is NOT new. Where does that come from? > > > > > > > By chance have you made a "amadmin Config force samba.intra rootfs" > > just before that? > > correct ;-) > > I do that in my crontab: > > 30 19 * * 1-5 /usr/sbin/amdump myconfig -ostorage=storage1; /bin/mt-st -f > /dev/nst0 offl > > 30 02 * * 7 /usr/sbin/amadmin myconfig force; /usr/sbin/amdump myconfig > -ostorage=storage2 > > > I wasn't aware that doing this "resets history" ... I just want to have lev0 > runs only on that day It blocks incremental backups to run until a lev0 is run sucessfully. Now I only do a "amdmin force " when I know I have lost the previous lev 0 or incrementals are broken. > > thx > > > > > Kind regards Jose M Calhariz -- -- O melhor no casamento são as brigas. O resto e mais ou menos. -- Thornton Wilder signature.asc Description: PGP signature
Re: what leads to a "new disk" ?
On Thu, Dec 01, 2022 at 10:18:03AM +0100, Stefan G. Weichinger wrote: > > I have an installation where I didn't add or remove DLEs for a long time. > > But now an then amanda seems to "forget" a DLE and come up with something > like: > > samba.intra rootfs lev 0 FAILED [dumps too big, 42606931 KB, but cannot > incremental dump new disk] > > The DLE is NOT new. Where does that come from? > By chance have you made a "amadmin Config force samba.intra rootfs" just before that? Kind regards Jose M Calhariz -- -- O melhor no casamento são as brigas. O resto e mais ou menos. -- Thornton Wilder signature.asc Description: PGP signature
Re: Multiple storage-definitions, generating archive tapes
On Mon, Aug 08, 2022 at 04:34:11PM +0200, Stefan G. Weichinger wrote: > Am 04.08.22 um 10:08 schrieb Stefan G. Weichinger: > (...) > > combined with > > flush-threshold-dumped200 # (or more) > flush-threshold-scheduled 200 # (or more) > taperflush200 My experience is this options do not work as documented. On my case there is a autoflush before the holding disk have enough files to fill a tape. On a setup that produces less files per amdump than the size of a physical tape. > autoflush yes > > (...) Kind regards Jose M Calhariz -- -- Ciência e tecnologia se multlipicam à nossa volta. Em grande parte elas ditam a extensão das linguagens com que falamos e pensamos. Ou usamos essa linguagem, ou permanecemos mudos --J.G. Ballard signature.asc Description: PGP signature
Re: New Amanda Community release 3.5.2 Has Arrived!
On Tue, Aug 02, 2022 at 06:27:24AM +0100, Jose M Calhariz wrote:
> On Mon, Aug 01, 2022 at 06:50:15PM +0100, Jose M Calhariz wrote:
> > On Mon, Aug 01, 2022 at 10:55:40AM +0200, Stefan G. Weichinger wrote:
> > > Am 29.07.22 um 04:11 schrieb Pavan Raj:
> > > > Hello Everyone,
> > > >
> > > > We at Zmanda are pleased to announce the 3.5.2 release of Amanda
> > > > Community.
> > >
> > > Nice to hear ...
> > >
> > > anyone touched that yet?
> > >
> > > Looking forward to that release packaged for Debian (most of my
> > > amanda-servers run Debian Linux).
> >
> > Give me sometime to prepare non oficial Debian source packages for
> > Debian 11 and 10, so you can easily build for your servers. This time
> > I would like some reports of success with 3.5.2 before upload an
> > official package to Debian unstable.
>
> I have problems with the autotools to compile amanda 3.5.2 for a
> pre-offcial package for Debian, with alot of warnings about deprecated
> macros. I will work on this.
I am not doing progress in solving the autotools problems.
I copied debian directory from official Debian 3.5.1, refresh patches,
and "debuild". I fails with alot of warnings and this relevant error:
automake: error: cannot open < config/amanda/file-list: No such file or
directory
autoreconf: automake failed with exit status: 1
find ! -ipath "./debian/*" -a ! \( -path '*/.git/*' -o -path '*/.hg/*'
-o -path '*/.bzr/*' -o -path '*/.svn/*' -o -path '*/CVS/*' \) -a -type f -exec
md5sum {} + -o -type l -printf "symlink %p
" > debian/autoreconf.after
dh_autoreconf: autoreconf -f -i returned exit code 1
make: *** [debian/rules:41: build] Error 2
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
debuild: fatal error at line 1182:
dpkg-buildpackage -us -uc -ui -i -ICVS -I.svn failed
Kind regards
Jose M Calhariz
>
> >
> >
> >
> > >
> > > On gentoo I am afraid I have to try to come up with an ebuild myself for
> > > now
> > > (even the 3.6 beta doesn't come with an ebuild yet).
> > >
> > >
> > >
> > >
> >
> >
> > Kind regards
> > Jose M Calhariz
> >
>
> Kind regards
> Jose M Calhariz
>
>
>
--
--
Não há fatos, só interpretações.
-- Friedrich Nietzsche
signature.asc
Description: PGP signature
Re: New Amanda Community release 3.5.2 Has Arrived!
On Tue, Aug 02, 2022 at 12:27:26PM +0200, Stefan G. Weichinger wrote: > Am 02.08.22 um 10:06 schrieb Stefan G. Weichinger: > > Am 02.08.22 um 09:44 schrieb gene heskett: > > > On 8/2/22 01:40, Winston Sorfleet wrote: > > > > Much appreciated José, count me in as a beta tester. > > > > > > > > > > Me too, but its been a while and this is a fairly fresh bullseye > > > install, and autogen > > > complains mightily, and quickly. > > > > > > gene@coyote:~/src/amanda-tag-community-3.5.2$ ./autogen > > > See DEVELOPING for instructions on updating: > > > * gettext macros > > > * gnulib > > > * libtool files > > > ..creating file lists > > > ..aclocal > > > config/amanda/libs.m4:160: warning: macro 'AM_PATH_GLIB_2_0' not > > > found in library > > > ...aclocal patches > > > ..autoconf > > > configure:46532: error: possibly undefined macro: AM_PATH_GLIB_2_0 > > > If this token and others are legitimate, please use > > > m4_pattern_allow. > > > See the Autoconf documentation. > > > configure:46533: error: possibly undefined macro: AC_MSG_ERROR > > > autoconf failed > > > > > > And the fix is? > > > > > > build-essential., debhejper and friends are installed. > > > > As far as I learned from Chris Hassell, the new packaging scripts should > > build packages for Debian with: > > > > ./packaging/deb/buildpkg > > > > I am trying that for the branch "tag-community-3.5.2" right now in a > > Debian-11.4-VM. > > > > There is quite a list of needed packages to install, Chris told me: > > > > gcc g++ binutils gettext libtool autoconf automake bison flex swig > > libglib2.0-dev libjson-glib-1.0 libjson-glib-dev libssl-dev > > libcurl4-openssl-dev libncurses5-dev libreadline-dev perl-base > > perl-modules libcpanplus-perl libio-socket-ssl-perl libswitch-perl > > bsd-mailx mtx procps smbclient dump gnuplot-nox xinetd > > > > and some extra: > > > > xsltproc build-essential debhelper fakeroot dpkg-dev dh-make-perl git > > make gawk grep tar passwd > > > > pressing SEND now, my build is still running > > I was able to build packages for 3.5.2 after applying the fix mentioned in > > https://github.com/zmanda/amanda/issues/185 > > Installing the packages over the packages coming from the Debian > repositories seems a bit tricky: > > the new packages use the user "amandabackup", so far it was "backup" > > the path to amandad seems to change as well > > I assume I can edit packaging/deb/rules to adjust that. > > Unsure if that is a good thing to do. > The Debian packages from Zmanda follow the official documentation, the Packages from Debian, aka now maintained by me, follow Debian guidelines. Upgrades between them is something that I do not try and I do not expect good results. There are patches to the build process and code to adapt the amanda for the Debian guidelines. I do my best to patch the documentation of amanda on Debian, so there is no difference between what is implemented and what is documented. Kind regards Jose M Calhariz -- -- Não há fatos, só interpretações. -- Friedrich Nietzsche signature.asc Description: PGP signature
Re: New Amanda Community release 3.5.2 Has Arrived!
On Mon, Aug 01, 2022 at 06:50:15PM +0100, Jose M Calhariz wrote: > On Mon, Aug 01, 2022 at 10:55:40AM +0200, Stefan G. Weichinger wrote: > > Am 29.07.22 um 04:11 schrieb Pavan Raj: > > > Hello Everyone, > > > > > > We at Zmanda are pleased to announce the 3.5.2 release of Amanda > > > Community. > > > > Nice to hear ... > > > > anyone touched that yet? > > > > Looking forward to that release packaged for Debian (most of my > > amanda-servers run Debian Linux). > > Give me sometime to prepare non oficial Debian source packages for > Debian 11 and 10, so you can easily build for your servers. This time > I would like some reports of success with 3.5.2 before upload an > official package to Debian unstable. I have problems with the autotools to compile amanda 3.5.2 for a pre-offcial package for Debian, with alot of warnings about deprecated macros. I will work on this. > > > > > > > On gentoo I am afraid I have to try to come up with an ebuild myself for now > > (even the 3.6 beta doesn't come with an ebuild yet). > > > > > > > > > > > Kind regards > Jose M Calhariz > Kind regards Jose M Calhariz -- -- Não há fatos, só interpretações. -- Friedrich Nietzsche signature.asc Description: PGP signature
Re: New Amanda Community release 3.5.2 Has Arrived!
On Mon, Aug 01, 2022 at 10:55:40AM +0200, Stefan G. Weichinger wrote: > Am 29.07.22 um 04:11 schrieb Pavan Raj: > > Hello Everyone, > > > > We at Zmanda are pleased to announce the 3.5.2 release of Amanda > > Community. > > Nice to hear ... > > anyone touched that yet? > > Looking forward to that release packaged for Debian (most of my > amanda-servers run Debian Linux). Give me sometime to prepare non oficial Debian source packages for Debian 11 and 10, so you can easily build for your servers. This time I would like some reports of success with 3.5.2 before upload an official package to Debian unstable. > > On gentoo I am afraid I have to try to come up with an ebuild myself for now > (even the 3.6 beta doesn't come with an ebuild yet). > > > > Kind regards Jose M Calhariz -- -- O que sabemos é uma gota, o que ignoramos é um oceano. -- Isaac Newton signature.asc Description: PGP signature
Re: amanda backup hanging consistently
Hi, If you run tar by hand on the DLE does it finish? After how much time? Kind regards Jose M Calhariz On Wed, Jun 15, 2022 at 09:50:11AM -0600, Orion Poplawski wrote: > On 6/15/22 09:38, Orion Poplawski wrote: > > Recently the backup of a particular DLE has started hanging consistently. I > > don't see any recent changes on the server except possibly a change from > > kernel 3.10.0-1160.62.1.el7 to 3.10.0-1160.66.1.el7 on Jun 2nd, but the > > problem didn't start until June 6th. > > > > The tar command is stuck trying to write out the name of the directory to > > amgtar: > > > > root 11321 11315 33 Jun14 ?03:55:46 /usr/bin/tar --create > > --verbose --verbose --block-number --file - --directory > > /export/backup/rufous > > --no-check-device --listed-incremental > > /var/lib/amanda/gnutar-lists/saga_export_backup_rufous_0.new > > --ignore-failed-read --totals --exclude-from > > /var/log/amanda/amgtar._export_backup_rufous.20220614211711.exclude . > > root 11432 11427 42 Jun14 ?03:57:48 /usr/bin/tar --create > > --verbose --verbose --block-number --file - --directory > > /export/backup/rufous > > --no-check-device --listed-incremental > > /var/lib/amanda/gnutar-lists/saga_export_backup_rufous_0.new > > --ignore-failed-read --totals --exclude-from > > /var/log/amanda/amgtar._export_backup_rufous.20220614234714.exclude . > > > > # strace -f -s 500 -p 11321 > > strace: Process 11321 attached > > write(2, " ./export/home/orion-admin/ansible-boulder/.git/objects/db/", 59 > > > > # strace -f -s 500 -p 11432 > > strace: Process 11432 attached > > write(2, " ./export/home/orion-admin/ansible-boulder/.git/objects/db/", 59 > > > > amgtar is stuck writing output to amandad: > > > > # strace -s 200 -p 11427 > > strace: Process 11427 attached > > write(4, "e_pylibssh.libs/\ndrwxr-x--- orion-admin/orion-admin 0 > > 2022-05-23 17:31 > > ./export/home/orion-admin/.local/lib/python3.8/site-packages/bcrypt/\ndrwxr-x--- > > orion-admin/orion-admin 0 2022-05-23 17:3"..., 4096 > > > > > > amgtar debug has: > > > > Tue Jun 14 23:47:14.104627682 2022: pid 11427: ??-amgtar : pid 11427 ruid > > 0 > > euid 27120 ppid 11418 version 3.6.0: start at Tue Jun 14 23:47:14 2022 > > Tue Jun 14 23:47:14.104731978 2022: pid 11427: ??-amgtar : version 3.6.0 > > Tue Jun 14 23:47:14.104957990 2022: pid 11427: ??-amgtar : state_stream: > > 156 > > Tue Jun 14 23:47:14.110961812 2022: pid 11427: ??-amgtar : pid 11427 ruid > > 0 > > euid 27120 ppid 11418 version 3.6.0: rename at Tue Jun 14 23:47:14 2022 > > Tue Jun 14 23:47:14.110991922 2022: pid 11427: ??-amgtar : GNUTAR-PATH > > /bin/tar > > Tue Jun 14 23:47:14.111004028 2022: pid 11427: ??-amgtar : GNUTAR-LISTDIR > > /var/lib/amanda/gnutar-lists > > Tue Jun 14 23:47:14.111013955 2022: pid 11427: ??-amgtar : > > ONE-FILE-SYSTEM no > > Tue Jun 14 23:47:14.111023583 2022: pid 11427: ??-amgtar : SPARSE yes > > Tue Jun 14 23:47:14.111033039 2022: pid 11427: ??-amgtar : NO-UNQUOTE no > > Tue Jun 14 23:47:14.111042417 2022: pid 11427: ??-amgtar : ATIME-PRESERVE > > no > > Tue Jun 14 23:47:14.111051865 2022: pid 11427: ??-amgtar : ACLS no > > Tue Jun 14 23:47:14.111061481 2022: pid 11427: ??-amgtar : SELINUX no > > Tue Jun 14 23:47:14.21121 2022: pid 11427: ??-amgtar : XATTRS no > > Tue Jun 14 23:47:14.30900 2022: pid 11427: ??-amgtar : CHECK-DEVICE no > > Tue Jun 14 23:47:14.40474 2022: pid 11427: ??-amgtar : SIZE ^ *Total > > bytes written: [0-9][0-9]* > > Tue Jun 14 23:47:14.50269 2022: pid 11427: ??-amgtar : IGNORE : > > Directory is new$ > > Tue Jun 14 23:47:14.59886 2022: pid 11427: ??-amgtar : IGNORE : > > Directory has been renamed > > Tue Jun 14 23:47:14.69511 2022: pid 11427: ??-amgtar : NORMAL ^could > > not > > open conf file > > Tue Jun 14 23:47:14.79212 2022: pid 11427: ??-amgtar : NORMAL > > ^Elapsed time: > > Tue Jun 14 23:47:14.111309287 2022: pid 11427: ??-amgtar : NORMAL > > ^Throughput > > Tue Jun 14 23:47:14.111321160 2022: pid 11427: ??-amgtar : NORMAL : > > directory is on a different filesystem; not dumped > > Tue Jun 14 23:47:14.111331690 2022: pid 11427: ??-amgtar : NORMAL : socket > > ignored$ > > Tue Jun 14 23:47:14.111342121 2022: pid 11427: ??-amgtar : NORMAL : File > > .* > > shrunk by [0-9][0-9]* bytes, padding with zeros > > Tue Jun 14 23:47:14.111397543 2022: pid 11427: ??-amgtar :
Re: "overdue" wrong
Hi I do not know about your case, but, in my case I get that when a full dump of a DLE fails. It will stay in that state of overdue until amanda gets a chance to do a full backup with success On Thu, Jun 02, 2022 at 10:04:16AM +0200, Stefan G. Weichinger wrote: > > > I see wrong "overdue" information in > > $ amadmin vtape due > > [..] > Overdue 19140 days: server:dle007 > [..] > > > $ amadmin vtape info > > Current info for server dle007: > > > Stats: dump rates (kps), Full: 64128.6, 62520.7, 64225.8 > > Incremental: 10.0, 1.1, 2.0 > > compressed size, Full: -100.0%,-100.0%,-100.0% > > Incremental: -100.0%,-100.0%,-100.0% > > Dumps: lev datestmp tape file origK compK secs > > 0 19700101 vtape-007-1 14 -1 -1 -1 > > > The DLEs are dumped OK, though. How to fix that? Remove some index file or > so? > > As you notice from my various postings lately I am trying to clean up my > amanda-configs and get rid of warnings/errors and other uncertainties ... > -- -- Todo mundo deveria ter dinheiro suficiente para fazer uma cirurgia plástica --Beverly Johnson signature.asc Description: PGP signature
Re: slow USB vtapes
On Wed, Jun 01, 2022 at 07:31:50AM +0200, Stefan G. Weichinger wrote: > > > I see low write performance to (modern) USB disks attached via USB 3.0 > > This leads to lng backup windows and even DLEs somehow not written > because things get stuck (?) somehow. > > Until yesterday the disks were attached to USB 2.0 ports, I expected to > solve this by adding a PCIe card with USB 3.0 ports. > > Maybe the mount options aren't optimal: > > UUID=3de7b456-019e-40ed-a1b9-aad41d371f26 /mnt/externaldisk7 ext4 > relatime,noauto,user 0 2 > > ? > > When I test things by doing something like: > > sync; dd if=/dev/zero of=tempfile bs=1M count=1024; sync > > I get values of maybe 130 MB/s or so, which is OK imo. > > The old internal RAID delivers ~150MB/s (reading from the holding disk). > > But with amanda (3.6.0pre2, btw) the flushes and dumps are slow. > > Does changing some blocksize help with vtapes? > > Sure, old hardware, I know. > Hi, How many DLEs and how many run in parallel (inparallel parameter)? How fast is your holdingdisk? What "iostat -k -x 2" command gives when amanda is running? Kind regards Jose M Calhariz -- -- Todo mundo deveria ter dinheiro suficiente para fazer uma cirurgia plástica --Beverly Johnson signature.asc Description: PGP signature
Re: debian 11, vtapes not found correctly anymore
On Wed, Apr 13, 2022 at 10:37:48AM +0200, Stefan G. Weichinger wrote:
> Am 13.04.22 um 09:56 schrieb Stefan G. Weichinger:
> >
> > Am 12.04.22 um 17:57 schrieb Jose M Calhariz:
> > > Hi,
> > >
> > > To tell that I have 1 instalation of amanda in Debian 11 with vtapes
> > > working flawless. Can we share the setup?
> >
> > Sure, I'd appreciate that.
> >
> > I have several vtape-installations working OK, it seems that the special
> > config with aggregating 2 or more chg-disk-changers is the problem here.
> >
> > I will post such a config in the next hour.
>
> OK, showing.
>
> I won't post the whole amanda.conf as it is long and maybe irrelevant for
> this topic.
>
> Just the parts around the changers, and some scheduling parameters.
>
> See "amadmin vtape config" here:
>
> https://gist.github.com/stefangweichinger/693eeb2c0c02d03abb31b53073352dd1
>
> (yes, way too many old dumptypes in there etc)
>
> -
>
> I take the setup from a site where we have 7 external USB drives with vtapes
> on them.
>
> So 7 changer devices like this:
>
> define changer disk1 {
> tpchanger "chg-disk:/mnt/externaldisk1"
> property "num_slot" "20"
> property "auto-create-slot" "yes"
> property "removable" "yes"
> property "MOUNT" "yes"
> property "UMOUNT" "yes"
> property "UMOUNT-LOCKFILE"
> "/etc/amanda/vtape/externaldisk1.lock"
> property "UMOUNT-DELAY" "1"
> }
>
> define changer disk2 {
> tpchanger "chg-disk:/mnt/externaldisk2"
> property "num_slot" "20"
> property "auto-create-slot" "yes"
> property "removable" "yes"
> property "MOUNT" "yes"
> property "UMOUNT" "yes"
> property "UMOUNT-LOCKFILE"
> "/etc/amanda/vtape/externaldisk2.lock"
> property "UMOUNT-DELAY" "1"
> }
>
> ... up to changer disk3. all the disks are listed in /etc/fstab
>
> UUID=5a5a9927-995f-4f0f-98ff-d222561f84ff /mnt/externaldisk1 ext4
> relatime,noauto,user 0 2
>
> and are (un-)mounted by the backup-user at amanda runtime.
>
> -
>
> The 7 chg-disk changers are aggregated into one "tpchanger" via
> chg-aggregate:
>
> define changer aggregate {
> tpchanger "chg-aggregate:{disk1,disk2,disk3,disk4,disk5,disk6,disk7}"
> property "state_filename" "/etc/amanda/vtape/aggregate.stats"
> property "allow-missing-changer" "yes"
> }
>
> And that one is used via:
>
> tpchanger "aggregate"
>
> - The "design goal" here was:
>
> an employee should swap the usb-disk every week.
>
> Amanda should rotate vtapes on one disk if they forget to change the disk.
>
> Amanda should use vtapes on each external disk, regardless which disk is
> attached.
>
> That works OK.
>
> Right now it's only that issue around "why aren't existing vtapes recognized
> and used?".
>
My setup is more simple
I have several RAID6, each one is always mounted, on /vTapes1,
/vTapes2, ... and there is a /vLibrary where there is all slots
directories that are symbolic links into /vTapes*
Have you look inside /mnt/externaldisk* to check if everything seams
OK?
Kind regards
Jose M Calhariz
--
--
Conheci no Brasil a miséria rica. Hoje, conheço a riqueza miserável
--Adolpho Bloch
signature.asc
Description: PGP signature
Re: debian 11, vtapes not found correctly anymore
Hi, To tell that I have 1 instalation of amanda in Debian 11 with vtapes working flawless. Can we share the setup? Kind regards Jose M Calhariz On Tue, Apr 12, 2022 at 10:22:38AM +0200, Stefan G. Weichinger wrote: > Am 05.04.22 um 14:39 schrieb Stefan G. Weichinger: > > > > At two amanda-installations on Debian11 I see this lately: > > > > both setups use an aggregate setup of multiple external usb disks with > > vtapes on them. > > > > That worked well for years. > > > > Now I get errors because amanda does not find valid tapes on one or more > > external disks. > > > > "amtape config inventory" shows the vtapes, but "amcheck -t config" > > tells me "No acceptable volumes found". > > > > If I relabel a tape "amlabel -f vtape_usb vtape_usb-002-004 slot 1:4" > > it gets detected again: > > > > $ amcheck -t vtape_usb > > Amanda Tape Server Host Check > > - > > mount: /mnt/externaldisk01: can't find > > UUID=98cb03d6-e95e-462d-a823-6011b37c9f42. > > slot 1:4: volume 'vtape_usb-002-004' > > Will write to volume 'vtape_usb-002-004' in slot 1:4. > > NOTE: skipping tape-writable test > > Server check took 6.673 seconds > > (brought to you by Amanda 3.5.1) > > > > > > (externaldisk01 is absent: OK, externaldisk02 is connected) > > > > I assume I should grep through some debug logs. What and where to look for? > > Still seeing these issues. I have to relabel every day, that is not the way > a backup setup should work like. > > See this tapelist, I wonder about that META column. > > /etc/amanda/vtape_usb/tapelist > 20220412084458 vtape_usb-002-006 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220411123301 vtape_usb-002-017 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220408224501 vtape_usb-002-016 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220408224501 vtape_usb-002-015 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220407224501 vtape_usb-002-014 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220407073600 vtape_usb-002-013 reuse META:vtape_usb-003 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220405224501 vtape_usb-002-005 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220405224501 vtape_usb-002-004 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220405132318 vtape_usb-002-003 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220405120227 vtape_usb-002-001 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220321224501 vtape_usb-002-012 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220320224501 vtape_usb-002-011 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220320224501 vtape_usb-002-010 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220319224501 vtape_usb-002-009 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220319224501 vtape_usb-002-008 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > 20220318224501 vtape_usb-002-007 reuse META:vtape_usb-002 BLOCKSIZE:32 > POOL:vtape_usb STORAGE:vtape_usb CONFIG:vtape_usb > > > what about that meta label? > > Is it a problem that it is duplicate? > > > > > -- -- Conheci no Brasil a miséria rica. Hoje, conheço a riqueza miserável --Adolpho Bloch signature.asc Description: PGP signature
Re: tape problem
I think the explanation for most of your problems is explained the amanda report. I have some questions that may help find the problem: - how much free space do you have on holding disk, how much space is used? - How big are the backups every day? - Do you use hardware compression on the tape? Kind regards Jose M Calhariz On Fri, Dec 03, 2021 at 11:18:08PM +, ghe2001 wrote: > amanda version: amadmin-3.5.1 > OS: Debian Linux, Buster > Host: Supermicro > PCI card: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 > [Falcon] (rev 03) > Tape drive: Quantum LTO-5 > Tapes: Quantum Ultrium 5 > > Problem: Over the years, I've written a bunch of amanda scripts. Here's what > the one that displays what's going on during a backup says at one point: > > gobook3.slsware.lan:/usr 20211203133758 0 4519450k > dump done, wait for writing > pi.slsware.lan:/lib20211203133758 0 1720720k > dump done, writing (1518944k done (88.27%)) (14:03:16) > pi.slsware.lan:/toshiba1 20211203133758 0 5089430k > dump done, wait for writing > pi.slsware.lan:/usr20211203133758 0 3108660k > dump done, wait for writing > sbox.slsware.lan:/blackHole/amanda 20211203133758 0 2251540k > dump done, wait for writing > sbox.slsware.lan:/home 20211203133758 0 74493810k > dump done, wait for writing > sbox.slsware.lan:/usr 20211203133758 0 5144210k > dump done, wait for writing >0: writing (pi.slsware.lan:/lib) > === Fri Dec 03, 2021 02:03:35 PM > > This is normal. A lot of flushing's been done, and all the small files. > The script futzes with amstatus and displays every 5 seconds. > > . > > The '.' means amstatus has written the same line, and nothing of interest > has happened. > > gobook3.slsware.lan:/usr 20211203133758 0 4519450k > dump done, wait for writing > pi.slsware.lan:/toshiba1 20211203133758 0 5089430k > dump done, wait for writing > pi.slsware.lan:/usr20211203133758 0 3108660k > dump done, wait for writing > sbox.slsware.lan:/blackHole/amanda 20211203133758 0 2251540k > dump done, wait for writing > sbox.slsware.lan:/home 20211203133758 0 74493810k > dump done, wait for writing > sbox.slsware.lan:/usr 20211203133758 0 5144210k > dump done, wait for writing >0: tape error: Couldn't rewind device to finish: No such > device, splitting not enabled (pi.slsware.lan:/lib) > === Fri Dec 03, 2021 02:03:52 PM > > Notice the than ~30 seconds from the last display. And who's trying to > rewind and finding no device (/dev/nst0 I suppose). > > After this, every line says "terminated while waiting for writing." > > This looks to me like maybe something can't deal with files larger that 1G. > But I've seen it get to 55G or so. > > > This morning, Logwatch said: > > WARNING: Kernel Errors Present > st 0:0:3:0: [st0] Error 1 (driver bt ...: 2 Time(s) > st 0:0:3:0: [st0] Error e (driver bt ...: 1 Time(s) > st 0:0:4:0: [st0] Error 1 (driver bt ...: 1 Time(s) > st 0:0:4:0: [st0] Error e (driver bt ...: 1 Time(s) > st 0:0:5:0: [st0] Error 1 (driver bt ...: 1 Time(s) > st 0:0:5:0: [st0] Error e (driver bt ...: 1 Time(s) > st 0:0:6:0: [st0] Error 1 (driver bt ...: 1 Time(s) > st 0:0:6:0: [st0] Error e (driver bt ...: 1 Time(s) > st 0:0:7:0: [st0] Error 1 (driver bt ...: 1 Time(s) > st 0:0:7:0: [st0] Error 7 (driver bt ...: 1 Time(s) > st 0:0:7:0: [st0] Error e (driver bt ...: 1 Time(s) > > st0 is the non-rewinding tape drive. As best I know, nobody does anything > with st0 -- nst0 is what I, and amanda, use. > > This looks like there might be a bent driver. > > > Amcheck: > > slot 1: volume 'sls-9' > Will write to volume 'sls-9' in slot 1. > Writing label 'sls-9' to check writability > Volume 'sls-9' is writeable. > Server check took 25.073 seconds > (brought to you by Amanda 3.5.1) > > > I'm at a loss. Amanda worked for a decade or so with the old DLT drive, then > for 3 or 4 years with the LTO -- then started breaking in every backup. I > trusted Quantum and LSI -- I ran tar to copy my entire / directory to the > Quantum tape that came with the drive, and it worked -- that ruled out the > card and the drive, so I bought a new collection of Quantum tapes to replace > the HPs I had been using. No joy. > >
Re: amandad paths
Let me add what dumptypes I have:
define dumptype bsd {
amandad_path "/usr/local/libexec/amanda/amandad"
client_username "amanda"
}
define dumptype rhel {
amandad-path "/usr/lib64/amanda/amandad"
client_username "amandabackup"
}
define dumptype osx {
client_username "amandabackup"
}
define dumptype upstream {
amandad-path "/usr/libexec/amanda/amandad"
client_username "amandabackup"
}
define dumptype source {
amandad-path "/usr/local/libexec/amanda"
client_username "amanda"
}
Kind regards
Jose M Calhariz
On Thu, Nov 11, 2021 at 04:47:25PM +, David Simpson wrote:
> Appear to have come across 3 possible amandad paths so far:
>
>
> Debian 11 (from repo): /usr/lib/amanda/amandad
>
> Alamlinux 8 (from repo @appstream): /usr/lib64/amanda/amandad
>
> RedHat 7 Zmanda supplied RPM (from website): /usr/libexec/amanda/amandad
>
>
>
> Do these cover all known (and current) combinations/everything?
>
> David
>
>
>
> -
> David Simpson - Senior Systems Engineer
> ARCCA, Redwood Building,
> King Edward VII Avenue,
> Cardiff, CF10 3NB
>
> David Simpson - peiriannydd uwch systemau
> ARCCA, Adeilad Redwood,
> King Edward VII Avenue,
> Caerdydd, CF10 3NB
--
--
Bill Gates e Scott McNealy estavam jogando frisbee perto de um lago.
Constantemente, Bill, demonstrando horrível pontaria, jogava muito alto e o
frisbee caía no meio do lago. Scott ia até lá, andava sobre a água e buscava o
frisbee, e o jogo prosseguia.
Na manhã seguinte, a Microsoft publica dois press-releases:
- Lançamentos da Microsoft superam expectativas!
- Scott não sabe nadar
signature.asc
Description: PGP signature
Re: amvault to terteriary media
Hi,
Have you tried?
amlabel -f -otapetype="LTO2" -otpchanger="" -olabelstr="Vault-[1-7]"
-ostorage=tape_storage vtl Vault-1 slot 1
Kind regards
Jose M Calhariz
On Fri, Sep 10, 2021 at 04:09:48AM -0400, Winston Sorfleet wrote:
> Is there anyone here making use of amvault, who has gotten amlabel to work?
>
> My old, old recipe went something like this: amlabel -f -otapetype="LTO2"
> -otpchanger="" -olabelstr="Vault-[1-7]" -otapedev="/dev/nst0" vtl Vault-1
> slot 1
>
> But that doesn't work with the current amanda.conf format
>
> Here's my /etc/amanda/vtl/amanda.conf, which vaults fine IF I have an
> already-labelled tape. Note the difference between "storage" - which is vtl
> - and "vault-storage" which should be the LTO.
>
>
>
>
> org "Romanus" # your organization name for reports
> mailto "w...@romanus.ca" # space separated list of operators at your site
> dumpuser "backup"
>
> dumpcycle 7 # the number of days in the normal dump cycle
> runspercycle 5 # the number of amdump runs in dumpcycle days
>
> tapecycle 40 tapes # the number of tapes in rotation
>
> storage "vtl"
> vault-storage "tape_storage"
> tpchanger "archivedisks"
> tapetype "HARDDISK" # what kind of tape it is
> runtapes 6 # number of tapes to be used in a single run
> of amdump
>
> define dumptype global {
> comment "Global definitions"
> auth "bsdtcp"
> }
>
> #define application-tool and dumptype for the amgtar application
> define application-tool app_amgtar {
> comment "amgtar"
> plugin "amgtar"
> #property "GNUTAR-PATH" "/path/to/gtar"
> #property "GNUTAR-LISTDIR" "/path/to/gnutar_list_dir"
> }
>
> define dumptype gui-base {
> global
> program "APPLICATION"
> application "app_amgtar"
> comment "gui base dumptype dumped with tar"
> compress none
> index yes
> }
>
> define tapetype HARDDISK {
> comment "Virtual Tapes"
> length 19768960 kbytes
> part_size 500 mbytes
> part_cache_type none
> }
>
> define changer LTO-2 {
> tpchanger "chg-single:/dev/nst0"
> device-property "LEOM" "TRUE"
> }
>
> define changer archivedisks {
> tpchanger "chg-disk:/amandatapes"
> property "num-slot" "45"
> property "auto-create-slot" "yes"
> }
>
> define storage "vtl" {
> tapedev "archivedisks"
> labelstr "vtl[0-9][0-9]*$" # label constraint regex: all tapes must
> match
> }
>
> define storage "tape_storage" {
> erase-on-failure yes
> policy "HP_Robot"
> runtapes 1
> set-no-reuse no
> #tapedev "HP_G2"
> tapedev "LTO-2"
> tapetype "LTO2"
> tapepool "$r"
> tpchanger "LTO-2"
> labelstr "Vault-[1-7]"
> autolabel "Vault-%" any
> }
>
> includefile "./advanced.conf"
> includefile "/etc/amanda/template.d/dumptypes"
> includefile "/etc/amanda/template.d/tapetypes"
>
>
--
--
O capitalismo dita inortodoxias, dissolve padrões sociais tradicionais e aplica
medidas comerciais e boa parte da vida. Por isso, a sociedade capitalista deve
desenvolver também um forte sistema de valores
--Henry Analote Grunwald
signature.asc
Description: PGP signature
Re: amflush surprize auth=ssh.
Hi, What you describe is what I see when I do not use chunks. The last backup to the last vtape will be transfered again to vtape on next amdump or amflush. Kind regards Jose M Calhariz On Sun, Aug 22, 2021 at 02:40:52PM -0400, Jon LaBadie wrote: > I have one large DLE that gets broken into about > 45 chunks for taping. My vtapes hold 20 of these > chunks and I allow up to 3 tapes to be used nightly. > > Two evening back another large DLE was in the same > dump so only about 30 of the 45 chunks fit on the > three tapes. > > Today I ran amflush thinking amanda would just tape > the 15 untaped chunks onto 1 vtape. But no, it is doing > the entire 45 which will take 3 vtapes. > > In a vtape environment, is this reasonable behavior? > > Was there a way to flush only the untaped chunks? > > Jon > -- -- O assassinato é uma forma extrema de censura. -- George Bernard Shaw signature.asc Description: PGP signature
Upload of amanda 3.5.1-8 to Debian with new documentation about auth=ssh.
Hi, I just upload a new package of amanda 3.5.1-8 to Debian. The NEWS is: * That I have updated the README.Debian with instructions for auth=ssh and more simple examples. * Added to a patch to build amanda with a new libc6, this patch came from Fedora and maybe interesting to merge unto 3.5.1 github repo. * I expect in a new upload to add the systemd units for auth=bsdtcp. I am not dropping the support for bsdtcp authentication, just making a little harder by not doing some automatic tasks on installation. Kind regards Jose M Calhariz -- -- A fama é boa até consegui-la --Tostão signature.asc Description: PGP signature
Re: Debian Buster, bsdtcp, systemd
On Sun, Aug 22, 2021 at 04:38:23PM +0200, Stefan G. Weichinger wrote: > Am 21.08.21 um 19:45 schrieb Jose M Calhariz: > > > One note, On Debian every choice I make when packaging amanda or as a > > sysadmin is I expect for amanda to run as backup:backup. > > Thanks > > but in the article in amanda@.service ... User=backup already. > > ok? not? > > backup:backup is a nomeclature used by chown to indicate user:group. On systemd unit you have "Group=disk # I am still testing if debian needs group backup here" Can you please update to "Group=backup"? Kind regards Jose M Calhariz -- -- A fama é boa até consegui-la --Tostão signature.asc Description: PGP signature
"taperflush 100" or 200 not working as documented
Hi, anyone is using taperflush, flush-threshold-dumped, flush-threshold-scheduled <> 0 with success? For me it does not work as documented, the holding disk is flushed before the ratio in taperflush is achieved. I need this working to fill an LTO-6 tape when holding disk have enough data and not when is around 50%. But for now I am playing with a toy installation of amanda and I am trying to understand the code in server-src/driver.c Kind regards Jose M Calhariz -- -- A imaginação sempre aumenta o mal que nos é oculto --Racine signature.asc Description: PGP signature
Re: Debian Buster, bsdtcp, systemd
On Fri, Aug 20, 2021 at 08:42:22AM +0200, Stefan G. Weichinger wrote: > Am 05.08.21 um 20:28 schrieb Stefan G. Weichinger: > > > A few years ago you could hope that it would be merged into the amanda > > sources ... now that the community project isn't maintained anymore, I > > would consider writing a blog post or so. I even have something in the > > pipeline already. > > Wrote some lines, published right now at > > https://www.oops.co.at/?p=341 > > comments and feedback welcome > One note, On Debian every choice I make when packaging amanda or as a sysadmin is I expect for amanda to run as backup:backup. Kind regards Jose M Calhariz -- -- Pressione qualquer tecla... Não, não, NÃÃO!! QUALQUER UMA MENOS ESSA!!! signature.asc Description: PGP signature
Re: Debian Buster, bsdtcp, systemd --- 10 GBit-NIC
On Fri, Jul 23, 2021 at 10:45:49AM +0200, Stefan G. Weichinger wrote:
> Am 22.07.21 um 13:54 schrieb Stefan G. Weichinger:
>
> > I defined this in amanda.conf
> >
> > define interface chelsio {
> >
> > comment "10G NIC"
> >
> > use 10 Gbps
> >
> > }
>
> More tuning ahead, not yet verified (= waiting for the next amdump):
>
>
> inparallel 6
> dumporder "BTBTBT"
> netusage 10 Gbps
> device-output-buffer-size 2048k # LTO6 drive
How many clients do you have?
>
> In
>
> "define application-tool app_amgtar"
>
> property "TAR-BLOCKSIZE" "1024"
>
> Quick tests show that this improves the creation of the "tar-stream" on the
> client.
>
> Restore test: todo. Sure.
>
> -
>
> What I can't yet explain:
>
> the holdingdisk (Samsung SSD 860 EVO 2TB)
>
> * it is attached to a MegaRAID SAS 2008 controller. The local admin created
> a RAID0 device on the controller, this gives us /dev/sdb in linux
>
> * one partition /dev/sdb1, XFS
>
> UUID=781a9caf-39f2-4e5a-b7cd-f2b320e06b74 /mnt/amhold xfs noatime 0 0
>
> * # cat /sys/block/sdb/queue/scheduler
>
> [none] mq-deadline
>
> I can write to it via dd with over 200 MB/s:
>
> root@backup:/mnt/amhold# dd if=/dev/zero of=/mnt/amhold/testfile bs=1G
> count=1 oflag=direct
>
> 1+0 Datensätze ein
>
> 1+0 Datensätze aus
>
> 1073741824 bytes (1,1 GB, 1,0 GiB) copied, 4,52339 s, 237 MB/s
>
> OK; slower with smaller blocks:
>
> root@backup:/mnt/amhold# dd if=/dev/zero of=/mnt/amhold/testfile bs=4M
> count=1000 oflag=direct
>
> 1000+0 Datensätze ein
>
> 1000+0 Datensätze aus
>
> 4194304000 bytes (4,2 GB, 3,9 GiB) copied, 23,2486 s, 180 MB/s
I was expecting much more from the SSD, but I can be thinking in
faster NVME.
Just for curiosity, what "hdparm -tT /dev/sdb" gives.
>
> -
>
> When I amdump a single DLE from another client, no compression, and watch
> with "atop", I see /dev/sdb1 at 100% "load" ... with around 130 MB/s max,
> decreasing write rate over time.
>
> The clients storage is able to deliver with around 300MB/s.
>
> And the NICs are 10G each.
>
> Where is the bottleneck? Or do I expect too much?
>
> The CPU cores are NOT fully loaded ...
>
On my setup I have more than 190 clients using auth=ssh with a NIC
of 10Gb/s.
On my amanda.conf for example:
inparallel 62
dumporder "tt"
Kind regards
Jose M Calhariz
--
--
Não preciso de advogados para me dizer o que não devo fazer.
Eu os contrato para me dizer como fazer o que quero fazer.
-- J. Pierpont Morgan
signature.asc
Description: PGP signature
Re: Optional exclude list results in STRANGE report
Hi,
I am using a .amanda-exclude.list per DLE on the top of it and is not
broken for me. I can share my settings if it help.
Kind regards
Jose M Calhariz
On Fri, Jul 09, 2021 at 05:13:19PM +, Debra S Baddorf wrote:
> On the other hand: I also used .amanda-exclude-list
> at the top of any DLE that needed an exclude list.
>
> However, they broke a few years ago. I don’t know if that was my
> version of Linux or my version of amanda.
>
> So trying a globalized version is a good idea.
>
> Deb Baddorf
> Fermilab
>
> > On Jul 9, 2021, at 8:28 AM, Kees Meijs | Nefos wrote:
> >
> > Hi Charles,
> >
> > Thank you for your prompt answer.
> >
> > On 09-07-2021 15:10, Charles Curley wrote:
> >> I wonder why you put the excludes file in with the stuff being backed
> >> up? I usually put my excludes files in with my amanda files, and refer
> >> to them with a fully qualified path:
> >>
> >> define dumptype comp-root-tar-var {
> >> comp-root-tar
> >> comment "Root partitions with compression, special for /var"
> >> exclude list "/etc/amanda/DailySet1/excludes.var"
> >> }
> >
> > Well that's easy: I was under the impression one must have a excludes file
> > per DLE. I was wrong.
> >
> >> I'm no expert on UEFI, but it strikes me as asking for problems to put
> >> anything other than UEFI files in /boot/efi. I vaguely recall that that
> >> is a FAT file system, in which case the file name may be a problem.
> >>
> >>
> >> Also, it's rather hard to diagnose what is likely a permissions issue
> >> without knowing what the relevant permissions are.
> >>
> >> root@hawk:/etc/amanda/DailySet1# ll excludes.var
> >> -rw-r--r-- 1 backup backup 138 Mar 26 2018 excludes.var
> >> root@hawk:/etc/amanda/DailySet1#
> >
> > Yes that's FAT32 and yes the filename is invalid and therefore a problem.
> >> -- Does anybody read signatures any more?
> >
> > Yes, I just did. :-)
> >
> > Thanks! Will try with a general exclude file in a different location.
> >
> > Cheers,
> > Kees
>
>
>
--
--
Ah se eu fosse homem...
Clodovil.
signature.asc
Description: PGP signature
Re: Problems configuring DLE for ZWC
Hi, On Sat, Apr 10, 2021 at 07:21:02AM -0700, Neil Richardson wrote: > Greetings. I've been trying to set up Amanda with the Zmanda Windows > Client (ZWC) for weeks and keep hitting various random problems, and would > *greatly* appreciate help. I'll try to start with a couple of basic > things, in the hopes that the rest are due to some configuration error I've > introduced while trying to fix the initial ones. > > (Before everything else, I guess I'll ask: Where are people supposed to go > to get info on Amanda? I've been looking at wiki.zmanda.com for months, > finally found forums.zmanda.com (appears to be read-only even after > registration) and the SourceForge project, but only in the past few days > found the GitHub site--and even amanda.org/about.php says that the source > is on SourceForge! (I tried to look at amanda.org/docs/README.txt to see > if there's more info, but it gave an HTTP 403 error.) > > > My first (technical) question is: Is it still true that ZWC only supports > the `exclude` and `exclude append` directives, but not the `import` one? > > > My second question is: is there a way, using planner or something, to get a > preview of what Amanda will back up based on my DLE? Some of my runs are > taking 10+ hours, which is a VERY long time to wait just to get an error at > the end. > > > My third question is: When I go to check what was actually backed up using > `amrecover`, one of my DLEs frequently reports: > 500 "/" is an invalid directory > No index records for cwd on new date > > When this happens, the output of `ls` is empty. I have verified that the > host and date match a date from `history` and my dumptype has `index yes` > specified. I believe this output is trying to say that there was no data > backed up from that DLE (perhaps because nothing changed in between > debugging runs) but if a DLE didn't get scheduled (or there were no changes > to be backed up) shouldn't it "superimpose" the results from the last > backup onto the date I've selected? Otherwise, I'd have to keep stepping > backward into every backup run to see when it was actually backed up...what > am I missing? The ZWC generates a zip file, so amanda does not understand what files are inside the backup. For restoring your only option is to recover the ZIP file from the tapes and run an unzip, pkzip or 7-zip or other zip software to restore the backup. Personally I gave up to use ZWC todo backups windows machines. Try to talk with Betsol, the owner of amanda and maybe they have a better solution for the use of ZWC. > > > Thank you for your time, > -Neil Kind regards Jose M Calhariz -- -- Uma autobiografia é um obituario em forma de seriado, ao qual falta o último capítulo. -- Quentin Crisp signature.asc Description: PGP signature
Re: Testing an Amanda installation
On Tue, Apr 13, 2021 at 10:22:16AM +0200, Cristian Zoicas wrote: > > Hello All > > I am very new to Amanda and I would like to ask a question about > the possibility of testing a specific configuration. > > Let's assume that I have enuogh confidence in my Amanda configuration but > before using it in a production environment I would like to test how the > backups work. Mainly I would like to do the following: > >1) To run the backup procedure a numer of times in a row and see/check > that the tapes are correctly used and reused. > >2) That I am able to perform restore operations. > > Is it possibile to do that? I am mainly interested in 1 because so far I > was not able to do that. The unexpected thing that happens when I > run the backup task in a row is that Amanda behaves as if it is not > able to detect the passing of time (probably because it checks the real > calendaristic time). Yes is possible to do more than one run per day and do some testing of your configuration. You just need some tweeks on amanda.conf from the one you will use in production. > > I've also tried to make the backup task thinkg that it is running in a > different day by using libfaketime. No success. No need for that. > > Thank you. > Cristian > Kind regards Jose M Calhariz -- -- Uma autobiografia é um obituario em forma de seriado, ao qual falta o último capítulo. -- Quentin Crisp signature.asc Description: PGP signature
Re: Strange bug on Debian buster, v10.3, segmentation fault on client doing amcheck
Hi, It is a race condition. While I am adding debug methods the problem goes away. After a pause of some time the problem start over again. By the look of the logs and strace seems that noop service ends to fast and the event loop waits for a process that have already terminated. Kind regards Jose M Calhariz On Fri, Jul 10, 2020 at 02:42:38PM +0100, Jose M Calhariz wrote: > Hi, > > I have done more research on this problem. More information about it > inline. > > On Tue, Jun 30, 2020 at 12:18:55PM +0100, Jose M Calhariz wrote: > > On Mon, Jun 29, 2020 at 11:06:46AM -0600, Charles Curley wrote: > > > On Mon, 29 Jun 2020 16:36:33 +0100 > > > Jose M Calhariz wrote: > > > > > > > On my main amanda installation I have a client that gives time out > > > > when doing backups. I have researched and checked out the most common > > > > problems. In the end I have found that: > > > > > > > > - "amcheck Config -c client" gives 30 seconds of timeout. > > > > > > I do not see that. I checked two clients, one AMD64, the other i386. > > > > On mine main amanda installation and have dozens of Debian clients. > > It is one client only that is failing and I do not understand why. > > Now I have two clients with problems, but the main problem are different. > > > > > > > > > > > > > > - I do not have any clue on the logs at the client. > > > > > > > > - Running the command by hand on the client I get segmentation fault. > > > > > > > > /usr/lib/amanda/amandad -auth=ssh amdump > > > > Segmentation fault > > > > > > I see that, on both machines. > > > > > > > OK, so the problem is another. More research to do. Thank you. > > I will post here when I find more info. > > > This nigth I have done more investigation. When I run "amcheck Conf > -c client" it gives a 30 seconds timeout. This timeout was increased > by me some time ago for other problem. So YMMV. > > On the client the amandad runs successfully but the never try to run > selfcheck and do not give an error. The prof is that I have no logs > in /var/log/amanda/client/Conf. I have made some changes, increased > the client debug logs and some others things and the selfcheck started > to run. Today selfcheck is not running again. > > > Anyone know where in the code of amandad is the launch of selfcheck so > I can quickly find the place and possibly add more debugging code? > > > > > > > > > > > > > > > > > - Running the command inside gdb I see a NULL pointer. > > > > > > > > gdb /usr/lib/amanda/amandad > > > > GNU gdb (Debian 8.2.1-2+b3) 8.2.1 > > > > > > I do not have symbols installed, so of course I can't examine the > > > variables. I do see a segment fault: > > > > > > ... > > > (gdb) run -auth=ssh amdump > > > Starting program: /usr/lib/amanda/amandad -auth=ssh amdump > > > [Thread debugging using libthread_db enabled] > > > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > > > > > Program received signal SIGSEGV, Segmentation fault. > > > 0x77f3a687 in stream_sendpkt () from > > > /usr/lib/x86_64-linux-gnu/amanda/libamanda-3.5.1.so > > > (gdb) > > > ... > > > > > > I have no idea what is going on here, not having the source in front of > > > me. But I wonder if this is because amanda is trying to use an SSH > > > connection that isn't there? > > > > > > The first time, I SSHed in as root, did an su - to backup, then ran > > > gdb. To test my hypothesis above, I went to my amanda server, su - to > > > backup, then sshed to the client. This time I did not get a seg fault, > > > and used Ctl-c to end the process: > > > > > > (gdb) run -auth=ssh amdump > > > Starting program: /usr/lib/amanda/amandad -auth=ssh amdump > > > [Thread debugging using libthread_db enabled] > > > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > > ^C > > > Program received signal SIGINT, Interrupt. > > > 0x776a27e4 in __GI___poll (fds=0x5559e3d0, nfds=2, > > > timeout=3) at ../sysdeps/unix/sysv/linux/poll.c:29 > > > 29../sysdeps/unix/sysv/linux/poll.c: No such file or directory. > > > (gdb) > > > > > > > > > > > > This is with the bog standard Buster version of amanda: > > > > > > root@dzur:~# pre amanda > > > amanda-client 1:3.5.1-2+b2amd64 > > > amanda-common 1:3.5.1-2+b2amd64 > > > root@dzur:~# > > > > > > > > > > Kind regards > > Jose M Calhariz > > > > > > Kind regards > Jose M Calhariz > > > -- -- Quando um não quer... o outro insiste. signature.asc Description: PGP signature
Re: Strange bug on Debian buster, v10.3, segmentation fault on client doing amcheck
Hi, I have done more research on this problem. More information about it inline. On Tue, Jun 30, 2020 at 12:18:55PM +0100, Jose M Calhariz wrote: > On Mon, Jun 29, 2020 at 11:06:46AM -0600, Charles Curley wrote: > > On Mon, 29 Jun 2020 16:36:33 +0100 > > Jose M Calhariz wrote: > > > > > On my main amanda installation I have a client that gives time out > > > when doing backups. I have researched and checked out the most common > > > problems. In the end I have found that: > > > > > > - "amcheck Config -c client" gives 30 seconds of timeout. > > > > I do not see that. I checked two clients, one AMD64, the other i386. > > On mine main amanda installation and have dozens of Debian clients. > It is one client only that is failing and I do not understand why. Now I have two clients with problems, but the main problem are different. > > > > > > > > > - I do not have any clue on the logs at the client. > > > > > > - Running the command by hand on the client I get segmentation fault. > > > > > > /usr/lib/amanda/amandad -auth=ssh amdump > > > Segmentation fault > > > > I see that, on both machines. > > > > OK, so the problem is another. More research to do. Thank you. > I will post here when I find more info. This nigth I have done more investigation. When I run "amcheck Conf -c client" it gives a 30 seconds timeout. This timeout was increased by me some time ago for other problem. So YMMV. On the client the amandad runs successfully but the never try to run selfcheck and do not give an error. The prof is that I have no logs in /var/log/amanda/client/Conf. I have made some changes, increased the client debug logs and some others things and the selfcheck started to run. Today selfcheck is not running again. Anyone know where in the code of amandad is the launch of selfcheck so I can quickly find the place and possibly add more debugging code? > > > > > > > > > > - Running the command inside gdb I see a NULL pointer. > > > > > > gdb /usr/lib/amanda/amandad > > > GNU gdb (Debian 8.2.1-2+b3) 8.2.1 > > > > I do not have symbols installed, so of course I can't examine the > > variables. I do see a segment fault: > > > > ... > > (gdb) run -auth=ssh amdump > > Starting program: /usr/lib/amanda/amandad -auth=ssh amdump > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x77f3a687 in stream_sendpkt () from > > /usr/lib/x86_64-linux-gnu/amanda/libamanda-3.5.1.so > > (gdb) > > ... > > > > I have no idea what is going on here, not having the source in front of > > me. But I wonder if this is because amanda is trying to use an SSH > > connection that isn't there? > > > > The first time, I SSHed in as root, did an su - to backup, then ran > > gdb. To test my hypothesis above, I went to my amanda server, su - to > > backup, then sshed to the client. This time I did not get a seg fault, > > and used Ctl-c to end the process: > > > > (gdb) run -auth=ssh amdump > > Starting program: /usr/lib/amanda/amandad -auth=ssh amdump > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > ^C > > Program received signal SIGINT, Interrupt. > > 0x7ffff76a27e4 in __GI___poll (fds=0x5559e3d0, nfds=2, > > timeout=3) at ../sysdeps/unix/sysv/linux/poll.c:29 > > 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. > > (gdb) > > > > > > > > This is with the bog standard Buster version of amanda: > > > > root@dzur:~# pre amanda > > amanda-client 1:3.5.1-2+b2amd64 > > amanda-common 1:3.5.1-2+b2amd64 > > root@dzur:~# > > > > > > Kind regards > Jose M Calhariz > > Kind regards Jose M Calhariz -- -- Aqueles que amam ser temidos temem ser amados, e eles próprios são mais medrosos do que todos, porque enquanto os outros homens temem apenas a eles, eles temem a tudo --São Francisco de Sales signature.asc Description: PGP signature
Re: Strange bug on Debian buster, v10.3, segmentation fault on client doing amcheck
On Mon, Jun 29, 2020 at 11:06:46AM -0600, Charles Curley wrote: > On Mon, 29 Jun 2020 16:36:33 +0100 > Jose M Calhariz wrote: > > > On my main amanda installation I have a client that gives time out > > when doing backups. I have researched and checked out the most common > > problems. In the end I have found that: > > > > - "amcheck Config -c client" gives 30 seconds of timeout. > > I do not see that. I checked two clients, one AMD64, the other i386. On mine main amanda installation and have dozens of Debian clients. It is one client only that is failing and I do not understand why. > > > > > - I do not have any clue on the logs at the client. > > > > - Running the command by hand on the client I get segmentation fault. > > > > /usr/lib/amanda/amandad -auth=ssh amdump > > Segmentation fault > > I see that, on both machines. > OK, so the problem is another. More research to do. Thank you. I will post here when I find more info. > > > > > - Running the command inside gdb I see a NULL pointer. > > > > gdb /usr/lib/amanda/amandad > > GNU gdb (Debian 8.2.1-2+b3) 8.2.1 > > I do not have symbols installed, so of course I can't examine the > variables. I do see a segment fault: > > ... > (gdb) run -auth=ssh amdump > Starting program: /usr/lib/amanda/amandad -auth=ssh amdump > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > Program received signal SIGSEGV, Segmentation fault. > 0x77f3a687 in stream_sendpkt () from > /usr/lib/x86_64-linux-gnu/amanda/libamanda-3.5.1.so > (gdb) > ... > > I have no idea what is going on here, not having the source in front of > me. But I wonder if this is because amanda is trying to use an SSH > connection that isn't there? > > The first time, I SSHed in as root, did an su - to backup, then ran > gdb. To test my hypothesis above, I went to my amanda server, su - to > backup, then sshed to the client. This time I did not get a seg fault, > and used Ctl-c to end the process: > > (gdb) run -auth=ssh amdump > Starting program: /usr/lib/amanda/amandad -auth=ssh amdump > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > ^C > Program received signal SIGINT, Interrupt. > 0x776a27e4 in __GI___poll (fds=0x5559e3d0, nfds=2, timeout=3) > at ../sysdeps/unix/sysv/linux/poll.c:29 > 29../sysdeps/unix/sysv/linux/poll.c: No such file or directory. > (gdb) > > > > This is with the bog standard Buster version of amanda: > > root@dzur:~# pre amanda > amanda-client 1:3.5.1-2+b2amd64 > amanda-common 1:3.5.1-2+b2amd64 > root@dzur:~# > > Kind regards Jose M Calhariz -- -- A ciência aumenta nosso poder na mesma proporção que diminui o nosso orgulho --Claude Bernard signature.asc Description: PGP signature
Strange bug on Debian buster, v10.3, segmentation fault on client doing amcheck
Hi, On my main amanda installation I have a client that gives time out when doing backups. I have researched and checked out the most common problems. In the end I have found that: - "amcheck Config -c client" gives 30 seconds of timeout. - I do not have any clue on the logs at the client. - Running the command by hand on the client I get segmentation fault. /usr/lib/amanda/amandad -auth=ssh amdump Segmentation fault - Running the command inside gdb I see a NULL pointer. gdb /usr/lib/amanda/amandad GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/amanda/amandad...Reading symbols from /usr/lib/debug/.build-id/02/91452cbae527e441191377fd040fc0e0605a13.debug...done. done. gdb) run -auth=ssh amdump Starting program: /usr/lib/amanda/amandad -auth=ssh amdump [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77f3a777 in stream_sendpkt (cookie=0x555ae6f0, pkt=0x7fffe940) at security-util.c:215 215 security-util.c: No such file or directory. (gdb) rint rh Undefined command: "rint". Try "help". (gdb) print rh $1 = (struct sec_handle *) 0x555ae6f0 (gdb) print rh->rc $2 = (struct tcp_conn *) 0x0 (gdb) print cookie $3 = (void *) 0x555ae6f0 (gdb) bt #0 0x77f3a777 in stream_sendpkt (cookie=0x555ae6f0, pkt=0x7fffe940) at security-util.c:215 #1 0xa4ab in protocol_accept (handle=0x555ae6f0, pkt=) at amandad.c:611 #2 0x77f4a9c1 in ssh_accept (driver=, conf_fn=0x9ec0 , in=0, out=1, fn=0xa430 , datap=0x0) at ssh-security.c:291 #3 0x7a1b in main (argc=, argv=0x7fffeca8) at amandad.c:522 I have seen this problema with the amanda from Debian for buster and with a personalized amanda package "3.5.1-4~WIP+5" that runs on all of my clients Debian buster. So the problem is not with my package. Can be something perculiar of Debian, but I presume that is something wrong with the client. I think that a SEGFAULT is not normal so here I am reporting in the case that someone can understand the cause in the code. Kind regards Jose M Calhariz -- -- A ciência aumenta nosso poder na mesma proporção que diminui o nosso orgulho --Claude Bernard signature.asc Description: PGP signature
Re: anyone using amgpgcrypt
On Mon, May 18, 2020 at 06:24:53PM +0200, Stefan G. Weichinger wrote:
> Am 16.05.20 um 19:28 schrieb Jose M Calhariz:
> >
> > Hi,
> >
> > I have start to use amgpgcrypt to do some backups to S3. I found
> > some problems and needed to adjust the perl script. Anyone else using
> > it to share ideas?
>
> Unfortunately I haven't yet used it. But feel free to start the
> discussion anyway ... maybe we get some ideas and suggestions here.
>
To me for the amgpgcrypt to work I disabled in the script the lauch of
gpg-agent, after everything seams to work. I think this is a problem
with my personal setup and not a bug with amgpgcrpt.
Follow the diff with my changes:
--- /usr/sbin/amgpgcrypt2019-04-17 14:11:15.0 +0100
+++ /usr/local/sbin/amgpgcrypt2 2020-05-16 17:11:44.830076773 +0100
@@ -72,14 +72,14 @@
sub encrypt() {
my $gpg_agent_cmd = do_gpg_agent();
my $gpg = which_gpg();
-system "$gpg_agent_cmd $gpg --batch --disable-mdc --encrypt --cipher-algo
AES256 --recipient $AMANDA";
+system "$gpg --batch --disable-mdc --encrypt --cipher-algo AES256
--recipient $AMANDA";
sleep(2); # allow gpg-agent the time to exit
}
sub decrypt() {
my $gpg_agent_cmd = do_gpg_agent();
my $gpg = which_gpg();
-system "$gpg_agent_cmd $gpg --batch --quiet --no-mdc-warning
--secret-keyring $AM_PRIV --decrypt --passphrase-fd 3 3<$AM_PASS";
+system "$gpg --batch --quiet --no-mdc-warning --secret-keyring $AM_PRIV
--decrypt --passphrase-fd 3 3<$AM_PASS";
sleep(2); # allow gpg-agent the time to exit
}
Kind regards
Jose M Calhariz
--
--
Mulheres têm de ter passado, e homens futuro
--Alice Carta
signature.asc
Description: PGP signature
anyone using amgpgcrypt
Hi, I have start to use amgpgcrypt to do some backups to S3. I found some problems and needed to adjust the perl script. Anyone else using it to share ideas? Kind regards Jose M Calhariz -- -- Na vida tudo passa. Ate uva passa. signature.asc Description: PGP signature
Re: A classic: ERROR: (hostname): selfcheck request failed: tcpm_recv_token: invalid size
On Thu, Jul 18, 2019 at 11:04:52PM -0400, Winston Sorfleet wrote: > On 2019-07-18 10:49 p.m., Nathan Stratton Treadway wrote: > > On Thu, Jul 18, 2019 at 21:51:56 -0400, Winston Sorfleet wrote: > >> |backup@flamen:/etc/amanda/vtl$ amcheck -c vtl --client-verbose pomerium|| > >> ||Amanda Backup Client Hosts Check|| > >> |||| > >> ||ERROR: pomerium.romanus.ca: selfcheck request failed: tcpm_recv_token: > >> invalid size|| > >> ||Client check: 1 host checked in 5.814 seconds. 1 problem found.|| > >> | > > > >> Anybody have a suggestion of where I should look first? > > Do /var/log/amanda/client//selfcheck.2019*.debug files get > > created on the client get created when you run amcheck? > > > > Nathan > They did not. However I've found what seems to have been part of the > problem: the upgrade process changed /etc/amandahosts to root:root when > it has to be backup:backup. > Please consider submitting a bug report about /etc/amandahosts. Currently I do not have a buster server running amanda-server, but I will research about that. I no longer use bsdauth or tcpauth, I only use ssh authentication. So yours bug reports are crucial for the good shape of amanda on Debian. Kind regards Jose M Calhariz -- -- Todo mundo quer comer na mesa do governo, mas ninguém quer lavar os pratos --William Faulkner signature.asc Description: PGP signature
Re: amanda-client: HOST localhost ERROR: //192.168.0.250/ftp: Application 'amsamba': exited with status 1
Hi, I do not have a setup for testing amsamba, but I will do my the best next week. I am going to DebConf19 and should have time to look into it. Kind regards Jose M Calhariz On Mon, Jul 08, 2019 at 05:51:44PM +0200, Tobias Koeck wrote: > Hi, > > since I have upgraded to Debian 10 I get strange amsamba errors. > > Any ideas why? > --- > > for amcheck a2g-2 I'll get for the samba checks > > HOST localhost ERROR: smbclient: Unable to initialize messaging context > HOST localhost ERROR: //192.168.0.250/ftp: Application 'amsamba': exited > with status 1 > > The Amsamba* file shows the following output > > on Jul 08 12:01:25.509075732 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: pid 2464 ruid 34 euid 34 version 3.5.1: start at Mon Jul 8 > 12:01:25 2019 > Mon Jul 08 12:01:25.510363259 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: Arguments: selfcheck > Mon Jul 08 12:01:25.574864631 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: pid 2464 ruid 34 euid 34 version 3.5.1: rename at Mon Jul 8 > 12:01:25 2019 > Mon Jul 08 12:01:25.574918101 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: application: Amsamba > Mon Jul 08 12:01:25.574971869 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: warning: Use of uninitialized value $regex_match in pattern > match (m//) at /usr/lib/amanda/application/amsamba line 92. > Mon Jul 08 12:01:25.575022213 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: Arguments: selfcheck --message line --config a2g-2 --host > localhost --disk //192.168.0.250/ftp --device //192.168.0.250/ftp > --index line --record --amandapass /etc/amandapass > Mon Jul 08 12:01:25.575041181 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: command: selfcheck > Mon Jul 08 12:01:25.575069629 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: disk //192.168.0.250/ftp > Mon Jul 08 12:01:25.575083965 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: amsamba version 3.5.1 > Mon Jul 08 12:01:25.614619170 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: amsamba smbclient-version 4.9.5-Debian > Mon Jul 08 12:01:25.614697420 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: /usr/bin/smbclient > Mon Jul 08 12:01:25.614786687 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: amandapass: /etc/amandapass > Mon Jul 08 12:01:25.616603666 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: password_wtr 4 > Mon Jul 08 12:01:25.616620367 2019: pid 2466: thd-0x55b9ce332000: > Amsamba: password_rdr 3 > Mon Jul 08 12:01:25.616742029 2019: pid 2466: thd-0x55b9ce332000: > Amsamba: warning: close() on unopened filehandle 1 at > /usr/lib/amanda/application/amsamba line 428. > Mon Jul 08 12:01:25.616817693 2019: pid 2466: thd-0x55b9ce332000: > Amsamba: warning: close() on unopened filehandle 2 at > /usr/lib/amanda/application/amsamba line 429. > Mon Jul 08 12:01:25.616890194 2019: pid 2466: thd-0x55b9ce332000: > Amsamba: execute: /usr/bin/smbclient /usr/bin/smbclient > //192.168.0.250/ftp -U backup -E -c quit > Mon Jul 08 12:01:25.647162371 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: stderr: WARNING: The "syslog" option is deprecated > Mon Jul 08 12:01:25.647300656 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: stderr: Unable to initialize messaging context > Mon Jul 08 12:01:25.647333909 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: smbclient: Unable to initialize messaging context > Mon Jul 08 12:01:25.647416879 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: stderr: WARNING: The "syslog" option is deprecated > Mon Jul 08 12:01:25.703629806 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_utime : 0 > Mon Jul 08 12:01:25.703651035 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_stime : 0 > Mon Jul 08 12:01:25.703658632 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_maxrss : 32104 > Mon Jul 08 12:01:25.703665341 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_ixrss : 0 > Mon Jul 08 12:01:25.703671709 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_idrss : 0 > Mon Jul 08 12:01:25.703677904 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_isrss : 0 > Mon Jul 08 12:01:25.703684089 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_minflt : 5399 > Mon Jul 08 12:01:25.703690386 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_majflt : 0 > Mon Jul 08 12:01:25.703696679 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_nswap : 0 > Mon Jul 08 12:01:25.703702963 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_inblock : 256 > Mon Jul 08 12:01:25.703709143 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_oublock : 16 > Mon Jul 08 12:01:25.703715213 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_msgsnd : 0 > Mon Jul 08 12:01:25.703721198 2019: pid 2464: thd-0x55b9ce332000: > Amsamba: ru_msgrcv : 0 > Mon Jul 08 12:01:25.703727193 2019: p
Re: Backup from an S3 drive, not to S3 drive
Hi, My prototype of a S3tarfs is progressing well, good enough to start thinking integrating with amanda. Anyone have experience to share about creating a new application for amanda backups? There is support for: - gtar - pgsql - samba - star - suntar - zfs-sendrecv - zfs-snapshot I want to add support for S3tar and S3tarfs, they are two implementations of the same, but the former implements a proprietary stream and the later uses S3fs and tar. Kind regards Jose M Calhariz On Wed, Jun 26, 2019 at 02:56:50PM +0100, Jose M Calhariz wrote: > > Hi, > > where I work we have several storage systems that the best way to > access them is using an S3 gateway. This systems needs backups and > archives. > > My question is: > > In this list there is more people that want to do backup of S3 > storage? > > What are your experiences? > > Want to help in assisting the development of a plugin for amanda? Beta > tester are welcome. > > Kind regards > Jose M Calhariz > > -- -- A consciência e aquela voz interior que nos adverte de que alguem pode estar olhando. -- H. L. Mencken signature.asc Description: PGP signature
Backup from an S3 drive, not to S3 drive
Hi, where I work we have several storage systems that the best way to access them is using an S3 gateway. This systems needs backups and archives. My question is: In this list there is more people that want to do backup of S3 storage? What are your experiences? Want to help in assisting the development of a plugin for amanda? Beta tester are welcome. Kind regards Jose M Calhariz -- -- Estar compromissado e meio caminho andado para sucesso -- Zinder signature.asc Description: PGP signature
Re: amanda client on updated debian-9.8
Hi, On Wed, Feb 27, 2019 at 08:13:17AM +0100, Stefan G. Weichinger wrote: > Am 26.02.19 um 16:26 schrieb Jose M Calhariz: > > > > My plan is for Debian 11, current is 9, to make ssh authentication > > the default. I will not disable bsd authentication, only harder to > > setup. > > > > In attach is the Readme.Debian that I have created. > > thanks > > What I wonder and what IMO is not explicitly clear from the docs: > > does the client have to be able to login into backupuser@server as > well? Only when you want to run amrecover on the client. Because of the security issues I have it disabled 99,9% of the time. > > And additionally I still wonder what docker does that makes amdump > hang at 99,99% > Kind regards Jose M Calhariz -- -- Se vives de acordo com as leis da natureza, nunca seras pobre; se vives de acordo com as opinioes alheias, nunca seras rico. -- Seneca signature.asc Description: PGP signature
Re: amanda client on updated debian-9.8
My plan is for Debian 11, current is 9, to make ssh authentication the default. I will not disable bsd authentication, only harder to setup. In attach is the Readme.Debian that I have created. Kind regards Jose M Calhariz On Mon, Feb 25, 2019 at 07:48:03AM +0100, Stefan G. Weichinger wrote: > Am 25.02.19 um 00:08 schrieb Jose M Calhariz: > > On Thu, Feb 21, 2019 at 04:50:25PM +0100, Stefan G. Weichinger > > wrote: > >> > >> does anyone see estimates fail on a updated Debian 9.8 amanda > >> client server? > >> > >> update: seems that my new docker daemon on the client closes the > >> iptables for amanda > >> > >> does anyone have a snippet for me? > >> > >> I read > >> https://wiki.zmanda.com/index.php/How_To:Set_Up_iptables_for_Amanda > >> and loaded that module without success so far. > >> > >> connection is coming in, estimate starts, but results seem not > >> get back to the tape server > >> > >> > > > > I would start using ssh authentication instead of old bsd. Is what > > I use in my setups and most probably would work with your docker > > daemon. > > > > I have written documentation on how to setup it and would like > > beta tester to read it. > > good suggestion, thanks! Will try that asap. > > And sure, show us the howto > > > > -- -- Se vives de acordo com as leis da natureza, nunca seras pobre; se vives de acordo com as opinioes alheias, nunca seras rico. -- Seneca Notes on making amanda-client work on a Debian system To get indexing (or specifically amrecover) to work right two things need to be done: 1. If you're using tcpd, make sure to edit the server's /etc/hosts.allow and allow all client machines into the daemon amandad 2. Edit the server(s) ~backup/.amandahosts and add an entry like: " root" As always: for more complex setups consult the manpages and available documentation in /usr/share/doc/amanda-common ;-) - - - - - To make a client work using SSH transport do: Copy the contents of id_rsa_amanda.pub from backup@amanda-server into ~backup/.ssh/authorized_keys mkdir -p ~backup/.ssh echo -n 'from="XXX.XXX.XXX.XXX",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad -auth=ssh amdump" ' >> ~backup/.ssh/authorized_keys cat id_rsa_amanda.pub >> ~backup/.ssh/authorized_keys Edit the autorized_keys to replace XXX.XXX.XXX.XXX with the IP of the backup server. Change the shell of the backup account to /bin/bash. chsh -s /bin/bash backup Test in the server that "amcheck $CONF -c $CLIENT" works -- Jose M Calhariz , Fri, 14 Jul 2017 11:53:08 +0100 signature.asc Description: PGP signature
Re: amanda client on updated debian-9.8
On Thu, Feb 21, 2019 at 04:50:25PM +0100, Stefan G. Weichinger wrote: > > does anyone see estimates fail on a updated Debian 9.8 amanda client server? > > update: seems that my new docker daemon on the client closes the > iptables for amanda > > does anyone have a snippet for me? > > I read > https://wiki.zmanda.com/index.php/How_To:Set_Up_iptables_for_Amanda and > loaded that module without success so far. > > connection is coming in, estimate starts, but results seem not get back > to the tape server > > I would start using ssh authentication instead of old bsd. Is what I use in my setups and most probably would work with your docker daemon. I have written documentation on how to setup it and would like beta tester to read it. Kind regards Jose M Calhariz -- -- Se vives de acordo com as leis da natureza, nunca seras pobre; se vives de acordo com as opinioes alheias, nunca seras rico. -- Seneca signature.asc Description: PGP signature
Re: Dump to tape AND keep copy on disk?
On Tue, Jan 15, 2019 at 05:33:55PM -0500, Jon LaBadie wrote: > On Tue, Jan 15, 2019 at 07:38:37PM +, Debra S Baddorf wrote: > > Amanda people: does the newer amanda have any means to dump to tape > > while still retaining a copy on the holding disk? > > > > Dumping to tape, and then vaulting BACK to a disk area seems excessive, > > if there is a better way? > > > > Deb Baddorf (asking for Stefan Weichinger) > > > > I've never used it, but ISTR amanda had a RAID feature > where you could tape to multiple devices simultaneously. The last time I tried to use "RAIT" I was told it was deprecated and should use vaulting. I have a limited experiencie with vaulting where one copy was on vTapes on disk and a second copy was on S3, that I can share. > > > jon Kind regards Jose M Calhariz > > > > > > > On Jan 15, 2019, at 1:34 PM, Stefan G. Weichinger wrote: > > > > > > Am 14.01.19 um 19:05 schrieb Debra S Baddorf: > > > > > >> You can let the normal job send the dumps to tape, and then > > >> “vault” a copy back onto a “vtape” on disk (not your holding disk, > > >> but that’s semantics). > > >> That might suit your need. > > >> > > >> I’ve done vaulting from a tape onto a disk area ….. moved the > > >> disk area to another node, and vaulted again to copy it to a > > >> different flavor of tape drive. So the very first part of my task > > >> might suit you to a tee. > > > > > > I understand that this might work but it seems to way more steps than > > > having a second "storage" to flush the holdingdisk content to. If that > > > works (and the "storage" doesn't allow to filter the lev0 afaik). > > > > > > I haven't yet found the time and the brain to continue testing that so > > > far. > >>> End of included message <<< > -- -- "A perda das vidas será irreversível." -- Dan Quayle, ex-vice-presidente americano signature.asc Description: PGP signature
Re: amrecover and readline
On Tue, Nov 13, 2018 at 11:10:03AM +0100, Stefan G. Weichinger wrote: > > man amrecover says: > > "The GNU readline library is used to provide command line history and > editing if it was built in to amrecover." > > I am unsure if that means we should have command completion as well > within amrecover? > > I get history via arrow keys, but no completion for paths or filenames. > > Could someone tell if that is all we get or if I have something missing > here? > > That all I get, when using amrecover. Kind regards Jose M Calhariz -- -- Há dois momentos na vida de um homem em que ele não deve especular: quando ele não pode pagar por isto, e quando ele pode --Mark Twain signature.asc Description: PGP signature
Re: Amanda "info on small DLEs not saved" bug -- proposed patch
On Sun, Nov 11, 2018 at 01:12:04PM -0500, Nathan Stratton Treadway wrote: > On Sun, Nov 11, 2018 at 14:43:48 +0000, Jose M Calhariz wrote: > > Thank you Nathan for your work on this. It gives me some hope for the > > future of amanda. > > (Well, this one was right at the edge my understanding of Amanda's > internals, so as far as the future of Amanda I hope you aren't confusing > me with an actual Amanda developer! :) ) > > > > > I am preparing a new release of amanda 3.5.1 for Debian unstable and > > stretch with this fix and other fix from JLM. I will be back with > > more information after some testing on my amanda servers. > > Sounds great, thanks. Let me know when you have some > packages/source-package to download and I can give it a try here. > (Hopefully you'll also get a chance to investigate the libcurl3 v.s. > libcurl4 dependency problems I ran into on the WIP package version you > had last September.) I have not. What is you OS, I can try to compile the packages for you or give you instructions on how to compile. > > Nathan > > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 > > Kind regards Jose M Calhariz -- -- O homem vale o que vale o seu ideal, esta e a sua medida -- J. Maira Puladas signature.asc Description: PGP signature
Re: Amanda "info on small DLEs not saved" bug -- proposed patch
Thank you Nathan for your work on this. It gives me some hope for the future of amanda. I am preparing a new release of amanda 3.5.1 for Debian unstable and stretch with this fix and other fix from JLM. I will be back with more information after some testing on my amanda servers. Kind regards Jose M Calhariz On Fri, Nov 09, 2018 at 06:00:41PM -0500, Nathan Stratton Treadway wrote: > On Fri, Nov 02, 2018 at 13:00:38 -0400, Nathan Stratton Treadway wrote: > > On Fri, Nov 02, 2018 at 12:35:06 -0400, Gene Heskett wrote: > > > > > Fri Nov 02 03:42:06.085962877 2018: pid 13139: thd-0x9824e00: driver: not > > > updating because origsize or dumpsize is 0 > > > Fri Nov 02 03:42:06.086158866 2018: pid 13139: thd-0x9824e00: driver: > > > Building type FILE header of 32768-32768 bytes with name='coyote' > > > disk='/usr/games' > > > dumplevel=1 and blocksize=0 > > > Fri Nov 02 03:42:06.086317001 2018: pid 13139: thd-0x9824e00: driver: > > > Building type FILE header of 32768-32768 bytes with name='coyote' > > > disk='/usr/games' > > > dumplevel=1 and blocksize=0 > > > Fri Nov 02 03:42:06.092807051 2018: pid 13139: thd-0x9824e00: driver: > > > driver: send-cmd time 2461.017 to taper0: FILE-WRITE worker0-0 > > > 00-00130 /usr/dumps/20181102030105/coyote._usr_games.1 coyote /usr/games > > > 1 20181102030105 "" "" "" 1 "" "" "" "" 10 > > > > > > > Ah, interesting, looks like this applies to level 1 dumps as well. What > > does "amadmin CONFIG info coyote /usr/games shop /usr/lib/amanda" output? > > > > Okay, I believe I have tracked down this "info on small DLEs not saved" > bug... > > > Summary: > > The short-ish summary is that in Amanda 3.4 and 3.5, any dump which ends > but being shorter than 1024 bytes long (after compression) is treated as > not having happened at all, as far as Amanda's recording of "info" > statistics goes. > > This is most significant for full dumps (i.e. of very small partitions), > because it causes Amanda to think that DLE has never been dumped (or, > that the last time it was dumped was on the final run made using Amanda > 3.3 or older), and thus it schedules that DLE for a full dump on every > run. > > However, the bug actually also affects incremental dumps (as we > discussed in the above-quoted message) -- so DLEs that don't change much > on a particular day and thus end up with very tiny incrementals end up > recording those dumps as having taken place on 1969/12/31 rather than > the day they actually occurred. > > > Neither of the above situations is "fatal" as far as preventing Amanda > from actually backup up your data, but for people (such as Gene) who are > effected, a workaround workaround is simply to make sure that the dump > on a particular day is at least 1024 bytes. > > For full dumps, you can do this just by creating a "dummy" file on the > otherwise-very-empty partition in question, using data that's already > compressed so that the dump file is still big enough after Amanda > compresses it. (In my tests, I just used the bytes off the front of the > amanda_3.4.2.orig.tar.gz file I happened to have sitting around.) > > (For incrementals the trick is to make sure there is enough changing on > the partition that the incremental dump is over the cutoff size; the > best way to do that will depend on what data is on that partition, etc.) > > > > Internal details and history: > > The bug happens because the messages that the chunker and driver > processes use to communicate with each other specify the size of the > files transferred in integral units of "kb" (=1024 bytes), and thus the > size given for very small files is "0" -- but the code in the driver > that handles updating the info database has a specific check for > zero-length dumps and refuses to update the database in that case. > (This check is found in driverio.c:update_info_dumper() .) > > It appears that the bug has existed since Amanda 3.4, when the old > chunker.c version of the chunker program was replaced with a new Perl > version. > > Both server-src/chunker.c as found in Amanda 3.3 and server-src/dumper.c > as it exists in 3.5 take special care to round "kb" value passed for > files which are short-but-not-empty files up to "1" -- but that logic > was not implemented in the Perl chunker code when it was created.. > > (Interestingly, if I am reading the old chunker.c code correctly, it > used to round up not just very-small-but-not-empty files to 1 kb, bu
Re: All level 0 on the same run?
On Wed, Oct 31, 2018 at 02:13:27PM -0400, Nathan Stratton Treadway wrote: > On Wed, Oct 31, 2018 at 14:38:43 +0000, Jose M Calhariz wrote: > > I bet this DLEs are very small and that you have done the upgrade of > > the amand server between 20 and 20+tapecycle ago. > > > > There is a bug in recent amanda server that if a DLE is very small it > > will not update properly the internal database after a level 0. > > Making that DLE overdue. > > Yes, that definitely would explain what Gene was seeing. > > Did you recieve or create a fix for that bug? (I didn't immediately > recognize any of the debian/patch files in the amanda_3.5.1-3_WIP_2 > source package I downloaded from you a few weeks ago as applying to this > bug.) No fix. I was waiting for a new release before reporting this bug. As I do not like to have many patches applied to the Debian packages, besides the ones to debianize the software. > > Do you know how small a DLE has to be to trigger this problem? No, usually they are 0 size on amreport, being MB or GB. > > > Nathan > > > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 > > Kind regards Jose M Calhariz -- -- Nada é tao bom que alguem, em algum lugar, não ira odiar. -- Joseph Murphy signature.asc Description: PGP signature
Re: All level 0 on the same run?
On Wed, Oct 31, 2018 at 08:39:43AM -0400, Nathan Stratton Treadway wrote: > On Wed, Oct 31, 2018 at 07:59:02 -0400, Gene Heskett wrote: > > yadda yadda. So just where the hell do I look for these? > > root@coyote:/amandatapes/Dailys# su amanda -c "/usr/local/sbin/amadmin > > Daily due"|grep Overdue > > Overdue 21 days: shop:/usr/local > > Overdue 21 days: shop:/var/amanda > > Overdue 21 days: lathe:/usr/local > > Overdue 21 days: lathe:/var/amanda > > Overdue 21 days: GO704:/var/amanda I bet this DLEs are very small and that you have done the upgrade of the amand server between 20 and 20+tapecycle ago. There is a bug in recent amanda server that if a DLE is very small it will not update properly the internal database after a level 0. Making that DLE overdue. > > > > So I look in the vtapes, and find its being done too. > > Checking for lathe:/var/amanda, its there > > Checking for lathe:/usr/local, they've been done too > > What do "amadmin Daily info shop", etc. say? > > Nathan > > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 > > Kind regards Jose M Calhariz -- -- A vida é como rapadura: é doce, mas não é mole. signature.asc Description: PGP signature
Re: amanda 3.5.1 ignoring option amandad-path in amanda.conf
On Tue, Oct 30, 2018 at 07:08:31AM -0400, Nathan Stratton Treadway wrote:
> On Mon, Oct 29, 2018 at 19:01:45 +0000, Jose M Calhariz wrote:
> > To workaround this I am using a dumptype with:
> >
> > amandad-path "/usr/amanda/amandad"
> >
> > After some changes in disklist I think this option is not working.
> > That is strange. Is anyone using successfully this option? What
> > version of amanda are you using in the server? Anyone can check the
> > code?
>
> I haven't used this option myself, but from the amanda.conf man page
> entry for it the first question to ask is whether you are indeed using
> ssh authentication in this particular dumptype?
Yes, I am using only ssh authentication on this server.
>
> In a quick scan of the (upstream) git repo changelog I don't see any
> recent changes that obviously affect this option.
>
> If no one else with actual experience using this option chimes in, I
> could try to take a closer look at the code, but it would probably be
> easier to track down where in the source to look if you posted the full
> definition of the dumptype in question and also the exact text of the
> related messages you are finding in the log files
This is the debug dumptype, the comments are my try to pinpoint the
problem.
define dumptype special {
# Global definitions
# global
# lev-medium
# rhel
# From global
# comment "Global definitions"
# index yes
auth "ssh"
ssh_keys "/var/backups/.ssh/id_rsa_amdump"
# max-warnings 111
# comprate 99, 99
# compress best
exclude list optional ".amanda-exclude.list"
# From lev-medium
# program "APPLICATION"
# application "amgtar"
# priority medium
# maxpromoteday 6
# From rhel
client_username "amandabackup"
amandad-path "/usr/lib64/amanda/amandad"
}
The relevant error on amanda server, when I run "amcheck Daily -c
host.fqdn" is:
sh: /usr/lib/amanda/amandad
>
> Nathan
>
>
> Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
> Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
> GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
> Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
>
>
Kind regards
Jose M Calhariz
--
--
Todo homem deveria ser incendiário até os 25 anos de idade, e bombeiro dali em
diante
--Alceu Amoroso Lima
signature.asc
Description: PGP signature
amanda 3.5.1 ignoring option amandad-path in amanda.conf
Hi, I am using the latest amanda 3.5.1 in Debian stretch and I want to do backup of other Linux systems, in this case CentOS. The amandad daemon in Debian packages is located in /usr/lib/amanda/amandad but in CentOS rpms is located in /usr/lib64/amanda/amandad. To workaround this I am using a dumptype with: amandad-path "/usr/amanda/amandad" After some changes in disklist I think this option is not working. That is strange. Is anyone using successfully this option? What version of amanda are you using in the server? Anyone can check the code? Kind regards Jose M Calhariz -- -- Eu quero ficar rica, mas não quero fazer o que é preciso para ficar rica --Gertrude Stein signature.asc Description: PGP signature
Problem verifying tapes stored on Amazon S3
Hi, I usually verify the vTapes right after amanda finishes writing them. When I started to use Amazon S3, I do the same, because the peace of mind is more valuable than the cost of the download. In the begin I saw one error from time to time, that was not found if I redo the amcheckdump. The last 2 days I got errors and they are not going away if I redo the amcheckdump. First question: Is anyone seeing this problem with Amazon S3? I am using a Debian machine, running v9 aka stretch, with amanda 1:3.5-2~bpo9+1. This means that is running the amanda 3.5, compiled from the Debian package for unstable to stable. https://packages.debian.org/source/sid/amanda The amanda server is on same site as the clients and the S3 is in Europe Amazon. More questions. Could this be a bug on amanda code that deals with S3? Can I have the wrong settings for using Amazon S3? I am not certain what are the relevant parameters about S3, to post it on this email. Kind regards Jose M Calhariz -- -- Aos sonhos não importa o preço --Ettore Bugatti
Re: amvault: FATAL no device is available to create an xfer_dest
On Sun, Mar 11, 2018 at 10:55:59PM -0400, Winston Sorfleet wrote: > Oh this is 3.4.5, on Debian - José's test package. I see that 3.5.1 is > available but I am in package-hold on a production server and I am > cautious by preference. I have seen changes in 3.5.x in amvault and S3 storage. I am currently successful in using it for amvault into a S3 storage, ceph back-end. The only problem that I see is with a very big installations of amanda, were if some hosts fails it cascade into much more fails. Jean-Louis is on it and have provided patchs to solve the problem. Kind regards Jose M Calhariz > > On 2018-03-11 10:45 PM, Winston Sorfleet wrote: > > /rant I swear, Amanda has given me nothing but grief since 3.3.6 -> 3.4.x. > > > > My last two monthly amvault --latest-fulls have given me this error > > message, which from my barely-literate read of the source code, is an > > error from get_device(). Previous amvaults worked. > > > > My amanda.conf and tapelist can be found at > > https://drive.google.com/drive/folders/0B_vw5EcgO15lXzJwQVk3UXpkTUE > > but... before asking anyone to do a deep-dive in there, can anyone give > > me hints as to what I might try to narrow the scope of the problem? I > > am not looking forward to trying an strace. > > > > I did, to ensure sanity of the destination robot (the source is a VTL), > > do an > > > > amtape -otpchanger="HP_G2" vtl update" (my config is "vtl") > > > > No problems. The amvault command line is > > > > amvault -q --latest-fulls --dest-storage "tape_storage" vtl > > > > -- -- Emacs, não só um estilo de vida mas um completo desperdício de espaço em disco (Alan Cox)
Re: Restoring files from amanda in a script
Hi,
Thank you for all the replies. They are a good food for the mind.
On Tue, Mar 06, 2018 at 09:10:48PM +, Jean-Louis Martineau wrote:
> You can't restore in a unique tree of files.
> I do not understand why you want to do that.
Let-me explain better. I have a big tree of files on OpenAFS, a
network filesystem, that is backup up by amanda. I need to copy this
tree to another place. I could use rsync, but I think this rsync will
take several days on a moving target.
My "clever idea" was to use the backups of amanda to restore the files
in the target. The backups I want forms a subset of all the clients
and DLEs in the amanda server. This means some thing like 6 clients
and 61 DLEs from 800. So is a good case for a script to recover this
61 DLEs.
>
> To do it:
> - patch amgtar to remove the -G flag ("-xpGvf" to "-xpvf"), otherwise
> extracting a DLE will remove what was extracted from another DLE, but file
> erase before the backup will not be erased
> - run 'amadmin CONF find' to get the list of all dumps [HOST DISK DATE LEVEL]
> you want to restore
> - run 'amfetchdump CONF --extract --directory /tmp/restore [HOST DISK DATE
> LEVEL]*',putting all [HOST DISK DATE LEVEL] on the same command line.
>
> Jean-Louis
>
> From: owner-amanda-us...@amanda.org <owner-amanda-us...@amanda.org> on behalf
> of Jose M Calhariz <jose.calha...@tecnico.ulisboa.pt>
> Sent: March 6, 2018 3:28 PM
> To: amanda-users@amanda.org
> Subject: Restoring files from amanda in a script
>
> Hi,
>
> In short I want to restore from a specific date, all the data from
> multiples DLEs and multiples servers into a unique tree of files in
> the amanda server. This is too much tedious to do using the
> interactive amrecover. This is Complex enough to use a script with
> amrestore or amfetchdump to restore all the files I want. My first
> approach is not working well. So I would like to hear the experiences
> from the list for similar problems. I am interested in hints before I
> deep dive into the RTFM.
>
> Kind regards
> Jose M Calhariz
>
Kind regards
Jose M Calhariz
--
--
Quem não se comunica se estrumbica
--Chacrinha
Restoring files from amanda in a script
Hi, In short I want to restore from a specific date, all the data from multiples DLEs and multiples servers into a unique tree of files in the amanda server. This is too much tedious to do using the interactive amrecover. This is Complex enough to use a script with amrestore or amfetchdump to restore all the files I want. My first approach is not working well. So I would like to hear the experiences from the list for similar problems. I am interested in hints before I deep dive into the RTFM. Kind regards Jose M Calhariz -- -- Quem não se comunica se estrumbica --Chacrinha
More problems with a big installation of amanda 3.5.1 on Debian stretch, v9
Hi, I am starting to investigate another problem with my big installation of amanda 3.5.1 on Debian stretch, v9. Now amanda is crashing somewhere near the end of the planning phase and the beginning of the dumping phase. In the last 4 days it happened 2 times. The information I have for now is very little. >From the report: FAILURE DUMP SUMMARY: chunker: FATAL Connection reset by peer at /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/IPC/LineProtocol.pm line 579. taper: FATAL Scribe cannot quit while a transfer is active at /usr/lib/x86_64-linux-gnu/amanda/perl/Amanda/Taper/Scribe.pm line 563. (...) >From the logs of the Linux (kern.log) I have this: Feb 22 00:47:22 kernel: warn_alloc: 222 callbacks suppressed Feb 22 00:47:22 kernel: swapper/22: page allocation failure: order:2, mode:0x2284020(GFP_ATOMIC|__GFP_COMP|__GFP_NOTRACK) Feb 22 00:47:22 kernel: CPU: 22 PID: 0 Comm: swapper/22 Not tainted 4.9.0-5-amd64 #1 Debian 4.9.65-3+deb9u2 Feb 22 00:47:22 kernel: Hardware name: Dell Inc. PowerEdge R730xd/0599V5, BIOS 2.4.3 01/17/2017 (...) Feb 22 01:11:35 kernel: traps: driver[31708] general protection ip:7fbb22b2c018 sp:7fffde984038 error:0 Feb 22 01:11:35 kernel: in libamanda-3.5.1.so[7fbb22af2000+7c000] Being that the logs of amanda have much more private information, I will send them by private email. Kind regards Jose M Calhariz -- -- "Sucesso = trabalho + estudo + boca fechada." -- Albert Einstein
Re: Regression in 3.5.1 or a broken compilation for Debian stretch
On Thu, Feb 08, 2018 at 06:06:47PM +, Jean-Louis Martineau wrote:
> add:
> debug-auth 9
> to amanda.conf and retry
> Post the planner debug file.
>
> For the failing client, do amandad is executed, post the amandad debug files.
>
> Jean-Louis
As promised I an posting here a summary of the private emails exchanged
between me and Jean-Louis.
After posting my debug logs Jean-Louis have quickly identified a quick
fix. The patch is attached, in case other people may find it usefull
before a new release of amanda.
Kind regards
Jose M Calhariz
--
--
Não tenha pressa, mas não perca tempo
--José Saramago
diff --git a/common-src/protocol.c b/common-src/protocol.c
index 1ab7294..972ef4e 100644
--- a/common-src/protocol.c
+++ b/common-src/protocol.c
@@ -179,8 +179,8 @@ protocol_sendreq(
void * datap)
{
proto_t *p;
-char*platform = NULL;
-char*distro = NULL;
+static char *platform = NULL;
+static char *distro = NULL;
p = g_malloc(sizeof(proto_t));
p->state = s_sendreq;
@@ -209,7 +209,10 @@ protocol_sendreq(
proto_debug(1, _("protocol: security_connect: host %s -> p %p\n"),
hostname, p);
-get_platform_and_distro(, );
+if (!platform && !distro) {
+ get_platform_and_distro(, );
+}
+
if (distro != NULL &&
!g_str_equal(distro, "mac") &&
#if defined HAVE_FUNC_GETSERVBYNAME_R_4 || defined HAVE_FUNC_GETSERVBYNAME_R_5 || defined HAVE_FUNC_GETSERVBYNAME_R_6
@@ -243,8 +246,6 @@ protocol_sendreq(
security_connect(p->security_driver, p->hostname, p->conf_fn, connect_callbackX,
p, p->datap);
}
-g_free(platform);
-g_free(distro);
}
static gpointer
Regression in 3.5.1 or a broken compilation for Debian stretch
Hi, I have been testing the new amanda 3.5 and 3.5.1 on Debian, on my servers, before uploading the package into to Debian sid. The 3.5 successfully solved the problem with big installations of amanda here the fault of one or 2 clients cascade to more failures during backups or "amcheck -c". I have been testing the 3.5.1 in my little server with success and upload it to Debian. But now that I have installed it on my big server, 130 clients and 700 DLE, I am seeing it again the cascade problem of multiple failures because of one or two failures. I am seeking help to pinpoint the problem. It can be a regression on the code or must probably a problem on my compiled packages for stretch. Main question: What logs I should look or what patch I can apply to try to identified the root cause of the problem? Details Currently I have 3 hosts that are unreachable. This cause a non predictable failure. Meaning that sometimes everything works as expected, but most of the times more clients fail with: selfcheck request failed: error sending REQ: write error to: Broken pipe Looking into one of the clients that fail, I do not see an obvious error message in the amanda logs. I am willing to continue looking into the logs or running modified code or even run a debugger. For privacy reasons I will post here a resume of the findings or send by private email the full logs and other results. More details: The server runs Debian 9 (stretch) and use amanda software 3.5.1 from Debian sid recompiled for stretch. Most of the clients are Debian 9 and runs amanda client from Debian 3.3.9-5 or 3.5 and 3.5.1 (backported from Debian sid). The patch that I have applied for Debian should not have changed this behaviour and can be checked in: https://packages.debian.org/buster/amanda-server TIA Kind regards Jose M Calhariz -- -- Goze a vida, afinal você nasceu de uma gozada!
Re: amflush run while amdump underway tries to flush .tmp files
I am interested in this fix. There is a final patch?
Or is better to use the code from git?
Kind regards
JOse M Calhariz
On Tue, Nov 21, 2017 at 12:57:00PM -0500, Nathan Stratton Treadway wrote:
> On Tue, Nov 21, 2017 at 11:45:52 -0500, Jean-Louis Martineau wrote:
> > There is no patch attached on your email.
>
> Ah, sorry, attached here.
>
> >
> > I do not see how Amanda::Util::setup_application call code in holding.c
>
> To be precise what I actually saw was activity involving the "pid" files
> in the holding directory showing up in an strace log. I am not sure how
> it got called, but assume it was coming from holding.c because it had
> the arguments for the kill syscall in the correct order (and thus I
> believe the activity couldn't have been from the then-in-place
> Holding.pm code). I will investigate further and let you know what I
> find.
>
> (In any case, I am sure that the pid read from the holding-directory pid
> file during the get_all_datestamps() call was the parent pid of the
> current process [and of course the file had not contained that value
> before amflush was invoked].)
>
>
> Nathan
>
>
> Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
> Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
> GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
> Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
> --- Holding.pm.orig 2017-11-20 16:51:32.0 -0500
> +++ Holding.pm2017-11-21 02:10:47.992749021 -0500
> @@ -25,6 +25,7 @@
> use File::stat;
> use IO::Dir;
> use POSIX qw( :fcntl_h );
> +use Errno;
> use Math::BigInt;
> use strict;
> use warnings;
> @@ -198,6 +199,36 @@
> return 1;
> }
>
> +# check to see if the given pid identifies a process that could
> +# validily be holding the Amanda directory lock (thus preventing
> +# us from taking it). (See also holding.c:can_take_holding() for
> +# related logic..)
> +sub _valid_locking_pid {
> +my $pid_to_check = shift;
> +
> +if ( $pid_to_check == $$ || $pid_to_check == getppid() ) {
> +# this process or the parent already hold the lock, so we
> +# can go ahead and use the directory.
> +return 0;
> +}
> +
> +if (kill(0, $pid_to_check) == 0 ) {
> +if ($! == Errno::EPERM) {
> + # the process exists (but we don't have permission to kill it)
> + return 1;
> +}
> +else {
> + # (if we reach here, presumably the errno was ESRCH)
> + # the process does not exist; we can use the directory
> + return 0;
> +}
> +}
> +else {
> + # kill succeeded, so process does exist
> + return 1;
> +}
> +}
> +
> sub _walk {
> my ($file_fn, $verbose, $take_pid) = @_;
>
> @@ -233,8 +264,10 @@
> if (open(my $pidh, $pidfn)) {
> my $pid = <$pidh>;
> close($pidh);
> - if (kill($pid, 0) == 0) {
> - # pid is alive, skip this directory
> +
> + if ( _valid_locking_pid($pid) ) {
> + # $pid seems valid, so we skip over this directory
> + print $verbose "skipping directory '$dirfn' due to lock by
> pid $pid. \n" if $verbose;
> next;
> }
> }
--
--
O dinheiro é simplesmente aquilo que o Estado, de tempos em tempos, declara ser
um bom instrumento legal para saldar contratos em dinheiro
--John Maynard Keynes
Re: amflush run while amdump underway tries to flush .tmp files
Hi, I have a user that have reported this problem and with a suspection that amflush could flush the temporary files. I leave here the link to the bugreport: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881754 Kind regards Jose M Calhariz On Fri, Nov 17, 2017 at 12:38:12AM -0500, Nathan Stratton Treadway wrote: > (Amanda v3.5) > > I noticed that Amanda 3.5 no longer aborts amflush if amdump is > currently running (as older versions of Amanda do). > > So out of curiousity I kicked of "amflush TestBackup" while amdump was > busy dumping to the holding disk... and I discovered that amflush > actually tries to go ahead and flush the ".tmp" file files that it finds > in the holding directory: > > = From /var/log/amanda/server/TestBackup/amflush.20171116200510.debug: > Thu Nov 16 20:05:17.590062176 2017: pid 26860: thd-0x2f07e00: amflush: > flushing /amanda/TestBackup-holding/2017111622/client1._.0.tmp > Thu Nov 16 20:05:17.590096226 2017: pid 26860: thd-0x2f07e00: amflush: > flushing /amanda/TestBackup-holding/2017111622/client2._.1.tmp > = > > In this case the taper failed (and thus the amflush didn't actually do > anything with the .tmp files): > > = From /var/log/amanda/TestBackup/amdump.1: > driver: send-cmd time 14.132 to taper0: FILE-WRITE worker0-0 00-2 > /amanda/TestBackup-holding/2017111622/client1._.0.tmp client1 / 0 > 2017111622 "" "" "" "" "" "" "" "" 0 > writing taper command 'FILE-WRITE worker0-0 00-2 > /amanda/TestBackup-holding/2017111622/client1._.0.tmp client1 / 0 > 2017111622 "" "" "" "" "" "" "" "" 0 > ' failed: Broken pipe > = > (There is a line break in the log file just before "' failed".) > > > = From /var/log/amanda/server/TestBackup/taper.20171116200517.debug: > Thu Nov 16 20:05:18.502419601 2017: pid 26862: thd-0x4232000: taper: Building > type SPLIT_FILE header of 32768-32768 bytes with name='client1' disk='/' > dumplevel=0 and blocksize=32768 > Thu Nov 16 20:05:22.427709157 2017: pid 26862: thd-0x4232050: taper: no > next_filename > Thu Nov 16 20:05:22.427743969 2017: pid 26862: thd-0x4232050: taper: sending > XMSG_CRC message > Thu Nov 16 20:05:22.427748905 2017: pid 26862: thd-0x4232050: taper: > xfer-source-holding CRC: 2e4f7128 size: 249856000 > Thu Nov 16 20:05:22.427757739 2017: pid 26862: thd-0x4232050: taper: > xfer_queue_message: MSG: <XMsg@0x7f46b8001bf0 type=XMSG_CRC > elt=<XferSourceHolding@0x423> version=0> > Thu Nov 16 20:05:22.427767783 2017: pid 26862: thd-0x4232050: taper: > xfer-source-holding sending XMSG_DONE message > Thu Nov 16 20:05:22.427773216 2017: pid 26862: thd-0x4232050: taper: > xfer_queue_message: MSG: <XMsg@0x7f46b8001f00 type=XMSG_DONE > elt=<XferSourceHolding@0x423> version=0> > [ *** file ends abruptly here ***] > = > > > but whether or not that indicates a bug in the taper, it seems like > amflush should not ever try to flush .tmp files from the holding disk... > (right?) > > > > Finally, after this testing I notice that the command_file still has > FLUSH commands for those .tmp files (even though neither the files nor > the containing holding directory now exist). I've run both "amdump" and > "amflush" since then, and tried "amcleanup" as well. Is there any > (good) way to clean up these orphan commands? > > = From /etc/amanda/TestBackup/command_file: > ID 1633 > 1603 FLUSH TestBackup > /amanda/TestBackup-holding/2017111622/client1._.0.tmp client1 / > 2017111622 0 TestBackup WORKING:17072 TODO > 1604 FLUSH TestBackup > /amanda/TestBackup-holding/2017111622/client2._.1.tmp client2 / > 2017111622 0 TestBackup WORKING:17072 TODO > = > > = > # ls -l /amanda/TestBackup-holding/ > total 0 > = > > > Nathan > > > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 > -- -- Todo homem luta com mais bravura por seus interesses do que seus direitos. -- Napoleao signature.asc Description: PGP signature
Re: DLE stuck on holdingdisk and being flushed on every dump
On Wed, Nov 01, 2017 at 05:03:58PM -0400, Jean-Louis Martineau wrote:
> Jose,
>
> The report should report the error.
> The attached patch fix it.
The patch applied cleanly and I am now compiling it.
Kind regards
Jose M Calhariz
>
> Jean-Louis
>
> On 01/11/17 12:18 PM, Jose M Calhariz wrote:
> > On Wed, Nov 01, 2017 at 10:47:10AM -0400, Jean-Louis Martineau wrote:
> > > Jose,
> > >
> > > When amanda did the backup, it computed a crc of 6828c030.
> > > But it compute b8d66d3d when it read it from holding disk to flush it.
> > > Do you see that error in the report for all flush attempt?
> > Yes, I see.
> >
> >
> > > The holding disk file is not erase because of the crc mismatch.
> > > You can manually remove it (amadmin holding list, amadmin holding
> > > delete) from the holding disk and force a full backup of that dle.
> > >
> > > That's why a added the crc, these kind of errors where undetected
> > > before.
> > I hove only seen this error, because after an amdump I do:
> >
> > /usr/bin/time /usr/sbin/amcheckdump ${CONF}
> > ls -alF /backup/amanda/${CONF}/data/ | tail
> >
> > I have not seen any error on the report generated by amdump. Should
> > not be there a notice about this type of errors?
> >
> >
> > > Jean-Louis
> >
> > Kind reagards
> > Jose M Calhariz
> >
> >
> > > On 01/11/17 10:24 AM, Jose M Calhariz wrote:
> > > > Hi
> > > >
> > > > I am using amanda 3.5 on my personal server and started to investigate
> > > > a strange problem on my amanda installation.
> > > >
> > > > Since around 10 days ago when it runs the amdump during the nigth, it
> > > > flush the holdingdisk, by starting allways with the same big DLE.
> > > > This means after the DLE is on vTape is not deleted from the
> > > > holdingdisk and will be flushed on the next night.
> > > >
> > > > I found an interesting error message in amdump.20171101031517, I think
> > > > this error is related to the problematic DLE. And I noticed that the
> > > > file on vTape is broken too, it generates an error from gzip.
> > > >
> > > > driver: result time 549.166 from taper0: PARTIAL worker0-0 00-1
> > > > INPUT-ERROR TAPE-GOOD "6828c030:54131462843" "[sec 548.00 bytes
> > > > 54131462843 kps 96464.883212 orig-kb 53706460]" "source server crc
> > > > (6828c030:54131462843) and input server crc (b8d66d3d:54131462843)
> > > > differ)" ""
> > > >
> > > > This problem possibly was caused by an error on SATA that caused the
> > > > system disk to became read-only.
> > > >
> > > > What logs should I investigate? Because this is a personal
> > > > installation with private data, I will send the logs to the interested
> > > > persons, not to the list.
> > > >
> > > >
> > > > Kind regards
> > > > Jose M Calhariz
> > > >
> > > 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
>
>
> diff --git a/perl/Amanda/Report/human.pm b/perl/Amanda/Report/human.pm
> index 0b80219..e6a700d 100644
> --- a/perl/Amanda/Report/human.pm
> +++ b/perl/Amanda/Report/human.pm
> @@ -667,7 +667,9 @@ sub output_error_summaries
> push @dump_failures, "$hostname $qdisk lev
> $try->{chunker}->{level} FAILED [$try->{chunker}->{error}]";
> $failed = 1;
> }
> - if ( exists $try->{taper} && exists $try->{dumper} && !exists
> $dle->{driver}
> + if ( exists $try->{taper}
> + && ((exists $try->{dumper} && !exists $dle->{driver})
> + || (!exists $try->{dumper} && !exists $dle->{driver}))
> && ( $try->{taper}->{status} eq 'fail'
> || ( $try->{taper}->{status} eq 'partial'))) {
> my $flush = "FLUSH";
--
--
A vaidade de ser tido como alguém que guarda segredos é geralmente um dos
principais motivos para revelá-los
--Samuel Johnson
Re: DLE stuck on holdingdisk and being flushed on every dump
On Wed, Nov 01, 2017 at 10:47:10AM -0400, Jean-Louis Martineau wrote:
> Jose,
>
> When amanda did the backup, it computed a crc of 6828c030.
> But it compute b8d66d3d when it read it from holding disk to flush it.
> Do you see that error in the report for all flush attempt?
Yes, I see.
>
> The holding disk file is not erase because of the crc mismatch.
> You can manually remove it (amadmin holding list, amadmin holding
> delete) from the holding disk and force a full backup of that dle.
>
> That's why a added the crc, these kind of errors where undetected
> before.
I hove only seen this error, because after an amdump I do:
/usr/bin/time /usr/sbin/amcheckdump ${CONF}
ls -alF /backup/amanda/${CONF}/data/ | tail
I have not seen any error on the report generated by amdump. Should
not be there a notice about this type of errors?
>
> Jean-Louis
Kind reagards
Jose M Calhariz
>
> On 01/11/17 10:24 AM, Jose M Calhariz wrote:
> > Hi
> >
> > I am using amanda 3.5 on my personal server and started to investigate
> > a strange problem on my amanda installation.
> >
> > Since around 10 days ago when it runs the amdump during the nigth, it
> > flush the holdingdisk, by starting allways with the same big DLE.
> > This means after the DLE is on vTape is not deleted from the
> > holdingdisk and will be flushed on the next night.
> >
> > I found an interesting error message in amdump.20171101031517, I think
> > this error is related to the problematic DLE. And I noticed that the
> > file on vTape is broken too, it generates an error from gzip.
> >
> > driver: result time 549.166 from taper0: PARTIAL worker0-0 00-1
> > INPUT-ERROR TAPE-GOOD "6828c030:54131462843" "[sec 548.00 bytes
> > 54131462843 kps 96464.883212 orig-kb 53706460]" "source server crc
> > (6828c030:54131462843) and input server crc (b8d66d3d:54131462843) differ)"
> > ""
> >
> > This problem possibly was caused by an error on SATA that caused the
> > system disk to became read-only.
> >
> > What logs should I investigate? Because this is a personal
> > installation with private data, I will send the logs to the interested
> > persons, not to the list.
> >
> >
> > Kind regards
> > Jose M Calhariz
> >
> 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
--
--
O grande prazer proporcionado por um cachorro e o de que
você pode se passar por um idiota na frente dele e ele não
apenas não rira de você, como se passara também por
idiota.
-- Samuel Butler
DLE stuck on holdingdisk and being flushed on every dump
Hi I am using amanda 3.5 on my personal server and started to investigate a strange problem on my amanda installation. Since around 10 days ago when it runs the amdump during the nigth, it flush the holdingdisk, by starting allways with the same big DLE. This means after the DLE is on vTape is not deleted from the holdingdisk and will be flushed on the next night. I found an interesting error message in amdump.20171101031517, I think this error is related to the problematic DLE. And I noticed that the file on vTape is broken too, it generates an error from gzip. driver: result time 549.166 from taper0: PARTIAL worker0-0 00-1 INPUT-ERROR TAPE-GOOD "6828c030:54131462843" "[sec 548.00 bytes 54131462843 kps 96464.883212 orig-kb 53706460]" "source server crc (6828c030:54131462843) and input server crc (b8d66d3d:54131462843) differ)" "" This problem possibly was caused by an error on SATA that caused the system disk to became read-only. What logs should I investigate? Because this is a personal installation with private data, I will send the logs to the interested persons, not to the list. Kind regards Jose M Calhariz -- -- Os três melhores sons do mundo são: a voz do ser amado, o borbulhar da água no deserto e o ruído de uma moeda de ouro batendo em outra --Provérbio árabe
Re: approaches to Amanda vaulting?
Hi, I am too interested in examples of vaulting. In my case is to duplicate the locals vtapes into a remote S3 endpoint, for purposes of reliability in case of disaster. If I have 50 locals vtapes, I want to have the same 50 vtapes on S3, on a amvault. Kind regards Jose M Calhariz On Wed, Oct 04, 2017 at 10:17:22AM -0400, Nathan Stratton Treadway wrote: > We are in the process of adding vaulting to our existing Amanda > environment, and I am curious to hear/see how other sites have > approached this. > > In particular, I'm curious what policies you have adopted for what gets > vaulted, and how exactly you have scripted the vaulting so that you are > sure the correct dumps always get copied the correct number of times, > etc. > > In our situation, our nightly backups are to vtapes on a large internal > drive, and our plan is to then vault to separate vtapes on external USB > drives that are rotated physically each business day. So I think we > don't want to use "vault-storage", since we want to let the nightly > dumps proceeded without concern for whether the next USB drive is > available yet. But what isn't clear is the best way to code a cron job > to run later in the day, so that it keeps track of which of the nightly > dumps have already been vaulted v.s. the ones that still need to be. > > But more generally, I'm just curious to see how various sites have > implemented vaulting. > > Thanks. > > Nathan > > > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239 > > -- -- Perguntar a um escritor o que acha dos criticos e como perguntar a um poste como ele se sente a respeito dos cachorros. -- John Osborne
Re: What are the correct permissions for lib binaries for amanda 3.5
On Sat, Oct 14, 2017 at 11:36:09AM -0400, Jean-Louis Martineau wrote: > On 14/10/17 11:14 AM, Jose M Calhariz wrote: > > -rwsr-xr-- 1 root backup 10232 Oct 13 17:23 ambind > > ambind must not be readable by all > > -rwsr-x--- 1 root backup 10232 Oct 13 17:23 ambind Thank you for the quick reply. May I ask why "ambind must not be readable by all" ? > > > Jean-Louis > 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 Kind regards Jose M Calhariz -- -- Perguntar a um escritor o que acha dos criticos e como perguntar a um poste como ele se sente a respeito dos cachorros. -- John Osborne
What are the correct permissions for lib binaries for amanda 3.5
I am trying to package amanda 3.5 for Debian. Where the user for backups is "backup" and during the packaging I have to manually set the correct permissions of the binaries, specially group owner and setuid bits. For example my VM for testing amanda have: backup@debian-at:~$ ls -alF /usr/lib/amanda/ total 892 drwxr-xr-x 4 root root4096 Oct 14 15:13 ./ drwxr-xr-x 36 root root4096 Oct 14 14:36 ../ -rwxr-xr-x 1 root root6683 Oct 13 17:23 amadmin_perl* -rwxr-xr-x 1 root root 39160 Oct 13 17:23 amandad* -rw-r--r-- 1 root root 935 Oct 13 17:23 amanda-sh-lib.sh -rwxr-xr-x 1 root root 40835 Oct 13 17:23 ambackupd* -rwsr-xr-- 1 root backup 10232 Oct 13 17:23 ambind* -rw-r--r-- 1 root root 135 Oct 13 17:23 amcat.awk -rwxr-xr-x 1 root root 11613 Oct 13 17:23 amcheck-device* -rwxr-xr-x 1 root root 10243 Oct 13 17:23 amdumpd* -rwxr-xr-x 1 root root3804 Oct 13 17:23 amidxtaped* -rwxr-xr-x 1 root root 47184 Oct 13 17:23 amindexd* -rwxr-xr-x 1 root root2448 Oct 13 17:23 amlogroll* -rwxr-xr-x 1 root root 48136 Oct 13 17:23 amndmjob* -rw-r--r-- 1 root root 20523 Oct 13 17:23 amplot.awk -rw-r--r-- 1 root root3400 Oct 13 17:23 amplot.g -rw-r--r-- 1 root root3410 Oct 13 17:23 amplot.gp -rwxr-xr-x 1 root root 26616 Oct 13 17:23 amtrmidx* -rwxr-xr-x 1 root root 14328 Oct 13 17:23 amtrmlog* drwxr-xr-x 2 root root4096 Oct 14 15:13 application/ -rwsr-xr-- 1 root backup 18424 Oct 13 17:23 calcsize* -rwxr-xr-x 1 root root2672 Oct 13 17:23 chunker* -rwxr-xr-x 1 root root 96336 Oct 13 17:23 driver* -rwxr-xr-x 1 root backup 63672 Oct 13 17:23 dumper* -rwsr-xr-- 1 root backup 10232 Oct 13 17:23 killpgrp* -rwxr-xr-x 1 root root 52232 Oct 13 17:23 ndmjob* -rwxr-xr-x 1 root root 10232 Oct 13 17:23 noop* -rwxr-xr-x 1 root root5024 Oct 13 17:23 patch-system* -rwxr-xr-x 1 root backup 67712 Oct 13 17:23 planner* -rwxr-xr-x 1 root root1556 Oct 13 17:23 restore* drwxr-xr-x 8 root root4096 Oct 14 15:13 rest-server/ -rwsr-xr-- 1 root backup 10232 Oct 13 17:23 rundump* -rwsr-xr-- 1 root backup 14328 Oct 13 17:23 runtar* -rwxr-xr-x 1 root root 43080 Oct 13 17:23 selfcheck* -rwxr-xr-x 1 root root 60840 Oct 13 17:23 sendbackup* -rwxr-xr-x 1 root root 18432 Oct 13 17:23 senddiscover* -rwxr-xr-x 1 root root 55736 Oct 13 17:23 sendsize* -rwxr-xr-x 1 root root2918 Oct 13 17:23 taper* -rwxr-xr-x 1 root root 10232 Oct 13 17:23 teecount* But I got this warning from amcheck: backup@debian-at:~$ amcheck DailySet1 '/etc/amanda/DailySet1/amanda.conf', line 71: warning: Keyword usetimestamps is deprecated. Amanda Tape Server Host Check - ERROR: program /usr/lib/amanda/ambind: wrong permission NOTE: Holding disk '/hdisk/DailySet1': 2478080 KB disk space available, using 2375680 KB '/etc/amanda/DailySet1/amanda.conf', line 71: warning: Keyword usetimestamps is deprecated. slot 2: volume 'DailySet1-02' Will write to volume 'DailySet1-02' in slot 2. NOTE: skipping tape-writable test Server check took 0.282 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 0.153 seconds. 0 problems found. (brought to you by Amanda 3.5) Is the permissions of the binaries in /usr/lib/amanda correct? Kind regards Jose M Calhariz -- -- O tempo e a imagem movel da eternidade imovel. -- Platao 428 ± 348 a.C.; filosofo grego.
Re: Using RAIT with vTapes and S3
On Wed, Oct 11, 2017 at 11:09:45AM -0400, Jean-Louis Martineau wrote: > Jose, > > What do you want to achieve? mirror? Yes, mirroring between local vTapes and remote S3. > Using RAIT for mirroring is deprecated since we added vault functionality. > It is better to write to vtape and then amvault to S3. I will try that under amanda 3.4 > > In amanda-3.5, you can configure a dump to be flushed from holding disk > to vtape and S3. I am still working on the package amanda 3.5 for Debian. > > Jean-Louis Kind regards Jose M Calhariz > > On 10/10/17 03:14 PM, Jose M Calhariz wrote: > > Hi, > > > > Anyone using RAIT with vTapes and S3 that can share the config tu use > > as example? > > > > Me and my colleague, we are struggling to setup an working RAIT using > > vTapes and S3 on amanda 3.3.9. The vTapes and S3 work alone. But > > when trying to make the RAIT, it fails. Before sharing here one of > > the failed setups, I would like to know if is possible to make it > > work? > > > > Kind regards > > Jose M Calhariz > > > > > 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 -- -- Os controles estatais sobre a economia, quando excessivos, são inevitavelmente perniciosos --Franco Modigliani
Using RAIT with vTapes and S3
Hi, Anyone using RAIT with vTapes and S3 that can share the config tu use as example? Me and my colleague, we are struggling to setup an working RAIT using vTapes and S3 on amanda 3.3.9. The vTapes and S3 work alone. But when trying to make the RAIT, it fails. Before sharing here one of the failed setups, I would like to know if is possible to make it work? Kind regards Jose M Calhariz -- -- Aprendi através da experiência amarga a suprema lição: controlar minha ira é torná-la como o calor que é convertido em energia. Nossa ira controlada pode ser convertida numa força capaz de mover o mundo. -- Mahatma Gandhi
New instructions for amanda using ssh authentication on Debian
I have created new instructions on how to setup ssh authentication on Debian, because of a recent experience on setting up a new amanda server and clients using ssh authentication and after a request from a user. I show my work here so more experienced people can spot errors or other improvements. First a diff of the changes, and in attach the new README.Debian files. diff --git a/debian/amanda-client.README.Debian b/debian/amanda-client.README.Debian index 30b4c02..81dc249 100644 --- a/debian/amanda-client.README.Debian +++ b/debian/amanda-client.README.Debian @@ -12,3 +12,25 @@ to be done: As always: for more complex setups consult the manpages and available documentation in /usr/share/doc/amanda-common ;-) +- - - - - + +To make a client work using SSH transport do: + + Copy the contents of id_rsa_amanda.pub from backup@amanda-server into ~backup/.ssh/authorized_keys + +mkdir -p ~backup/.ssh +echo -n 'from="XXX.XXX.XXX.XXX",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad -auth=ssh amdump" ' >> ~backup/.ssh/authorized_keys +cat id_rsa_amanda.pub >> ~backup/.ssh/authorized_keys + + Edit the autorized_keys to replace XXX.XXX.XXX.XXX with the IP of + the backup server. + + Change the shell of the backup account to /bin/bash. + +chsh -s /bin/bash backup + + Test in the server that "amcheck $CONF -c $CLIENT" works + + + + -- Jose M Calhariz <calha...@debian.org>, Fri, 14 Jul 2017 11:53:08 +0100 diff --git a/debian/amanda-server.README.Debian b/debian/amanda-server.README.Debian index c51849c..de4b934 100644 --- a/debian/amanda-server.README.Debian +++ b/debian/amanda-server.README.Debian @@ -15,10 +15,11 @@ do to configure your server. For a simple setup, as root you need to: 2. populate this directory with config files. At a minimum, you need amanda.conf and disklist. - cp /usr/share/doc/amanda-server/examples/amanda.conf \ - /etc/amanda/DailySet1/amanda.conf* + cp /usr/share/doc/amanda-server/examples/amanda.conf.gz \ + /etc/amanda/DailySet1/amanda.conf.gz cp /usr/share/doc/amanda-server/examples/disklist \ /etc/amanda/DailySet1/disklist +gunzip /etc/amanda/DailySet1/amanda.conf.gz Edit these files as needed, following the instructions in each file. @@ -142,3 +143,27 @@ This information from Marc Schaefer may relevant: > - use the proposed work-around > - ignore those messages in your logcheck. +- - - - - + +Setup server for backups using ssh transport. + + As root do: + +mkdir ~backup/.ssh +chown backup: ~backup/.ssh +sudo -u backup ssh-keygen -f .ssh/id_rsa_amanda + + Do not setup a password for the ssh keys + + Now put the ~backup/.ssh/id_rsa_amanda.pub on the clients, but with + some extra security. Add to the beginning of entry in + autorized_keys something like: + +from="XXX.XXX.XXX.XXX",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad -auth=ssh amdump" + + Where XXX.XXX.XXX.XXX is the ip of the server. + + Please see /usr/share/doc/amanda-client/README.Debian for more + details. + + -- Jose M Calhariz <calha...@debian.org>, Tue, 18 Jul 2017 09:09:19 +0100 Kind regards JOse M Calhariz -- -- Todas as elites a perigo se socorrem, de um jeito ou de outro, de seus rasputins. Às vezes, em vez de mães-de-santo, são falsos videntes com cursos de Economia no exterior --Luis Fernando Veríssimo Notes on making amanda-client work on a Debian system To get indexing (or specifically amrecover) to work right two things need to be done: 1. If you're using tcpd, make sure to edit the server's /etc/hosts.allow and allow all client machines into the daemon amandad 2. Edit the server(s) ~backup/.amandahosts and add an entry like: " root" As always: for more complex setups consult the manpages and available documentation in /usr/share/doc/amanda-common ;-) - - - - - To make a client work using SSH transport do: Copy the contents of id_rsa_amanda.pub from backup@amanda-server into ~backup/.ssh/authorized_keys mkdir -p ~backup/.ssh echo -n 'from="XXX.XXX.XXX.XXX",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,command="/usr/lib/amanda/amandad -auth=ssh amdump" ' >> ~backup/.ssh/authorized_keys cat id_rsa_amanda.pub >> ~backup/.ssh/authorized_keys Edit the autorized_keys to replace XXX.XXX.XXX.XXX with the IP of the backup server. Change the shell of the backup account to /bin/bash. chsh -s /bin/bash backup Test in the server that "amcheck $CONF -c $CLIENT" works -- Jose M Calhariz <calha...@debian.org>, Fri, 14 Jul 2017 11:53:08 +0100 amanda for DEBIAN - Since every Amanda installation is different, there is some work you need to do to configure your server. For a simple setup, as root you need t
Re: Problems with a big amanda-server
On Thu, Jul 13, 2017 at 04:07:19PM +0100, Jose M Calhariz wrote: > > Hi, > > I have another installation of amanda. This one is very big, 120 > hosts, 750 DLE and using ssh authentication. Anyone using an > instlation of this size? > > My problem is that this setup works for some days without problems and > other days it can not backup all the servers. > > I have investigated the clients. When there is problems, not one tried > to contact the faulty clients, no traffic is being generated from the > server to the client. > > Now I am trying to make sense from the server logs. Looking into the > planner logs I see messages from the sucessfully servers but not the > name of the faulty servers. Looking into /var/log/amanda/Daily I see > messages in the log and amdump of requesting estimates and in the same > second saying: > > > amdump.20170713000603:planner: time 0.055: setting up estimates for > hostanme.domain.name:/ > amdump.20170713000603:setup_estimate: hostanme.domain.name:/: command 0, > options: nonelast_level 1 next_level0 5 level_days 6getting estimates > 0 (-3) 1 (-3) 2 (-3) > amdump.20170713000603:planner: time 0.055: setting up estimates for > hostanme.domain.name:/boot > amdump.20170713000603:setup_estimate: hostanme.domain.name:/boot: command 0, > options: nonelast_level 1 next_level0 4 level_days 7getting estimates > 0 (-3) 1 (-3) -1 (-3) > amdump.20170713000603:planner: FAILED hostanme.domain.name / 20170713000603 0 > "[hmm, no error indicator!]" > amdump.20170713000603:planner: FAILED hostanme.domain.name /boot > 20170713000603 0 "[hmm, no error indicator!]" > > I am out of ideas about things to do to find a possible reason for the > failure. Can anyone help me? If I comment entries in disklist the list of failed machines changes. To get an idea how big is this installation here is: amstatus Daily --summary Using /var/log/amanda/Daily/amdump.1 >From Sun Jul 16 07:45:03 BST 2017 SUMMARY part real estimated size size partition : 967 estimated : 166 578g flush : 240 2711g failed : 5610g ( 0.00%) wait for dumping: 00g ( 0.00%) dumping to tape : 00sunit ( 0.00%) dumping : 0 0g 0g ( 0.00%) ( 0.00%) dumped : 166 539g 578g ( 93.13%) ( 93.13%) wait for writing: 166 539g 578g ( 93.13%) ( 93.13%) wait to flush : 62 269g 269g (100.00%) ( 0.00%) writing to tape : 0 0g 0g ( 0.00%) ( 0.00%) failed to tape : 0 0g 0g ( 0.00%) ( 0.00%) taped : 178 2441g 2441g (100.00%) ( 74.21%) tape 1: 178 2441g 2441g (100.00%) Daily-39 (178 chunks) 16 dumpers idle : 0 taper 0 status: Idle taper qlen: 229 network free kps: 1000 holding space : 10191g (122.95%) > > Kind regards > Jose M Calhariz > > Now I am looking into the code in planner.c to see if I can insert debug code and understand why is failing to launch some ssh commands. Kind regards Jose M Calhariz -- -- A verdade e a melhor camuflagem. Ninguem acredita nela. -- Max Frisch; escritor suico.
Re: Problems with a big amanda-server
On Fri, Jul 14, 2017 at 11:25:20AM +0200, Stefan G. Weichinger wrote: > Am 2017-07-14 um 10:13 schrieb Jose M Calhariz: > > >> Does it always happen with the same clients or does that vary? > > > > It vary, the set of affected machines may increase or decrease between > > amdump runs. But all the others tools runs without problems > > Could you check sshd-logs if there were any ssh-connections from > amanda-server to that client in the time window of the planned > amdump? From the sshd logs on the clients and from a tcpdump on the server, the server seams to not start the ssh connections. The amanda logs on the clients confirm that idea. > > > I did not notice that the estimate was 5 hours. The amdump was > > progressing after all the other machines returned an estimate. > > ... but no estimates got in from the problematic clients? And they > FAILed in the report mail? Yes. The error in the report mail is a bit strange: hostname.domain.name / lev 0 FAILED [hmm, no error indicator!] hostname.domain.name /usr lev 0 FAILED [hmm, no error indicator!] hostname.domain.name /var lev 0 FAILED [hmm, no error indicator!] I never seen this error in other situations > > > How do I increase the debug levels? > > man amanda.conf : look for parameters like "debug-*" > For this night I will use: debug-planner 3 # Increase debug on planner module Kind regards Jose M Calhariz -- -- É preciso que você saiba se vender bem, sem que isso pareça uma exploração --Cindy Crawford signature.asc Description: PGP signature
Re: Problems with a big amanda-server
On Fri, Jul 14, 2017 at 09:02:38AM +0200, Stefan G. Weichinger wrote: > Am 2017-07-13 um 17:07 schrieb Jose M Calhariz: > > > > Hi, > > > > I have another installation of amanda. This one is very big, 120 > > hosts, 750 DLE and using ssh authentication. Anyone using an > > instlation of this size? > > > > My problem is that this setup works for some days without problems and > > other days it can not backup all the servers. > > > > I have investigated the clients. When there is problems, not one tried > > to contact the faulty clients, no traffic is being generated from the > > server to the client. > > > > Now I am trying to make sense from the server logs. Looking into the > > planner logs I see messages from the sucessfully servers but not the > > name of the faulty servers. Looking into /var/log/amanda/Daily I see > > messages in the log and amdump of requesting estimates and in the same > > second saying: > > > > > > amdump.20170713000603:planner: time 0.055: setting up estimates for > > hostanme.domain.name:/ > > amdump.20170713000603:setup_estimate: hostanme.domain.name:/: command 0, > > options: nonelast_level 1 next_level0 5 level_days 6getting > > estimates 0 (-3) 1 (-3) 2 (-3) > > amdump.20170713000603:planner: time 0.055: setting up estimates for > > hostanme.domain.name:/boot > > amdump.20170713000603:setup_estimate: hostanme.domain.name:/boot: command > > 0, options: nonelast_level 1 next_level0 4 level_days 7getting > > estimates 0 (-3) 1 (-3) -1 (-3) > > amdump.20170713000603:planner: FAILED hostanme.domain.name / 20170713000603 > > 0 "[hmm, no error indicator!]" > > amdump.20170713000603:planner: FAILED hostanme.domain.name /boot > > 20170713000603 0 "[hmm, no error indicator!]" > > > > I am out of ideas about things to do to find a possible reason for the > > failure. Can anyone help me? > > What happens if you amcheck or amdump only these servers? The amcheck runs without problems allways. Being to only the client or all the machines. > > Does it always happen with the same clients or does that vary? It vary, the set of affected machines may increase or decrease between amdump runs. But all the others tools runs without problems > > Does it only happen with specific clients: this and that OS, version of > amanda, or so. Almost all the clients runs Debian 7, 8, and 9. They use amanda from Debian, v3.3.1, v3.3.6 and v3.3.9. The clients are spread by two sites and the affected clients happen in both sites, > > What is your estimate timeout for that config? maybe share the > amanda.conf etimeout -18000 #5 Hours # number of seconds per filesystem for estimates I did not notice that the estimate was 5 hours. The amdump was progressing after all the other machines returned an estimate. The setup have evolved very much since when this 5 hours were needed. I have to request authorization before disclosing logs or config files to the list. But I see no problem in disclosing it to the developers of amanda. > > What version of amanda on the server? > > ... and ... ;-) The server runs Debian 9 with amanda 3.3.9 from Debian, but the problem started with Debian 8. I have done the upgrade to see if it solved or to report againts the latest versions. > > I assume JLM would suggest to debug that somehow by increasing log > levels etc. > > How do I increase the debug levels? Kind regards Jose M Calhariz -- -- É preciso que você saiba se vender bem, sem que isso pareça uma exploração --Cindy Crawford signature.asc Description: PGP signature
Re: using S3 on amanda, how to select the region?
On Thu, Jul 13, 2017 at 02:53:13PM +0100, Jose M Calhariz wrote: > On Thu, Jul 13, 2017 at 08:58:38AM -0400, Greg Dickie wrote: > > In the Amazon admin console you can select the region you are interested > > in. At the top right beside your account there is a drop down to select the > > region. > > > > This is actually annoying if you have multiple regions to manage. > > My problem is with the amanda interface, not the AWS interface. I > have created an S3 bucket in N. Ireland, but the amanda keeps creating > a new bucket in US. I found the solution, and I leave it for others. I needed the option: device-property "S3_BUCKET_LOCATION" "eu-west1" Now it works as needed. > > > > > > hth, > > Greg > > Kind regards > Jose M Calhariz > Kind regards Jose M Calhariz > > > > > On Thu, Jul 13, 2017 at 7:30 AM, Jose M Calhariz < > > jose.calha...@tecnico.ulisboa.pt> wrote: > > > > > > > > Hi, > > > > > > I sucessfully setup a S3 bucket for backups on Amanda. But I would > > > like to create the Bucket in a different region, in my case N.Ireland. > > > > > > How can I do it? > > > > > > Kind regards > > > Jose Calhariz > > > > > > > > > > > > Quando vou à caça, penso numa ave de cada vez. E numa mulher de cada vez > > > > > > --Giovanni Agnelli > > > > > > > > > > -- -- É preciso que você saiba se vender bem, sem que isso pareça uma exploração --Cindy Crawford
Problems with a big amanda-server
Hi, I have another installation of amanda. This one is very big, 120 hosts, 750 DLE and using ssh authentication. Anyone using an instlation of this size? My problem is that this setup works for some days without problems and other days it can not backup all the servers. I have investigated the clients. When there is problems, not one tried to contact the faulty clients, no traffic is being generated from the server to the client. Now I am trying to make sense from the server logs. Looking into the planner logs I see messages from the sucessfully servers but not the name of the faulty servers. Looking into /var/log/amanda/Daily I see messages in the log and amdump of requesting estimates and in the same second saying: amdump.20170713000603:planner: time 0.055: setting up estimates for hostanme.domain.name:/ amdump.20170713000603:setup_estimate: hostanme.domain.name:/: command 0, options: nonelast_level 1 next_level0 5 level_days 6getting estimates 0 (-3) 1 (-3) 2 (-3) amdump.20170713000603:planner: time 0.055: setting up estimates for hostanme.domain.name:/boot amdump.20170713000603:setup_estimate: hostanme.domain.name:/boot: command 0, options: nonelast_level 1 next_level0 4 level_days 7getting estimates 0 (-3) 1 (-3) -1 (-3) amdump.20170713000603:planner: FAILED hostanme.domain.name / 20170713000603 0 "[hmm, no error indicator!]" amdump.20170713000603:planner: FAILED hostanme.domain.name /boot 20170713000603 0 "[hmm, no error indicator!]" I am out of ideas about things to do to find a possible reason for the failure. Can anyone help me? Kind regards Jose M Calhariz -- -- Os homens ficam mais velhos, mas isso não os melhora muito. -- Oscar Wilde
Re: using S3 on amanda, how to select the region?
On Thu, Jul 13, 2017 at 08:58:38AM -0400, Greg Dickie wrote: > In the Amazon admin console you can select the region you are interested > in. At the top right beside your account there is a drop down to select the > region. > > This is actually annoying if you have multiple regions to manage. My problem is with the amanda interface, not the AWS interface. I have created an S3 bucket in N. Ireland, but the amanda keeps creating a new bucket in US. > > hth, > Greg Kind regards Jose M Calhariz > > On Thu, Jul 13, 2017 at 7:30 AM, Jose M Calhariz < > jose.calha...@tecnico.ulisboa.pt> wrote: > > > > > Hi, > > > > I sucessfully setup a S3 bucket for backups on Amanda. But I would > > like to create the Bucket in a different region, in my case N.Ireland. > > > > How can I do it? > > > > Kind regards > > Jose Calhariz > > > > > > > > Quando vou à caça, penso numa ave de cada vez. E numa mulher de cada vez > > > > --Giovanni Agnelli > > > > > -- -- Quando vou à caça, penso numa ave de cada vez. E numa mulher de cada vez --Giovanni Agnelli
using S3 on amanda, how to select the region?
Hi, I sucessfully setup a S3 bucket for backups on Amanda. But I would like to create the Bucket in a different region, in my case N.Ireland. How can I do it? Kind regards Jose Calhariz -- -- Quando vou à caça, penso numa ave de cada vez. E numa mulher de cada vez --Giovanni Agnelli
Re: Debian: inetd required for amanda?
On Mon, Jul 10, 2017 at 01:37:21PM -0500, Jason L Tibbitts III wrote: > >>>>> "JMC" == Jose M Calhariz <jose.calha...@tecnico.ulisboa.pt> writes: > > JMC> I happily ship a systemd unit for amanda if someone writes one for > JMC> the Debian package. > > Amanda in Fedora has been socket-activated for years. Feel free to grab > the relevant units from our git tree: > https://src.fedoraproject.org/cgit/rpms/amanda.git/tree/ > > - J< > > I will then do that. That you for the pointer. Kind regards Jose M Calhariz -- -- Seu filho usa saia e não come ninguém? Calma, vai ver ele é padre. signature.asc Description: PGP signature
Re: Debian: inetd required for amanda?
On Mon, Jul 10, 2017 at 05:32:25PM +0200, Heiko Schlittermann wrote: > Lorenzo Marcantonio <lomar...@tin.it> (Mo 10 Jul 2017 13:23:36 CEST): > > On Mon, Jul 10, 2017 at 04:30:34AM -0600, Charles Curley wrote: > > > It seems that inetd is required for amanda 1:3.3.9-5 on Debian 9 > > > (stretch). In the days of SSH, is this necessary? I have no use for it, > > > and if it isn't installed it can't be cracked. > > > > Amanda needs some kind of way to be launched when somebody knocks on a > > port, when using standard authentication. Would that be inetd, xinetd or > > some tool from daemontool/s6 or maybe probably systemd. > > Modern Debian systems are shipped with systemd. So I suggest distributing > systemd socket unit files for use with Amanda. It is up to the admin, to > use these units or to setup (x)inetd or some other tool. > > Best regards from Dresden/Germany > Viele Grüße aus Dresden > Heiko Schlittermann I happily ship a systemd unit for amanda if someone writes one for the Debian package. Kind regards Jose M Calhariz -- -- Todas as pessoas que estudam Administração, ao deixar a faculdade, deveriam assinar um contrato incancelável prometendo não tomar mais do que vinte grandes decisões ao longo da vida --Warren Buffett signature.asc Description: PGP signature
Re: Debian: inetd required for amanda?
On Mon, Jul 10, 2017 at 04:30:34AM -0600, Charles Curley wrote: > It seems that inetd is required for amanda 1:3.3.9-5 on Debian 9 > (stretch). In the days of SSH, is this necessary? I have no use for it, > and if it isn't installed it can't be cracked. > Maybe I should change that and make inetd a suggest. The days of inetd being secure are on the past. Please open a bugreport, so I do not forget to do the changes. Kind regards Jose M Calhariz -- -- A gente não vê a radioatividade, e os inimigos desconhecidos são os piores --De uma vítima de Chernobyl signature.asc Description: PGP signature
Re: Draft of amanda 3.4.5 for Debian jessie
On Thu, Jun 22, 2017 at 11:13:43PM +0200, Stefan G. Weichinger wrote: > Am 2017-06-22 um 10:10 schrieb Jose M Calhariz: > > I have compiled the new amanda 3.4.5 for stretch and amd64 or i386. > > > > http://blog.calhariz.com/public/sft/amanda/amanda-3.4.5-1_rc1_bpo9_1.tar > > > > Please report any problem to this list. > > thanks @Jose, installed, on the way to first tests. > Ever considered setting up some specific repo for these packages? > And please do amd64 per default, it's 2017! ;-) > > greets, regards, Stefan > My plan is to allow access to this packages by stretch-backports, for alll users of Debian stretch. My main server is an installation of Debian since XX that I have upgraded until today. My next step is to upgrade the software from i386 to amd64. :-) Kind regards Jose M Calhariz -- -- Hoje eu tentei desenhar minha própria sombra. Não consegui! :( Meu braço não parava de se mexer... signature.asc Description: PGP signature
Re: Draft of amanda 3.4.5 for Debian jessie
I have compiled the new amanda 3.4.5 for stretch and amd64 or i386. http://blog.calhariz.com/public/sft/amanda/amanda-3.4.5-1_rc1_bpo9_1.tar Please report any problem to this list. On Wed, Jun 21, 2017 at 01:04:15PM +0200, Stefan G. Weichinger wrote: > Am 2017-06-21 um 12:51 schrieb Jose M Calhariz: > > On Wed, Jun 21, 2017 at 08:53:39AM +0200, Stefan G. Weichinger wrote: > >> Am 2017-06-15 um 18:20 schrieb Jose M Calhariz: > >> > >>> I have been running 3.4.5 on stretch without problems too. > >> > >> Which packages? > >> I currently prepare a deb9 server and could use them ;-) > >> > >> > > > > > > Is the machine amd64? Mine is i386, but I can easily recompile the > > de packages for amd64. > > I only do amd64 anymore. > thanks > > > Kind regards Jose M Calhariz -- -- É preciso que você saiba se vender bem, sem que isso pareça uma exploração --Cindy Crawford
Re: Draft of amanda 3.4.5 for Debian jessie
On Wed, Jun 21, 2017 at 08:53:39AM +0200, Stefan G. Weichinger wrote: > Am 2017-06-15 um 18:20 schrieb Jose M Calhariz: > > > I have been running 3.4.5 on stretch without problems too. > > Which packages? > I currently prepare a deb9 server and could use them ;-) > > Is the machine amd64? Mine is i386, but I can easily recompile the de packages for amd64. -- -- Um bom casamento exige que o homem seja surdo e a mulher cega --Sócrates
Re: Draft of amanda 3.4.5 for Debian jessie
On Wed, Jun 14, 2017 at 04:44:38PM -0600, Charles Curley wrote: > On Thu, 8 Jun 2017 23:30:09 +0100 > Jose M Calhariz <jose.calha...@tecnico.ulisboa.pt> wrote: > > > http://blog.calhariz.com/public/sft/amanda/amanda-3.4.5-1_rc1_bpo8_1.tar > > > > The tar file contains the package source for anyone to recompile, the > > i386 and x86_64/amd64 packages for jessie. > > > > I am distributing this packages in the hope they work because I am no > > longer able to test this packages on jessie. > > Installed (replacing 3.4.3) on a VM running jessie. amcheck and one test > run were successful. If that runs well for a few days, I will put it > onto some production machines. > > Is there anything specific I should look at? > I have been running 3.4.5 on stretch without problems too. There are some features of amanda that I never used until now. * amvault * Encrypted backups * backup to S3 If you know howto use them, please test. Kind regards Jose M Calhariz -- -- As empresas só podem prosperar em um mundo diversificado e multicultural se refletirem de alguma forma essa multiplicidade --James Houghton signature.asc Description: PGP signature
Re: Draft of amanda 3.4.5 for Debian jessie
On Mon, Jun 12, 2017 at 10:23:34PM +0200, Stefan G. Weichinger wrote: > Am 2017-06-09 um 00:30 schrieb Jose M Calhariz: > > > > I have just prepared a draft of amanda 3.4.5 for Debian. This is > > the result of my work for a future amanda 3.4.5 in Debian > > experimental. Debian testing is in freeze, so no longer possible to > > prepare new package versions for testing/unstable. > > > > You can download a tar file from: > > > > http://blog.calhariz.com/public/sft/amanda/amanda-3.4.5-1_rc1_bpo8_1.tar > > > > The tar file contains the package source for anyone to recompile, > > the i386 and x86_64/amd64 packages for jessie. > > > > I am distributing this packages in the hope they work because I am > > no longer able to test this packages on jessie. > > hmm, interesting: you are the maintainer of amanda for debian and > can't/don't test for stable debian? Because my personal server is now on stretch, future stable. Is were I do the heavy testing of the new amanda packages. > > Thanks anyway for providing the packages, I installed them on one > server already and look forward to its backup reports. > > Stefan > Kind regards Jose M Calhariz -- -- Vírus Garotada de Brasília: Apaga um dos seu arquivos e depois explica: "Pensei que fosse um mendigo..." signature.asc Description: PGP signature
Draft of amanda 3.4.5 for Debian jessie
I have just prepared a draft of amanda 3.4.5 for Debian. This is the result of my work for a future amanda 3.4.5 in Debian experimental. Debian testing is in freeze, so no longer possible to prepare new package versions for testing/unstable. You can download a tar file from: http://blog.calhariz.com/public/sft/amanda/amanda-3.4.5-1_rc1_bpo8_1.tar The tar file contains the package source for anyone to recompile, the i386 and x86_64/amd64 packages for jessie. I am distributing this packages in the hope they work because I am no longer able to test this packages on jessie. Kind regards Jose M Calhariz -- -- Toda mulher é bonita... dependendo da distância. signature.asc Description: PGP signature
Re: Planner in loop, amanda-3.4.4
ep = get_est(elist);
> dp = ep->disk;
>
> if(ep->dump_est->level != 0) continue;
>
> +g_debug("delay_dumps 2.a1b");
> get_info(dp->host->hostname, dp->name, );
> +g_debug("delay_dumps 2.a1c");
> if(ISSET(info.command, FORCE_FULL)) {
> nb_forced_level_0 += 1;
> preserve_ep = ep;
> @@ -2930,6 +2937,7 @@ static void delay_dumps(void)
> timestamps = ep->info->inf[0].date;
> }
> }
> +g_debug("delay_dumps 2.a2");
> if (delayed_ep) {
> /* Format dumpsize for messages */
> g_snprintf(est_kb, 20, "%lld KB,",
> @@ -2954,8 +2962,10 @@ static void delay_dumps(void)
> delay_one_dump(delayed_ep, delete, _("dumps too big,"), est_kb,
> message, NULL);
> }
> +g_debug("delay_dumps 2.a3");
> } while (delayed_ep);
>
> +g_debug("delay_dumps 2.b");
> /* 2.b. Delay forced full if needed */
> if(nb_forced_level_0 > 0 && total_size > tape_length) {
> for (elist = schedq.tail;
Kind regards
Jose M Calhariz
--
--
O oposto do amor não e o ódio e sim, a indiferença.
-- Erico Verissimo
signature.asc
Description: PGP signature
Planner in loop, amanda-3.4.4
Hi, I have a private server of amanda. It is the second time that the planner enter in loop and I have to kill for the amdump to finish. What logs are relevant to help fix the problem? From the report: NOTES: (...) driver: WARNING: got empty schedule from planner taper: tape Daily2-11 kb 110099818 fm 16 [OK] (...) Kind regards Jose M Calhariz -- -- Historia: um conjunto de mentiras sobre as quais se chegou a um acordo. -- Napoleao Bonaparte signature.asc Description: Digital signature
Re: Draft of amanda 3.4.4 for Debian
As requested I updated the tar file with packages for 64bits machines. The URL is the same, now have the packages for Intel 32bits and 64bits. On Tue, May 23, 2017 at 10:16:38PM +0200, Stefan G. Weichinger wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am 2017-05-05 um 19:09 schrieb Jose M Calhariz: > > > > I have just prepared a draft of amanda 3.4.4 for Debian. This is > > the result of my work for a future amanda 3.4.4 in Debian > > experimental. Debian testing is in freeze, so no longer possible to > > prepare new package versions for testing/unstable. > > > > You can download a tar file from: > > > > http://blog.calhariz.com/public/sft/amanda/amanda-3.4.4-1_rc1_bpo8_1.t > ar > > > > The tar file contains the package source for anyone to recompile > > and the i386 packages for jessie. > > replied a few days ago, seems to have been lost somewhere: > > pls provide 64bit packages: most people use 64bit on their servers > these days. Thank you for the request. > > thanks, Stefan > > > Kind regards Jose M Calhariz -- -- A verdade e a melhor camuflagem. Ninguem acredita nela. -- Max Frisch; escritor suico. signature.asc Description: Digital signature
Draft of amanda 3.4.4 for Debian
I have just prepared a draft of amanda 3.4.4 for Debian. This is the result of my work for a future amanda 3.4.4 in Debian experimental. Debian testing is in freeze, so no longer possible to prepare new package versions for testing/unstable. You can download a tar file from: http://blog.calhariz.com/public/sft/amanda/amanda-3.4.4-1_rc1_bpo8_1.tar The tar file contains the package source for anyone to recompile and the i386 packages for jessie. Kind regards Jose M Calhariz -- -- A imaginação e igual a natureza . A sensualidade, sua escrava. -- Johann wolfgang von goethe ; pensador e poeta alemao. signature.asc Description: Digital signature
Re: Released in Debian, on experimental, amanda-3.4.3
On Mon, May 01, 2017 at 12:14:48PM +0200, Stefan G. Weichinger wrote: > Am 2017-03-06 um 19:14 schrieb Jose M Calhariz: > > > > Hi, > > > > I am announcing that I have released in Debian a new amanda package > > 3.4.3, in experimental. Was released in experimental because Debian > > is on freeze. > > What is the status for amanda on Debian now? > > Which release(s) available for stable jessie, which via experimental repos? > > I have to change OS on a server, from Gentoo to Debian, and need some > features that came with 3.4.x somewhere. > > Someone have already replied with the list of packages available for amanda. As I personally use amanda on Debian stable, so is easy for me to supply my packages for i386 architecture. Is easy to compile from the sources the amanda package of experimental. I can help. My recomended way to get the latest amanda 3.4.x for Debian stable jessie is to compile the experimental sources. Kind regards Jose M Calhariz -- -- O cheque não compensa. signature.asc Description: Digital signature
Re: Released in Debian, on experimental, amanda-3.4.3
On Mon, Mar 13, 2017 at 12:58:59PM +, Tobias Köck wrote: > Hi Jose, > > I get a while trying to cleanup > > backup@chronos:/u1/bin$ amcleanup -k a2g-1 > amcleanup: Can't open trace_log file '/var/lib/amanda/a2g-1/log/log': No such > file or directory > > Can it be possible that the new version uses the log directory two > times? I haven't changed the configuration file just updated the > Debian AMANDA version to your version from experimental. I get the same problem the second time I do amcleanup. So I think it is armless. > > Greetings > Tobias Kind regards Jose M Calhariz > > -Ursprüngliche Nachricht- > Von: Jose M Calhariz [mailto:jose.calha...@tecnico.ulisboa.pt] > Gesendet: Mittwoch, 8. März 2017 15:47 > An: Tobias Köck > Cc: Jose M Calhariz; amanda-users@amanda.org > Betreff: Re: Released in Debian, on experimental, amanda-3.4.3 > > On Wed, Mar 08, 2017 at 10:19:30AM +, Tobias Köck wrote: > > Hi Jose, > > > > very nice. Does it also install on Debian Stretch with the required > > dependencies if I download it manually? > > Probably, I only test it on unstable and recompile for stable. > > > > > Greetings and thanks, > > Tobias > > Kind regards > Jose M Calhariz > > > > > -----Ursprüngliche Nachricht- > > Von: owner-amanda-us...@amanda.org > > [mailto:owner-amanda-us...@amanda.org] Im Auftrag von Jose M Calhariz > > Gesendet: Montag, 6. März 2017 19:15 > > An: amanda-users@amanda.org > > Betreff: Released in Debian, on experimental, amanda-3.4.3 > > > > > > Hi, > > > > I am announcing that I have released in Debian a new amanda package 3.4.3, > > in experimental. Was released in experimental because Debian is on freeze. > > > > > > Kind regards > > Jose M Calhariz > > > -- -- É mais fácil um camelo passar por um buraco de agulha do que encontrarmos um ditado bíblico razoável signature.asc Description: Digital signature
Re: Released in Debian, on experimental, amanda-3.4.3
On Wed, Mar 08, 2017 at 10:19:30AM +, Tobias Köck wrote: > Hi Jose, > > very nice. Does it also install on Debian Stretch with the required > dependencies if I download it manually? Probably, I only test it on unstable and recompile for stable. > > Greetings and thanks, > Tobias Kind regards Jose M Calhariz > > -Ursprüngliche Nachricht- > Von: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] Im > Auftrag von Jose M Calhariz > Gesendet: Montag, 6. März 2017 19:15 > An: amanda-users@amanda.org > Betreff: Released in Debian, on experimental, amanda-3.4.3 > > > Hi, > > I am announcing that I have released in Debian a new amanda package 3.4.3, in > experimental. Was released in experimental because Debian is on freeze. > > > Kind regards > Jose M Calhariz > -- -- É mais fácil um camelo passar por um buraco de agulha do que encontrarmos um ditado bíblico razoável signature.asc Description: Digital signature
Released in Debian, on experimental, amanda-3.4.3
Hi, I am announcing that I have released in Debian a new amanda package 3.4.3, in experimental. Was released in experimental because Debian is on freeze. Kind regards Jose M Calhariz -- -- A fortuna que eu gasto hoje será uma bagatela amanhã --Sol Kerzner
Re: segfault from planner (3.4.2-1)
On Mon, Feb 20, 2017 at 07:55:27AM -0500, Jean-Louis Martineau wrote:
> Uwe,
>
> Thanks for your good bug report and patch.
> Can you tried the attached patch instead of yours?
I have tried your patch Jean-Louis, it solved for me. Problem that
remains is that the palnner was happy in scheduling a backup bigger
than the VTAPE. Is this a bug in the planner or a new setting that I
am missing.
>
> Jean-Louis
Kind regards
Jose M Calhariz
>
> On 18/02/17 06:31 PM, Uwe Menges wrote:
> >Hi,
> >
> >Today I got a segfault from planner when I tried to run the weekly
> >backup on my Fedora 24 workstation:
> >
> >Feb 18 12:16:26 lima audit[4905]: ANOM_ABEND auid=1000 uid=0 gid=6 ses=11
> >subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=4905
> >comm="planner" exe="/usr/lib64/amanda/planner" sig=11
> >Feb 18 12:16:26 lima kernel: planner[4905]: segfault at 0 ip
> >7f20c57cd47a sp 7fff62d27ae8 error 4 in
> >libc-2.23.so[7f20c5731000+1b9000]
> >
> >After some debugging efforts involving wrapping planner in valgrind, I
> >got that:
> >
> >==27328== 1 errors in context 1 of 20:
> >==27328== Invalid read of size 1
> >==27328==at 0x8432460: __strcmp_sse2_unaligned (in
> >/usr/lib64/libc-2.23.so)
> >==27328==by 0x65AD0B8: g_str_equal (in
> >/usr/lib64/libglib-2.0.so.0.4800.2)
> >==27328==by 0x4E54D88: nb_tape_in_storage (tapefile.c:1201)
> >==27328==by 0x10EBB0: when_overwrite (planner.c:1315)
> >==27328==by 0x1103AE: setup_estimate (planner.c:1024)
> >==27328==by 0x10DF79: main (planner.c:633)
> >==27328== Address 0x0 is not stack'd, malloc'd or (recently) free'd
> >
> >The attached patch seems to fix the segfault for me.
> >
> >Yours, Uwe
> >
> diff --git a/server-src/tapefile.c b/server-src/tapefile.c
> index bb06173..38173ca 100644
> --- a/server-src/tapefile.c
> +++ b/server-src/tapefile.c
> @@ -1199,8 +1199,7 @@ nb_tape_in_storage(
> int nb_tapes = 0;
>
> for (tp = tape_list; tp != NULL; tp = tp->next) {
> - if (tp->storage &&
> - g_str_equal(storage_name, tp->storage)) {
> + if (g_strcmp0(storage_name,tp->storage) == 0) {
> nb_tapes++;
> }
> }
--
--
A long time ago: - Cara, comprei um XT, e agora só falta um modem 300 bps!!
Problems running amanda 3.4.2 on Debian jessie
The new package of amanda 3.4.2 for Debian is working on sid and testing for some people. But after I have done the upgrade of amanda on my home server, running jessie, it fails. The Debian package of amanda 3.4.2 was recompiled for jessie. The easiest way to check that it fails is "amcheck -c DailySet1": Amanda Backup Client Hosts Check (process:24609): GLib-ERROR **: /build/glib2.0-3vWc1h/glib2.0-2.42.1/./glib/gmem.c:103: failed to allocate 494820 bytes (brought to you by Amanda 3.4.2) How can I help diagnose the problem? Kind regards Jose M Calhariz -- -- A fortuna que eu gasto hoje será uma bagatela amanhã --Sol Kerzner
Released in Debian, on experimental, amanda-3.4.2
Hi, I am announcing that I have released in Debian a new amanda package, in experimental. Was released in experimental because Debian is on freeze and the amanda 3.4.2 does not in one of my configs. Expect some reports about problems in this list. I would like to thank you Nathan Stratton Treadway and Charles Curley for beta testing my amanda package. You made my life easier. Kind regards Jose M Calhariz -- -- A fortuna que eu gasto hoje será uma bagatela amanhã --Sol Kerzner
Re: A few minor fixups
On Wed, Feb 22, 2017 at 09:37:39AM -0500, Jean-Louis Martineau wrote:
> On 21/02/17 05:28 PM, Charles Curley wrote:
> > While working on 1:3.4.2-1~rc2 for Debian:
> >
> > In the sample amanda.conf:
> >
> > define tapetype HARD-DISK {
> > global
> > comment "DAT tape drives"
> > # data provided by Rob Browning
> > length 1930 mbytes
> > filemark 111 kbytes
> > speed 468 kbytes
> > }
> >
> > That should probably be 'comment "VIRTUAL tape drives"' or some such.
> There is 'define tapetype HARD-DISK' in the amanda source, this is
> probably an addition from Debian.
I will check that and fix it.
>
> The others fixups are good.
>
> Thanks.
> Jean-Louis
> >
> > In man amanda:
> >
> > CONFIGURATION FILES
> > There are four user-editable files that control the behavior of
> > Amanda.
> >
> > Shouldn't that be five?
> >
> > Output from amcheck:
> >
> > NOTE: tapelist file do not exists
> >it will be created on the next run
> >
> > That should probably be "file does not exists"
> >
> >
> >
> >
> >
> >
--
--
A fortuna que eu gasto hoje será uma bagatela amanhã
--Sol Kerzner
signature.asc
Description: Digital signature
Source ALPHA packages for amanda 3.4.2 on Debian
Hi, beta testers. This is the first time that I am packaging for Debian a new major version of amanda. I expect some problems, that are dificult for me to find. I am releasing early my work on this, so anyone can try and report the success or the failure. I think this work is only good for testing servers, not production ready, yet. You can download a tar file with the sources of a Debian package from here: http://blog.calhariz.com/public/sft/amanda/amanda_3.4.2-1_rc2.tar Kind regards Jose M Calhariz -- -- "Nosso time estava na beira do precício, mas, agora, demos um passo à frente", de João Pinto, ex-jogador do Benfica. signature.asc Description: Digital signature
Re: recent amanda on Debian?
On Fri, Feb 10, 2017 at 04:23:29PM +0100, Stefan G. Weichinger wrote: > Am 2017-02-10 um 16:13 schrieb Jose M Calhariz: > > I have started on creating the official Debian packages of amanda > > 3.4.2, and I would like to have beta testers, in case you are > > interested. > > sure, yes > > btw: I wrote to you on january 31 personally asking for amanda-packages > in debian. > > my email might have been filtered to spam or so ... > I have replied to you, so maybe was my reply that was tagged as spam. -- -- Sucrilhos Multi I/O. Com saída Cereal. signature.asc Description: Digital signature
Re: recent amanda on Debian?
I have started on creating the official Debian packages of amanda 3.4.2, and I would like to have beta testers, in case you are interested. On Thu, Feb 09, 2017 at 07:35:58PM +0100, Stefan G. Weichinger wrote: > > Does anyone use amanda 3.4.2 packages on debian jessie already? > Which one, do they work? > > I have to switch OS on a backup server and want to stay with > amanda-3.4.x because I need some of the latest features ... > > self-compile, you know ... I can do but I'd like to avoid. > lower maintenance. > Kind regards Jose M Calhariz -- -- Sucrilhos Multi I/O. Com saída Cereal. signature.asc Description: Digital signature
Re: Patches used by Debian on amanda
On Sun, Jan 08, 2017 at 12:51:45PM -0700, Charles Curley wrote: > On Sun, 8 Jan 2017 18:35:39 + > Jose M Calhariz <jose.calha...@tecnico.ulisboa.pt> wrote: > > > I am reviewing the patches used by Debian to build amanda 3.3.9 and > > updating them for amanda 3.4.1. I think some of them are not specific > > to Debian. My plan is to present the patches here so they can be > > reviewed for adoption or not. > > Thank you, thank you. > > May I request you end two irritants about the Debian version. It creates > a user, "backup". That's fine, although "amanda", say, would avoid > stepping on some other user named "backup". > > The irritant is that debian makes the user's home > directory /var/backups. Something else uses that directory, and I don't > like co-mingling the two different functions. ??? Can you explain better? > It also sets the user > shell to "/usr/sbin/nologin" rather than to bash, which is an irritant > on the way to using amanda over ssh. > I will try to search the archives for the reasoning of the decisions. Kind regards Jose M Calhariz -- -- Erro de usuário: Troque o usuário e pressione qualquer tecla para continuar. signature.asc Description: Digital signature
Patches used by Debian on amanda
I am reviewing the patches used by Debian to build amanda 3.3.9 and
updating them for amanda 3.4.1. I think some of them are not specific
to Debian. My plan is to present the patches here so they can be
reviewed for adoption or not.
The first batch are about small English mistakes in documentation that
lintian complains.
In attach there is 3 patches.
Kind regards
Jose M Calhariz
--
--
Erro de usuário: Troque o usuário e pressione qualquer tecla para continuar.
Description: Fix miss spelling that are pointed by lintian.
Author: Jose M Calhariz <j...@calhariz.com>
Index: amanda-3.4.1/man/amanda-auth.7
===
--- amanda-3.4.1.orig/man/amanda-auth.7 2017-01-08 17:17:49.620890682 +
+++ amanda-3.4.1/man/amanda-auth.7 2017-01-08 17:21:24.089181439 +
@@ -673,7 +673,7 @@ Besides user keys, SSH uses host keys to
As Amanda will not answer this question itself, you must manually make every
connection (server to client and client to server) that you expect Amanda to
make\&. Note that you must use the same username that Amanda will use (that is,
ssh client and ssh client\&.domain\&.com are distinct)\&.
.SS "Authenticated Peer Hostnames with SSH Authentication"
.PP
-When accepting an incoming conneciton, the SSH daemon gives Amanda information
about the remote system in the $SSH_CONNECTION environment variable\&. Amanda
parses this information to determine the remote address, and then performs a
similar check to that done by the BSD authentications: the forward and reverse
DNS entries for the remote host must match\&. As such, while SSH authentication
can cryptographically ensure that the remote system is recognized (since it had
a recognized secret key), its assurances about the remote host\*(Aqs identity
are weaker and depend on the integrity of the DNS\&.
+When accepting an incoming connection, the SSH daemon gives Amanda information
about the remote system in the $SSH_CONNECTION environment variable\&. Amanda
parses this information to determine the remote address, and then performs a
similar check to that done by the BSD authentications: the forward and reverse
DNS entries for the remote host must match\&. As such, while SSH authentication
can cryptographically ensure that the remote system is recognized (since it had
a recognized secret key), its assurances about the remote host\*(Aqs identity
are weaker and depend on the integrity of the DNS\&.
.SH "SSL COMMUNICATION AND AUTHENTICATION"
.PP
See
Index: amanda-3.4.1/man/amanda-changers.7
===
--- amanda-3.4.1.orig/man/amanda-changers.7 2017-01-08 17:17:49.620890682
+
+++ amanda-3.4.1/man/amanda-changers.7 2017-01-08 17:17:49.620890682 +
@@ -132,7 +132,7 @@ define changer aggregate {
tpchanger "aggregate"
.fi
.PP
-This changer driver allow to use two or more changers or standalone drive in
sequence\&.
+This changer driver allow one to use two or more changers or standalone drive
in sequence\&.
.SS "Properties"
.PP
LOCK\-TIMEOUT
Index: amanda-3.4.1/man/amanda-devices.7
===
--- amanda-3.4.1.orig/man/amanda-devices.7 2017-01-08 17:17:49.620890682
+
+++ amanda-3.4.1/man/amanda-devices.7 2017-01-08 17:17:49.620890682 +
@@ -778,7 +778,7 @@ INDIRECT
.RS 4
(read\-write) The default in "yes"\&. You can set it to "no" if the ndmp server
-allow to set a window length to 0\&.
+allow one to set a window length to 0\&.
.RE
.PP
NDMP_AUTH
fix-lintian-miss-spelling-amanda.conf.5.xml
Description: XML document
fix-lintian-miss-spelling-amanda-changers.7.xml
Description: XML document
signature.asc
Description: Digital signature
Re: Possible fix for 3.3.8 that maybe relevant for 3.4.1
On Tue, Jan 03, 2017 at 03:10:27PM -0500, Jean-Louis Martineau wrote:
> Jose,
>
> The patch is good and I committed it.
> Thanks for reporting the issue.
>
> Jean-Louis
>
It is me that tank you the review. I will give the good news to the
reporter of the bug.
Kind regards
Jose M Calhariz
>
> On 03/01/17 02:51 PM, Jose M Calhariz wrote:
> > A user of amanda on Debian have sent me a patch to fix a problem in
> > amanda 3.3.8. I do not know enough perl to validate the patch. But a
> > quick look to the file, seams to not changed much between 3.3.8 and
> > amanda 3.4.1.
> >
> > Can someone review the patch and give the opnion if it fix a problem
> > or not?
> >
> > The patch for amanda 3.3.8 is:
> >
> > --- /tmp/robot.pm 2016-12-27 09:41:57.285488949 -0700
> > +++ /usr/lib/amanda/perl/Amanda/Changer/robot.pm2016-12-27
> > 09:41:34.045222046 -0700
> > @@ -2359,6 +2359,7 @@
> > use Amanda::Debug qw( debug warning );
> > use Amanda::MainLoop qw( :GIOCondition synchronized make_cb define_steps
> > step );
> > use Amanda::Device qw( :constants );
> > +use Carp;
> >
> > sub new {
> > my $class = shift;
> >
> >
> > The URL to the bugreport is:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849481
> >
> > Kind regards
> > Jose M Calhariz
> >
> >
> >
> >
>
> Disclaimer
>
> The information contained in this communication from the sender is
> confidential. It is intended solely for use by the recipient and others
> authorized to receive it. If you are not the recipient, you are hereby
> notified that any disclosure, copying, distribution or taking action in
> relation of the contents of this information is strictly prohibited and may
> be unlawful.
>
> This email has been scanned for viruses and malware, and may have been
> automatically archived by Mimecast Ltd, an innovator in Software as a Service
> (SaaS) for business. Providing a safer and more useful place for your human
> generated data. Specializing in; Security, archiving and compliance. To find
> out more visit the Mimecast website.
--
--
MS-DOS nunca diz: EXCELENT command or filename.
signature.asc
Description: Digital signature
Possible fix for 3.3.8 that maybe relevant for 3.4.1
A user of amanda on Debian have sent me a patch to fix a problem in
amanda 3.3.8. I do not know enough perl to validate the patch. But a
quick look to the file, seams to not changed much between 3.3.8 and
amanda 3.4.1.
Can someone review the patch and give the opnion if it fix a problem
or not?
The patch for amanda 3.3.8 is:
--- /tmp/robot.pm 2016-12-27 09:41:57.285488949 -0700
+++ /usr/lib/amanda/perl/Amanda/Changer/robot.pm2016-12-27
09:41:34.045222046 -0700
@@ -2359,6 +2359,7 @@
use Amanda::Debug qw( debug warning );
use Amanda::MainLoop qw( :GIOCondition synchronized make_cb define_steps step
);
use Amanda::Device qw( :constants );
+use Carp;
sub new {
my $class = shift;
The URL to the bugreport is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849481
Kind regards
Jose M Calhariz
--
--
Quem ri por último não entendeu a piada...
signature.asc
Description: Digital signature
Re: Amanda-3.3.8/amanda-3.3.9 fails to configure with the future openssl 1.1.0
On Mon, Jun 27, 2016 at 07:42:36PM +0100, Jose M Calhariz wrote:
> Thank you.
>
> Now it configures and compiles. Fails during linking, but I think the
> problem is outside amanda. But for the record is here the error:
>
> /usr/bin/ld: warning: libcrypto.so.1.0.2, needed by
> /usr/lib/x86_64-linux-gnu/libcurl.so, may conflict with libcrypto.so.1.1
> ./.libs/libamanda.so: undefined reference to `OPENSSL_init_ssl'
> collect2: error: ld returned 1 exit status
I found the problem, but I don't know how to fix it properly. I don't
know how to edit the configure.in or the Makefile.am to fix it.
During linking if I add "-lssl" it works. Because libcurl was linked
with openssl 1.0.2 and amanda programs need openssl 1.1.0, that is at
-lssl.
Anyone can help me?
>
> Kind regards
> Jose M Calhariz
Kind regards
Jose M Calhariz
>
> On Mon, Jun 27, 2016 at 11:47:24AM -0400, Jean-Louis Martineau wrote:
> > Can you try the attached patch?
> >
> > Jean-Louis
> >
> > On 27/06/16 05:33 AM, Jose M Calhariz wrote:
> > >Debian is preparing for the release of the future openssl 1.1.0. It
> > >seams it have changes that breaks some software. I was warned by a
> > >bugreport that amanda does not compile with the new openssl. Further
> > >investigation points to a problem during the configuration of amanda.
> > >
> > >checking whether to include the Amazon S3 device... no
> > >configure: error: Cannot build the Amazon S3 device: one or more
> > >prerequisites are missing.
> > >debian/rules:18: recipe for target 'configure-stamp' failed
> > >
> > >More information is available on the Debian bug report.
> > >
> > >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828232
> > >
> > >If you need more information I am happy to help.
> > >
> > >Kind regards
> > >Jose M Calhariz
> > >
> > >
> >
>
> > diff --git a/common-src/glib-util.c b/common-src/glib-util.c
> > index ff26d53..c6f79dd 100644
> > --- a/common-src/glib-util.c
> > +++ b/common-src/glib-util.c
> > @@ -35,6 +35,8 @@
> >
> > #ifdef LIBCURL_USE_OPENSSL
> > #include
> > +#include
> > +#if OPENSSL_VERSION_NUMBER < 0x1010L
> > static GMutex **openssl_mutex_array;
> > static void openssl_lock_callback(int mode, int type, const char *file,
> > int line)
> > {
> > @@ -47,19 +49,23 @@ static void openssl_lock_callback(int mode, int type,
> > const char *file, int line
> > g_mutex_unlock(openssl_mutex_array[type]);
> > }
> > }
> > +#endif /* OPENSSL_VERSION_NUMBER */
> >
> > static void
> > init_ssl(void)
> > {
> > +#if OPENSSL_VERSION_NUMBER < 0x1010L
> > int i;
> > -
> > openssl_mutex_array = g_new0(GMutex *, CRYPTO_num_locks());
> >
> > +SSL_library_init();
> > for (i=0; i<CRYPTO_num_locks(); i++) {
> > openssl_mutex_array[i] = g_mutex_new();
> > }
> > CRYPTO_set_locking_callback(openssl_lock_callback);
> > -
> > +#else
> > +OPENSSL_init_ssl(0, NULL);
> > +#endif /* OPENSSL_VERSION_NUMBER */
> > }
> >
> > #else /* LIBCURL_USE_OPENSSL */
> > diff --git a/config/amanda/libs.m4 b/config/amanda/libs.m4
> > index 098d8e4..a090a3e 100644
> > --- a/config/amanda/libs.m4
> > +++ b/config/amanda/libs.m4
> > @@ -54,7 +54,12 @@ AC_DEFUN([AMANDA_CHECK_LIBCURL], [
> > #
> > AC_DEFUN([AMANDA_CHECK_HMAC], [
> > HAVE_HMAC=yes
> > -AC_CHECK_LIB([crypto], [HMAC_CTX_init], [], [HAVE_HMAC=no])
> > +AC_CHECK_LIB([crypto], [HMAC_CTX_init], [], [HAVE_HMAC_CTX_INIT=no])
> > +AC_CHECK_LIB([crypto], [HMAC_CTX_reset], [], [HAVE_HMAC_CTX_RESET=no])
> > +if test x"HAVE_HMAC_CTX_INIT" == x"no" -a \
> > + x"HAVE_HMAC_CTX_RESET" == x"no"; then
> > + HAVE_HMAC=no
> > +fi
> >
> > found_hmac_h=no
> > AC_CHECK_HEADERS([openssl/hmac.h crypto/hmac.h hmac.h],
> > diff --git a/config/compile b/config/compile
> > old mode 100644
> > new mode 100755
> > diff --git a/config/config.guess b/config/config.guess
> > old mode 100644
> > new mode 100755
> > diff --git a/device-src/s3-util.c b/device-src/s3-util.c
> > index 50e7bfb..778ec8f 100644
> > --- a/device-src/s3-util.c
> > +++ b/device-src/s3-util.c
> > @@ -238,7 +238,11 @@ EncodeHMACSHA256(
> > unsigned char tk[SHA256_DIGEST_LENGTH];
> >
> > // Initialise HMACh
> &
Re: Amanda-3.3.8/amanda-3.3.9 fails to configure with the future openssl 1.1.0
Thank you.
Now it configures and compiles. Fails during linking, but I think the
problem is outside amanda. But for the record is here the error:
/usr/bin/ld: warning: libcrypto.so.1.0.2, needed by
/usr/lib/x86_64-linux-gnu/libcurl.so, may conflict with libcrypto.so.1.1
./.libs/libamanda.so: undefined reference to `OPENSSL_init_ssl'
collect2: error: ld returned 1 exit status
Kind regards
Jose M Calhariz
On Mon, Jun 27, 2016 at 11:47:24AM -0400, Jean-Louis Martineau wrote:
> Can you try the attached patch?
>
> Jean-Louis
>
> On 27/06/16 05:33 AM, Jose M Calhariz wrote:
> >Debian is preparing for the release of the future openssl 1.1.0. It
> >seams it have changes that breaks some software. I was warned by a
> >bugreport that amanda does not compile with the new openssl. Further
> >investigation points to a problem during the configuration of amanda.
> >
> >checking whether to include the Amazon S3 device... no
> >configure: error: Cannot build the Amazon S3 device: one or more
> >prerequisites are missing.
> >debian/rules:18: recipe for target 'configure-stamp' failed
> >
> >More information is available on the Debian bug report.
> >
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828232
> >
> >If you need more information I am happy to help.
> >
> >Kind regards
> >Jose M Calhariz
> >
> >
>
> diff --git a/common-src/glib-util.c b/common-src/glib-util.c
> index ff26d53..c6f79dd 100644
> --- a/common-src/glib-util.c
> +++ b/common-src/glib-util.c
> @@ -35,6 +35,8 @@
>
> #ifdef LIBCURL_USE_OPENSSL
> #include
> +#include
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> static GMutex **openssl_mutex_array;
> static void openssl_lock_callback(int mode, int type, const char *file, int
> line)
> {
> @@ -47,19 +49,23 @@ static void openssl_lock_callback(int mode, int type,
> const char *file, int line
> g_mutex_unlock(openssl_mutex_array[type]);
> }
> }
> +#endif /* OPENSSL_VERSION_NUMBER */
>
> static void
> init_ssl(void)
> {
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> int i;
> -
> openssl_mutex_array = g_new0(GMutex *, CRYPTO_num_locks());
>
> +SSL_library_init();
> for (i=0; i<CRYPTO_num_locks(); i++) {
> openssl_mutex_array[i] = g_mutex_new();
> }
> CRYPTO_set_locking_callback(openssl_lock_callback);
> -
> +#else
> +OPENSSL_init_ssl(0, NULL);
> +#endif /* OPENSSL_VERSION_NUMBER */
> }
>
> #else /* LIBCURL_USE_OPENSSL */
> diff --git a/config/amanda/libs.m4 b/config/amanda/libs.m4
> index 098d8e4..a090a3e 100644
> --- a/config/amanda/libs.m4
> +++ b/config/amanda/libs.m4
> @@ -54,7 +54,12 @@ AC_DEFUN([AMANDA_CHECK_LIBCURL], [
> #
> AC_DEFUN([AMANDA_CHECK_HMAC], [
> HAVE_HMAC=yes
> -AC_CHECK_LIB([crypto], [HMAC_CTX_init], [], [HAVE_HMAC=no])
> +AC_CHECK_LIB([crypto], [HMAC_CTX_init], [], [HAVE_HMAC_CTX_INIT=no])
> +AC_CHECK_LIB([crypto], [HMAC_CTX_reset], [], [HAVE_HMAC_CTX_RESET=no])
> +if test x"HAVE_HMAC_CTX_INIT" == x"no" -a \
> + x"HAVE_HMAC_CTX_RESET" == x"no"; then
> + HAVE_HMAC=no
> +fi
>
> found_hmac_h=no
> AC_CHECK_HEADERS([openssl/hmac.h crypto/hmac.h hmac.h],
> diff --git a/config/compile b/config/compile
> old mode 100644
> new mode 100755
> diff --git a/config/config.guess b/config/config.guess
> old mode 100644
> new mode 100755
> diff --git a/device-src/s3-util.c b/device-src/s3-util.c
> index 50e7bfb..778ec8f 100644
> --- a/device-src/s3-util.c
> +++ b/device-src/s3-util.c
> @@ -238,7 +238,11 @@ EncodeHMACSHA256(
> unsigned char tk[SHA256_DIGEST_LENGTH];
>
> // Initialise HMACh
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> HMAC_CTX HMAC;
> +#else
> +HMAC_CTX *HMAC;
> +#endif
> unsigned int hmaclength = 32;
> memset(hmachash, 0, hmaclength);
>
> @@ -249,11 +253,20 @@ EncodeHMACSHA256(
> }
>
> // Digest the key and message using SHA256
> +#if OPENSSL_VERSION_NUMBER < 0x1010L
> HMAC_CTX_init();
> HMAC_Init_ex(, key, keylen, EVP_sha256(),NULL);
> HMAC_Update(, datatohash, datalen);
> HMAC_Final(, hmachash, );
> HMAC_CTX_cleanup();
> +#else
> +HMAC = HMAC_CTX_new();
> +HMAC_CTX_reset(HMAC);
> +HMAC_Init_ex(HMAC, key, keylen, EVP_sha256(),NULL);
> +HMAC_Update(HMAC, datatohash, datalen);
> +HMAC_Final(HMAC, hmachash, );
> +HMAC_CTX_free(HMAC);
> +#endif
>
> return hmachash;
> }
> diff --git a/device-src/s3.c b/device-src/s3.c
> index 10f5a20..d7d8
