Re: amcheck-ing root files
On Thu, Nov 29, 2018 at 03:06:17PM +0100, Stefan G. Weichinger wrote: > > I know it was topic here already ... long ago, maybe someone knows a > solution to this already: > > I have files owned by root that get correctly amdump-ed but throw ugly > errors/warnings when I run my daily amcheck via cron (to remind admins to > change tapes if necessary). > > So I get for example: > > Amanda Backup Client Hosts Check > > HOST backup ERROR: backup: Could not access samba_DC_meta > (/root/dc_stuff/backups): Permission denied > > but the actual backup works > > Can I get rid of that? This floods my inboxes and is noise ... Are the directories not group root and readable/executable by group? Maybe make the amanda a secondary member of the group. Use acl's to specifically let amanda user access. jl -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: amvault configoptions failing
Hi Nathan,
Thanks for the response!
> On Nov 28, 2018, at 7:02 PM, Nathan Stratton Treadway
> wrote:
>
> On Wed, Nov 28, 2018 at 16:54:08 -0800, Chris Deiss wrote:
>> Hi,
>>
>> Under previous version of amvault, I was able to do this:
>>
>>
>> amvault -o diskfile=/usr/local/etc/amanda/daily/disklist.drs . . .
>>
>>
>> and it worked great! Was an excellent was to vault only a subset of DLEs to
>> special media/storage.
>
> What version were you using when this worked?
I have two active AMANDA servers, one running 3.3.6, the other at 3.5.1. The
“-o diskfile=...” option works as desired in 3.3.6.
>> It???s not working under 3.5.1, instead it defaults to the disklist
>> parameter defined in amanda.conf. Other options like '-o tapecycle=2'
>> _do_ work with the latest amvault, so it???s not a total failure to
>> modify the config, just appears to be a problem which includes the
>> ???disklist' parameter.
>
> There were some fixes to config-parameter processing in the versions
> leading up to v3.5.1. Off hand I wouldn't expect those changes to cause
> the symptoms you describe, but it's possible. I will try to look at the
> code for amvault and see if anything obvious is going on.
>
> I take it there is no error message?
Nope, no error. Instead, when I specify “-o
diskfile=/usr/local/etc/amanda/daily/disklist.drs“ on the command-line under
3.5.1, amvault vaults all DLEs in the file specified by the default ‘diskfile’
parameter defined in amanda.conf (that file is
"/usr/local/etc/amanda/daily/disklist").
> What happens if you specify a path to a non-existant file, or something
> like that?
In that case (e.g. “disklist.foo" which doesn’t exist), it produces "errors
processing disklist” and exits.
> Depending on what I find in the code for amvault, it might help narrow
> in on the problem to have the full command line you are trying to run,
> as well as a bit more information on what list of DLEs you want to vault
> and which ones are actually getting vaulted instead….
On 3.3.6, I’m exec’ing:
`amvault -o tapedev=vtape-fs1 -o tapetype=LTO6-2Gbfc -o tapecycle=1 -o
diskfile=/usr/local/etc/amanda/daily/disklist.drs \
--autolabel any --latest-fulls --label-template "drs-tape-%" --dst-changer
tapelib2 daily`
On 3.5.1, I’m exec'ing:
`amvault -o tapedev=vtape-fs1 -o tapecycle=2 -o
diskfile=/usr/local/etc/amanda/daily/disklist.drs --src-storage=daily \
--dest-storage s3-vault --latest-fulls daily`
When I issue that, amvault vaults all DLEs in the default ‘diskfile' file
("/usr/local/etc/amanda/daily/disklist”), which BTW contains the line:
includefile disklist.drs
That way, a normal amdump run includes all DLEs, both the ones I want vaulted
offsite (listed in “disklist.drs”) and all the rest (listed in the default file
“disklist”).
Another aside: it doesn’t seem to matter whether I specify the full path of the
diskfile file or not . . . presumably AMANDA commands prepend the path at which
amanda.conf resides if a relative filename is given? All of my diskfile files
are in the same directory as amanda.conf.
>> If anyone has alternative ways to vault a subset of DLEs, or an
>
>
> Well, amvault does accept a number of parameters and arguments to
> control what gets vaulted, but I guess those might not be sufficient if
> your disklist.drs list is long and arbitrary…
Yes, in this use-case, we’re trying to send an arbitrary set of DLE’s off-site
for DRS, and the DLEs span multiple hosts but not all filesystems on any given
host.
>
>> effective way to report a bug, please let me know.
>
> (This mailing list is currently the best way to report a bug...)
>
> 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: amcheck-ing root files
On Thu, Nov 29, 2018 at 15:06:17 +0100, Stefan G. Weichinger wrote: > > I have files owned by root that get correctly amdump-ed but throw > ugly errors/warnings when I run my daily amcheck via cron (to remind > admins to change tapes if necessary). > > So I get for example: > > Amanda Backup Client Hosts Check > > HOST backup ERROR: backup: Could not access samba_DC_meta > (/root/dc_stuff/backups): Permission denied > > but the actual backup works > > Can I get rid of that? This floods my inboxes and is noise ... Which backup program is used for this DLE? (Which version of Amanda?) What are the ownership and permissions on /root, /root/dc_stuff, and /root/dc_stuff/backups directories? (I am trying to remember the details of this situation, but for example it might be significant if is it just the final level of the path that is unreadable, or if the intermediate directories are also.) (On the client machine in qustion) is the Unix user amanda runs under a member of any Unix groups? 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: amvault configoptions failing
On Wed, Nov 28, 2018 at 22:02:30 -0500, Nathan Stratton Treadway wrote: > Depending on what I find in the code for amvault, it might help narrow > in on the problem to have the full command line you are trying to run, > as well as a bit more information on what list of DLEs you want to vault > and which ones are actually getting vaulted instead > Looking at the code (in amvault v3.5.1 as installed from the amanda_3.5.1-4_WIP_4 Debian source package), amvault does apear to process configuration overrides on the command line before trying to load the diskfile, as one would expect. And when I try running amvault specifying an invalid diskfile name I get a run-time error, while a valid file name does not: == # su backup -c "amvault -odiskfile=asdf TestBackup dummyhost" errors processing disklist # su backup -c "amvault -odiskfile=/dev/null TestBackup dummyhost" No dumps to vault =- So it seems like the basic processing of the -odiskfile= command-line option hasn't changed in v3.5.1 Maybe some broader aspect of amvault's functioning has changed between 3.5 and your earlier versions? 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
amcheck-ing root files
I know it was topic here already ... long ago, maybe someone knows a solution to this already: I have files owned by root that get correctly amdump-ed but throw ugly errors/warnings when I run my daily amcheck via cron (to remind admins to change tapes if necessary). So I get for example: Amanda Backup Client Hosts Check HOST backup ERROR: backup: Could not access samba_DC_meta (/root/dc_stuff/backups): Permission denied but the actual backup works Can I get rid of that? This floods my inboxes and is noise ...
