amsuntar patch 3.5.1

[Chris Deiss]

Heya,

If anyone else uses the amsuntar application with exclude lists, you’ll want to 
apply this (oldie-but-goodie - been around at least since 3.3.6) patch to 

amanda-3.5.1/application-src/amsuntar.pl


365c365
<if($self->{action} eq 'backup' && $#{$self->{exculde_list}} >= 0) {
---
>if($self->{action} eq 'backup' && $#{$self->{exclude_list}} >= 0) {


Be well,
Chris


Chris Deiss
Database Administrator | Reed College
e: cde...@reed.edu | w: 503-777-7551 | c: 503-539-4681

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

[Gene Heskett]

On Sunday 11 November 2018 15:57:13 Nathan Stratton Treadway wrote:

> On Sun, Nov 11, 2018 at 15:20:54 -0500, Gene Heskett wrote:
> > Please do not throw wheezy support under the bus just yet, there are
>
> (Jose is talking about working on an update for the Debian packaging
> of Amanda, but you build your own installations direclty from the
> upstream Amanda source release anyway, so Jose's work won't affect
> you)
>
Not the same concern as amanda at all, but there is currently quite a 
bruhaha over the diffs for libcurl3 vs libcurl4 on the *buntu lists, and 
this shouldn't be a reason to drop wheezy support.

Yes, I build my own but thats in self defense to maintain compatibility 
continuity in the face of every developer using his own pet configure 
script. Mine seems to do that compatibility thing quite well. Its been 
posted here in the last 2 weeks or so if you want to check it out. As 
gh.cf.

Most of the clients here are running the often older distro version of 
amanda_client. Looks like my lonely jessie install on the r-pi is using 
an older 3.3.6-4 version. Works well so far, ignore the faint thumping 
sound. :)

>   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



Copyright 2018 by Maurice E. Heskett
-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

[Nathan Stratton Treadway]

On Sun, Nov 11, 2018 at 15:20:54 -0500, Gene Heskett wrote:
> Please do not throw wheezy support under the bus just yet, there are 

(Jose is talking about working on an update for the Debian packaging of
Amanda, but you build your own installations direclty from the upstream
Amanda source release anyway, so Jose's work won't affect you)

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

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

[Nathan Stratton Treadway]

On Sun, Nov 11, 2018 at 18:35:01 +, Jose M Calhariz wrote:
> On Sun, Nov 11, 2018 at 01:12:04PM -0500, Nathan Stratton Treadway wrote:
> > 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.

The issue I had was that the WIP packages you build in September seem to
have been built in an environment where somehow both libcurl3 and
libcurl4-openssl-dev were installed, and those two are incompatible. 
(Well, they definitely were incompatible in Ubuntu Bionic, and looked at
the package-website listings for the Debian repository they looked like
they would conflict in Debian, too.)

I was able to rebuild from your source package on my Bionic system with
no problem (and no changes to the source other than the Debian changelog
entry, as I recall), so I think the issue is limited to the build
environment where you built those particular .deb files

(See my (private) emails to you from
  Date: Thu, 20 Sep 2018 20:38:52 -0400
and
  Date: Mon, 24 Sep 2018 23:23:54 -0400
for more details.)


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

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

[Gene Heskett]

On Sunday 11 November 2018 13:35:01 Jose M Calhariz wrote:

> On Sun, Nov 11, 2018 at 01:12:04PM -0500, Nathan Stratton Treadway 
wrote:
> > On Sun, Nov 11, 2018 at 14:43:48 +, 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

Please do not throw wheezy support under the bus just yet, there are 
those of us still running it because the app it has to run, which milks 
the cash cow, LinuxCNC, runs best on an i386 install, even if the cpu 
itself is 64 bitter! The 64 bit architecture may be able to do more, but 
it simply takes too long to respond to an IRQ due its its increased data 
to swap for a context switch. A 5 microsecond increase in that latency 
can ruin parts AND BREAK TOOLS by causing motor stalls where once there 
were none.

There is progress being made on a 64 bit stretch version, but some users 
may be required to spend additional money bringing in a consultant 
because they are machinists, not computer/electronics whizzes, to up 
grade the machines controller interfacing to actually do good work with 
the new 64 bit stuff.

I am doing it, but there's more than $200 in interfacing cards just so I 
can do it with a $32 Raspi-3b running a jessie 64 bit install.

-- 
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

[Jose M Calhariz]

On Sun, Nov 11, 2018 at 01:12:04PM -0500, Nathan Stratton Treadway wrote:
> On Sun, Nov 11, 2018 at 14:43:48 +, 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

[Nathan Stratton Treadway]

On Sun, Nov 11, 2018 at 14:43:48 +, 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.)

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

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

[Jose M Calhariz]

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: Amanda "info on small DLEs not saved" bug -- proposed patch

[Gene Heskett]

On Friday 09 November 2018 20:46:03 Gene Heskett wrote:

> On Friday 09 November 2018 18:00:41 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,

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

[Gene Heskett]

On Friday 09 November 2018 18:00:41 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, but
> actually rounded the kb figure up to count any trailing partial
> kilobytes at the end of the file... while the new program seems to
> just ignore those trailing partial kilobytes.  Presumably this
> difference simply doesn't matter -- except for the when the size is
> rounded down to zero.)
>
>
> Proposed patch:
>
> This is where having an actual Amanda developer wo

Re: Amanda "info on small DLEs not saved" bug -- proposed patch

[Nathan Stratton Treadway]

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, but
actually rounded the kb figure up to count any trailing partial
kilobytes at the end of the file... while the new program seems to just
ignore those trailing partial kilobytes.  Presumably this difference
simply doesn't matter -- except for the when the size is rounded down to
zero.)


Proposed patch:

This is where having an actual Amanda developer would be very handy...
but given that planner.c and old-chunker.c both have special handling
for small-but-not-empty files, I figured that adding a similar check to
the new Chunker implementation is probably the best fix for this
situation, and that hopefully doing so would be safe from unwanted
side-effects

So, I edited the perl/Amanda/Chunker/Controller.pm to implement such a
check, as shown in the attached patch.  I've been running with this
patch in p

Re: amanda.conf.5 patch: expanded vault-storage description

[Jean-Louis Martineau]

Nathan,

Thanks for the patch, I committed it

Jean-Louis

On 27/11/17 02:38 AM, Nathan Stratton Treadway wrote:
> The attached patch against amanda.conf.5.xml tries to fill in some
> specific details on the operation of the vault-storage parameter, and
> also fixes a couple typos in other parts of the page.
>
> (The patch is against the git master branch version of the file, though
> I believe the changes should apply easily to the 3.4 and 3.5 versions of
> the page as well.)
>
> Nathan
>
> 
> Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
> Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ 
> <http://www.ontko.com/>
> GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt 
> <http://www.ontko.com/~nathanst/gpg_key.txt> 
> ID: 1023D/ECFB6239
> Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
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

amanda.conf.5 patch: expanded vault-storage description

[Nathan Stratton Treadway]

The attached patch against amanda.conf.5.xml tries to fill in some
specific details on the operation of the vault-storage parameter, and
also fixes a couple typos in other parts of the page.

(The patch is against the git master branch version of the file, though
I believe the changes should apply easily to the 3.4 and 3.5 versions of
the page as well.)

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
diff --git a/man/xml-source/amanda.conf.5.xml b/man/xml-source/amanda.conf.5.xml
index 89a1a87..6a4db1e 100644
--- a/man/xml-source/amanda.conf.5.xml
+++ b/man/xml-source/amanda.conf.5.xml
@@ -970,7 +970,7 @@ option enabled.
 The file or directory name for the historical information database.
 If Amanda was configured to use DBM databases, this is the base file
 name for them.
-If it was configured to use text formated databases (the default),
+If it was configured to use text formatted databases (the default),
 this is the base directory and within here will be a directory per
 client, then a directory per disk, then a text file of data.
   
@@ -1603,9 +1603,19 @@ This option allows Amanda to track multiple runs per calendar day.
   
 
   
-  vault-storage string
+  vault-storage string+
   
-Default: not set.  The list of storages to vault to, vaulting to theses storages are automaticaly done.
+Default: not set.  The list of storages to vault to.
+After writing to the storages listed in the
+storage parameter, amdump will
+automatically write all pending dumps to the vault storage(s).  (These
+dumps are queued for vaulting based on the vault
+option specified in the definition section for the primary storage and the
+dump-selection option specified on the vault
+storage.)
+(amvault also uses the first storage in the
+vault-storage list as its default
+destination storage.)
   
   
 
@@ -3539,7 +3549,7 @@ allow another storage to use that volume.
   
 
   
-  interactivity int
+  interactivity string
   
 Default: value of the global interactivity.
   

amanda-2.6.2alpha-20090905 with patch failed last night

[Gene Heskett]

Greetings Dustin;

The amcheck error it didn't think was one, was.

From last nights run, the email:

*** THE DUMPS DID NOT FINISH PROPERLY!

The next tape Amanda expects to use is: Dailys-17.

FAILURE DUMP SUMMARY:
   coyote /GenesAmandaHelper-0.6  RESULTS MISSING
   coyote /binRESULTS MISSING
   coyote /boot   RESULTS MISSING
   coyote /etcRESULTS MISSING
   coyote /home   RESULTS MISSING
   coyote /libRESULTS MISSING
   coyote /optRESULTS MISSING
   coyote /root   RESULTS MISSING
   coyote /sbin   RESULTS MISSING
   coyote /tmpRESULTS MISSING
   coyote /varRESULTS MISSING
   coyote /usr/binRESULTS MISSING
   coyote /usr/dlds/misc  RESULTS MISSING
   coyote /usr/dlds/rpms  RESULTS MISSING
   coyote /usr/dlds/tgzs  RESULTS MISSING
   coyote /usr/brlcad RESULTS MISSING
   coyote /usr/java   RESULTS MISSING
   coyote /usr/weber  RESULTS MISSING
   coyote /usr/includeRESULTS MISSING
   coyote /usr/kerberos   RESULTS MISSING
   coyote /usr/libRESULTS MISSING
   coyote /usr/libexecRESULTS MISSING
   coyote /usr/movies RESULTS MISSING
   coyote /usr/local  RESULTS MISSING
   coyote /usr/music  RESULTS MISSING
   coyote /usr/pixRESULTS MISSING
   coyote /usr/sbin   RESULTS MISSING
   coyote /usr/share  RESULTS MISSING
   coyote /usr/srcRESULTS MISSING
  planner: FATAL euid (500) does not match uid (0); is this program setuid-root 
when it shouldn't be?
  driver: FATAL Did not get DATE line from planner


STATISTICS:
  Total   Full  Incr.
      
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min)0:00   0:00   0:00
Output Size (meg)   0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- -- 
Filesystems Dumped0  0  0
Avg Dump Rate (k/s) -- -- -- 

Tape Time (hrs:min)0:00   0:00   0:00
Tape Size (meg) 0.00.00.0
Tape Used (%)   0.00.00.0
Filesystems Taped 0  0  0

Chunks Taped  0  0  0
Avg Tp Write Rate (k/s) -- -- -- 

DUMP SUMMARY:
 DUMPER STATS   
TAPER STATS  
HOSTNAME DISKL ORIG-kB  OUT-kB COMP% MMM:SSKB/s 
MMM:SSKB/s
-  
--
coyote  /GenesAmandaHelper-0.6MISSING 
---
coyote  /bin  MISSING 
---
coyote  /boot MISSING 
---
coyote  /etc  MISSING 
---
coyote  /home MISSING 
---
coyote  /lib  MISSING 
---
coyote  /opt  MISSING 
---
coyote  /root MISSING 
---
coyote  /sbin MISSING 
---
coyote  /tmp  MISSING 
---
coyote  /usr/bin  MISSING 
---
coyote  /usr/brlcad   MISSING 
---
coyote  /usr/dlds/miscMISSING 
---
coyote  /usr/dlds/rpmsMISSING 
---
coyote  /usr/dlds/tgzsMISSING 
---
coyote  /usr/include  MISSING 
---
coyote  /usr/java MISSING 
---
coyote  /usr/kerberos MISSING 
---
coyote  /usr/lib  MISSING 
---
coyote  /usr/libexec  MISSING 
---
coyote  /usr/localMISSING 
---
coyote  /usr/movies   MISSING 
---
coyote  /usr/musicMISSING 

application/amgtar patch for review

[Christopher]

Hello...

Recently I started using application-tool with amgtar to solve some
backup problems.  One of these problems is where several smaller
filesystems were merged creating a large filesystem.  The amanda backup
run using gtar started failing.  After much debugging I saw that the
gtar argument --listed-incremental /PATH was taking too long and failing
with:
dumper: [request failed: timeout waiting for REP](too)
df -ih shows 14M inodes used

I switched from the standard gtar to a hacked application/amgtar with
these lines ripped out:
my_argv[i++] = --listed-incremental;
my_argv[i++] = incrname;

The backup is currently running successfully :) Attached is a patch to
amgtar.c adding an option to disable listed-incremental based on the
atime option.  I have not tested this yet as the current run will not
finish for another 20 hours or so.  Can someone glance at the patch to
see if I missed anything?





-- 
Christopher McCrory
 The guy that keeps the servers running
 
chris...@pricegrabber.com
 http://www.pricegrabber.com
 
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense.  I tried it.  Only tinfoil works.

--- amanda-2.6.1p1-orig/application-src/amgtar.c	2009-04-07 09:57:25.0 -0700
+++ amanda-2.6.1p1-new/application-src/amgtar.c	2009-08-21 11:26:09.141031000 -0700
@@ -45,6 +45,7 @@
  * EXCLUDE-FILE
  * EXCLUDE-LIST
  * EXCLUDE-OPTIONAL
+ * LISTED-INCREMENTAL (default YES)
  * NORMAL
  * IGNORE
  * STRANGE
@@ -146,6 +147,7 @@
 static int gnutar_atimepreserve;
 static int gnutar_checkdevice;
 static int gnutar_sparse;
+static int gnutar_listedincremental;
 static GSList *normal_message = NULL;
 static GSList *ignore_message = NULL;
 static GSList *strange_message = NULL;
@@ -181,6 +183,7 @@
 {exit-handling   , 1, NULL, 26},
 {calcsize, 0, NULL, 27},
 {tar-blocksize   , 1, NULL, 28},
+{listed-incremental , 1, NULL, 29},
 {NULL, 0, NULL, 0}
 };
 
@@ -454,6 +457,9 @@
 	case 27: argument.calcsize = 1;
 		 break;
 	case 28: argument.tar_blocksize = stralloc(optarg);
+	case 29: if (optarg  strcasecmp(optarg, YES) != 0)
+		 gnutar_listedincremental = 0;
+		 break;
 	case ':':
 	case '?':
 		break;
@@ -518,6 +524,7 @@
 dbprintf(SPARSE %s\n, gnutar_sparse? yes:no);
 dbprintf(ATIME-PRESERVE %s\n, gnutar_atimepreserve? yes:no);
 dbprintf(CHECK-DEVICE %s\n, gnutar_checkdevice? yes:no);
+dbprintf(LISTED-INCREMENTAL %s\n, gnutar_listedincremental? yes:no);
 {
 	amregex_t *rp;
 	for (rp = re_table; rp-regex != NULL; rp++) {
@@ -1184,8 +1191,10 @@
 	my_argv[i++] = --atime-preserve=system;
 if (!gnutar_checkdevice)
 	my_argv[i++] = --no-check-device;
-my_argv[i++] = --listed-incremental;
-my_argv[i++] = incrname;
+if (gnutar_listedincremental) {
+my_argv[i++] = --listed-incremental;
+my_argv[i++] = incrname;
+}
 if (gnutar_sparse)
 	my_argv[i++] = --sparse;
 if (argument-tar_blocksize) {

Re: application/amgtar patch for review

[Jean-Louis Martineau]

Patch looks good.

All code that copy/rename listed incremental files should be done only 
if it is used.


If you disable --listed-incremental, you will get FULL backup at every 
run, is it what you want?

The amgtar_support function must output MAX-LEVEL 0 in this case.

Jean-Louis

Christopher wrote:

Hello...

Recently I started using application-tool with amgtar to solve some
backup problems.  One of these problems is where several smaller
filesystems were merged creating a large filesystem.  The amanda backup
run using gtar started failing.  After much debugging I saw that the
gtar argument --listed-incremental /PATH was taking too long and failing
with:
dumper: [request failed: timeout waiting for REP](too)
df -ih shows 14M inodes used

I switched from the standard gtar to a hacked application/amgtar with
these lines ripped out:
my_argv[i++] = --listed-incremental;
my_argv[i++] = incrname;

The backup is currently running successfully :) Attached is a patch to
amgtar.c adding an option to disable listed-incremental based on the
atime option.  I have not tested this yet as the current run will not
finish for another 20 hours or so.  Can someone glance at the patch to
see if I missed anything?





  

Re: application/amgtar patch for review

[Christopher]

Hello...

On Fri, 2009-08-21 at 14:59 -0400, Jean-Louis Martineau wrote:
 Patch looks good.
 
 All code that copy/rename listed incremental files should be done only 
 if it is used.
 

Ouch, that will take me a little longer to do.  My C skills are weak and
I need to study the logic a bit.



 If you disable --listed-incremental, you will get FULL backup at every 
 run, is it what you want?

In my case with 14M files, the choice is always full or never.  The next
filesystem I need to tackle is 2.9T with ~350M files.  I'll settle for
no incremental backups.  I also noted this in the source.



 The amgtar_support function must output MAX-LEVEL 0 in this case.
 

newer patch attached but without incrname part done yet.



 Jean-Louis
 
 Christopher wrote:
  Hello...
 
  Recently I started using application-tool with amgtar to solve some
  backup problems.  One of these problems is where several smaller
  filesystems were merged creating a large filesystem.  The amanda backup
  run using gtar started failing.  After much debugging I saw that the
  gtar argument --listed-incremental /PATH was taking too long and failing
  with:
  dumper: [request failed: timeout waiting for REP](too)
  df -ih shows 14M inodes used
 
  I switched from the standard gtar to a hacked application/amgtar with
  these lines ripped out:
  my_argv[i++] = --listed-incremental;
  my_argv[i++] = incrname;
 
  The backup is currently running successfully :) Attached is a patch to
  amgtar.c adding an option to disable listed-incremental based on the
  atime option.  I have not tested this yet as the current run will not
  finish for another 20 hours or so.  Can someone glance at the patch to
  see if I missed anything?
 
 
 
 
 

 
-- 
Christopher McCrory
 The guy that keeps the servers running
 
chris...@pricegrabber.com
 http://www.pricegrabber.com
 
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense.  I tried it.  Only tinfoil works.

--- amanda-2.6.1p1-orig/application-src/amgtar.c	2009-04-07 09:57:25.0 -0700
+++ amanda-2.6.1p1-new/application-src/amgtar.c	2009-08-21 12:21:58.573312000 -0700
@@ -45,6 +45,8 @@
  * EXCLUDE-FILE
  * EXCLUDE-LIST
  * EXCLUDE-OPTIONAL
+ * LISTED-INCREMENTAL (default YES, If set to NO then incremental backups are
+   impossible)
  * NORMAL
  * IGNORE
  * STRANGE
@@ -146,6 +148,7 @@
 static int gnutar_atimepreserve;
 static int gnutar_checkdevice;
 static int gnutar_sparse;
+static int gnutar_listedincremental;
 static GSList *normal_message = NULL;
 static GSList *ignore_message = NULL;
 static GSList *strange_message = NULL;
@@ -181,6 +184,7 @@
 {exit-handling   , 1, NULL, 26},
 {calcsize, 0, NULL, 27},
 {tar-blocksize   , 1, NULL, 28},
+{listed-incremental , 1, NULL, 29},
 {NULL, 0, NULL, 0}
 };
 
@@ -454,6 +458,9 @@
 	case 27: argument.calcsize = 1;
 		 break;
 	case 28: argument.tar_blocksize = stralloc(optarg);
+	case 29: if (optarg  strcasecmp(optarg, YES) != 0)
+		 gnutar_listedincremental = 0;
+		 break;
 	case ':':
 	case '?':
 		break;
@@ -518,6 +525,7 @@
 dbprintf(SPARSE %s\n, gnutar_sparse? yes:no);
 dbprintf(ATIME-PRESERVE %s\n, gnutar_atimepreserve? yes:no);
 dbprintf(CHECK-DEVICE %s\n, gnutar_checkdevice? yes:no);
+dbprintf(LISTED-INCREMENTAL %s\n, gnutar_listedincremental? yes:no);
 {
 	amregex_t *rp;
 	for (rp = re_table; rp-regex != NULL; rp++) {
@@ -559,7 +567,7 @@
 fprintf(stdout, CONFIG YES\n);
 fprintf(stdout, HOST YES\n);
 fprintf(stdout, DISK YES\n);
-fprintf(stdout, MAX-LEVEL 9\n);
+fprintf(stdout, MAX-LEVEL %s\n, gnutar_listedincremental? 9:0);
 fprintf(stdout, INDEX-LINE YES\n);
 fprintf(stdout, INDEX-XML NO\n);
 fprintf(stdout, MESSAGE-LINE YES\n);
@@ -1184,8 +1192,10 @@
 	my_argv[i++] = --atime-preserve=system;
 if (!gnutar_checkdevice)
 	my_argv[i++] = --no-check-device;
-my_argv[i++] = --listed-incremental;
-my_argv[i++] = incrname;
+if (gnutar_listedincremental) {
+my_argv[i++] = --listed-incremental;
+my_argv[i++] = incrname;
+}
 if (gnutar_sparse)
 	my_argv[i++] = --sparse;
 if (argument-tar_blocksize) {

Re: application/amgtar patch for review

[Christopher]

Hello...


On Fri, 2009-08-21 at 12:52 -0700, Christopher wrote:
 Hello...
 
 On Fri, 2009-08-21 at 14:59 -0400, Jean-Louis Martineau wrote:
  Patch looks good.
  
  All code that copy/rename listed incremental files should be done only 
  if it is used.
  
 
 Ouch, that will take me a little longer to do.  My C skills are weak and
 I need to study the logic a bit.
 


in: 
static char *
amgtar_get_incrname(



@@ -1049,7 +1057,7 @@
 char *errmsg = NULL;
 char *buf;
 
-if (gnutar_listdir) {
+if (gnutar_listdir  gnutar_listedincremental) {
char number[NUM_STR_SIZE];
int baselevel;
char *sdisk = sanitise_filename(argument-dle.disk);



Is it really that easy?

in amgtar_backup

incrname = amgtar_get_incrname(argument,

GPOINTER_TO_INT(argument-level-data));
cmd = stralloc(gnutar_path);
my_argv = amgtar_build_argv(argument, incrname, CMD_BACKUP);

I'm not sure exactly what the result will be.  I'll test tomorrow.



confidence level:  well... it compiles for me  ;)


snip


-- 
Christopher McCrory
 The guy that keeps the servers running
 
chris...@pricegrabber.com
 http://www.pricegrabber.com
 
Let's face it, there's no Hollow Earth, no robots, and
no 'mute rays.' And even if there were, waxed paper is
no defense.  I tried it.  Only tinfoil works.

FSF AFTER FILEMARK patch

[McGraw, Robert P]

I have Amanda 2.6.1p1. Darin Perusich mentioned a patch
FSF_AFTER_FILEMARK that needs to be added for Solaris hosts.

Where or how do I get this patch or a patched source.

Thanks

Robert


_
Robert P. McGraw, Jr.
Manager, Computer SystemEMAIL: rmcg...@purdue.edu
Purdue UniversityROOM: MATH-807
Department of Mathematics   PHONE: (765) 494-6055
150 N. University Street  
West Lafayette, IN 47907-2067
 

Re: FSF AFTER FILEMARK patch

[Dustin J. Mitchell]

On Tue, May 19, 2009 at 12:33 PM, McGraw, Robert P rmcg...@purdue.edu wrote:
 I have Amanda 2.6.1p1. Darin Perusich mentioned a patch
 FSF_AFTER_FILEMARK that needs to be added for Solaris hosts.

 Where or how do I get this patch or a patched source.

http://github.com/zmanda/amanda/commit/2cb92fbc5f7f1ad452b9be44670b02d5bd33d194
http://github.com/zmanda/amanda/commit/2cb92fbc5f7f1ad452b9be44670b02d5bd33d194.patch

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com

Re: FSF AFTER FILEMARK patch

[Gene Heskett]

On Tuesday 19 May 2009, McGraw, Robert P wrote:
FSF_AFTER_FILEMARK

According to the ChangeLog for the 2.6.2 snapshot I'm running, that was added 
on 4-21.  Whether its in 2.6.1p1 I do not know.  For space reasons I rarely 
keep more than about 10 of the previous snapshots here.

Did you get your src's from zmanda.com?  The right hand column is the 
ChangeLog incremental, and that was also added into the 2.6.1p1 snapshot as of 
amanda-2.6.1p1-20090421.tar.gz, but there are even newer versions there.  See
http://www.zmanda.com/community-builds.php for a full list.

-- 
Cheers, Gene
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
Poverty begins at home.

amreport crash - proposed patch

[Deb Baddorf]

amdump  myconfig
  has been crashing during the report phase  -- after the dumps are
done and okay.   We are at 2.5.1p2which was thought to fix this,
but it hasn't helped.
   After some local debugging,   my  expert source tells me
that this patch should fix the problem  (it fixed ours):



The main() function in reporter.c has the lines:

if (postscript) {
do_postscript_output();
}

such that the function do_postscript_output() will only be called if the
variable postscript is not null...

however the function do_postscript_output() subsequently calls the
function copy_template_file() which MAY under several conditions call the
function afclose(postscript), that sets the postscript variable to NULL

after the return from copy_template_file() to do_postscript_output() the
do_postscript_output() function proceeds to call fprintf() with the
assumption that the postscript variable is valid, resulting in a core
dump.

The following diff should cure that core dump.

diff -wub reporter.c.orig reporter.c
--- reporter.c.orig Thu Feb  8 14:16:40 2007
+++ reporter.c  Thu Feb  8 14:17:16 2007
@@ -2796,6 +2796,8 @@

copy_template_file(tapetype_get_lbl_templ(tp));

+   if (postscript == NULL) return;
+
/* generate a few elements */
fprintf(postscript,(%s) DrawDate\n\n,
nicedate(run_datestamp ? run_datestamp : 0));

Please report this information back to the amanda developers.
(I'll add the patch and install on our server.)

Thanks,

 - Tim

Re: DB compatability, 2.4.5 + split/span patch

[Paul Bijnens]

Christopher Linn wrote:


i have been experimenting with 2.4.5 with the split/span patch.  
it would be nice to be able to simply upgrade from our current 
2.4.2p1 to 2.4.5 + split/span 7.2, using the same curinfo database.


The 2.5.0, now in beta, will have split/span incorporated.
Testing appreciated.


is it the case that the split/span changes use exactly the same 
database format, or are they different and thus incompatable??


The curinfo database is indeed backward compatible.
(curinfo databases are pure text files since 2.4.2, about 7 years old 
now, unless you set special compile time options).



--
Paul Bijnens, xplanation Technology ServicesTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
http://www.xplanation.com/  email:  [EMAIL PROTECTED]
***
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  Are you sure?  ...   YES   ...   Phew ...   I'm out  *
***

DB compatability, 2.4.5 + split/span patch

[Christopher Linn]

hi,

i have been experimenting with 2.4.5 with the split/span patch.  
it would be nice to be able to simply upgrade from our current 
2.4.2p1 to 2.4.5 + split/span 7.2, using the same curinfo database.

is it the case that the split/span changes use exactly the same 
database format, or are they different and thus incompatable??

(john stange are you still around??)

sincerely,

chris

-- 
Christopher Linn celinn at mtu.edu  | By no means shall either the CEC
System Administrator II   | or MTU be held in any way liable
  Center for Experimental Computation | for any opinions or conjecture I
Michigan Technological University | hold to or imply to hold herein.

Re: Estimate Disable/tweak patch?

[Paul Bijnens]

Michael Loftis wrote:


This sounds exactly like what I need  Do you know if 2.4.5 server 
and clients can be intermixed with 2.4.4p3 (thereabouts) clients?  I 


Yes, without any problem.  Of course, you cannot use the newer features
on a 2.4.4 client like the advanced estimate options.
As far as I know any 2.4.X version can communicate with eachother.


--
Paul Bijnens, XplanationTel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax  +32 16 397.512
http://www.xplanation.com/  email:  [EMAIL PROTECTED]
***
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, ^^, *
* F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... *
* ...  Are you sure?  ...   YES   ...   Phew ...   I'm out  *
***

Re: Estimate Disable/tweak patch?

[Michael Loftis]

--On October 21, 2005 9:42:13 AM +0200 Paul Bijnens 
[EMAIL PROTECTED] wrote:



Michael Loftis wrote:


This sounds exactly like what I need  Do you know if 2.4.5 server
and clients can be intermixed with 2.4.4p3 (thereabouts) clients?  I


Yes, without any problem.  Of course, you cannot use the newer features
on a 2.4.4 client like the advanced estimate options.
As far as I know any 2.4.X version can communicate with eachother.


That's a given :)  and perfectly fine.  I really only have four-five hosts 
that *need* this.  Other than that the rest can get upgraded whenever.


Thanks again!

Estimate Disable/tweak patch?

[Michael Loftis]

There was someone who had posted here or to hackers an AMANDA estimate 
disabler tweak or patch.  I was wondering where this is.


And yes I tried searching but Yahoo groups is apparently completely broken. 
After a second or two it comes back with Partial search completed. Your 
search timed out before any results matching your search were found. Find 
more results for this search by clicking the button below. which would be 
fine if it were searching a decent chunk of articles.  It's not, only about 
100-500 at each click and not finding anything and it insists on startinf 
from oldest I think.



--
Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler

Re: Estimate Disable/tweak patch?

[Matt Hyclak]

On Thu, Oct 20, 2005 at 11:13:55AM -0600, Michael Loftis enlightened us:
 There was someone who had posted here or to hackers an AMANDA estimate 
 disabler tweak or patch.  I was wondering where this is.
 

Since 2.4.5b1 there are a couple of options for estimates in your dumptype:

* new 'estimate' dumptype option to select estimate type:
CLIENT: estimate by the dumping program.
CALCSIZE: estimate by the calcsize program, a lot faster but less acurate.
SERVER: estimate based on statistic from previous run, take second but
can be wrong on the estimate size.

I use CALCSIZE on my slow clients.

Matt

-- 
Matt Hyclak
Department of Mathematics 
Department of Social Work
Ohio University
(740) 593-1263

Re: Estimate Disable/tweak patch?

[Michael Loftis]

--On October 20, 2005 1:40:00 PM -0400 Matt Hyclak [EMAIL PROTECTED] 
wrote:



On Thu, Oct 20, 2005 at 11:13:55AM -0600, Michael Loftis enlightened us:

There was someone who had posted here or to hackers an AMANDA estimate
disabler tweak or patch.  I was wondering where this is.



Since 2.4.5b1 there are a couple of options for estimates in your
dumptype:


This sounds exactly like what I need  Do you know if 2.4.5 server and 
clients can be intermixed with 2.4.4p3 (thereabouts) clients?  I have a 
bunch of machines being backed  up that it will take a long time to get a 
new version out to, but I need this badly for my mailserver and main 
fileserver if it indeed will speed things up.  Right now the systems all 
wait for several hrs for the mail server, and the fileserver takes over two 
hrs too.  Lots of files, lots of data.




* new 'estimate' dumptype option to select estimate type:
CLIENT: estimate by the dumping program.
CALCSIZE: estimate by the calcsize program, a lot faster but less
acurate. SERVER: estimate based on statistic from previous run, take
second but can be wrong on the estimate size.

I use CALCSIZE on my slow clients.

Matt

--
Matt Hyclak
Department of Mathematics
Department of Social Work
Ohio University
(740) 593-1263





--
Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds.
-- Samuel Butler

Re: The spanning patch

[John Stange]

  I haven't looked at amverify yet at all (you're the first person who's
  tried to use it with the patch).  I'll take a whack at it once some regular
  work stuff is off my plate.
 
 When you've had your whack at it let me know and I'll give it a run as
 well.

Whacking now, expect stuff in the next week or so...

-- 
John Stange, Systems Administrator
National Academies Press
202-334-3514

Re: The spanning patch

[Bruce S. Skinner]

John Stange [EMAIL PROTECTED] writes:
 
 Whacking now, expect stuff in the next week or so...

Awaiting results... :-)

-- 

Bruce S. Skinner
Defence RD Canada - Atlantic
9 Grove St.  mailto:[EMAIL PROTECTED]
P.O. Box 1012http://www.drdc-rddc.dnd.ca
Dartmouth  NS
CANADAtel: (902) 426-3100 x205
B2Y 3Z7   fax: (902) 426-9654

Re: The spanning patch

[Bruce S. Skinner]

Hello John,

John Stange [EMAIL PROTECTED] writes:

 I haven't looked at amverify yet at all (you're the first person who's tried 
 to
 use it with the patch).  I'll take a whack at it once some regular work stuff
 is off my plate.

When you've had your whack at it let me know and I'll give it a run
as well.

regards :-)
BruceS

-- 

Bruce S. Skinner
Defence RD Canada - Atlantic
9 Grove St.  mailto:[EMAIL PROTECTED]
P.O. Box 1012http://www.drdc-rddc.dnd.ca
Dartmouth  NS
CANADAtel: (902) 426-3100 x205
B2Y 3Z7   fax: (902) 426-9654

spanning patch

[Peter Kunst]

Hi,
sorry for the delay, don't wonna break our production setup, so i've
setup another Solaris9 box together with a spare dds4x6 changer connected
to it for some testing. here we go...
1st of all, spanning of a single DLE over two tapes works fine, using
 http://www.cs.umd.edu/~building/span_split_V7.0-2.4.5b1-20050214.patch.gz
against
 http://www.iro.umontreal.ca/~martinea/amanda/amanda-2.4.5b1-20050214.tar.gz
i haven't tested recovering yet.
John Stange wrote:
 Gene Heskett wrote:
I'm afraid that the results of the spanning patch by John
Stange (Hi John) are a bit less than optimum in some regards.
it's a patch, leading us to some kind of fine release later on, so let's
test it :-)
using amverify mysetup, i've got this when the next tape is a fresh tape:
$ amverify mysetup
Tape changer is chg-zd-mtx...
2 slots... (should read: 6 slots ?)
Verify summary to [EMAIL PROTECTED]
Defects file is /tmp/amanda/amverify.17109/defects
amverify mysetup
Loading current slot...
Using device /dev/rmt/0cbn
Volume mysetup07, Date 20050308
End-of-Information detected.
Loading next slot...
Using device /dev/rmt/0cbn
Volume mysetup08, Date X
Fresh tape. Skipping...
$
..whereas mysetup07 is the 2nd tape of the last run. mysetup06 would be
the 1st tape of this run. never used amverify before anyways... just tested
it because of Gene's hint.
after loading the 1st tape of this run, i get:
Loading current slot...
Using device /dev/rmt/0cbn
Volume myetup06, Date 20050308
End-of-Information detected.
Loading next slot...
Using device /dev/rmt/0cbn
Volume mysetup07, Date 20050308
End-of-Information detected.
$
mail report says:
Tapes: mysetup07
No errors found!
...seems as amanda thinks only mysetup07 was written by this run.
don't know if this happens using 2.4.5b1-20050214 also... haven't tested.
...will give you more results when i've checked recovery, or should i
switchover to the hackers list ?
 Cheers, Peter
--
read http://www.faqs.org/rfcs/rfc1855.html before replying

Re: spanning patch

[Gene Heskett]

On Tuesday 08 March 2005 16:42, Peter Kunst wrote:
Hi,

sorry for the delay, don't wonna break our production setup, so i've
setup another Solaris9 box together with a spare dds4x6 changer
 connected to it for some testing. here we go...

1st of all, spanning of a single DLE over two tapes works fine,
 using

 
 http://www.cs.umd.edu/~building/span_split_V7.0-2.4.5b1-20050214.pa
tch.gz

against

 
 http://www.iro.umontreal.ca/~martinea/amanda/amanda-2.4.5b1-2005021
4.tar.gz

i haven't tested recovering yet.

John Stange wrote:
  Gene Heskett wrote:
 
I'm afraid that the results of the spanning patch by John
Stange (Hi John) are a bit less than optimum in some regards.

it's a patch, leading us to some kind of fine release later on, so
 let's test it :-)

using amverify mysetup, i've got this when the next tape is a
 fresh tape:

$ amverify mysetup
Tape changer is chg-zd-mtx...
2 slots... (should read: 6 slots ?)
Verify summary to [EMAIL PROTECTED]
Defects file is /tmp/amanda/amverify.17109/defects
amverify mysetup
Loading current slot...
Using device /dev/rmt/0cbn
Volume mysetup07, Date 20050308
End-of-Information detected.
Loading next slot...
Using device /dev/rmt/0cbn
Volume mysetup08, Date X
Fresh tape. Skipping...
$

..whereas mysetup07 is the 2nd tape of the last run. mysetup06
 would be the 1st tape of this run. never used amverify before
 anyways... just tested it because of Gene's hint.

after loading the 1st tape of this run, i get:

Loading current slot...
Using device /dev/rmt/0cbn
Volume myetup06, Date 20050308
End-of-Information detected.
Loading next slot...
Using device /dev/rmt/0cbn
Volume mysetup07, Date 20050308
End-of-Information detected.
$

mail report says:

Tapes: mysetup07
No errors found!

This would seem to be the default, since amrecover has not yet been 
patched to behave itself when doing the spanned tapes.

I had a bit of trouble switching it back after the 2 day test, so my 
stuff is now out of numerical synch, but thats not a showstopper by 
any means.

...seems as amanda thinks only mysetup07 was written by this run.
don't know if this happens using 2.4.5b1-20050214 also... haven't
 tested.

No, thats amverify only, since it hasn't been patched yet according to 
John. That (2.4.5b1-20050214) also is the version I patched.

...will give you more results when i've checked recovery, or should
 i switchover to the hackers list ?

  Cheers, Peter

--
read http://www.faqs.org/rfcs/rfc1855.html before replying

-- 
Cheers, Gene
There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order.
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.

Re: spanning patch

[Peter Kunst]

Gene Heskett wrote:
On Tuesday 08 March 2005 16:42, Peter Kunst wrote:((read http://www.faqs.org/rfcs/rfc1855.html before replying
(this is Tue, 8 Mar 2005 22:55:05 +0100 (CET) :-)
Loading current slot...
Using device /dev/rmt/0cbn
Volume myetup06, Date 20050308
End-of-Information detected.
Loading next slot...
Using device /dev/rmt/0cbn
Volume mysetup07, Date 20050308
[..]
mail report says:
Tapes: mysetup07
No errors found!
This would seem to be the default, since amrecover has not yet been 
patched to behave itself when doing the spanned tapes.

I had a bit of trouble switching it back after the 2 day test, so my 
stuff is now out of numerical synch, but thats not a showstopper by 
any means.
that's why i have _not_ touched production setup o)
just joined amanda hackers... give me some days to wait for
something like a howto-amanda-hackers, if there is one, like on
sunmanagers.org, and i'll join testing, now that i've spent some
hours to setup a working test-setup.
John, cc: me for updates, please :o)
 Cheers, Peter
--
read http://www.faqs.org/rfcs/rfc1855.html before replying

Re: The spanning patch

[John Stange]

 I'm afraid that the results of the spanning patch by John
 Stange (Hi John) are a bit less than optimum in some regards.
 
 1: The printed reports as to whats on which tape are at quite
 large odds with the results of doing a directory on that vtape.
 The two hosts are coyote and gene, gene being my firewall, and
 coyote this box.
 
 On vtape Dailys-21 from the printout:
 File# Host Filesystem level origK compK 
 0 - Dailys-21 - 32 32
 6 coyote /usr/dlds/misc 0 6304950 6305248
 24 gene /bin  1 10 64
 2 gene /boot  0 29930 29984
 14 gene /etc  0 11780 2144
 12 gene /home  0 17200 4096
 4 gene /lib  0 62870 22560
 20 gene /opt  1 5470 320
 16 gene /root  1 8750 800
 10 gene /sbin  0 12210 5344
 22 gene /usr/bin 1 50 96
 18 gene /usr/local 1 4030 544
 8 gene /usr/src 1 57850 9248
 ---end of printout for that vtape---
 However, here is an ls -l of that vtape:
 -rw---  1 amanda disk10 Mar  2 01:31 0-Dailys-21
 -rw---  1 amanda disk 32768 Mar  2 01:31 0.Dailys-21
 -rw---  1 amanda disk12 Mar  2 01:35 1-gene._boot.0
 -rw---  1 amanda disk  30703616 Mar  2 01:35 1.gene._boot.0
 -rw---  1 amanda disk12 Mar  2 01:40 2-gene._lib.0
 -rw---  1 amanda disk  23101440 Mar  2 01:40 2.gene._lib.0
 -rw---  1 amanda disk14 Mar  2 01:41 3-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk 805273600 Mar  2 01:41 3.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk14 Mar  2 01:42 4-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk 805306368 Mar  2 01:42 4.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk14 Mar  2 01:44 5-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk 805306368 Mar  2 01:44 5.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk14 Mar  2 01:45 6-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk 805306368 Mar  2 01:45 6.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk14 Mar  2 01:46 7-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk 805306368 Mar  2 01:46 7.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk14 Mar  2 01:48 8-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk 805306368 Mar  2 01:48 8.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk14 Mar  2 01:49 9-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk 805306368 Mar  2 01:49 9.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk14 Mar  2 01:50 00010-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk 805306368 Mar  2 01:50 00010.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk12 Mar  2 01:51 00011-coyote._usr_dlds-misc.0
 -rw---  1 amanda disk  14155776 Mar  2 01:51 00011.coyote._usr_dlds-misc.0
 -rw---  1 amanda disk12 Mar  2 01:51 00012-gene._usr_src.1
 -rw---  1 amanda disk   9469952 Mar  2 01:51 00012.gene._usr_src.1
 -rw---  1 amanda disk12 Mar  2 01:51 00013-gene._sbin.0
 -rw---  1 amanda disk   5472256 Mar  2 01:51 00013.gene._sbin.0
 -rw---  1 amanda disk12 Mar  2 01:51 00014-gene._home.0
 -rw---  1 amanda disk   4194304 Mar  2 01:51 00014.gene._home.0
 -rw---  1 amanda disk11 Mar  2 01:51 00015-gene._etc.0
 -rw---  1 amanda disk   2195456 Mar  2 01:51 00015.gene._etc.0
 -rw---  1 amanda disk11 Mar  2 01:51 00016-gene._root.1
 -rw---  1 amanda disk819200 Mar  2 01:51 00016.gene._root.1
 -rw---  1 amanda disk11 Mar  2 01:51 00017-gene._usr_local.1
 -rw---  1 amanda disk557056 Mar  2 01:51 00017.gene._usr_local.1
 -rw---  1 amanda disk10 Mar  2 01:51 00018-gene._opt.1
 -rw---  1 amanda disk327680 Mar  2 01:51 00018.gene._opt.1
 -rw---  1 amanda disk10 Mar  2 01:51 00019-gene._usr_bin.1
 -rw---  1 amanda disk 98304 Mar  2 01:51 00019.gene._usr_bin.1
 -rw---  1 amanda disk10 Mar  2 01:53 00020-gene._bin.1
 -rw---  1 amanda disk 65536 Mar  2 01:53 00020.gene._bin.1
 -rw---  1 amanda disk14 Mar  2 01:54 00021-coyote._amanda.0
 -rw---  1 amanda disk 805273600 Mar  2 01:54 00021.coyote._amanda.0
 -rw---  1 amanda disk12 Mar  2 01:54 00022-coyote._amanda.0
 -rw---  1 amanda disk  11632640 Mar  2 01:54 00022.coyote._amanda.0
 
 Note that there is nominally 817 megabytes of /amanda from coyote
 and this is the file that was actually spanned to the next tape
 but which is not included in the printout.  It is listed as the
 top item on the subsequent Dailys-22 printout page with its total
 size of 1350310K, which compressed to 8180880K.

Hm, the reporter stuff works normally with my current setup, that could be an
issue with the patch I generated for the latest snapshot.

 2:  Where formerly the emailed report from amverify reported in
 full format, listing all the files it verified, now it does not.
 A very limited form of the report is sent instead:

I haven't looked at amverify yet at all (you're the first person who's tried to
use

The spanning patch

[Gene Heskett]

Hi everybody;

I'm afraid that the results of the spanning patch by John
Stange (Hi John) are a bit less than optimum in some regards.

1: The printed reports as to whats on which tape are at quite
large odds with the results of doing a directory on that vtape.
The two hosts are coyote and gene, gene being my firewall, and
coyote this box.

On vtape Dailys-21 from the printout:
File# Host Filesystem level origK compK 
0 - Dailys-21 - 32 32
6 coyote /usr/dlds/misc 0 6304950 6305248
24 gene /bin  1 10 64
2 gene /boot  0 29930 29984
14 gene /etc  0 11780 2144
12 gene /home  0 17200 4096
4 gene /lib  0 62870 22560
20 gene /opt  1 5470 320
16 gene /root  1 8750 800
10 gene /sbin  0 12210 5344
22 gene /usr/bin 1 50 96
18 gene /usr/local 1 4030 544
8 gene /usr/src 1 57850 9248
---end of printout for that vtape---
However, here is an ls -l of that vtape:
-rw---  1 amanda disk10 Mar  2 01:31 0-Dailys-21
-rw---  1 amanda disk 32768 Mar  2 01:31 0.Dailys-21
-rw---  1 amanda disk12 Mar  2 01:35 1-gene._boot.0
-rw---  1 amanda disk  30703616 Mar  2 01:35 1.gene._boot.0
-rw---  1 amanda disk12 Mar  2 01:40 2-gene._lib.0
-rw---  1 amanda disk  23101440 Mar  2 01:40 2.gene._lib.0
-rw---  1 amanda disk14 Mar  2 01:41 3-coyote._usr_dlds-misc.0
-rw---  1 amanda disk 805273600 Mar  2 01:41 3.coyote._usr_dlds-misc.0
-rw---  1 amanda disk14 Mar  2 01:42 4-coyote._usr_dlds-misc.0
-rw---  1 amanda disk 805306368 Mar  2 01:42 4.coyote._usr_dlds-misc.0
-rw---  1 amanda disk14 Mar  2 01:44 5-coyote._usr_dlds-misc.0
-rw---  1 amanda disk 805306368 Mar  2 01:44 5.coyote._usr_dlds-misc.0
-rw---  1 amanda disk14 Mar  2 01:45 6-coyote._usr_dlds-misc.0
-rw---  1 amanda disk 805306368 Mar  2 01:45 6.coyote._usr_dlds-misc.0
-rw---  1 amanda disk14 Mar  2 01:46 7-coyote._usr_dlds-misc.0
-rw---  1 amanda disk 805306368 Mar  2 01:46 7.coyote._usr_dlds-misc.0
-rw---  1 amanda disk14 Mar  2 01:48 8-coyote._usr_dlds-misc.0
-rw---  1 amanda disk 805306368 Mar  2 01:48 8.coyote._usr_dlds-misc.0
-rw---  1 amanda disk14 Mar  2 01:49 9-coyote._usr_dlds-misc.0
-rw---  1 amanda disk 805306368 Mar  2 01:49 9.coyote._usr_dlds-misc.0
-rw---  1 amanda disk14 Mar  2 01:50 00010-coyote._usr_dlds-misc.0
-rw---  1 amanda disk 805306368 Mar  2 01:50 00010.coyote._usr_dlds-misc.0
-rw---  1 amanda disk12 Mar  2 01:51 00011-coyote._usr_dlds-misc.0
-rw---  1 amanda disk  14155776 Mar  2 01:51 00011.coyote._usr_dlds-misc.0
-rw---  1 amanda disk12 Mar  2 01:51 00012-gene._usr_src.1
-rw---  1 amanda disk   9469952 Mar  2 01:51 00012.gene._usr_src.1
-rw---  1 amanda disk12 Mar  2 01:51 00013-gene._sbin.0
-rw---  1 amanda disk   5472256 Mar  2 01:51 00013.gene._sbin.0
-rw---  1 amanda disk12 Mar  2 01:51 00014-gene._home.0
-rw---  1 amanda disk   4194304 Mar  2 01:51 00014.gene._home.0
-rw---  1 amanda disk11 Mar  2 01:51 00015-gene._etc.0
-rw---  1 amanda disk   2195456 Mar  2 01:51 00015.gene._etc.0
-rw---  1 amanda disk11 Mar  2 01:51 00016-gene._root.1
-rw---  1 amanda disk819200 Mar  2 01:51 00016.gene._root.1
-rw---  1 amanda disk11 Mar  2 01:51 00017-gene._usr_local.1
-rw---  1 amanda disk557056 Mar  2 01:51 00017.gene._usr_local.1
-rw---  1 amanda disk10 Mar  2 01:51 00018-gene._opt.1
-rw---  1 amanda disk327680 Mar  2 01:51 00018.gene._opt.1
-rw---  1 amanda disk10 Mar  2 01:51 00019-gene._usr_bin.1
-rw---  1 amanda disk 98304 Mar  2 01:51 00019.gene._usr_bin.1
-rw---  1 amanda disk10 Mar  2 01:53 00020-gene._bin.1
-rw---  1 amanda disk 65536 Mar  2 01:53 00020.gene._bin.1
-rw---  1 amanda disk14 Mar  2 01:54 00021-coyote._amanda.0
-rw---  1 amanda disk 805273600 Mar  2 01:54 00021.coyote._amanda.0
-rw---  1 amanda disk12 Mar  2 01:54 00022-coyote._amanda.0
-rw---  1 amanda disk  11632640 Mar  2 01:54 00022.coyote._amanda.0

Note that there is nominally 817 megabytes of /amanda from coyote
and this is the file that was actually spanned to the next tape
but which is not included in the printout.  It is listed as the
top item on the subsequent Dailys-22 printout page with its total
size of 1350310K, which compressed to 8180880K.

2:  Where formerly the emailed report from amverify reported in
full format, listing all the files it verified, now it does not.
A very limited form of the report is sent instead:
-
From: Amanda user [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 
Tapes:  Dailys-21 Dailys-22
No errors found!

amverify Daily
Wed Mar  2 02:16:35 EST 2005

Loading 21 slot...
Using device file:/amandatapes/Dailys/
Volume Dailys-21, Date 20050302
Checked gene._boot.20050302.0.1
End

Dumper Patch Problem

[Jim Summers]

I have recently upgraded my Amanda server to 2.4.4p1 on Redhat9.  All is
well except I occassionally get strange results and the following in my
/var/log/messages file.
===
kernel: application bug: dumper(23061) has SIGCHLD set to SIG_IGN but 
calls wait()
===
I found a reference to this in the amanda-users archive and a patch from
Jay Fenalson.  

I have tried to apply the patch with:  patch -p2  dumper-patch
and patch -f -p2 dumper-patch.  But I can not get the patch to complete
successfully.

My patch file is as follows:
- amanda-2.4.3/server-src/dumper.c.orig 2003-02-11
21:10:03.0 -0500
+++ amanda-2.4.3/server-src/dumper.c 2003-02-11 21:10:27.0 -0500
@@ -254,7 +254,6 @@
error(can't get login name for my uid %ld, (long)getuid());
 
signal(SIGPIPE, SIG_IGN);
- signal(SIGCHLD, SIG_IGN);
 
interactive = isatty(0);

I am in the server-src directory when I run the commands above.  

Reading the patch file does it mean I simply need to delete the line
dumper.c that has the SIGCHLD in it?  

But I guess I should figure out the correct patch command also?

Suggestions or ideas would be greatly appreciated.

TIA
-- 
Jim Summers [EMAIL PROTECTED]
University of Oklahoma - Computer Science

Re: Dumper Patch Problem

[Joshua Baker-LePain]

On 7 Oct 2003 at 10:57am, Jim Summers wrote

 I have recently upgraded my Amanda server to 2.4.4p1 on Redhat9.  All is
 well except I occassionally get strange results and the following in my
 /var/log/messages file.
 ===
 kernel: application bug: dumper(23061) has SIGCHLD set to SIG_IGN but 
 calls wait()
 ===
 I found a reference to this in the amanda-users archive and a patch from
 Jay Fenalson.  
 
 I have tried to apply the patch with:  patch -p2  dumper-patch
 and patch -f -p2 dumper-patch.  But I can not get the patch to complete
 successfully.

 I am in the server-src directory when I run the commands above.  

Sit in the top-level amanda directory and do this:

[EMAIL PROTECTED] amanda-2.4.4p1]$ patch -p1  amanda-2.4.3-sigchld.patch
patching file server-src/dumper.c
Hunk #1 succeeded at 253 (offset -1 lines).

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

Re: Dumper Patch Problem

[Jim Summers]

I think my patch file is not correct.  I tried the command recommended
and got the following:
[EMAIL PROTECTED] amanda-2.4.4p1]# patch -p1  dumper-patch
patching file server-src/dumper.c
patch:  malformed patch at line 4: error(can't get login name for
my uid %ld, (long)getuid());

I don't have the actual file that Jay mentioned in the archives.  So I
did a cut/paste from the message to build the file.

Suggestions / Ideas ?

Thanks again,
jim



On Tue, 2003-10-07 at 11:06, Joshua Baker-LePain wrote:
 On 7 Oct 2003 at 10:57am, Jim Summers wrote
 
  I have recently upgraded my Amanda server to 2.4.4p1 on Redhat9.  All is
  well except I occassionally get strange results and the following in my
  /var/log/messages file.
  ===
  kernel: application bug: dumper(23061) has SIGCHLD set to SIG_IGN but 
  calls wait()
  ===
  I found a reference to this in the amanda-users archive and a patch from
  Jay Fenalson.  
  
  I have tried to apply the patch with:  patch -p2  dumper-patch
  and patch -f -p2 dumper-patch.  But I can not get the patch to complete
  successfully.
 
  I am in the server-src directory when I run the commands above.  
 
 Sit in the top-level amanda directory and do this:
 
 [EMAIL PROTECTED] amanda-2.4.4p1]$ patch -p1  amanda-2.4.3-sigchld.patch
 patching file server-src/dumper.c
 Hunk #1 succeeded at 253 (offset -1 lines).
-- 
Jim Summers [EMAIL PROTECTED]
University of Oklahoma - Computer Science

Re: Dumper Patch Problem

[Eric Siegerman]

On Tue, Oct 07, 2003 at 10:57:50AM -0500, Jim Summers wrote:
 Reading the patch file does it mean I simply need to delete the line
 dumper.c that has the SIGCHLD in it?  

Correct.

 But I guess I should figure out the correct patch command also?

Well, you could, but for this particular patch, editing by hand
is probably easier :-)

--

|  | /\
|-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot

a little patch which made my changer working

[C.Scheeder]

Hi folks,
i have a ADIC 12-Tape DAT autoloader which worked out of the box to 99% 
with chg-scsi.
Only if i opend the door it gave me an error the first time i accessed 
it afterwards.
Now the tapeunit died, and i replaced it with a HP dat24I drive,
and chg-scsi stoped working.
i dug into the source of amanda 2.4.4 and the messages chg-scsi
gave and found two problems, one tape-related and one changer-related.
the tape does enter unit-attention mode direct after loading a tape, and
that caused chg-scsi to think there was something wrong with the drive.
Fixed it by defining the correct answers for this tape-unit in sense.c

verry similar problem for the changer, after opening the frontdoor it 
enters unit-attention-mode too, telling me someone opened the door...

so i defined the correct codes for the changer too, and now
realy all is fine with this changer and drive combination.
i atach the changes i made as a patch, so everyone interested
in it can have a look at it.
it applys to 2.4.4p1 too.

to whom should i send it to get it into the release next time?

Christoph





adic+C1537A.diff.gz
Description: GNU Zip compressed data

please add sencrypt ssl patch to main Amanda release

[John Lane]

The sencrypt ssl patch ( 
http://cns.utoronto.ca/~pkern/stuff/amanda-patch/) has been around
for a while now, and seems to work well as simple approach to encrypting
amanda network traffic. As it is an unobtrusive, configurable patch 
could it be assimilated into the mainstream Amanda code base, rather 
than have to patch for each release?

Thanks

John

--
=
John Lane
WorldPay plc
WorldPay Centre
The Science Park
Milton Road
Cambridge
CB4 0WE
Tel. +44 (0) 870 742 7000
Fax. +44 (0) 870 742 7009
---
Important: This e-mail may contain information confidential to WORLDPAY. 
If you are not the intended recipient take care
as it may be unlawful for you to read, copy, distribute, disclose or 
otherwise use information contained in it. If this is the case, please
contact us immediately and we will assist you: Tel: 0870 742 7000 Fax: 
0870 742 7009 E-mail: Reply to sender
---

Tar patch

[Vijay Kumar]

hi!


How do i apply the Tar patfch in the patches directory?
I am using tar 1.13.19 . Do i still need the patch?

thanks for any replies,

Vijay

Using Patch to apply advfs.diff

[Clinton Dilks]

Hi Everyone

I am trying to setup the amanda client on a  TRU64 in particular  OSF1
V4.0. (Note the amanda client is amanda-2.4.2p2)

This means that I need to apply the advfs.diff patch.  To do this I 
believed that I need ed to go into the  client-src directory then type

patch  getfsent.h advfs.diff

but when I do this I get a message saying  Hmm...  I can't seem to find
a patch in there anywhere.

Ive tried various combinations of switchs such as -l , p0 and p1 with no
change.

Can anyone give me an idea where Im going wrong ??
Thank You for your time
Have a nice day :)



__
The contents of this e-mail are privileged and/or confidential to the
named recipient and are not to be used by any other person and/or
organisation. If you have received this e-mail in error, please notify 
the sender and delete all material pertaining to this e-mail.
__

Applying Ditial Unix advfs patch issues

[Eric Zylstra]

I've created a file called duampatch with vi, copied the patch from the 
web page http://www.amanda.org/patches/2.4.2p2/advfs.diff, and pasted 
it into the file.  When I issue:
  patch -p1  duampatch

from the top level of the amamanda-2.4.2 tree, it just says, Hmm...  I 
can't seem to find a patch in there anywhere.

Same thing if I do a:
  patch -p1 -i duampatch

In this case ignorance is NOT bliss.  What should I be doing?

Thanks,

EZ

amrecover reserved port and stream_client.diff patch file

[Jason Upton]

I have compiled amanda 2.4.2p2 with the --with-port-range option and am 
getting the amrecover: did not get a reserved port message.  Amanda 
has been backing up fine as far as I can tell, but I wanted to test the 
restore capabilities before I actually needed them and found that I have 
this problem.

So I searched the yahoo groups archive for amanda-users and found a 
patch located at www.amanda.org/patches.html (real location of patch 
file is http://www.amanda.org/patches/2.4.2p2/stream_client.diff) and 
tried to apply it, but it appears the patch was generated against a 
different version of common-src/stream.c than what I have downloaded 
with the 2.4.2p2 tar file release.

Here is what I see when applying the patch:
# patch -p0  stream_client.diff
patching file common-src/stream.c
Hunk #1 succeeded at 145 (offset 2 lines).
Hunk #2 succeeded at 159 with fuzz 1 (offset 3 lines).
Hunk #3 succeeded at 180 (offset 3 lines).
Hunk #4 succeeded at 198 (offset 3 lines).
Hunk #5 succeeded at 213 (offset 3 lines).
Hunk #6 succeeded at 263 (offset 3 lines).
Hunk #7 succeeded at 275 (offset 3 lines).
Hunk #8 FAILED at 285.
Hunk #9 succeeded at 307 (offset 5 lines).
1 out of 9 hunks FAILED -- saving rejects to file common-src/stream.c.rej
patching file common-src/stream.h
patching file recover-src/amrecover.c
Hunk #1 succeeded at 513 (offset -11 lines).
patching file recover-src/extract_list.c

I checked the patch file and see that stream.c was diff'd with version 
1.10.2.8:
diff -u -r1.10.2.8
--- common-src/stream.c 2001/06/18 22:23:19 1.10.2.8
+++ common-src/stream.c 2001/07.30 19:13:19

My amanda 2.4.2p2 tar ball has the 1.10.2.7 version of common-src/stream.c:
$Id: stream.c,v 1.10.2.7 2001/02/28 00:53:15 jrjackson Exp $

Is this why the patch is failing?  If so, how do I patch my 1.10.2.7 to 
be 1.10.2.8 before I apply the stream_client.diff patch?

Thanks for any help,
Jason Upton
[EMAIL PROTECTED]

Patch problems

[John Peter Gormley]

Hi,
I wanted to swap from dump to tar for my backups and figured if I'm going to
recompile amanda, I might as well upgrade from 2.4.1p1 to 2.4.2p2. I have
downloaded the 2.4.2p2 software, gnutar, gnupatch2.5 and the two patches
advfs and stream client for amanda 2.4.2p2. I am running amanda on two
servers and about 30 clients all tru64 boxes versions 4.0d- 4.0g.

I am having problems getting the patches in, regardless of all the
information in the mail archives I keep coming up with 2 errors. One tells
me the patch can't be located (o.k. so I changed the -p option a few times,
still can't figure out where it wants it) and the 2nd problem is:
# /usr/local/inst/gnu/patch-2.5/bin/patch -p1  ../advfs.patch.dif
patching file `getfsent.h'
Hunk #1 FAILED at 54.
1 out of 1 hunk FAILED -- saving rejects to getfsent.h.rej
patching file `getfsent.c'
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 144.
Hunk #3 FAILED at 186.
Hunk #4 FAILED at 438.
Hunk #5 FAILED at 488.
Hunk #6 FAILED at 532.
Hunk #7 FAILED at 545.
Hunk #8 FAILED at 558.
Hunk #9 FAILED at 617.
Hunk #10 FAILED at 626.
10 out of 10 hunks FAILED -- saving rejects to getfsent.c.rej

What am I doing wrong? Should the patch diff file be in the top level
directory or the directory where the src is (e.g. client-src, common-src)or
is this irrelevant depending on which -p parameter is used. What are all
these hunk failed messages?

Any help would be appreciated, I've been playing with this for a few days
now and am getting pretty frustrated with what may be my own stupidity.

Regards, John

John Gormley
Senior Unix Systems Administrator
Information Technology and Telecommunications Services
Southern Cross University
Lismore NSW
AUSTRALIA 2480

phone: (02)6620-3365e-mail [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mobile: 0409150060   fax: (02)6620-3033

Re: Tar patch

[Gene Heskett]

On Tuesday 23 April 2002 12:44 am, Vijay Kumar wrote:
hi!


How do i apply the Tar patfch in the patches directory?
I am using tar 1.13.19 . Do i still need the patch?

thanks for any replies,

Vijay

No, that, or 1.13.25, the latest 'alpha' version, appear to be 
good according to reports coming in here.  I've been using 
1.13.19 for much of a year here.

-- 
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
98.8+% setiathome rank, not too shabby for a hillbilly

Re: Tar patch

[Joshua Baker-LePain]

On Tue, 23 Apr 2002 at 12:44am, Vijay Kumar wrote

 How do i apply the Tar patfch in the patches directory?
 I am using tar 1.13.19 . Do i still need the patch?

You don't need the patch for tar 1.13.19.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University

Tar patch

[Vijay Kumar]

hi!


How do i apply the Tar patfch in the patches directory?
I am using tar 1.13.19 . Do i still need the patch?

thanks for any replies,

Vijay

Applying Ditial Unix advfs patch issues

[Eric Zylstra]

I've created a file called duampatch with vi, copied the patch from the 
web page http://www.amanda.org/patches/2.4.2p2/advfs.diff, and pasted 
it into the file.  When I issue:
  patch -p1  duampatch

from the top level of the amamanda-2.4.2 tree, it just says, Hmm...  I 
can't seem to find a patch in there anywhere.

Same thing if I do a:
  patch -p1 -i duampatch

In this case ignorance is NOT bliss.  What should I be doing?

Thanks,

EZ

Re: Applying Ditial Unix advfs patch issues

[John R. Jackson]

I've created a file called duampatch with vi, copied the patch from the 
web page http://www.amanda.org/patches/2.4.2p2/advfs.diff, and pasted 
it into the file.  ...

Bad idea.  Never try to copy/paste patches.  There is practically
zero chance it won't get messed up along the way (tabs = blanks,
for instance).

Use whatever your browser provides to do a save as (e.g. for Netscape
on Unix it's Shift-Button1) to get the file.

If that's a problem, let me know and I'll drop a copy in my ftp area.

EZ

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Re: Using Patch to apply advfs.diff

[John R. Jackson]

This means that I need to apply the advfs.diff patch.  To do this I 
believed that I need ed to go into the  client-src directory then type

patch  getfsent.h advfs.diff

What version of patch are you using (patch --version)?

Are you sure you got a good copy of advfs.diff?  It should start something
like this:

  Index: client-src/getfsent.h
  ===
  RCS file: /cvsroot/amanda/amanda/client-src/getfsent.h,v
  retrieving revision 1.4
  retrieving revision 1.4.4.1
  diff -u -r1.4 -r1.4.4.1
  --- client-src/getfsent.h   1998/07/04 00:18:15 1.4
  +++ client-src/getfsent.h   2001/04/12 00:58:47 1.4.4.1
  @@ -54,7 +54,7 @@
   void close_fstab P((void));

What I would have done is cd to the top level of the Amanda sources
(the directory with configure.in in it) and done:

  patch  advfs.diff

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Using Patch to apply advfs.diff

[Clinton Dilks]

Hi Everyone

I am trying to setup the amanda client on a  TRU64 in particular  OSF1
V4.0. (Note the amanda client is amanda-2.4.2p2)

This means that I need to apply the advfs.diff patch.  To do this I 
believed that I need ed to go into the  client-src directory then type

patch  getfsent.h advfs.diff

but when I do this I get a message saying  Hmm...  I can't seem to find
a patch in there anywhere.

Ive tried various combinations of switchs such as -l , p0 and p1 with no
change.

Can anyone give me an idea where Im going wrong ??
Thank You for your time
Have a nice day :)



__
The contents of this e-mail are privileged and/or confidential to the
named recipient and are not to be used by any other person and/or
organisation. If you have received this e-mail in error, please notify 
the sender and delete all material pertaining to this e-mail.
__

Re: help :: advfs patch

[Bernhard R. Erdmann]

 i would like to extend my amanda backup capabitities to one of my DEC v5.1
 boxes.  the problem is it's running advfs.  I've downloaded the patch and
 tried to install it unsuccessfully for about a week now.  however, i've
 never used `patch` and i'm running into a wall on this one.
 
 could someone perhaps offer some assistance or point me to a website i could
 read up on the patch binary some more.  for example, DEC includes its own
 version of `patch`.  do i have to use gnu patch?  can i use the dec patch?

Though I've no idea of DEC's version of patch, but I'd recommend GNU
patch.

Then you do something like:
cd /usr/local/src
tar xzf /where/ever/you/stored/amanda-2.4.2p2.tar.gz
cd amanda-2.4.2p2
patch -p1  /where/ever/you/lost/advfs-patch.diff

The -p option specifies the number of subdir levels to strip off in the
diff file, i.e. the might be something like:
+++ amanda-2.4.2p2/client/sendsize.c ...
--- amanda-2.4.2p2-orig/client/sendsize.c ...

So -p1 is to strip off the first level of subdir to apply the diff / to
patch client/sendsize.c.

append-patch

[Yannick LeBlanc]

Hello,
i want to know if someone use the amanda-2.4.2p2-append-patch.bz2
(from
http://www-internal.alphanet.ch/archives/local/alphanet/divers/patches/amanda/
)

Your comment are welcome.

Thanks

Yannick

advfs.diff patch

[Travis Rail]

How do you apply this patch?

patch -l client-src/getfsent.h advfs.diff

Travis

Re: advfs.diff patch

[Nupur Pande]

When I tried installing the above patch, I got this error while running
make and make install. Would amanda still work?


Making install in client-src
/sbin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I.
-I../config -I../common-src-g   -c -o getfsent.lo getfsent.c
cc -DHAVE_CONFIG_H -I. -I. -I../config -I../common-src -g -c getfsent.c -o
getfsent.o
cc-1162 cc: ERROR File = getfsent.c, Line = 489
  Too few arguments in function call.

  if(search_fstab(str, fsent))
 ^

cc-1162 cc: ERROR File = getfsent.c, Line = 501
  Too few arguments in function call.

  if(search_fstab(str, fsent))
 ^

2 errors detected in the compilation of getfsent.c.
*** Error code 1 (bu21)
*** Error code 1 (bu21)



On Thu, 26 Jul 2001, John R. Jackson wrote:

 How do you apply this patch?
 
 Cd to the top of your Amanda source tree (the directory with the
 ./configure script).  Then run patch with advfs.diff as stdin.  Depending
 on what version of patch you have, you may need -p0 on the command line.
 
 Then remove config.cache (or make distclean), run make and (as root)
 run make install.
 
 Note that this patch applies to the client, so that's what needs to be
 updated, not the server (although updating the server as well won't hurt).
 
 Travis
 
 John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
 

Re: advfs.diff patch

[John R. Jackson]

When I tried installing the above patch, I got this error while running
make and make install.  ...

Are you sure you are working with the 2.4.2p2 sources?

Would amanda still work?

Not likely.

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Minor reporter patch

[Joshua Baker-LePain]

Attached is a minor patch which changes the stats printed on tape labels
to reflect what is actually on the tape rather than what got dumped.
This makes all fields accurate during an amflush run, where Total Size
used to be reported as 0, as well as after an amdump run that hit EOT.
As such, Filesystems Dumped is now Filesystems Taped.

If I broke anything, please let me know.  And if it's right, please let me
know too, as it's my first official patch.  :)

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University


--- server-src/reporter.c~	Fri Feb  2 14:07:57 2001
+++ server-src/reporter.c	Tue May 29 10:39:54 2001
@@ -865,7 +865,7 @@
 
 if (postscript) {
   fprintf(postscript, (Total Size:%6.1f MB) DrawStat\n,
-	  mb(stats[2].outsize));
+	  mb(stats[2].tapesize));
   fprintf(postscript, (Tape Used (%%)   );
   divzero(postscript, pct(stats[2].tapesize+marksize*stats[2].tapedisks),
 	  tapesize);
@@ -873,8 +873,8 @@
   fprintf(postscript, (Compression Ratio:  );
   divzero(postscript, pct(stats[2].coutsize),stats[2].corigsize);
   fprintf(postscript, %%) DrawStat\n);
-  fprintf(postscript,(Filesystems Dumped: %4d) DrawStat\n,
-	  stats[2].dumpdisks);
+  fprintf(postscript,(Filesystems Taped: %4d) DrawStat\n,
+	  stats[2].tapedisks);
 }
 }
 

Re: Minor reporter patch

[John R. Jackson]

Attached is a minor patch which changes the stats printed on tape labels
to reflect what is actually on the tape rather than what got dumped.

Thanks!  I tried it on a couple of my configs and it seems to do the right
thing.  The patch has been applied to all the current source branches.

About the only thing some other folks might request is a ChangeLog entry
to go along with the patch.  I've taken care of it for this change.

Joshua Baker-LePain

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

patch

[Olivier Collet]

Hello,

Few month ago, I was told to apply this patch :

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/amanda/server-src/taper.c.diff?cvsroot=amandaonly_with_tag=amanda-242-branchr1=texttr1=1.47.2.15r2=texttr2=1.47.2.16r2=textf=u

but now the page doesn't exist anymore, and when I follow the link to the
new page I don't know which patch to choose.
Anyone can help ?

Thanks in advance
regards
-- 
Olivier Collet

System Administrator

If you ask questions, you might look stupide,
but if you don't, you will be stupide.

Re: patch

[John R. Jackson]

Few month ago, I was told to apply this patch :

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/amanda/server-src/taper.c.diff?c
vsroot=amandaonly_with_tag=amanda-242-branchr1=texttr1=1.47.2.15r2=texttr
2=1.47.2.16r2=textf=u

but now the page doesn't exist anymore, and when I follow the link to the
new page I don't know which patch to choose.

Sigh.  Seems like the SourceForge people have done it to us again.  Yet
another unannounced change.

This appears to be the correct new URL:

  
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/amanda/amanda/server-src/taper.c.diff?r1=1.47.2.15r2=1.47.2.16diff_format=u

I've also appended the patch as an attachment in case you have any
other trouble.

Thanks for pointing out this problem.  I'll get the scripts changed that
generate those URL's so they send out the right thing.

Olivier Collet

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

 taper-15-16.diff

Announcing Amanda 2.4.2, patch level 2

[John R. Jackson]

[ I sent this to amanda-announce last Friday, but there appears to be
something wrong with that list.  Apologies if you get duplicates.  --JJ ]

The Amanda core development team is pleased to announce the availability
of patch level 2 of Amanda version 2.4.2 (amanda-2.4.2p2).  It may be
obtained from the usual locations (www.amanda.org or the download area
of www.sourceforge.net).  A brief overview of the changes from the NEWS
file is appended.  See the ChangeLog file for more detail.

A problem has recently been reported dealing with advfs file systems.
Users with this file system type should probably avoid 2.4.2p2 until a
patch is available.

John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]

Changes in release 2.4.2p2

* Mostly bug fixes.
* Samba passwords are now sent to smbclient via a pipe and never displayed.
* Amrecover should now work with xfsrestore.
* Amrecover no longer binds an incorrect port that resulted in connection
  failures on some systems.
* Debug files in /tmp/amanda (--with-debug-dir) are now timestamped and old
  ones automatically cleaned out.  This means more space (a few KBytes) will
  be used since in a given run, several of the programs are called more than
  once.  But it also means important debugging information should no longer
  be lost by the file being overwritten.  The length of time to keep the
  files is controlled by --with-debug-days (default: 4).  The old flag
  --with-pid-debug-files is no longer needed and is ignored.
* updated chg-zd-mtx.sh.in changer.

tar-patch

[mack]

Hi,

I'm trying to install Amanda, but having a little trouble patching tar. I'm not
even sure if it's necessary, as the patch is for tar-1.12, and I have version
1.13-17. Maybe the problems described for version 1.12 don't occur with 1.13 ?

Marion

-- 
Der Herr hat uns nicht die Gnade zuteil werden lassen, daß wir uns
wie andere Lebewesen durch saubere und keusche Zellteilung fortpflanzen können.

Re: tar-patch

[Jean-Louis Martineau]

On Fri, Jan 12, 2001 at 02:35:25PM +0100, [EMAIL PROTECTED] wrote:
 Hi,
 
 I'm trying to install Amanda, but having a little trouble patching tar. I'm not
 even sure if it's necessary, as the patch is for tar-1.12, and I have version
 1.13-17. Maybe the problems described for version 1.12 don't occur with 1.13 ?

Install tar-1.13.18 from ftp://alpha.gnu.org/gnu/tar
and the patch from http://www.amanda.org/patches.html

Jean-Louis
-- 
Jean-Louis Martineau email: [EMAIL PROTECTED] 
Departement IRO, Universite de Montreal
C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529
Montreal, Canada, H3C 3J7Fax: (514) 343-5834

Re: patch

[Chris Karakas]

Yann PURSON wrote:
 
 I need to apply the samba patch but I don't know how to do it...
 

cd /usr/src/packages/BUILD (or, wherever the amanda directory is located
under, e.g. for me it is in /usr/src/packages/BUILD/amanda-2.4.1p1)

patch -p0  /home/chris/amanda/samba2-2418.diff (or whatever path
you have for the diff file)

(the samba2-2418.diff patch is against samba-2.06,
while samba2.diff is against samba-2.05)

check for reject files...;-)

I think you will not need to patch if you use 2.4.2, which has just been
released, so check your version first (and its change log file,
CHANGES), as well as that of your SAMBA.

-- 
Regards

Chris Karakas
Dont waste your cpu time - crack rc5: http://www.distributed.net

Re: patch

[Eric Wadsworth]

What operating system?

If you are using FreeBSD and the ports collection, I have instructions on
how to do it (they work; I just did it and it fixed my problems).

Otherwise you can probably use the patch command. Do a 'man patch' to see
info.

--- Eric Wadsworth

On Mon, 11 Dec 2000, Yann PURSON wrote:

 Hi,
 
 I need to apply the samba patch but I don't know how to do it...
 
 -- 
 Yann PURSON - Administrateur systemes et reseaux
 ADNTIC - www.adntic.com 
 93, rue du Hocquet - 80.000 AMIENS
 Tel : 03.22.22.27.27 - Fax 03 22 22 03 57