Re: Patches used by Debian on amanda -- "backup" user under Debian
For what its worth, this creates problems with inter-operability between CentOS and Debian; we rebuilt the CentOS rpm for amanda client so it used the backup user instead of amanda, as our amanda server was on Debian. We tried hard but never found a way to configure this. It would be nice to be able to configure this and not have to have it compiled in. On Mon, Jan 9, 2017 at 11:21 AM, Nathan Stratton Treadway < natha...@ontko.com> wrote: > On Sun, Jan 08, 2017 at 12:51:45 -0700, Charles Curley wrote: > > May I request you end two irritants about the Debian version. It creates > > a user, "backup". That's fine, although "amanda", say, would avoid > > stepping on some other user named "backup". > > > > The irritant is that debian makes the user's home > > directory /var/backups. Something else uses that directory, and I don't > > like co-mingling the two different functions. It also sets the user > > shell to "/usr/sbin/nologin" rather than to bash, which is an irritant > > on the way to using amanda over ssh. > > > > For what it's worth, the "backup" user (uid 34) -- including its home > directory and login shell settings -- is actually defined on all Debian > systems as part of the base-passwd package (and thus exist completely > separately from the Amanda packages). > > See, for example: > https://anonscm.debian.org/cgit/users/cjwatson/base- > passwd.git/tree/passwd.master > https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 > (_Debian Policy Manual_ "9.2.2 UID and GID classes") > > > I've always figured that whoever did the original Debian packaging for > the Amanda software (years ago) decided it would be easier to make use > of that pre-existing user rather than having to have the package > installation scripts manage creation (and deletion) of a separate > "amanda" user > > Interestingly, /usr/share/doc/base-passwd/users-and-groups.txt.gz doesn't > seem to know what the "backup" user is for, either: > backup > > Presumably so backup/restore responsibilities can be locally delegated > to > someone without full root permissions? > > HELP: Is that right? Amanda reportedly uses this, details? > > so I suspect that this user was "allocated" in the early mists of > time for the Debian project, and since then has mostly or completely > fallen out of use -- except for the use by the Amanda packages > > > 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: xinetd is being deprecated. What will replaec it?
Optional systemd configuration files for amanda; please don't make it compulsory. On Thu, Aug 27, 2015 at 5:07 AM, Jean-Louis Martineau wrote: > > systemd (which you probably already run) replace xinetd. > Most services are already started by systemd. > We just need systemd configuration files for amanda. > > Jean-Louis > > > On 26/08/15 08:47 PM, Gene Heskett wrote: > >> Heads up in case yopu haven't heard it yet. >> >> From a comment I just read on another list, slack has already expunged >> it. >> >> I would not be surprised to see other distro's follow suit. >> >> Cheers, Gene Heskett >> > >
restoring without amanda
Hi there I'm preparing some documentation on our backup/restore process. Some time ago I linked to amanda documentation on how to extract from tapes without using any amanda tools or indexes. This link was: http://www.amanda.org/docs/using.html#restoring_without_amanda and is now broken. This isn't quite what I'm after as it uses amrestore: http://wiki.zmanda.com/index.php/How_To:Recover_Lost_Amanda_Configuration Can anyone point me at the current correct link please? Thanks! -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Amanda-friendly distro?
Hi there I've been looking at the state of Amanda in a few distros. Ubuntu and Centos so far seem to have pretty old versions of Amanda. Can anyone suggest a distro that tracks Amanda upstream reasonably well? Ie doesn't include bug-ridden versions in their stable releases... Not that I'm accusing the Amanda people of releasing bug-ridden software but hey we all make mistakes. Its the putting right that counts. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Gene Heskett wrote: On Tuesday 09 March 2010, Dustin J. Mitchell wrote: On Wed, Mar 3, 2010 at 1:58 PM, Steve Wray wrote: Right, so the LATEST most up-to-date version of Debian uses a 3 year old version of amanda. Fantastic, thanks Debian for keeping things so 'stable'. To be fair, that's exactly the intent, and maintaining a Linux distribution is *not* easy. All of the binary-only distros are "behind the times" to varying degrees, although Debian is usually bringing up the rear of the bunch. I downloaded the actual latest stable version of amanda (2.6.1p2 from November 2009), compiled it and tested it. No bug. Yay! Thanks, Debian package maintainer. Not. [snip] If there are Amanda bugs that are holding back a version bump, please let me know. At the moment, I only see two open bugs, one from 2006 and one from 2008, neither of which is blocking a bump. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500364 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=370319 Dustin I'm on your side here Dustin. The distros, debian in particular need prodding. What you use for a prod is up to you. :-) The problem I have with submitting bug reports to Debian on this sort of thing is this: If the bug is not security related then its extremely unlikely to be fixed until the NEXT stable release. In Debian, stability means making sure that non-security bugs are maintained throughout the lifetime of the release. The bugs are *part* of the stability. The theory is that people may have implemented workarounds for these bugs. If you go fixing the bug then you break their workaround. Since, due to this (and other ongoing concerns with the 'stability' problems of Debian), I will not be using the next stable release. So why would I bother to point out to them that, "hey, maybe when you release the next Debian version you use the current version of Amanda?" if I am not going to be using that version? This would be purely altruistic... and if Debian can't figure this out for themselves well... to be frank, I have no time for that. I go back 11+ years with amanda, usually running the bleeding edge as now. Considering that I build the new snapshot and use it nightly several times a week, the number of real bugs has been almost vanishingly small even when its labeled as alpha, not for production use. FWIW, 90% of those were tar's fault, not amanda's. There are several tar versions about, not all of which are even compatible with themselves. Amanda is compatible with itself with one exception, a format change a good 8 or 9 years ago. Folks like Dustin and Jean-Louis write tight, and correct code. I mentally salute them as I toss last nights printout on top of the stack (should, heaven forbid, I need to consult it) every morning. That reminds me; in one release of Debian the version of tar and of amanda were incompatible! It was the 'tar gives exit status 1 if a file changed while being read' problem IIRC. This was NEVER fixed in that 'stable' release. I should have seen the writing on the wall, really. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
I'd like to put in an update to this thread, for anyone interested. The backup server had been running Debian Etch. The version of amanda on Etch was giving the errors described in this thread. I upgraded the server to Debian Lenny. The problems still occured with the version in Lenny. Then I noticed that the version of amanda in Lenny dates from 2007. It gives its version as: 1:2.5.2p1-4 When I look at the amanda.org download page and compare version numbers I see this: 2.5.2p1 June 6 2007 Right, so the LATEST most up-to-date version of Debian uses a 3 year old version of amanda. Fantastic, thanks Debian for keeping things so 'stable'. I downloaded the actual latest stable version of amanda (2.6.1p2 from November 2009), compiled it and tested it. No bug. Thanks, Debian package maintainer. Not. Backup software is mission critical. Failing to track the upstream to this extent is simply unforgivable. I'm revising my opinion of Debian. Steve Wray wrote: Dustin J. Mitchell wrote: On Thu, Jan 21, 2010 at 5:05 PM, Jean-Louis Martineau wrote: xinetd is still configured to accept a tcp connection, but amandad expect a udp packet, so amandad do nothing and the server fail while waiting for an ACK. Right - it was the failure I expected to see, not Steve's bug. I'm not able to replicate Steve bug, many fix have been committed since 2.5.0p2. Good point. By my back-of-the-envelope calculations, we've fixed something like 500 bugs in the 4 years since 2.5.0 was released. Of course, we *introduced* some of of those bugs in those 4 years, too :) Steve: if you don't see something obvious that I missed in my replication effort, can you give this a try with a 2.6.1p2 server? I'm not able to make this test yet, perhaps later in the week. However, I've discovered that the amcheck problem may not actually reflect a genuine problem that affects backup. The other day, the cronjob amcheck reported these errors -- so for one thing its clearly intermittent. But the thing is that the backup job that ran that very night completed with no problems at all. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Dustin J. Mitchell wrote: On Thu, Jan 21, 2010 at 5:05 PM, Jean-Louis Martineau wrote: xinetd is still configured to accept a tcp connection, but amandad expect a udp packet, so amandad do nothing and the server fail while waiting for an ACK. Right - it was the failure I expected to see, not Steve's bug. I'm not able to replicate Steve bug, many fix have been committed since 2.5.0p2. Good point. By my back-of-the-envelope calculations, we've fixed something like 500 bugs in the 4 years since 2.5.0 was released. Of course, we *introduced* some of of those bugs in those 4 years, too :) Steve: if you don't see something obvious that I missed in my replication effort, can you give this a try with a 2.6.1p2 server? I'm not able to make this test yet, perhaps later in the week. However, I've discovered that the amcheck problem may not actually reflect a genuine problem that affects backup. The other day, the cronjob amcheck reported these errors -- so for one thing its clearly intermittent. But the thing is that the backup job that ran that very night completed with no problems at all. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
I am going to try and resurrect this thread having been able to home in on
the apparent bug I found with bsdtcp auth.
I have now converted most of our systems to using bsdtcp and amcheck is
showing no errors at this time.
The problem I had before was, to reiterate:
Disklist with two entries.
One entry uses bsdtcp
The other entry uses BSD.
If the client of the disklist entry that is configured on the server to use
bsdtcp is not configured to use bsdtcp on the CLIENT in /etc/inetd.conf
then the client which is configured to use default authentication returns
errors.
I now have a full disklist for all of our servers. Some are using bsdtcp
others are using the default (which as I understand it is BSD).
If I go to one of the clients whose disklist entry on the server is for
bsdtcp and I change its /etc/inetd.conf from this:
amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad
-auth=bsdtcp amdump
to this:
amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad
then ALL other disklist entries which are NOT using bsdtcp return errors on
amcheck -c
Disklist entries which are configured to use bsdtcp are not affected and do
not generate errors, only those using BSD auth.
This is just a change in inetd.conf on ONE client.
The errors for the other disklist entries are:
ERROR: : [access as backup not allowed from root@amanda server>] amandahostsauth failed
I have no idea if this is an amanda problem or a Debian packaging problem
or what it is. But its repeatable.
Version info for the amanda-server package on the amanda server is:
r...@fileserver:~# dpkg -s amanda-server
Package: amanda-server
Status: install ok installed
Priority: optional
Section: utils
Installed-Size: 1216
Maintainer: Bdale Garbee
Architecture: i386
Source: amanda
Version: 1:2.5.2p1-5
Steve Wray wrote:
Steve Wray wrote:
Jean-Louis Martineau wrote:
Run 'amadmin disklist' and check the auth is set as expected
for all dles.
I've done this, with the amanda.conf having bsdudp and with it having
bsdtcp for that entry.
In both cases all auth entries for all other DLE's are 'BSD'.
In both cases only that one DLE is reported as having either bsdtcp or
bsdudp, in both cases matching what is in the amanda.conf
So I'd say that was all as expected.
Having changed this one DLE to bsdudp I'm still seeing intermittent
problems with the nightly backup run.
I'd like to change to bsdtcp as it seems more robust but as I've
mentioned there were some serious problems with that.
Any further advice or help would be appreciated.
Thanks.
Jean-Louis
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
On the client, in the sendbackup.20100106012630.debug log I see:
sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348
sendbackup: time 0.057: started backup
sendbackup: time 90.352: index tee cannot write [Broken pipe]
sendbackup: time 90.352: pid 3346 finish time Wed Jan 6
01:28:01 2010
90 seconds, it's not a dtimeout issue.
Post all debug files for the run.
You can also try the bsdtcp auth, it is more firewall friendly.
Ah hang on, am I right in understanding that you can't have just
one dle using bsdtcp auth? That they would all have to have it?
(ie the inetd configuration)
All dles for a client must have the same auth.
different client can have different auth.
We are going around in circles a little here.
Allow me to try to make things very clear.
In my amanda.conf I have a dumptype defined as such:
(I've included the parent dumptypes. The 'global' dumptype is empty)
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/etc/amanda/exclude.gtar"
priority low
}
define dumptype nocomp-root-tar {
root-tar
comment "Root partitions without compression"
compress none
}
define dumptype problem-nocomp-root-tar {
nocomp-root-tar
comment "Root partitions without compression, problem client"
compress none
auth "bsdudp"
#auth "bsdtcp"
}
There are several DLEs for clients using the 'nocomp-root-tar'
dumptype and only *one* DLE for *one* client using the
'problem-nocomp-root-tar' dumptype.
With the bsdudp line uncommented everything is happy with an amcheck.
With the bsdtcp line uncommented (and the bsdudp line commented out)
*no* client is happy with the amcheck *other* than the client which
uses 'problem-nocomp-root-tar'. However, as noted in another email
this is intermittent, sometimes some clients using nocomp-root-tar
are happy. So far its not exhibiting much pattern that I can see.
The above *does* include the fact that I *do* change the inetd.conf
on the client wh
Re: intermittent amanda failure
Steve Wray wrote:
Jean-Louis Martineau wrote:
Run 'amadmin disklist' and check the auth is set as expected
for all dles.
I've done this, with the amanda.conf having bsdudp and with it having
bsdtcp for that entry.
In both cases all auth entries for all other DLE's are 'BSD'.
In both cases only that one DLE is reported as having either bsdtcp or
bsdudp, in both cases matching what is in the amanda.conf
So I'd say that was all as expected.
Having changed this one DLE to bsdudp I'm still seeing intermittent
problems with the nightly backup run.
I'd like to change to bsdtcp as it seems more robust but as I've mentioned
there were some serious problems with that.
Any further advice or help would be appreciated.
Thanks.
Jean-Louis
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
On the client, in the sendbackup.20100106012630.debug log I see:
sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348
sendbackup: time 0.057: started backup
sendbackup: time 90.352: index tee cannot write [Broken pipe]
sendbackup: time 90.352: pid 3346 finish time Wed Jan 6 01:28:01
2010
90 seconds, it's not a dtimeout issue.
Post all debug files for the run.
You can also try the bsdtcp auth, it is more firewall friendly.
Ah hang on, am I right in understanding that you can't have just
one dle using bsdtcp auth? That they would all have to have it? (ie
the inetd configuration)
All dles for a client must have the same auth.
different client can have different auth.
We are going around in circles a little here.
Allow me to try to make things very clear.
In my amanda.conf I have a dumptype defined as such:
(I've included the parent dumptypes. The 'global' dumptype is empty)
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/etc/amanda/exclude.gtar"
priority low
}
define dumptype nocomp-root-tar {
root-tar
comment "Root partitions without compression"
compress none
}
define dumptype problem-nocomp-root-tar {
nocomp-root-tar
comment "Root partitions without compression, problem client"
compress none
auth "bsdudp"
#auth "bsdtcp"
}
There are several DLEs for clients using the 'nocomp-root-tar'
dumptype and only *one* DLE for *one* client using the
'problem-nocomp-root-tar' dumptype.
With the bsdudp line uncommented everything is happy with an amcheck.
With the bsdtcp line uncommented (and the bsdudp line commented out)
*no* client is happy with the amcheck *other* than the client which
uses 'problem-nocomp-root-tar'. However, as noted in another email
this is intermittent, sometimes some clients using nocomp-root-tar
are happy. So far its not exhibiting much pattern that I can see.
The above *does* include the fact that I *do* change the inetd.conf
on the client which uses problem-nocomp-root-tar *and* restart inetd.
So, with a change of one line in a dumptype in a DLE used by one
client, all other clients have problems.
Perhaps I am misunderstanding something basic about dumptype
configuration?
--
Please remember that an email is just like a postcard; it is not
confidential nor private nor secure and can be read by many other people
than the intended recipient. A postcard can be read by anyone at the mail
sorting office and expecting what is written on it to be private and secret
is not realistic. Please hold no higher expectation of email.
If you need to send confidential information in an email you need to use
encryption. PGP is Pretty good for this.
Re: [Amanda-users] Changing Next Tape Expected
brnn8r wrote: Hi All, This is my first post on this forum and I'm a bit of a Amanda newb. At my company we have a Weekly backup regime and after each weekly backup the tape is sent offsite for storage and the next Weekly tape is > brought in. I've just come back from holiday and Amanda is expecting our next Weekly backup tape to be called Weekly03. Unfortunately while I was away this tape was given to the backup company and we now have Weekly04. My question is: Can I change what Amanda expects to be the next Weekly tape? i.e. can I set it to Weekly04 instead of Weekly03? Otherwise I'll have to request the previous weekly tape is returned and this will of course have some cost. I'd get the correct tape from offsite storage. I have seen amanda start to request tapes in strange, counter-intuitive numerical sequences after being 'made to' accept tapes out of sequence. This sort of thing can mess the offsite storage and retrieval up even more. Imagine what'll happen when the backup company deliver Weekly05 and amanda is asking for Weekly03. I've had some very confusing conversations with offsite storage people over things like this. Best to keep it as simple as possible. Thanks Steve +-- |This was sent by venge...@gmail.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
I'll attach some debug logs.
For the purposes of this test I cut the disklist file down to two entries:
One entry is a client which is configured to use simple BSD auth.
The other entry is a client which is configured to use bsdtcp auth.
Both of these have been verified by running amcheck disklist.
This file:
amcheck.20100107131821.debug
is from the client whose DLE has it using BSD auth.
This file:
amandad.20100107131826.debug
is from the client whose DLE has it using bsdtcp auth.
This file:
amcheck.20100107131821.debug
is from the server on that same run.
The amcheck -c command reported:
bac...@fileserver:~$ amcheck -c cwa-lto
Amanda Backup Client Hosts Check
ERROR: NAK zimbra1.internal.cwa.co.nz: user root from
fileserver.internal.cwa.co.nz is not allowed to execute the service noop:
Please add "amdump" to the line in /var/backups/.amandahosts on the client
Client check: 2 hosts checked in 5.097 seconds, 1 problem found
(brought to you by Amanda 2.5.2p1)
Steve Wray wrote:
Jean-Louis Martineau wrote:
Run 'amadmin disklist' and check the auth is set as expected
for all dles.
I've done this, with the amanda.conf having bsdudp and with it having
bsdtcp for that entry.
In both cases all auth entries for all other DLE's are 'BSD'.
In both cases only that one DLE is reported as having either bsdtcp or
bsdudp, in both cases matching what is in the amanda.conf
So I'd say that was all as expected.
Jean-Louis
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
On the client, in the sendbackup.20100106012630.debug log I see:
sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348
sendbackup: time 0.057: started backup
sendbackup: time 90.352: index tee cannot write [Broken pipe]
sendbackup: time 90.352: pid 3346 finish time Wed Jan 6 01:28:01
2010
90 seconds, it's not a dtimeout issue.
Post all debug files for the run.
You can also try the bsdtcp auth, it is more firewall friendly.
Ah hang on, am I right in understanding that you can't have just
one dle using bsdtcp auth? That they would all have to have it? (ie
the inetd configuration)
All dles for a client must have the same auth.
different client can have different auth.
We are going around in circles a little here.
Allow me to try to make things very clear.
In my amanda.conf I have a dumptype defined as such:
(I've included the parent dumptypes. The 'global' dumptype is empty)
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/etc/amanda/exclude.gtar"
priority low
}
define dumptype nocomp-root-tar {
root-tar
comment "Root partitions without compression"
compress none
}
define dumptype problem-nocomp-root-tar {
nocomp-root-tar
comment "Root partitions without compression, problem client"
compress none
auth "bsdudp"
#auth "bsdtcp"
}
There are several DLEs for clients using the 'nocomp-root-tar'
dumptype and only *one* DLE for *one* client using the
'problem-nocomp-root-tar' dumptype.
With the bsdudp line uncommented everything is happy with an amcheck.
With the bsdtcp line uncommented (and the bsdudp line commented out)
*no* client is happy with the amcheck *other* than the client which
uses 'problem-nocomp-root-tar'. However, as noted in another email
this is intermittent, sometimes some clients using nocomp-root-tar
are happy. So far its not exhibiting much pattern that I can see.
The above *does* include the fact that I *do* change the inetd.conf
on the client which uses problem-nocomp-root-tar *and* restart inetd.
So, with a change of one line in a dumptype in a DLE used by one
client, all other clients have problems.
Perhaps I am misunderstanding something basic about dumptype
configuration?
--
Please remember that an email is just like a postcard; it is not
confidential nor private nor secure and can be read by many other people
than the intended recipient. A postcard can be read by anyone at the mail
sorting office and expecting what is written on it to be private and secret
is not realistic. Please hold no higher expectation of email.
If you need to send confidential information in an email you need to use
encryption. PGP is Pretty good for this.
amandad: debug 1 pid 5084 ruid 34 euid 34: start at Thu Jan 7 13:18:21 2010
Could not open conf file "/etc/amanda/amanda-client.conf": No such file or
directory
amandad: time 0.000: security_getdriver(name=bsd) returns 0xb7f834c0
amandad: version 2.5.2p1
amandad: time 0.000: build: VERSION="Amanda-2.5.2p1"
amandad: time 0.000:BUILT_DATE="Sat Aug 16 16:06:29 ART 20
Re: intermittent amanda failure
Jean-Louis Martineau wrote:
Run 'amadmin disklist' and check the auth is set as expected
for all dles.
I've done this, with the amanda.conf having bsdudp and with it having
bsdtcp for that entry.
In both cases all auth entries for all other DLE's are 'BSD'.
In both cases only that one DLE is reported as having either bsdtcp or
bsdudp, in both cases matching what is in the amanda.conf
So I'd say that was all as expected.
Jean-Louis
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
On the client, in the sendbackup.20100106012630.debug log I see:
sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348
sendbackup: time 0.057: started backup
sendbackup: time 90.352: index tee cannot write [Broken pipe]
sendbackup: time 90.352: pid 3346 finish time Wed Jan 6 01:28:01
2010
90 seconds, it's not a dtimeout issue.
Post all debug files for the run.
You can also try the bsdtcp auth, it is more firewall friendly.
Ah hang on, am I right in understanding that you can't have just one
dle using bsdtcp auth? That they would all have to have it? (ie the
inetd configuration)
All dles for a client must have the same auth.
different client can have different auth.
We are going around in circles a little here.
Allow me to try to make things very clear.
In my amanda.conf I have a dumptype defined as such:
(I've included the parent dumptypes. The 'global' dumptype is empty)
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/etc/amanda/exclude.gtar"
priority low
}
define dumptype nocomp-root-tar {
root-tar
comment "Root partitions without compression"
compress none
}
define dumptype problem-nocomp-root-tar {
nocomp-root-tar
comment "Root partitions without compression, problem client"
compress none
auth "bsdudp"
#auth "bsdtcp"
}
There are several DLEs for clients using the 'nocomp-root-tar'
dumptype and only *one* DLE for *one* client using the
'problem-nocomp-root-tar' dumptype.
With the bsdudp line uncommented everything is happy with an amcheck.
With the bsdtcp line uncommented (and the bsdudp line commented out)
*no* client is happy with the amcheck *other* than the client which
uses 'problem-nocomp-root-tar'. However, as noted in another email
this is intermittent, sometimes some clients using nocomp-root-tar are
happy. So far its not exhibiting much pattern that I can see.
The above *does* include the fact that I *do* change the inetd.conf on
the client which uses problem-nocomp-root-tar *and* restart inetd.
So, with a change of one line in a dumptype in a DLE used by one
client, all other clients have problems.
Perhaps I am misunderstanding something basic about dumptype
configuration?
--
Please remember that an email is just like a postcard; it is not
confidential nor private nor secure and can be read by many other people
than the intended recipient. A postcard can be read by anyone at the mail
sorting office and expecting what is written on it to be private and secret
is not realistic. Please hold no higher expectation of email.
If you need to send confidential information in an email you need to use
encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Jean-Louis Martineau wrote:
Steve Wray wrote:
Jean-Louis Martineau wrote:
Steve Wray wrote:
On the client, in the sendbackup.20100106012630.debug log I see:
sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348
sendbackup: time 0.057: started backup
sendbackup: time 90.352: index tee cannot write [Broken pipe]
sendbackup: time 90.352: pid 3346 finish time Wed Jan 6 01:28:01 2010
90 seconds, it's not a dtimeout issue.
Post all debug files for the run.
You can also try the bsdtcp auth, it is more firewall friendly.
Ah hang on, am I right in understanding that you can't have just one
dle using bsdtcp auth? That they would all have to have it? (ie the
inetd configuration)
All dles for a client must have the same auth.
different client can have different auth.
We are going around in circles a little here.
Allow me to try to make things very clear.
In my amanda.conf I have a dumptype defined as such:
(I've included the parent dumptypes. The 'global' dumptype is empty)
define dumptype root-tar {
global
program "GNUTAR"
comment "root partitions dumped with tar"
compress none
index
exclude list "/etc/amanda/exclude.gtar"
priority low
}
define dumptype nocomp-root-tar {
root-tar
comment "Root partitions without compression"
compress none
}
define dumptype problem-nocomp-root-tar {
nocomp-root-tar
comment "Root partitions without compression, problem client"
compress none
auth "bsdudp"
#auth "bsdtcp"
}
There are several DLEs for clients using the 'nocomp-root-tar' dumptype and
only *one* DLE for *one* client using the 'problem-nocomp-root-tar' dumptype.
With the bsdudp line uncommented everything is happy with an amcheck.
With the bsdtcp line uncommented (and the bsdudp line commented out) *no*
client is happy with the amcheck *other* than the client which uses
'problem-nocomp-root-tar'. However, as noted in another email this is
intermittent, sometimes some clients using nocomp-root-tar are happy. So
far its not exhibiting much pattern that I can see.
The above *does* include the fact that I *do* change the inetd.conf on the
client which uses problem-nocomp-root-tar *and* restart inetd.
So, with a change of one line in a dumptype in a DLE used by one client,
all other clients have problems.
Perhaps I am misunderstanding something basic about dumptype configuration?
--
Please remember that an email is just like a postcard; it is not
confidential nor private nor secure and can be read by many other people
than the intended recipient. A postcard can be read by anyone at the mail
sorting office and expecting what is written on it to be private and secret
is not realistic. Please hold no higher expectation of email.
If you need to send confidential information in an email you need to use
encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Dustin J. Mitchell wrote: On Wed, Jan 6, 2010 at 4:01 PM, Steve Wray wrote: Am I to understand that there could be a problem in having 'too many' DLE's for bsd or bsdudp to cope with? I never thought of there being a limit to the number of DLE's before... Our disklist file has 178. Yes, it's quite possible, and quite common with folks who have an Amanda built with only a small range of available ports. Ok I'm not sure about amanda as built for Debian but would it be safer for me to change pretty much our entire system to use bsdtcp? So far my experiments in this regard have not been great; adding just one single DLE using bsdtcp has caused all other DLE's to have problems. And intermittent problems at that Sometimes 'amcheck -c' will report an error like: ERROR: NAK : user root from is not allowed to execute the service noop: Please add "amdump" to the line in /var/backups/.amandahosts on the client and the next time I run amcheck this error is not reported. Might be fine another run and then bad later. Whereas the amanda client which I configured for bsdtcp -- the only one I have thus configured so far -- does not return any error. (and yes, I am running amcheck from a 'su - backup' session where backup is the user that amanda runs as). -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Dustin J. Mitchell wrote: On Wed, Jan 6, 2010 at 3:42 PM, Steve Wray wrote: Ah hang on, am I right in understanding that you can't have just one dle using bsdtcp auth? That they would all have to have it? (ie the inetd configuration) Well, all DLEs on a given host have to have the same auth. If you define different host-level parameters for DLEs on the same host, the results are undefined. On a given host, sure. In the case of bsdtcp it appears that there needs to be some config on the server to handle this (in inetd/xinetd on the server). I think thats what was causing the cascade of errors I posted before. The inetd configuration is on the client, and has to be set up to correspond with the auth you want to use. Check out Paul Yeatman's wonderful amanda-auth(7) for the nitty-gritty details. http://wiki.zmanda.com/man/amanda-auth.7.html Yes I've been reading that. This caught my eye: bsd communication and authentication The authentication is done using .amandahosts file in the Amanda user's home directory. The protocol between Amanda server and client is UDP. The number of disk list entries (DLEs)--number of Amanda clients--is limited by the UDP packet size. This authentication protocol will use a different port for each data stream (see PORT USAGE below) bsdudp communication and authentication The authentication is done using .amandahosts files in the Amanda user's home directory. It uses UDP protocol between Amanda server and client for data and hence the number of DLEs is limited by the UDP packet size. It uses one TCP port to establish the connection and multiplexes all data streams using one port on the server (see PORT USAGE below). Am I to understand that there could be a problem in having 'too many' DLE's for bsd or bsdudp to cope with? I never thought of there being a limit to the number of DLE's before... Our disklist file has 178. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Jean-Louis Martineau wrote: Steve Wray wrote: Dustin J. Mitchell wrote: On Wed, Jan 6, 2010 at 4:01 PM, Steve Wray wrote: Am I to understand that there could be a problem in having 'too many' DLE's for bsd or bsdudp to cope with? I never thought of there being a limit to the number of DLE's before... Our disklist file has 178. Yes, it's quite possible, and quite common with folks who have an Amanda built with only a small range of available ports. Ok I'm not sure about amanda as built for Debian but would it be safer for me to change pretty much our entire system to use bsdtcp? So far my experiments in this regard have not been great; adding just one single DLE using bsdtcp has caused all other DLE's to have problems. You can't change only one dle, you must change all dles for that client, you must also change inetd/xinetd on that client, don't change it on the server. This particular client has only one DLE. The other DLE's which are having problems are all for other clients. Ie: a change to bsdtcp in the DLE for one client has broken all other clients. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Jean-Louis Martineau wrote: Steve Wray wrote: On the client, in the sendbackup.20100106012630.debug log I see: sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348 sendbackup: time 0.057: started backup sendbackup: time 90.352: index tee cannot write [Broken pipe] sendbackup: time 90.352: pid 3346 finish time Wed Jan 6 01:28:01 2010 90 seconds, it's not a dtimeout issue. Post all debug files for the run. You can also try the bsdtcp auth, it is more firewall friendly. Ah hang on, am I right in understanding that you can't have just one dle using bsdtcp auth? That they would all have to have it? (ie the inetd configuration) Jean-Louis -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Jean-Louis Martineau wrote:
Steve Wray wrote:
On the client, in the sendbackup.20100106012630.debug log I see:
sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348
sendbackup: time 0.057: started backup
sendbackup: time 90.352: index tee cannot write [Broken pipe]
sendbackup: time 90.352: pid 3346 finish time Wed Jan 6 01:28:01 2010
90 seconds, it's not a dtimeout issue.
Post all debug files for the run.
You can also try the bsdtcp auth, it is more firewall friendly.
I just tried following the instructions here:
http://wiki.zmanda.com/index.php/How_To:Configure_bsd,_bsdtcp,_or_bsdudp_authentication
I've added a single new dle config for this host:
define dumptype problemserver-nocomp-root-tar {
nocomp-root-tar
comment "Root partitions with compression"
compress none
auth "bsdtcp"
}
and a single change to the disklist file to refer to this config entry for
just that one single host.
When I 'su - backup' and run 'amcheck -c' I get errors such as:
ERROR: NAK : user root from is not
allowed to execute the service noop: Please add "amdump" to the line in
/var/backups/.amandahosts on the client
for *every* amanda client in the list.
It seems rather odd that this change for a single dle would introduce this
error for every other dle? Its as if something has leaked out.
I made no changes to any other configuration yet, just the change to the
amanda server modifying a dle for a single client.
I expected that it might fail for that client, but not for all of them...
(I'll get to posting the debug logs soon).
--
Please remember that an email is just like a postcard; it is not
confidential nor private nor secure and can be read by many other people
than the intended recipient. A postcard can be read by anyone at the mail
sorting office and expecting what is written on it to be private and secret
is not realistic. Please hold no higher expectation of email.
If you need to send confidential information in an email you need to use
encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Steve Wray wrote: Dustin J. Mitchell wrote: I suspect an estimate or data timeout. Have you tried increasing dtimeout and etimeout? etimeout 2000 dtimeout 2000 I'd be surprised. These seem like fairly substantial values. 2000 seconds is roughly half an hour. I'll increase them by another 1000 seconds though, to see what happens. It failed again last night with 3000 second timeouts for these values. How can I verify whether theres a problem with timeouts? Thanks. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: intermittent amanda failure
Dustin J. Mitchell wrote: I suspect an estimate or data timeout. Have you tried increasing dtimeout and etimeout? etimeout 2000 dtimeout 2000 I'd be surprised. These seem like fairly substantial values. 2000 seconds is roughly half an hour. I'll increase them by another 1000 seconds though, to see what happens. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
intermittent amanda failure
Hi there I have a server, at a remote location, which has recently started to intermittently fail backups. The amanda client is running Debian Lenny, the amanda server is running Debian Etch. On the amanda server, dpkg -s amanda-server shows Version: 1:2.5.2p1-5 On the amanda client, dpkg -s amanda-client shows Version: 1:2.5.2p1-4 There are two firewalls between the two sites and both have the kernel modules ip_nat_amanda and ip_conntrack_amanda loaded. This is happening often enough to be a worry. I'd like to find out what steps I can take. I've replaced the actual name of the amanda client with in the enclosed log entries. When it fails, in the daily email I get this error reported: cannot read header: got 0 instead of 32768 On the client, in the sendbackup.20100106012630.debug log I see: sendbackup-gnutar: time 0.056: /usr/lib/amanda/runtar: pid 3348 sendbackup: time 0.057: started backup sendbackup: time 90.352: index tee cannot write [Broken pipe] sendbackup: time 90.352: pid 3346 finish time Wed Jan 6 01:28:01 2010 On the server, in the amdump log I see: driver: send-cmd time 1426.876 to taper: FILE-WRITE 00-00011 /dumps/amanda/holding/20100101003007/._.1 UNKNOWNFEATURE / 1 20100101 0 driver: startaflush: LARGEST / 1200164 353040132 (I see this UNKNOWNFEATURE on dle's that do finish fine). I also see this on the server: FAIL chunker / 20100106 1 [cannot read header: got 0 instead of 32768] Thanks -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: debian etch update broke amanda
Steve Wray wrote: Hi there, I am still trying to get to the bottom of this. I think I got to the bottom of this. You know how Debian never fixes bugs in the stable release unless its a security related bug? And how the amanda in Debian Etch was released to stable with the gtar bug? So that in order to have a working amanda/gtar in Debian Etch you have to use the amanda packages from the testing branch? Well, on the two servers that had this problem, the apt/sources.list entry pointing to testing was commented out. I'm not sure exactly how this actually ended up being applied because the dpkg.log shows NO changes to amanda packages, but after an apt-get upgrade these two servers ended up with the broken 'stable' version of amanda from Debian Etch. I replaced the 'stable' version with the one from 'testing' and it all seems good now. Stability. I love it and hate it at the same time. I have some servers running Debian Etch. They have been fine with amanda for a very long time now. I just ran an apt-get upgrade to apply some security patches and suddenly I'm getting the old "file changed as we read it" and "error [/bin/tar returned 1]" again. I'd hoped to see the last of this. The thing is, looking at the packages that apt-get upgrade installed I have no idea why this should have happened: 2009-08-20 09:17:09 status installed libisc11 1:9.3.4-2etch5 2009-08-20 09:17:09 status installed libdns22 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed libisccc0 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed libisccfg1 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed libbind9-0 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed liblwres9 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed bind9-host 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed dnsutils 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed libapr1 1.2.7-9 2009-08-20 09:17:11 status installed libaprutil1 1.2.7+dfsg-2+etch3 2009-08-20 09:17:11 status installed apache2-utils 2.2.3-4+etch10 2009-08-20 09:17:12 status installed apache2.2-common 2.2.3-4+etch10 2009-08-20 09:17:14 status installed apache2-mpm-worker 2.2.3-4+etch10 2009-08-20 09:17:14 status installed apache2 2.2.3-4+etch10 2009-08-20 09:17:15 status installed libruby1.8 1.8.5-4etch5 2009-08-20 09:17:15 status installed libopenssl-ruby1.8 1.8.5-4etch5 2009-08-20 09:17:15 status installed libxml2 2.6.27.dfsg-6+etch1 2009-08-20 09:17:15 status installed ruby1.8 1.8.5-4etch5 This seems to make little sense. Package: amanda-client Status: install ok installed Priority: optional Section: utils Installed-Size: 288 Maintainer: Bdale Garbee Architecture: i386 Source: amanda Version: 1:2.5.1p1-2.1 Package: tar Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 1576 Maintainer: Bdale Garbee Architecture: i386 Version: 1.16-2etch1 Yeah at some stage this should go to a Debian list, but I feel that I need to do more figuring out yet. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
debian etch update broke amanda
Hi there, I am still trying to get to the bottom of this. I have some servers running Debian Etch. They have been fine with amanda for a very long time now. I just ran an apt-get upgrade to apply some security patches and suddenly I'm getting the old "file changed as we read it" and "error [/bin/tar returned 1]" again. I'd hoped to see the last of this. The thing is, looking at the packages that apt-get upgrade installed I have no idea why this should have happened: 2009-08-20 09:17:09 status installed libisc11 1:9.3.4-2etch5 2009-08-20 09:17:09 status installed libdns22 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed libisccc0 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed libisccfg1 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed libbind9-0 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed liblwres9 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed bind9-host 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed dnsutils 1:9.3.4-2etch5 2009-08-20 09:17:10 status installed libapr1 1.2.7-9 2009-08-20 09:17:11 status installed libaprutil1 1.2.7+dfsg-2+etch3 2009-08-20 09:17:11 status installed apache2-utils 2.2.3-4+etch10 2009-08-20 09:17:12 status installed apache2.2-common 2.2.3-4+etch10 2009-08-20 09:17:14 status installed apache2-mpm-worker 2.2.3-4+etch10 2009-08-20 09:17:14 status installed apache2 2.2.3-4+etch10 2009-08-20 09:17:15 status installed libruby1.8 1.8.5-4etch5 2009-08-20 09:17:15 status installed libopenssl-ruby1.8 1.8.5-4etch5 2009-08-20 09:17:15 status installed libxml2 2.6.27.dfsg-6+etch1 2009-08-20 09:17:15 status installed ruby1.8 1.8.5-4etch5 This seems to make little sense. Package: amanda-client Status: install ok installed Priority: optional Section: utils Installed-Size: 288 Maintainer: Bdale Garbee Architecture: i386 Source: amanda Version: 1:2.5.1p1-2.1 Package: tar Essential: yes Status: install ok installed Priority: required Section: utils Installed-Size: 1576 Maintainer: Bdale Garbee Architecture: i386 Version: 1.16-2etch1 Yeah at some stage this should go to a Debian list, but I feel that I need to do more figuring out yet. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: broadcast traffic
Dustin J. Mitchell wrote: On Tue, Jun 16, 2009 at 9:11 AM, Charlie Reitsma wrote: So, perhaps, the ISP is mistaking the backup traffic as a broadcast storm. It would appear as a sudden spike of traffic leaving the server. If so, a conversation with the ISP should clear up the issue. Other possibilities: The Amanda server or a client is accidentally configured with a broadcast address (this can happen easily in the tiny subnets hosting providers will often make for customers) An ARP cache is broken somewhere, so every packet requires an ARP probe. (Charlie, your suggestion is the simplest, but broadcast traffic is usually counted and reported separately, so I suspect this may, indeed, be broadcast) I had seen some mention of broadcast being used by amanda to locate tape servers or something... But this problem turned out to be a misconfiguration on one of the ISPs routers which was exacerbated by our amanda backup runs. They then proceeded to blame the backup process for the problem until I did a test run during the day while they were watching. Fixed now. -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
broadcast traffic
Hi there, We have a server hosted with our ISP and we have recently started to run amanda backups from this server to our main backup server. The ISP has contacted us about broadcast storms emanating from this server. These storms coincide with backup runs. I wasn't aware that amanda used broadcast traffic but there is nothing else on this server which could be causing this. If amanda does use broadcast, is there a way to turn it off or otherwise contain it? Thanks -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
increasing tar failures
Hi there, over the last month or so I've been seeing increasing amounts of disk list entries showing this in the amanda report: FAILED [/bin/tar returned 1] I've gone to the hosts involved and checked their logs and really thats about as informative as it gets. I've checked the tar command used on these hosts and run that to hand (sending to /dev/null) and have never seen tar fail yet. Amanda versions vary a lot here, we have Debian Sarge, Etch and Lenny hosts. Nothing major has changed with the hosts which have started to show this problem. There have been no network changes in the form of routers, switches or firewalls. Can someone please suggest some further diagnostics? Thanks! -- Please remember that an email is just like a postcard; it is not confidential nor private nor secure and can be read by many other people than the intended recipient. A postcard can be read by anyone at the mail sorting office and expecting what is written on it to be private and secret is not realistic. Please hold no higher expectation of email. If you need to send confidential information in an email you need to use encryption. PGP is Pretty good for this.
Re: Backing up VMware-VMs
Paul Bijnens wrote: On 2008-03-06 21:38, Steve Wray wrote: Stefan G. Weichinger wrote: Patrick M. Hausen schrieb: So if you want to backup/copy an entire VM with the guarantee of consistent hard disk state, you need to shut it down. Copying a multi gigabyte virtal disk file is bound to take quite some time. So you need to power down your virtual machine for what can amount to hours. What about combining it with LVM-snapshots? Are LVM snapshots working properly now? The last few times I tried it (several months ago) it was a total disaster and not something I'd want to risk even attempting on a virtual machine. What kind of disaster on which kernel? This would have been Debian Sarge last year. I forget the exact kernel version. The sort of disaster where it runs out of RAM while taking the snapshot and you are left with a kind of zombie logical volume which can't be deleted and the system is confused about the state of the source logical volume. Required a reboot to fix it. At the time I was aware that snapshots were an unsupported 'feature' in LVM2 though so this wasn't a production system. Snapshots had been so useful in LVM1, I still don't understand why they had to break it in LVM2, seems like a step back to me. Still, if the LVM crew have fix0red it I'll give it another go on a sacrificial server... I had problems when using LVM2 in CentOS/RHEL 4.2 or so, but in 4.5 and 5 it is stable as long as you have 256 Mbyte RAM or more (I have one machine with 128 Mbyte RAM running CentOS 4.5, and that one had a kernel panic once every 6 months or so due to LVM2 snapshots -- I do not use snapshots anymore on that machine since last time it crashed about 3 weeks ago. Most of my other servers take snapshots twice a day (as "cheap backup" during noon, and as quiet filesystem for nightly Amanda backups), and have no problems with it.
Re: Backing up VMware-VMs
Stefan G. Weichinger wrote: Patrick M. Hausen schrieb: So if you want to backup/copy an entire VM with the guarantee of consistent hard disk state, you need to shut it down. Copying a multi gigabyte virtal disk file is bound to take quite some time. So you need to power down your virtual machine for what can amount to hours. What about combining it with LVM-snapshots? Are LVM snapshots working properly now? The last few times I tried it (several months ago) it was a total disaster and not something I'd want to risk even attempting on a virtual machine. host your VMs on a LV at backup-time you shutdown the VM(s), generate a LV-snapshot, power on the VM(s) again (nearly as fast as a simple reboot ...), amdump the LV-snapshot . I have that opportunity here in the given case, everything VM-related hosted on LVM. (Yes, this only works on Linux, all you Solaris/etc people ;-) ) Stefan
use of multiple tape drives
Hi there, We have just acquired an LTO3 Ultrium drive but we still have a tape robot with AIT tape drive. I am wondering if there is a way to use the AIT drive together with the LTO drive in some useful fashion. I doubt that RAIT would work as the capacity of the tapes is so different, but I'm curious if there is a way to store some kind of error correction/parity data on the AIT tapes? Thanks!
Re: amverifyrun getting stuck
Gene Heskett wrote: > On Tuesday 31 October 2006 14:12, Steve Wray wrote: >> Dominik Schips wrote: >>> Hello, >>> >>> Am Dienstag, den 31.10.2006, 08:12 +1300 schrieb Steve Wray: >>>> Hi there, >>>> My amanda backup scripts do an amverifyrun after every run. >>>> >>>> One of our backup sets is on a tape changer. >>> Sorry for the questinon, but I also have a tape changer. >>> >>> How do you do the amverifyrun after the backup if the backup used 2 >>> tapes? >> It never uses 2 tapes. >> > At your place maybe, but there is not a limit other than practical, to the > number of tapes that can be set in "runtapes". *sigh* ok then, interpret me as saying 'on our installation it never uses 2 tapes'. Thats what I meant, ie I can't offer advice as it never uses 2 tapes (for me).
Re: amverifyrun getting stuck
Gene Heskett wrote: > On Tuesday 31 October 2006 14:12, Steve Wray wrote: >> Dominik Schips wrote: >>> Hello, >>> >>> Am Dienstag, den 31.10.2006, 08:12 +1300 schrieb Steve Wray: >>>> Hi there, >>>> My amanda backup scripts do an amverifyrun after every run. >>>> >>>> One of our backup sets is on a tape changer. >>> Sorry for the questinon, but I also have a tape changer. >>> >>> How do you do the amverifyrun after the backup if the backup used 2 >>> tapes? >> It never uses 2 tapes. >> > At your place maybe, but there is not a limit other than practical, to the > number of tapes that can be set in "runtapes". *sigh* ok then, interpret me as saying 'on our installation it never uses 2 tapes'. Thats what I meant, ie I can't offer advice as it never uses 2 tapes (for me).
Re: amverifyrun getting stuck
Dominik Schips wrote: > Hello, > > Am Dienstag, den 31.10.2006, 08:12 +1300 schrieb Steve Wray: >> Hi there, >> My amanda backup scripts do an amverifyrun after every run. >> >> One of our backup sets is on a tape changer. > > Sorry for the questinon, but I also have a tape changer. > > How do you do the amverifyrun after the backup if the backup used 2 > tapes? It never uses 2 tapes. > Do you have a special script for this or is this possible with > amverifyrun by default? > How can I check my tapes after a backup? > > I was thinking I can do this with a script grapping for the last used > tapes in the disklist file. > But if someone else know a better solution, please let me know. amverifyrun is supposed to 'know' which tape was used last based on the log files. Looking at the man page again though I have to say I am a little dubious. It seems awfuly lacking in clarity or, well, any information at all really. > Thank you for every help. > >> Recently, amverifyrun appears to have been getting 'stuck', verifying >> the same tape over and over again regardless of which tape was actually >> used in the last backup run. >> >> Most recently its become stuck on a tape which has not yet been used in >> amanda (labelled, never written to) resulting in some very amusing output... >> >> Any suggestions on how to unstick it? >> >> Thanks! > > Best regards > > Dominik Schips >
amverifyrun getting stuck
Hi there, My amanda backup scripts do an amverifyrun after every run. One of our backup sets is on a tape changer. Recently, amverifyrun appears to have been getting 'stuck', verifying the same tape over and over again regardless of which tape was actually used in the last backup run. Most recently its become stuck on a tape which has not yet been used in amanda (labelled, never written to) resulting in some very amusing output... Any suggestions on how to unstick it? Thanks!
Re: Problems with gtar
Paul Yeatman wrote: > ->>In response to your message<<- > --received from Jean-Louis Martineau-- >> >>> I have been seeing the same thing for about two weeks. >>> [snip] > This is all with Debian Etch. > > Now I'm experiencing similar problems again as explained in this thread > but with Fedora 5 boxes. > > I find it a bit bothersome that not just one but two linux > distributions are releasing packages of incompatible versions of tar > and amanda. I suppose this is reasonable considering the complexity of > the issue and that both are progressive versions of the distributions? It may be a Good Idea to make certain that this issue is brought to the attention of the Debian package maintainer for amanda, hence the CC to Bdale Garbee. If this *isn't* fixed before Etch freezes (some time in December?) its unlikely that it will *ever* be fixed (since its not a security issue) and will remain broken until the next release of Debian. Thanks!
Re: tape order
Jon LaBadie wrote: > On Tue, Oct 17, 2006 at 11:44:53AM -0400, Steven Settlemyre wrote: >> I have 24 tapes and a 8 tape changer. For some reason, it is going >> 13->16->15->14->17. How can I fix this? can i just force it to take 14 >> after 13 by only having 14 in there when it's expecting 16? My tapecycle >> is 10. > > As Michael suggests, your human ordering is VERY likely > to get out of sequence. Best to forget about it. This has been bugging me for years. It makes daily off-site storage of backup tapes problematic; the data-vault outfits typically need to know 24 hours in advance which tape they should bring to your site as they need to plan the route for their van. If you request that they send you a tape at 'short notice' they will typically charge extra for this. I've been looking for a way to get amanda to try to predict which tape it will want next in good time (a schedule for the next 3 days or so would be ideal). No luck so far...
Re: Why Oh Why only THIS DLE is giving me those timeout problems ?
Geert Uytterhoeven wrote: > On Tue, 30 Aug 2005, Graeme Humphries wrote: > >>Guy Dallaire wrote: >> >>>Yes, thanks. I know about hard links. But how would it impact the size >>>or performance of my backups ? >>> >> >>Well, if a file is hard linked multiple times, it'll be backed up multiple >>times. Therefor, a filesystem with tons of hard links will take a really long >>time to back up. :) > > > Fortunately tar is sufficiently smart to back it up only once. > > Usually the problem with lots of hard links is not the data timeout value, but > the estimate timeout value, as I found out the hard way[*]. We've been having similar problems with estimates timeing out. I just ran the 'find' command given in an earlier email and found a grand total of 607 hard links on the entire filesystem. What I'm wondering is, does 607 count as 'lots' WRT amanda estimate timeouts?
amanda through openbsd firewall?
Hi there, I know that on a Linux firewall through which amanda traffic is routed or natted, one needs to load the appropriate modules (ip_conntrack_amanda, ip_nat_amanda). I am wondering what we will need to do to ensure that amanda traffic can pass/nat through an openbsd firewall with no problems? Thanks!
somewhere other than /tmp/amanda
Hi there, we'd like it if amanda would use /var/tmp/amanda instead of /tmp/amanda Ideally, we'd do this without rebuilding the debian package. I've noticed this in the examples/config.site and I'm wondering if I set this to /var/tmp/amanda in my amanda.conf will this change all of amanda's use of /tmp/amanda or just 'debug' output? # DEBUGGING=/var/amanda/debug Thanks!
Re: dumpcycle versus noinc
Peter Kunst wrote: Hi Steve, Steve Wray wrote: Gaby vanhegan wrote: Hello again! Whilst setting up a full dump configuration to do monthly full dumps to tape, I'm torn between either: strategy "noinc" or dumpcycle 0 To do a full dump. What's the difference here? Does it matter which one I use? Heres my reading of what I've experienced from experimenting with these; Suppose that a filesystem has grown too large to fit on the tape. noinc will simply not dump that filesystem at all on that run. dumpcycle 0 will fall back to incremental for that filesystem. so when will amanda do a level 0 for that DLE, if that result for dumpcycle 0 would be true ? in normal cases, amanda would simply say "dumps too large" or something like that. This is where amanda starts 'optimising' which tape it wants next based on when it last did a full dump and when the incrementals happened. If I understand it right, it would try to schedule the zero-level for the next run. If again it couldn't fit, it would fall back some more. I was just mentioning this because having a backup completely *fail* when using noinc can be very unfortunate :-/ which amanda version do we speak about ? its debian sarge, and dpkg -s tells me; 2.4.4p3-2 ...i'm just testing the spanning patch. this would be another testcase. so, thanks's for your hint :-)
Re: dumpcycle versus noinc
Gaby vanhegan wrote: Hello again! Whilst setting up a full dump configuration to do monthly full dumps to tape, I'm torn between either: strategy "noinc" or dumpcycle 0 To do a full dump. What's the difference here? Does it matter which one I use? Heres my reading of what I've experienced from experimenting with these; Suppose that a filesystem has grown too large to fit on the tape. noinc will simply not dump that filesystem at all on that run. dumpcycle 0 will fall back to incremental for that filesystem.
unknown service: noop?
Hi there, we just had an inexplicable hiccup in our (recently configured) backup cycle. Night before last, the backup for this host went perfectly. Last night, it didn't come back with its estimates. So far as I can tell, there were no changes to the amanda config on this host in between these. The client concerned is running debian 'woody'. Looking at the /tmp/amanda/ logfiles on the client in question, I find something I've not seen before. Any ideas would be appreciated! Thanks [snip] got packet: Amanda 2.4 REQ HANDLE 004-B0080708 SEQ 1110921966 SECURITY USER backup SERVICE noop OPTIONS features=feff9ffe0f; sending nack: Amanda 2.4 NAK HANDLE 004-B0080708 SEQ 1110921966 ERROR unknown service: noop amandad: pid 16404 finish time Wed Mar 16 10:26:02 2005
predicting tapes
I was wondering if there was any way to predict, say a few days in advance, which tapes amanda would want to use? Thanks!
Re: tuning dumpcycle, runspercycle, and tapecycle
David Newman wrote: On Sun, 13 Feb 2005, Gene Heskett wrote: On Sunday 13 February 2005 12:02, David Newman wrote: Greetings. For backups to a server with one DLT-IV drive, I would like to change the tape once per week. During the week, I would like to do one full backup on day 1, and incremental backups on days 2-5. [snip] Yes, because it thinks its over-writing the last full level 0 with each new backup. This isn't so good; again, I'm looking for one full dump and four incremental dumps on each tape. (FWIW, the server in question is at a remote location and we can't get to it every day.) Jon LaBadie's post on the Amanda top 10 list suggests that Amanda is not the right tool for this. Is there some way to do this using Amanda? If not, any recommendations for alternatives? Not exactly an answer to your question, but its a familiar problem; I know 'stuff' about the backups and the machines that are being backed up. I know 'stuff' about rate of file changes and filesystem growth. How do I explain this to amanda? Eg; Cases where zero-level backups are virtually guaranteed to fit onto a tape... I've been experimenting with 'stratecy noinc' (IIRC the spelling of that). Unfortunately, I've found that when, in rare cases, the zero-level won't fit I sometimes see messages like 'cannot switch to incremental' and knock me down with a feather but it doesn't back anything up at all for that DLE. What I'd like to know is how to tell it "always do a full dump except when theres not enough room and then -- and *only* then -- revert to an incremental"
Re: parse of reply message failed?
Steve Wray wrote: Hi there, I've been reading this thread; http://www.mail-archive.com/amanda-users@amanda.org/msg27491.html which is interesting because we've been experiencing a very similar problem since upgrading 2.6.8 to 2.6.9 on a small cluster here. The amanda connection tracking is all built into the kernel, not modules; but it was like that when the backups worked. CONFIG_PACKET_MMAP was disabled in both the amanda-working and non-working kernels. In fact, there don't seem to be a lot of differences between these kernels. I'll attach the diff here in case it helps! The ones prefixed wth '-' is the non-amanda-working config, the ones with the '+' are the amanda-working config. I'm hoping that we can get this going without having to install a new kernel... Any ideas? Following up to my own post, it turns out that with kernel 2.6.8 the interaction between the amanda 2.4.2p2 'server' (in debian woody) and the amanda 2.4.4p3 client (in debian sarge) works, whereas when the client is running 2.6.9 this interaction breaks down in the manner described. I found a woody backport of amanda 2.4.4p3 here; http://www.localguru.de/debian/woody/amanda/ and applied this to the backup server; everything now works.
parse of reply message failed?
Hi there, I've been reading this thread; http://www.mail-archive.com/amanda-users@amanda.org/msg27491.html which is interesting because we've been experiencing a very similar problem since upgrading 2.6.8 to 2.6.9 on a small cluster here. The amanda connection tracking is all built into the kernel, not modules; but it was like that when the backups worked. CONFIG_PACKET_MMAP was disabled in both the amanda-working and non-working kernels. In fact, there don't seem to be a lot of differences between these kernels. I'll attach the diff here in case it helps! The ones prefixed wth '-' is the non-amanda-working config, the ones with the '+' are the amanda-working config. I'm hoping that we can get this going without having to install a new kernel... Any ideas? Thanks! --- config-2.6.9-dell750 2004-12-08 23:00:43.0 +1300 +++ config-2.6.8.1-dell750 2004-09-24 11:18:54.0 +1200 @@ -1,13 +1,10 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.9-dell750 -# Wed Dec 8 23:00:43 2004 # CONFIG_X86=y CONFIG_MMU=y CONFIG_UID16=y CONFIG_GENERIC_ISA_DMA=y -CONFIG_GENERIC_IOMAP=y # # Code maturity level options @@ -18,7 +15,6 @@ # # General setup # -CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y # CONFIG_POSIX_MQUEUE is not set @@ -39,8 +35,6 @@ CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set -CONFIG_SHMEM=y -# CONFIG_TINY_SHMEM is not set # # Loadable module support @@ -99,7 +93,7 @@ # CONFIG_HPET_TIMER is not set CONFIG_SMP=y CONFIG_NR_CPUS=8 -CONFIG_SCHED_SMT=y +# CONFIG_SCHED_SMT is not set # CONFIG_PREEMPT is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y @@ -133,7 +127,6 @@ # Power management options (ACPI, APM) # # CONFIG_PM is not set -# CONFIG_PM_DEBUG is not set # # ACPI (Advanced Configuration and Power Interface) Support @@ -149,7 +142,6 @@ CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set -CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y @@ -272,6 +264,7 @@ # CONFIG_BLK_DEV_IDEDMA_FORCED is not set CONFIG_IDEDMA_PCI_AUTO=y # CONFIG_IDEDMA_ONLYDISK is not set +CONFIG_BLK_DEV_ADMA=y # CONFIG_BLK_DEV_AEC62XX is not set # CONFIG_BLK_DEV_ALI15X3 is not set # CONFIG_BLK_DEV_AMD74XX is not set @@ -345,8 +338,7 @@ # CONFIG_SCSI_AIC79XX is not set # CONFIG_SCSI_DPT_I2O is not set # CONFIG_SCSI_IN2000 is not set -# CONFIG_MEGARAID_NEWGEN is not set -# CONFIG_MEGARAID_LEGACY is not set +# CONFIG_SCSI_MEGARAID is not set CONFIG_SCSI_SATA=y # CONFIG_SCSI_SATA_SVW is not set CONFIG_SCSI_ATA_PIIX=y @@ -406,7 +398,6 @@ # CONFIG_MD_LINEAR is not set # CONFIG_MD_RAID0 is not set CONFIG_MD_RAID1=y -CONFIG_MD_RAID10=y CONFIG_MD_RAID5=y # CONFIG_MD_RAID6 is not set # CONFIG_MD_MULTIPATH is not set @@ -456,7 +447,6 @@ # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set -# CONFIG_INET_TUNNEL is not set # # IP: Virtual Server Configuration @@ -499,8 +489,6 @@ # IP: Netfilter Configuration # CONFIG_IP_NF_CONNTRACK=y -# CONFIG_IP_NF_CT_ACCT is not set -# CONFIG_IP_NF_CT_PROTO_SCTP is not set CONFIG_IP_NF_FTP=y CONFIG_IP_NF_IRC=y CONFIG_IP_NF_TFTP=y @@ -525,15 +513,8 @@ CONFIG_IP_NF_MATCH_STATE=y CONFIG_IP_NF_MATCH_CONNTRACK=y CONFIG_IP_NF_MATCH_OWNER=y -CONFIG_IP_NF_MATCH_ADDRTYPE=y -CONFIG_IP_NF_MATCH_REALM=y -# CONFIG_IP_NF_MATCH_SCTP is not set -# CONFIG_IP_NF_MATCH_COMMENT is not set CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y -CONFIG_IP_NF_TARGET_LOG=y -CONFIG_IP_NF_TARGET_ULOG=y -CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_IP_NF_NAT=y CONFIG_IP_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y @@ -552,8 +533,13 @@ CONFIG_IP_NF_TARGET_DSCP=y CONFIG_IP_NF_TARGET_MARK=y CONFIG_IP_NF_TARGET_CLASSIFY=y -# CONFIG_IP_NF_RAW is not set +CONFIG_IP_NF_TARGET_LOG=y +CONFIG_IP_NF_TARGET_ULOG=y +CONFIG_IP_NF_TARGET_TCPMSS=y # CONFIG_IP_NF_ARPTABLES is not set +# CONFIG_IP_NF_RAW is not set +CONFIG_IP_NF_MATCH_ADDRTYPE=y +CONFIG_IP_NF_MATCH_REALM=y # # SCTP Configuration (EXPERIMENTAL) @@ -737,7 +723,6 @@ CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set -# CONFIG_SERIO_RAW is not set # # Input Device Drivers @@ -777,6 +762,7 @@ CONFIG_UNIX98_PTYS=y CONFIG_LEGACY_PTYS=y CONFIG_LEGACY_PTY_COUNT=256 +# CONFIG_QIC02_TAPE is not set # # IPMI @@ -934,27 +920,11 @@ # # Network File Systems # -CONFIG_NFS_FS=m -CONFIG_NFS_V3=y -CONFIG_NFS_V4=y -# CONFIG_NFS_DIRECTIO is not set -CONFIG_NFSD=y -CONFIG_NFSD_V3=y -# CONFIG_NFSD_V4 is not set -CONFIG_NFSD_TCP=y -CONFIG_LOCKD=y -CONFIG_LOCKD_V4=y -CONFIG_EXPORTFS=y -CONFIG_SUNRPC=y -CONFIG_SUNRPC_GSS=m -CONFIG_RPCSEC_GSS_KRB5=m -# CONFIG_RPCSEC_GSS_SPKM3 is not set -CONFIG_SMB_FS=m -# CONFIG_SMB_NLS_DEFAULT is not set -CONFIG_CIFS=m -# CONFIG_CIFS_STATS is not set -# CONFIG_CIFS_XATTR is not set -# CONFIG_CIFS_POSIX is not set +# CONFIG_
Re: amanda article on sun.com
Its interesting that they don't configure it to use gnu tar... and so far as I can tell, none of the config that they give would use gnutar to backup Solaris boxes. On Fri, 14 Nov 2003 16:02, Galen Johnson wrote: > Jon LaBadie wrote: > >Recently posted to the "Big Admin" > >section of Sun's website is a pretty > >long article on setting up amanda. > > > >Haven't read it yet, so I'm unable > >to comment on its content. > > > >http://enews.sun.com/CTServlet?id=47250049-814460813:1068762499806 > > > > or > > > >http://www.sun.com/bigadmin/features/articles/backups_amanda.html > > Not a bad article...very straight-forward. It even walks you through > creating a package for Solaris. The only thing I might have recommended > different would've been to split out the tapetype, dumptypes and > interfaces into separate files and 'include'd them in the main config > file rather than keeping a monolithic conf file. That would make for > cleaner config files since the info you would tend to reuse between > configs would be in a central location...plus it would allow you to > update the files once instead of however many config files you had...but > that's just me... > > gonna add this link to my Amanda links. > > =G=
Re: configure bug or misunderstanding?
I unpacked the tarball and ran the ./configure, didn't work out. Second time I ran ./configure after changing $PATH. No distclean at all. Why would that make the difference? from 'INSTALL'; 5. You can remove the program binaries and object files from the source code directory by typing `make clean'. To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'. There is also a `make maintainer-clean' target, but that is intended mainly for the package's developers. If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution. Sounds like distclean is only required after a ./configure has been run. Presumably the pristine sources don't have any of that 'trash' in them? Also, its very interesting, given the above, that it all went so swimmingly well after merely changing $PATH... On Thu, 13 Nov 2003 06:24, Paul Bijnens wrote: > Steve Wray wrote: > > Finally I seem to have figured it out; > > > > If $PATH has another version of tar which would be found > > before the gnu tar, even though one explicitly puts it on the > > configure commandline, the #ifdef's in runtar.c don't appear > > to pick it up and hence its not compiled in; all that gets compiled > > in are the messages bitching about not having gnu tar. > > Don't think so. IMHO. > > > Or something like that. > > > > By setting my $PATH at configure time so that /usr/local/bin > > was at the front, I got a build on Sloarsis which works with > > gnu tar! > > > > Bug in the configure script? Or am I misunderstanding something? > > Forgot to run "make distclean" before you "./configure"?
configure bug or misunderstanding?
Hi all! I've been having trouble getting amanda to support gnu tar on Solaris boxes. What I discovered was that even though I explicitly set the path to gnu tar at configure time; ./configure --with-gnutar=/usr/local/bin/tar and even though amanda appeared to configure for gnu tar (judging from the config log file and the debugging output where it actually shows the path I gave configure) it refused to recognise it, claiming that it wasn't a gnu tar. Finally I seem to have figured it out; If $PATH has another version of tar which would be found before the gnu tar, even though one explicitly puts it on the configure commandline, the #ifdef's in runtar.c don't appear to pick it up and hence its not compiled in; all that gets compiled in are the messages bitching about not having gnu tar. Or something like that. By setting my $PATH at configure time so that /usr/local/bin was at the front, I got a build on Sloarsis which works with gnu tar! Bug in the configure script? Or am I misunderstanding something? Cheers!
