Re: lev 0 FAILED [data timeout]

2019-05-27 Thread Tom Robinson 
On Tue, 14 May 2019 at 22:14, Nathan Stratton Treadway 
wrote:

Hi Nathan,

Thanks for you reply and help.

On Mon, May 13, 2019 at 09:59:13 +1000, Tom Robinson wrote:
> > I have a weekly backup that backs-up the daily disk based backup to tape
> (daily's are a separate
> > amanda config).
>
> (As a side note: if you are running Amanda 3.5 you might consider using
> vaulting to do this sort of backup, so that Amanda knows about the
> copies that are put onto the tape.)
>
>
Unfortunately, no. We're on 3.3.3. Considering updating that on an Illumos
variant (OmniOS CE)... looks like I may have to compile a custom package.
Originally I installed a CSW package but I haven't seen any updates for
that as of yet.



> > Occasionally on the weekly backup a DLE will fail to dump writing only a
> 32k header file before
> > timing out.
> >
> > I can't seem to identify the error when looking in logging. Has anyone a
> few clues as to what to
> > look for?
> >
> > FAILURE DUMP SUMMARY:
> >   monza /data/backup/amanda/vtapes/daily/slot9 lev 0  FAILED [data
> timeout]
> >   monza /data/backup/amanda/vtapes/daily/slot9 lev 0  FAILED [dumper
> returned FAILED]
> >   monza /data/backup/amanda/vtapes/daily/slot9 lev 0  FAILED [data
> timeout]
> >   monza /data/backup/amanda/vtapes/daily/slot9 lev 0  FAILED [dumper
> returned FAILED]
>
> [...]
> >
> > A while ago I changed estimate to calcsize as the estimates were taking
> a very long time and all
> > daily slots are a know maximum fixed size. I thought it might help with
> time outs. Alas not.
>
> Amanda's estimate timeouts are separate from data timeouts; changing to
> calcsize will help with the former but not the latter.  (Note that if
> the slots are really a known size, using "server" estimate is even
> faster than "calcsize", since it then just uses the size from the
> previous run and doesn't read through the current contents of the DLE
> directory to add up the sizes.)
>
> You can control the data timeouts with the "dtimeout" parameter in
> amanda.conf.  Just try bumping that up so that you are sure it's longer
> than a dump actually takes.
>

My dtimeout was set to half an hour. After I check some logs and found the
average dump time for my DLEs was around 55 minutes I've adjusted the
dtimeout to 1hour. The last run went well so I'm waiting on the next run to
see if it's consistent.


> (The sendbackup..debug and runtar..debug client log
> files should confirm that the GNU tar is running without error but then
> unable to write to the output pipe on the server side.  In the server
> logs, I think the 'data timeout reached, aborting'-sort of message would
> be found in the dumper..debug file for that run...)
>

yes, that helps knowing where to look!

I am getting a new issue now which is annoying but not a show stopper. I
think I will have to revisit my threshold settings to fix this but maybe
you can offer some insight.

I have a tape robot and the following settings in amanda.conf

runtapes 3
flush-threshold-dumped 100
flush-threshold-scheduled 100
taperflush 100
autoflush yes

There is enough room for all the data to go on three tapes yet after the
amdump run is complete only two tapes are written and I am left to flush
the remaining dumps to tape manually.

I think it's because I'm trying to get a whole tape's worth of data before
writing to tape. Is my thinking correct?

What I'd like to do is make sure there's a tape's worth of data to write to
the first two tapes in turn and then dump all remaining backup data to tape
three (this will not be a complete tapes worth).

Should I be setting taperflush as follows to achieve this?

taperflush 0

Kind regards,
Tom

Re: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Gene Heskett 
On Monday 27 May 2019 05:32:52 pm Nathan Stratton Treadway wrote:

> On Mon, May 27, 2019 at 16:48:38 -0400, Gene Heskett wrote:
> > Fixed that, restarted xinetd, amcheck is happy.
> >
> > Step into /GenesAmandaHelper-0.61 and type ./backup.sh Daily" and
> > gkrellm acts like its going to do it,
>
> Yay!
>
> Let us know how the dump goes, in the end...

getting close. gkrellm is showing a couple hundred megs a second being 
read from sda, and being stuffed into sdd. But I think its used all of 
slot1, and has not started on slot2.  No, not yet, its still making 2GB 
gzip smunched pieces out of coyote/gene/Downloads, 8 of them so far.

I'm gonna send this, as its been munching along for over 4 hours, but its 
not finished yet, its put 47GB in each of the two vtapes it was allowed, 
and has another 25GB piled up in dumps.  So there'll need to be a flush 
to at least one more vtape by the time it is done.  Looking promising 
Nathan.  Thanks.  I'll set it up in the amanda crontab tomorrow if this 
looks ok.

> > gene@coyote:~$ sudo apt install netstat
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > E: Unable to locate package netstat
>
> (The netstat command is in the "net-tools" package.  At this point you
> don't need it, but it can be a handy tool to have when you need to
> find out whether or not xinetd has a particular port open or otherwise
> debug network-port activity.)
>
>   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 2019 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: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Nathan Stratton Treadway 
On Mon, May 27, 2019 at 16:48:38 -0400, Gene Heskett wrote:
> 
> Fixed that, restarted xinetd, amcheck is happy.
> 
> Step into /GenesAmandaHelper-0.61 and type ./backup.sh Daily" and gkrellm 
> acts like its going to do it,
> 

Yay!

Let us know how the dump goes, in the end...


> gene@coyote:~$ sudo apt install netstat
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package netstat

(The netstat command is in the "net-tools" package.  At this point you
don't need it, but it can be a handy tool to have when you need to find
out whether or not xinetd has a particular port open or otherwise debug
network-port activity.)

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: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Charles Curley 
On Mon, 27 May 2019 16:48:38 -0400
Gene Heskett  wrote:

> gene@coyote:~$ sudo apt install netstat
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: Unable to locate package netstat

For debian et al. users: apt-file is your friend.

charles@hawk:~/projects/amanda$ apt-file search netstat | grep /netstat$
munin-plugins-core: /usr/share/munin/plugins/netstat
net-tools: /bin/netstat
charles@hawk:~/projects/amanda$ 

So I would install net-tools.

-- 
"When we talk of civilization, we are too apt to limit the meaning of
the word to its mere embellishments, such as arts and sciences; but
the true distinction between it and barbarism is, that the one
presents a state of society under the protection of just and
well-administered law, and the other is left to the chance government
of brute force."
- The Rev. James White, Eighteen Christian Centuries, 1889
Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB
https://charlescurley.com

Re: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Gene Heskett 
On Monday 27 May 2019 03:06:33 pm Nathan Stratton Treadway wrote:

> On Mon, May 27, 2019 at 14:37:31 -0400, Gene Heskett wrote:
> > It does now, and amcheck is happy with everything but coyote,
> > connection refused.
>
> Coyote is the Amanda-server machine itself, right?
>
> What's your current /etc/xinetd.d/amanda look like?  (And have you
> restarted/reloaded xinetd since that file was last changed?)
>
# default: on
#
# description: Amanda services for Amanda server and client.
#

service amanda
{
disable = no
flags   = IPv4
socket_type = stream
protocol= tcp
wait= no
user= amanda
group   = backup
groups  = yes
server  = /usr/local/lib/amanda/amandad
server_args = -auth=bsdtcp amdump amindexd amidxtaped
}

And its been restarted, but the path above is wrong, lib s/b libexec.  

Fixed that, restarted xinetd, amcheck is happy.

Step into /GenesAmandaHelper-0.61 and type ./backup.sh Daily" and gkrellm 
acts like its going to do it, but its only got 2 vtapes to play with, so 
I may not have room enough, in which case it will leave the extras 
in /usr/dumps, and a run of flush.sh will handle the rest (maybe).

> "connection refused" sounds like xinetd is not even listening on that
> port.  What does
>   $ netstat -a | grep amanda
> show?

Command not found. And:

gene@coyote:~$ sudo apt install netstat
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package netstat

> Check your syslog file for error messages from xinetd.
>
None now. I think I'll close for around 3 hours because it has several 
tens of gigabytes to handle.  Thanks you very much Nathan.

>   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 2019 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: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Nathan Stratton Treadway 
On Mon, May 27, 2019 at 14:37:31 -0400, Gene Heskett wrote:
> It does now, and amcheck is happy with everything but coyote, connection 
> refused. 

Coyote is the Amanda-server machine itself, right?

What's your current /etc/xinetd.d/amanda look like?  (And have you
restarted/reloaded xinetd since that file was last changed?)

"connection refused" sounds like xinetd is not even listening on that
port.  What does
  $ netstat -a | grep amanda
show?

Check your syslog file for error messages from xinetd.

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: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Gene Heskett 
On Monday 27 May 2019 12:36:51 pm Nathan Stratton Treadway wrote:

> On Mon, May 27, 2019 at 11:57:29 -0400, Gene Heskett wrote:
> > next pass at amcheck Daily got this:
> >
> > manda@coyote:/root$ /usr/local/sbin/amcheck Daily
> > Amanda Tape Server Host Check
>
> [...]
>
> > Amanda Backup Client Hosts Check
> > 
> > ERROR: lathe: selfcheck request failed: amcheck-clients: error
> > [exec /usr/local/libexec/amanda/ambind: Permission denied]
>
> [...]
>
> > amanda@coyote:/root$ ls -l /usr/local/libexec/amanda/ambind
> > -rwsr-x--- 1 root backup 26840 May 27
> > 11:11 /usr/local/libexec/amanda/ambind
> >
> > Is that correct? If wrong for owner root, whats the fix, which we'll
> > need
>
> Yes, that is correct.  This is a setuid binary (note the "s" in
> "rwsr-x") and is intended to run as root (and thus it needs to be
> owned by root).
>
> > This is /etc/group now
> >
> > amanda@coyote:/root$ grep amanda /etc/group
> > mail:x:8:gene,amanda
> > amanda:x:1001:
> >
> > amanda@coyote:/root$ grep backup /etc/group
> > backup:x:34:
>
> Ah, I see...  Looking back your at email from yesterday, you had:
> > root@coyote:amanda$ grep backup /etc/group
> > disk:x:6:gene,backup
> > backup:x:34:
> > amanda:x:1001:backup
>
> Well, when I looked through that message, I didn't notice that you had
> added the "backup" user to the "amanda" group, rather than the other
> way around
>
> That is, in your new build script your are telling the Amanda config
> that you want to use the "backup" group to run Amanda... but at the
> moment your "amanda" user is not a member of that group.
>
> So, add "amanda" to the "backup" group and try amcheck again.
>
> (Then you might as well remove "backup" from the "amanda" group, to
> keep things cleaned up...
>
> In the end the groups file should have these two lines:
>   backup:x:34:amanda
>   amanda:x:1001:
> )

It does now, and amcheck is happy with everything but coyote, connection 
refused. Wanders off in general direction of kitchen, scratching head 
because it doesn't tell me why.

Thanks Nathan.
>
>   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 2019 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: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Nathan Stratton Treadway 
On Mon, May 27, 2019 at 11:57:29 -0400, Gene Heskett wrote:
> hummm, it still installed a new amanda-security.conf file one directory 
> deeper than was specced in gh.cf. Moved it, but who is supposed to 
> own:group it. I moved it with a root session of mc, and it was root:root 
> after the move.

(Yes, this is the build/install bug that Charles ran into
yesterday.  The file is installed with the correct
permissions/ownership, just in the wrong place.  So the first time you
do an install you will need to move it manually.  After you've moved it
once, though, I think you can just leave it alone on later installs
if you want.   [The only exception would be if you change your configure
parameters in such a way that the newly-build security file has
different contents that your existing one, but that's pretty rare.])

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: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Nathan Stratton Treadway 
On Mon, May 27, 2019 at 11:57:29 -0400, Gene Heskett wrote:
> next pass at amcheck Daily got this:
> 
> manda@coyote:/root$ /usr/local/sbin/amcheck Daily
> Amanda Tape Server Host Check
[...]
> Amanda Backup Client Hosts Check
> 
> ERROR: lathe: selfcheck request failed: amcheck-clients: error 
> [exec /usr/local/libexec/amanda/ambind: Permission denied]
[...] 
> amanda@coyote:/root$ ls -l /usr/local/libexec/amanda/ambind
> -rwsr-x--- 1 root backup 26840 May 27 
> 11:11 /usr/local/libexec/amanda/ambind
> 
> Is that correct? If wrong for owner root, whats the fix, which we'll need 

Yes, that is correct.  This is a setuid binary (note the "s" in
"rwsr-x") and is intended to run as root (and thus it needs to be owned
by root).

> 
> This is /etc/group now
> 
> amanda@coyote:/root$ grep amanda /etc/group
> mail:x:8:gene,amanda
> amanda:x:1001:
> 
> amanda@coyote:/root$ grep backup /etc/group
> backup:x:34:



Ah, I see...  Looking back your at email from yesterday, you had:
> root@coyote:amanda$ grep backup /etc/group
> disk:x:6:gene,backup
> backup:x:34:
> amanda:x:1001:backup

Well, when I looked through that message, I didn't notice that you had
added the "backup" user to the "amanda" group, rather than the other way
around

That is, in your new build script your are telling the Amanda config
that you want to use the "backup" group to run Amanda... but at the
moment your "amanda" user is not a member of that group.

So, add "amanda" to the "backup" group and try amcheck again.  

(Then you might as well remove "backup" from the "amanda" group, to keep
things cleaned up...

In the end the groups file should have these two lines:
  backup:x:34:amanda
  amanda:x:1001:
)

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: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Gene Heskett 
On Monday 27 May 2019 02:16:12 am Nathan Stratton Treadway wrote:

> On Mon, May 27, 2019 at 00:59:53 -0400, Gene Heskett wrote:
> > I figured the debs were using backup it was a good idea, just
> > because it adds another layer of security by having to look up group
> > to find backup is a member of the disk group.  But theres so many
> > places to change that
>
> Your User/Group info, copied from your other message:
> =
> root@coyote:amanda$ grep amanda /etc/passwd
> amanda:x:1001:1001:,0,,:/home/amanda:/bin/bash
>
> root@coyote:amanda$ grep amanda /etc/group
> mail:x:8:gene,amanda
> amanda:x:1001:backup
>
> root@coyote:amanda$ grep backup /etc/group
> disk:x:6:gene,backup
> backup:x:34:
> amanda:x:1001:backup
>
> root@coyote:amanda$ grep backup /etc/passwd
> backup:x:34:34:backup:/var/backups:/bin/bash
> ==
>
> So... groups can't be members of groups in Unix; what you have right
> now is the _user_ "backup" as a member of the "disk" group (which
> doesn't matter at all to Amanda on your system)... and the user
> "amanda" is _not_ a member of "disk", which is why you are having
> permission problems trying to run the executables.
>
> So, trying to make the "backup" group a member of the "disk" group
> doesn't work... but you can achieve added security if you actually
> avoiding the use of the "disk" group entirely.  Amanda used to need to
> be a member of that group in order to run the "dump" utility, but now
> under Linux a setuid "rundump" program can used instead (and you don't
> use "dump" anyway -- even more reason you don't need "disk"
> membership).
>
>
> But if you do want to go down that road right now, you need to change
> your gh.cf script so that it has "--with-group=backup" in place of the
> current "--with-group=disk" line.
>
> Your most recent error message (copied from your post in the other
> thread) says:
> ==
> ERROR: program /usr/local/libexec/amanda/ambind: wrong permission,
> must be 'rwsr-x---' But that is what it almost is:
> -rwsr-x--x 1 root disk 26840 May 26 21:59
> /usr/local/libexec/amanda/ambind It won't get past that point for
> anything if that final x isn't there ==
>
> When you run the configure using --with-group=backup, that will cause
> the Amanda install process to use "backup" as the group owner of those
> binaries, thus allowing your Amanda user to execute them.
>
> (Note that those setuid binaries MUST NOT BE executable by "other"; as
> you can see, Amanda won't allow the programs to run if they are,
> because otherwise any user on the system could execute them and obtain
> root privileges  But if you re-build Amanda now, it should install
> the newly-build copies with all that corrected.)
>
>
>   Nathan
>
ok, I've fixed my script to use group backup and its rebuilding now. I've 
alsa taken amanda out of group. So there should not be any aliases 
getting in the way.  And while the build is running, my coffee is both 
old and cold, so go make some fresh. I'm surprised the missus hasn't 
barked for some more.

hummm, it still installed a new amanda-security.conf file one directory 
deeper than was specced in gh.cf. Moved it, but who is supposed to 
own:group it. I moved it with a root session of mc, and it was root:root 
after the move.

first pass at amcheck, no perms in /tmp, looking, both amanda and 
amanda-dbg belonged to gene, so they got chown'd -R to amanda:backup
next pass at amcheck Daily got this:

manda@coyote:/root$ /usr/local/sbin/amcheck Daily
Amanda Tape Server Host Check
-
ERROR: program /usr/local/libexec/amanda/ambind: not executable
NOTE: Holding disk '/usr/dumps': 1477644 MB disk space available, using 
1477144 MB
slot 1: volume 'Dailys-1'
Will write to volume 'Dailys-1' in slot 1.
NOTE: skipping tape-writable test
NOTE: conf info dir '/usr/local/var/amanda/Daily/curinfo' does not exist
  it will be created on the next run
NOTE: index dir '/usr/local/var/amanda/Daily/index' does not exist
  it will be created on the next run
Server check took 1.098 seconds
Amanda Backup Client Hosts Check

ERROR: lathe: selfcheck request failed: amcheck-clients: error 
[exec /usr/local/libexec/amanda/ambind: Permission denied]
ERROR: picnc: selfcheck request failed: amcheck-clients: error 
[exec /usr/local/libexec/amanda/ambind: Permission denied]
ERROR: GO704: selfcheck request failed: amcheck-clients: error 
[exec /usr/local/libexec/amanda/ambind: Permission denied]
ERROR: coyote: selfcheck request failed: amcheck-clients: error 
[exec /usr/local/libexec/amanda/ambind: Permission denied]
ERROR: shop: selfcheck request failed: amcheck-clients: error 
[exec /usr/local/libexec/amanda/ambind: Permission denied]
Client check: 5 hosts checked in 13.260 seconds.  5 problems found.
(brought to you by Amanda 3.5.1.git.19364c7b)

amanda@coyote:/root$ ls -l /usr/local/libexec/amanda/ambind
-rwsr-x--- 1 root backup 26840 May 27 
11:11

Re: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Nathan Stratton Treadway 
On Mon, May 27, 2019 at 00:59:53 -0400, Gene Heskett wrote:
> I figured the debs were using backup it was a good idea, just because it 
> adds another layer of security by having to look up group to find backup 
> is a member of the disk group.  But theres so many places to change that 


Your User/Group info, copied from your other message:
=
root@coyote:amanda$ grep amanda /etc/passwd 
 
amanda:x:1001:1001:,0,,:/home/amanda:/bin/bash  
 

 
root@coyote:amanda$ grep amanda /etc/group  
 
mail:x:8:gene,amanda
 
amanda:x:1001:backup
 

 
root@coyote:amanda$ grep backup /etc/group  
 
disk:x:6:gene,backup
 
backup:x:34:
 
amanda:x:1001:backup
 

 
root@coyote:amanda$ grep backup /etc/passwd 
 
backup:x:34:34:backup:/var/backups:/bin/bash
 
==

So... groups can't be members of groups in Unix; what you have right now
is the _user_ "backup" as a member of the "disk" group (which doesn't
matter at all to Amanda on your system)... and the user "amanda" is
_not_ a member of "disk", which is why you are having permission problems
trying to run the executables.

So, trying to make the "backup" group a member of the "disk" group
doesn't work... but you can achieve added security if you actually
avoiding the use of the "disk" group entirely.  Amanda used to need to
be a member of that group in order to run the "dump" utility, but now
under Linux a setuid "rundump" program can used instead (and you don't
use "dump" anyway -- even more reason you don't need "disk" membership).


But if you do want to go down that road right now, you need to change
your gh.cf script so that it has "--with-group=backup" in place of the
current "--with-group=disk" line.

Your most recent error message (copied from your post in the other
thread) says:
==
ERROR: program /usr/local/libexec/amanda/ambind: wrong permission, must be 
'rwsr-x---'
But that is what it almost is:
-rwsr-x--x 1 root disk 26840 May 26 21:59 /usr/local/libexec/amanda/ambind 
It won't get past that point for anything if that final x isn't there 
==

When you run the configure using --with-group=backup, that will cause
the Amanda install process to use "backup" as the group owner of those
binaries, thus allowing your Amanda user to execute them.

(Note that those setuid binaries MUST NOT BE executable by "other"; as
you can see, Amanda won't allow the programs to run if they are, because
otherwise any user on the system could execute them and obtain root
privileges  But if you re-build Amanda now, it should install the
newly-build copies with all that corrected.)


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: building (non-Debianized) Amanda on Stretch

2019-05-27 Thread Gene Heskett 
On Sunday 26 May 2019 11:38:01 pm Nathan Stratton Treadway wrote:

> On Sun, May 26, 2019 at 19:58:30 -0400, Nathan Stratton Treadway wrote:
> > On Sun, May 26, 2019 at 17:24:47 -0400, Gene Heskett wrote:
> > > So in order to keep it a little closer together, I used that exact
> > > path in gh.cf, and a rebuild is in progress.  There is I believe a
> >
> > Just to make sure we're on the same page, please post here the
> > actual version of the gh.cf you are using for your current build
>
> [...]
>
> > What do
> >   # grep amanda /etc/passwd /etc/group
> > and
> >   # grep backup /etc/passwd /etc/group
> > show on that box?
>
> (Posted in another thread: "Well I am down to 2 errors from amcheck")
>
> Gene,  don't post your updates to another thread!  It's already hard
> enough to keep track of the current status of things just within this
> one...
>
>
> From the details in that post, it looks even more like you are not
> being consistent in the group you are using.
>
> For the past many years you have had Amanda running using the "disk"
> group.  Are you actively trying to change that now (to use "backup"
> instead)?
>
> (Personally I wouldn't recommend changing that at this point, since it
> adds to the complexity of your current efforts -- though in the long
> run it should be possible to get either one to work.)
>
> Anyway, please let me know which group you are intending to be using
> now, and post build script and user info as mentioned above...
>
>   Nathan
>
I figured the debs were using backup it was a good idea, just because it 
adds another layer of security by having to look up group to find backup 
is a member of the disk group.  But theres so many places to change that 
its quite a chore.  Obviously I haven't found them all. But I'm about 
~30~ for the day, and last night was way too short.
>
> --
>-- 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 2019 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