Re: client stopped getting backed up after June 18

[Charles Curley]

On Mon, Jul 02, 2007 at 08:21:12PM +, Julian C. Dunn wrote:
> On Mon, 2007-07-02 at 13:43 -0600, Charles Curley wrote:


> > After you changed the xinetd file for amanda, did you restart xinetd?
> 
> Whoops! I guess I'd better try that before complaining...

having restarted xindetd, did you know you can test it right then &
there with, e.g.:

[EMAIL PROTECTED] ~]# su - amanda
-bash-3.2$ /usr/sbin/amcheck -s DailySet1
Amanda Tape Server Host Check
-
Holding disk /crc/back/amanda: 41 GB disk space available, using 30 GB as 
requested
slot 17: read label `DailySet1_17', date `20070524'
NOTE: skipping tape-writable test
Tape DailySet1_17 label ok
Server check took 6.343 seconds

(brought to you by Amanda 2.5.1p3)
-bash-3.2$ 

-- 

Charles Curley  /"\ASCII Ribbon Campaign
Looking for fine software   \ /Respect for open standards
and/or writing?  X No HTML/RTF in email
http://www.charlescurley.com/ \No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB


pgpbXu6XlKm23.pgp
Description: PGP signature

Re: suggestion for a disk-to-disk backup server

[Olivier Nicole]

> I think by tapedev=/no/such/tape Paul meant that literally, or at
> > least some string that could not be a legit tape device.

Not speaking for Paul, but I guess he did.

> >> # find /tmp/amanda -type f | xargs grep '/dev/rmt/0'
> >>
> >> and got nothing except the alternative "weekend" configuration I had
> >> played with the previous weekend.

I was looking the same direction, in fact I could not see any place
where Amanda logs the tape device she is going to use. The only bits
that would log the name of the tape device used are amcheck -t and
amrecover. I checked the config logs too /var/amanda/daily but nothing
there either.

> >> 4. There are additional parameters in my configuration that end up
> >> overriding my attempt to override tapedev?
> My AIT drive is /dev/rmt/1n, and the changer for it is addressed as
> /dev/scsi/changer/c7t0d0 in amanda.conf.

Can't there be an interaction between the changer and the tape drive?
That is the changer will anyway load the requested tape (changer names
has not been overwritten) and let Amanda know that the requested tape
is available at that known tape device, then Amanda using the device
provided by the changer rather than the one configured/overwritten?

You could try overwritting the changer too.

Bests,

Olivier

misformatted output of "amadmin balance"

[Stefan G. Weichinger]

Greets, amanda-users and -hackers,
does anyone know how to get properly formatted output from

# amadmin daily balance

 due-date  #fsorig MB out MB   balance
--
 7/02 Mon   16 85542 62735   +339.6%
 7/03 Tue2 14319 2546-82.2%
 7/04 Wed0 0 0  ---
 7/05 Thu   20 45645 27801+94.8%
 7/06 Fri   15 82366 54334   +280.8%

[...]

The columns aren't in line, maybe someone knows a fix.
Example taken from a amanda server running 2.5.1p3.

Greets, Stefan

Re: client stopped getting backed up after June 18

[Julian C. Dunn]

On Mon, 2007-07-02 at 13:43 -0600, Charles Curley wrote:
> On Mon, Jul 02, 2007 at 12:40:06PM -0400, Julian C. Dunn wrote:
> > On Mon, 2007-07-02 at 17:07 +0200, Radek Brich wrote:
> 
> > > Can amanda 2.5.1p3 really talk IPv6? I think it doesn't support it at all.
> > 
> > Looks like you're right - I see your bug #198351 in RedHat bugzilla. Any
> > idea when we might see Amanda 2.5.2 in FC7 updates? And until then,
> > ought I just to downgrade xinetd to the last known working version?
> 
> I am currently running F7 with xinetd-2.3.14-12.fc7 and no problems,
> but this is an IPv4 network. I believe the previous version of xinetd
> is that in the Fedora repo. The one in the Fedora repo also works,
> without the workround line.
> 
> After you changed the xinetd file for amanda, did you restart xinetd?

Whoops! I guess I'd better try that before complaining...

- Julian

Re: client stopped getting backed up after June 18

[Charles Curley]

On Mon, Jul 02, 2007 at 12:40:06PM -0400, Julian C. Dunn wrote:
> On Mon, 2007-07-02 at 17:07 +0200, Radek Brich wrote:

> > Can amanda 2.5.1p3 really talk IPv6? I think it doesn't support it at all.
> 
> Looks like you're right - I see your bug #198351 in RedHat bugzilla. Any
> idea when we might see Amanda 2.5.2 in FC7 updates? And until then,
> ought I just to downgrade xinetd to the last known working version?

I am currently running F7 with xinetd-2.3.14-12.fc7 and no problems,
but this is an IPv4 network. I believe the previous version of xinetd
is that in the Fedora repo. The one in the Fedora repo also works,
without the workround line.

After you changed the xinetd file for amanda, did you restart xinetd?

-- 

Charles Curley  /"\ASCII Ribbon Campaign
Looking for fine software   \ /Respect for open standards
and/or writing?  X No HTML/RTF in email
http://www.charlescurley.com/ \No M$ Word docs in email

Key fingerprint = CE5C 6645 A45A 64E4 94C0  809C FFF6 4C48 4ECD DFDB


pgpVvtwSO5zv7.pgp
Description: PGP signature

Re: suggestion for a disk-to-disk backup server

[Chris Hoogendyk]

Jon LaBadie wrote:
> On Mon, Jul 02, 2007 at 01:48:59PM -0400, Chris Hoogendyk wrote:
>   
>>> Paul Bijnens wrote:
>>>   
>>>   
 Instead of making it a different configuration, and running into trouble
 on which full to base an incrmeental, why don't you run an additional
 amdump of the normal config in the weekend, but which has options to
 override the config:

amdump daily -o reserver=100,tapedev=/no/such/tape

 With the option "tapedev /no/such/tape" we force Amanda to fall back
 to degraded mode, making backup to holdingdisk only, and with the
 "reserve 100", we avoid wasting holdingdisk space for full backups in
 the degraded mode.
 
>> ok, tried this over the preceding weekend.
>>
>> the amanda user's crontab has these entries:
>>
>>   0 15 * * 1-5 /usr/local/sbin/amcheck -m daily
>>   45 0 * * 2-6 /usr/local/sbin/amdump daily
>>   45 0 * * 0-1 /usr/local/sbin/amdump daily -o
>> reserve=100,tapedev=/dev/rmt/0n
>>
>> however, the weekend runs looked exactly like the weekday runs. They
>> used an AIT tape off /dev/rmt/1n and ran fulls and incrementals
>> intermixed. I searched the report, the log files, the debug files, etc.
>> for any error messages about the command line options or any references
>> to /dev/rmt/0n. none. I even tried
>>
>> # find /tmp/amanda -type f | xargs grep '/dev/rmt/0'
>>
>> and got nothing except the alternative "weekend" configuration I had
>> played with the previous weekend.
>>
>> I checked the documentation & man pages and the documentation of the -o
>> option is pretty sparse. All references say "see the configuration
>> override section in amanda(8)". That section is only a few lines long
>> and makes no reference to the syntax with a comma separating multiple
>> parameter=value pairs.
>>
>> So, possibilities ...
>>
>> 1. The syntax is wrong? And I need to use "amdump daily -o reserve=100
>> -o tapedev=/dev/rmt/0n"? (In either case, this should be documented,
>> since one would typically want to override more than one parameter if
>> any at all.)
>>
>> 2. There is a bug in amanda, and it doesn't work?
>>
>> 3. Amanda is being too "smart" and reverting to /dev/rmt/1n when my
>> override to /dev/rmt/0n fails? Doesn't seem likely.
>>
>> 4. There are additional parameters in my configuration that end up
>> overriding my attempt to override tapedev?
>>
>> 
>
> Maybe an additional possibility:
>
>   5. /dev/rmt/0n == /dev/rmt/1n
>
> I think by tapedev=/no/such/tape Paul meant that literally, or at
> least some string that could not be a legit tape device.
>
> Two ways I can see the 0 and 1 devices being equivalent.  My HP-DDS
> changer shows up in Solaris 9 x86 as two /dev/rmt devices, 0 and 1
> for me.  They are the same SCSI ID but different LUNs (the d# in
> c5t3d0 scsi dev nomenclature).  One is for the changer mechanism
> and the other for the tape drive.  At least that is what it is
> supposed to be.  Only one can be used for the changer, but either
> seems to work for the tape drive.  I don't think that is common,
> but who knows.
>
> The other way is if you "installed" the tape drive multiple times.
> /dev/rmt/# are not cleared at boot to allow for persistant
> names for the same device.  For example, you could have two tape
> drives and only one powered up at boot time.  Which was rmt/0
> would vary.  This is handled by recording the /devices data in
> /etc/path_to_inst and is only updated by a reconfigure reboot
> or options to the /usr/sbin/devfsadm command.  Maybe there is
> a stale entry in there that makes rmt/0 and rmt/1 the same.
>
> You might also check what the symlinks in /dev/rmt point to
> with an ls -l and what the targets in /devices have for
> maj/min device numbers with ls -lL of /dev/rmt.
>   

/dev/rmt/0n is actually my internal dds/3 drive. It exists and works,
but does not have a tape in it. I've used it recently to do some tests
of the behavior of ufsdump for incremental recoveries (checking how
ufsdump deals with deleted, moved, etc. files and directories -- the
answer being "quite well" :-)  ).

When I tried a separate "weekend" configuration the previous weekend, I
used tapedev "/dev/rmt/0n" in amanda.conf, and it worked as expected --
found the drive but no tape and just spooled to holding disk.

My AIT drive is /dev/rmt/1n, and the changer for it is addressed as
/dev/scsi/changer/c7t0d0 in amanda.conf.

They all work just fine from mt, mtx, ufsdump, various scripts and
amanda (amtape, amdump, etc) -- except for the above "-o" command line
override failure.

---

Chris Hoogendyk

-
   O__   Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~ - University of Massachusetts, Amherst 

<[EMAIL PROTECTED]>

--- 

Erdös 4

Re: suggestion for a disk-to-disk backup server

[Jon LaBadie]

On Mon, Jul 02, 2007 at 01:48:59PM -0400, Chris Hoogendyk wrote:
> 
> > Paul Bijnens wrote:
> >   
> >> Instead of making it a different configuration, and running into trouble
> >> on which full to base an incrmeental, why don't you run an additional
> >> amdump of the normal config in the weekend, but which has options to
> >> override the config:
> >>
> >>amdump daily -o reserver=100,tapedev=/no/such/tape
> >>
> >> With the option "tapedev /no/such/tape" we force Amanda to fall back
> >> to degraded mode, making backup to holdingdisk only, and with the
> >> "reserve 100", we avoid wasting holdingdisk space for full backups in
> >> the degraded mode.
> 
> ok, tried this over the preceding weekend.
> 
> the amanda user's crontab has these entries:
> 
>   0 15 * * 1-5 /usr/local/sbin/amcheck -m daily
>   45 0 * * 2-6 /usr/local/sbin/amdump daily
>   45 0 * * 0-1 /usr/local/sbin/amdump daily -o
> reserve=100,tapedev=/dev/rmt/0n
> 
> however, the weekend runs looked exactly like the weekday runs. They
> used an AIT tape off /dev/rmt/1n and ran fulls and incrementals
> intermixed. I searched the report, the log files, the debug files, etc.
> for any error messages about the command line options or any references
> to /dev/rmt/0n. none. I even tried
> 
> # find /tmp/amanda -type f | xargs grep '/dev/rmt/0'
> 
> and got nothing except the alternative "weekend" configuration I had
> played with the previous weekend.
> 
> I checked the documentation & man pages and the documentation of the -o
> option is pretty sparse. All references say "see the configuration
> override section in amanda(8)". That section is only a few lines long
> and makes no reference to the syntax with a comma separating multiple
> parameter=value pairs.
> 
> So, possibilities ...
> 
> 1. The syntax is wrong? And I need to use "amdump daily -o reserve=100
> -o tapedev=/dev/rmt/0n"? (In either case, this should be documented,
> since one would typically want to override more than one parameter if
> any at all.)
> 
> 2. There is a bug in amanda, and it doesn't work?
> 
> 3. Amanda is being too "smart" and reverting to /dev/rmt/1n when my
> override to /dev/rmt/0n fails? Doesn't seem likely.
> 
> 4. There are additional parameters in my configuration that end up
> overriding my attempt to override tapedev?
> 

Maybe an additional possibility:

  5. /dev/rmt/0n == /dev/rmt/1n

I think by tapedev=/no/such/tape Paul meant that literally, or at
least some string that could not be a legit tape device.

Two ways I can see the 0 and 1 devices being equivalent.  My HP-DDS
changer shows up in Solaris 9 x86 as two /dev/rmt devices, 0 and 1
for me.  They are the same SCSI ID but different LUNs (the d# in
c5t3d0 scsi dev nomenclature).  One is for the changer mechanism
and the other for the tape drive.  At least that is what it is
supposed to be.  Only one can be used for the changer, but either
seems to work for the tape drive.  I don't think that is common,
but who knows.

The other way is if you "installed" the tape drive multiple times.
/dev/rmt/# are not cleared at boot to allow for persistant
names for the same device.  For example, you could have two tape
drives and only one powered up at boot time.  Which was rmt/0
would vary.  This is handled by recording the /devices data in
/etc/path_to_inst and is only updated by a reconfigure reboot
or options to the /usr/sbin/devfsadm command.  Maybe there is
a stale entry in there that makes rmt/0 and rmt/1 the same.

You might also check what the symlinks in /dev/rmt point to
with an ls -l and what the targets in /devices have for
maj/min device numbers with ls -lL of /dev/rmt.

-- 
Jon H. LaBadie  [EMAIL PROTECTED]
 JG Computing
 4455 Province Line Road(609) 252-0159
 Princeton, NJ  08540-4322  (609) 683-7220 (fax)

Re: suggestion for a disk-to-disk backup server

[Chris Hoogendyk]

> Paul Bijnens wrote:
>   
>> Instead of making it a different configuration, and running into trouble
>> on which full to base an incrmeental, why don't you run an additional
>> amdump of the normal config in the weekend, but which has options to
>> override the config:
>>
>>amdump daily -o reserver=100,tapedev=/no/such/tape
>>
>> With the option "tapedev /no/such/tape" we force Amanda to fall back
>> to degraded mode, making backup to holdingdisk only, and with the
>> "reserve 100", we avoid wasting holdingdisk space for full backups in
>> the degraded mode.

ok, tried this over the preceding weekend.

the amanda user's crontab has these entries:

  0 15 * * 1-5 /usr/local/sbin/amcheck -m daily
  45 0 * * 2-6 /usr/local/sbin/amdump daily
  45 0 * * 0-1 /usr/local/sbin/amdump daily -o
reserve=100,tapedev=/dev/rmt/0n

however, the weekend runs looked exactly like the weekday runs. They
used an AIT tape off /dev/rmt/1n and ran fulls and incrementals
intermixed. I searched the report, the log files, the debug files, etc.
for any error messages about the command line options or any references
to /dev/rmt/0n. none. I even tried

# find /tmp/amanda -type f | xargs grep '/dev/rmt/0'

and got nothing except the alternative "weekend" configuration I had
played with the previous weekend.

I checked the documentation & man pages and the documentation of the -o
option is pretty sparse. All references say "see the configuration
override section in amanda(8)". That section is only a few lines long
and makes no reference to the syntax with a comma separating multiple
parameter=value pairs.

So, possibilities ...

1. The syntax is wrong? And I need to use "amdump daily -o reserve=100
-o tapedev=/dev/rmt/0n"? (In either case, this should be documented,
since one would typically want to override more than one parameter if
any at all.)

2. There is a bug in amanda, and it doesn't work?

3. Amanda is being too "smart" and reverting to /dev/rmt/1n when my
override to /dev/rmt/0n fails? Doesn't seem likely.

4. There are additional parameters in my configuration that end up
overriding my attempt to override tapedev?

I am using a tpchanger, but there is no reference to tapedev there. If I
search the daily configuration directory for reference to /dev/rmt, the
only reference I find is the 'tapedev "/dev/rmt/1n"' in amanda.conf.

In case it matters & got lost in the beginnings of this thread, I'm
running 2.5.1p3 on Solaris 9 on SPARC (E250).




---

Chris Hoogendyk

-
   O__   Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~ - University of Massachusetts, Amherst 

<[EMAIL PROTECTED]>

--- 

Erdös 4

Re: client stopped getting backed up after June 18

[Julian C. Dunn]

On Mon, 2007-07-02 at 17:07 +0200, Radek Brich wrote:
> On Monday 02 of July 2007 16:09:55 Julian C. Dunn wrote:
> > On Sat, 2007-06-30 at 11:08 -0600, Charles Curley wrote:
> > > On Sat, Jun 30, 2007 at 12:20:43PM -0400, Julian C. Dunn wrote:
> > > > I have the following strange problem with a FreeBSD amanda server
> > > > running 2.5.1p3 and a Fedora 7 Linux client running the same. The last
> > >
> > > See bug 244916 in Redhat's Bugzilla.
> >
> > I tried the workaround, which is adding
> >
> > flags   = IPv4
> >
> > to /etc/xinetd.d/amanda on the client, but last night's backup failed
> > again. I'm wondering if the problem is really applicable to me, because
> > both the client and server already talk IPv6... unless Amanda has
> > problems with IPv6?
>
> Can amanda 2.5.1p3 really talk IPv6? I think it doesn't support it at all.

Looks like you're right - I see your bug #198351 in RedHat bugzilla. Any
idea when we might see Amanda 2.5.2 in FC7 updates? And until then,
ought I just to downgrade xinetd to the last known working version?

- Julian

smbclient got signal 13

[watts]

Does size provoke the message 
"sendbackup: time 2069.484: error [/usr/local/bin/smbclient got signal 13]"?


Total bytes written: 5200947200

remuda# more sendbackup.20070701083211.debug
sendbackup: debug 1 pid 4208 ruid 2 euid 2: start at Sun Jul  1 08:32:11 2007
/usr/local/libexec/amanda/sendbackup: version 2.4.5
  parsed request as: program `GNUTAR'
 disk `//pillbox/primary'
 device `//pillbox/primary'
 level 0
 since 1970:1:1:0:0:0
 options `|;bsd-auth;compress-best;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.52851
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.65194
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.58013
sendbackup: time 0.000: waiting for connect on 52851, then 65194, then 58013
sendbackup: time 0.002: stream_accept: connection from 10.0.3.148.64749
sendbackup: time 0.002: stream_accept: connection from 10.0.3.148.51619
sendbackup: time 0.002: stream_accept: connection from 10.0.3.148.52604
sendbackup: time 0.002: got all connections
sendbackup: time 0.002: spawning /usr/bin/gzip in pipeline
sendbackup: argument list: /usr/bin/gzip --best
sendbackup-gnutar: time 0.005: pid 4210: /usr/bin/gzip --best
sendbackup-gnutar: time 0.034: doing level 0 dump from date: 1970-01-01  
0:00:00
 GMT
sendbackup-gnutar: time 0.035: backup of \\pillbox\primary
sendbackup: time 0.035: spawning /usr/local/bin/smbclient in pipeline
sendbackup: argument list: smbclient \\pillbox\primary -U administrator -E -W 
ro
under -d0 -Tqca -
sendbackup-gnutar: time 0.036: /usr/local/bin/smbclient: pid 4213
sendbackup: time 0.042: started index creator: "/usr/bin/gtar -tf - 2>
/dev/null
| sed -e 's/^\.//'"
sendbackup: time 0.116: 124: strange(?): Domain=[PILLBOX] OS=[Windows Server 
200
3 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
sendbackup: time 2069.440:  75:  normal(|): tar: dumped 1545 files and 
directori
es
sendbackup: time 2069.441:  53:size(|): Total bytes written: 5200947200
sendbackup: time 2069.443: index created successfully
sendbackup: time 2069.484: error [/usr/local/bin/smbclient got signal 13]
sendbackup: time 2069.484: pid 4208 finish time Sun Jul  1 09:06:40 2007
remuda# 


Total bytes written: 105021440
=
remuda# more sendbackup.20070702015031.debug
sendbackup: debug 1 pid 6612 ruid 2 euid 2: start at Mon Jul  2 01:50:31 2007
/usr/local/libexec/amanda/sendbackup: version 2.4.5
  parsed request as: program `GNUTAR'
 disk `//pillbox/admin'
 device `//pillbox/admin'
 level 0
 since 1970:1:1:0:0:0
 options `|;bsd-auth;compress-best;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.49450
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.50956
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.58958
sendbackup: time 0.000: waiting for connect on 49450, then 50956, then 58958
sendbackup: time 0.002: stream_accept: connection from 10.0.3.148.55230
sendbackup: time 0.002: stream_accept: connection from 10.0.3.148.55837
sendbackup: time 0.002: stream_accept: connection from 10.0.3.148.54857
sendbackup: time 0.002: got all connections
sendbackup: time 0.006: spawning /usr/bin/gzip in pipeline
sendbackup: argument list: /usr/bin/gzip --best
sendbackup-gnutar: time 0.007: pid 6614: /usr/bin/gzip --best
sendbackup-gnutar: time 0.047: doing level 0 dump from date: 1970-01-01  
0:00:00
 GMT
sendbackup-gnutar: time 0.048: backup of \\pillbox\admin
sendbackup: time 0.048: spawning /usr/local/bin/smbclient in pipeline
sendbackup: argument list: smbclient \\pillbox\admin -U administrator -E -W 
roun
der -d0 -Tqca -
sendbackup-gnutar: time 0.049: /usr/local/bin/smbclient: pid 6617
sendbackup: time 0.069: started index creator: "/usr/bin/gtar -tf - 2>
/dev/null
| sed -e 's/^\.//'"
sendbackup: time 0.133: 124: strange(?): Domain=[PILLBOX] OS=[Windows Server 
200
3 3790 Service Pack 1] Server=[Windows Server 2003 5.2]
sendbackup: time 863.858:  75:  normal(|): tar: dumped 240 files and 
directories
sendbackup: time 863.859:  53:size(|): Total bytes written: 105021440
sendbackup: time 863.861: index created successfully
sendbackup: time 863.896: pid 6612 finish time Mon Jul  2 02:04:55 2007
remuda# 



nvloke smbclient interactively and the tar succeeds
remuda# smbclient //pillbox/primary -U administrator%  -E -W rounder -d0 
-Tqca - | gzip  -c >/scratch2/justsmb
Domain=[PILLBOX] OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows 
Server 2003 5.2]

tar: dumped 15

Re: UID under which amanda services should run, if backup server is only client?

[Chris Hoogendyk]

Mark Scheufele wrote:
> Hi,
>
> in our amanda setup there are no other clients than the backup server
> itself. The amanda software was compiled with the
> options--with-user=amanda --with-owner=amanda --with-group=sys so that
> all services do run under a separate amanda user. 
>
> To be able to read all files within the local filesystems I have set the
> parameter dumpuser to "root" in the amanda.conf file. Backups are now
> running fine. But I am running into permission problems with amrecover.
>
> The problem is that all files under etc//index and all log.*
> files under etc/ are all assigned to the root user. The amindexd
> yet runs under the amanda user and therefore isn't able to read those
> files properly.
>
> To fix the problem I was thinking about recompiling amanda to run all
> services completely under the uid root to avoid the permission problems.
>
> But maybe there is a better way to accomplish my goal. It would be great
> if someone could point me into the right direction.

I would not do that. Generally speaking, use root as little as possible.

Just follow the setup instructions and use the amanda user.

You need root to run amrecover, but not to run backups.

When I first set up amanda, I followed the quick_start more or less:
. I had only the server
backing up itself. Once that was working, I expanded from there. But the
basic setup didn't have to change.

If you set things up with root, and then decide to add other clients,
you will be stuck in a situation requiring root processes and root
logins all across your net on a regular basis. It's best not to do that.
As Paul's comments said, get it working as intended rather than trying
to force your way past difficulties using root.


---

Chris Hoogendyk

-
   O__   Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~ - University of Massachusetts, Amherst 

<[EMAIL PROTECTED]>

--- 

Erdös 4

Re: UID under which amanda services should run, if backup server is only client?

[Paul Bijnens]

On 2007-07-02 17:12, Mark Scheufele wrote:
> Hi,
> 
> in our amanda setup there are no other clients than the backup server
> itself. The amanda software was compiled with the
> options--with-user=amanda --with-owner=amanda --with-group=sys so that
> all services do run under a separate amanda user. 

Good.


> 
> To be able to read all files within the local filesystems I have set the
> parameter dumpuser to "root" in the amanda.conf file. Backups are now
> running fine. But I am running into permission problems with amrecover.

Bad.  Amanda already runs the real backup program (gnutar) with
a setuid-root program, ("runtar" -- look in libexec) , giving it all
the permissions needed.  For dump all that is needed is that the amanda
has read-access to the disk-groups.  There are other programs needing a
setuid-flag on the executable as well.

It could be that while installing, you did not do "make install" as the
root user, thereby losing the setuid-bit on many programs that need it.
Another frequent error is that you have the setuid-programs on a
partition that is mounted with the "nosuid" option.


> 
> The problem is that all files under etc//index and all log.*
> files under etc/ are all assigned to the root user. The amindexd
> yet runs under the amanda user and therefore isn't able to read those
> files properly.

Revert to user "amanda", and "chown -R amanda" all the index, and log
files.  Then at least, amrecover works again.


> 
> To fix the problem I was thinking about recompiling amanda to run all
> services completely under the uid root to avoid the permission problems.
> 
> But maybe there is a better way to accomplish my goal. It would be great
> if someone could point me into the right direction.

No, better find out why the setuid bit was not working for your
installation.


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

Re: client stopped getting backed up after June 18

[Radek Brich]

On Monday 02 of July 2007 16:09:55 Julian C. Dunn wrote:
> On Sat, 2007-06-30 at 11:08 -0600, Charles Curley wrote:
> > On Sat, Jun 30, 2007 at 12:20:43PM -0400, Julian C. Dunn wrote:
> > > I have the following strange problem with a FreeBSD amanda server
> > > running 2.5.1p3 and a Fedora 7 Linux client running the same. The last
> >
> > See bug 244916 in Redhat's Bugzilla.
>
> I tried the workaround, which is adding
>
> flags   = IPv4
>
> to /etc/xinetd.d/amanda on the client, but last night's backup failed
> again. I'm wondering if the problem is really applicable to me, because
> both the client and server already talk IPv6... unless Amanda has
> problems with IPv6?
>
> - Julian

Can amanda 2.5.1p3 really talk IPv6? I think it doesn't support it at all.

UID under which amanda services should run, if backup server is only client?

[Mark Scheufele]

Hi,

in our amanda setup there are no other clients than the backup server
itself. The amanda software was compiled with the
options--with-user=amanda --with-owner=amanda --with-group=sys so that
all services do run under a separate amanda user. 

To be able to read all files within the local filesystems I have set the
parameter dumpuser to "root" in the amanda.conf file. Backups are now
running fine. But I am running into permission problems with amrecover.

The problem is that all files under etc//index and all log.*
files under etc/ are all assigned to the root user. The amindexd
yet runs under the amanda user and therefore isn't able to read those
files properly.

To fix the problem I was thinking about recompiling amanda to run all
services completely under the uid root to avoid the permission problems.

But maybe there is a better way to accomplish my goal. It would be great
if someone could point me into the right direction.

Many thanks in advance,

mark
Dialog Semiconductor GmbH
Neue Str. 95
D-73230 Kirchheim
Managing Director: Dr. Jalal Bagherli
Chairman of the Supervisory Board: Gregorio Reyes
Commercial register: Amtsgericht Stuttgart: HRB 231181
UST-ID-Nr. DE 811121668


Legal Disclaimer: This e-mail communication (and any attachment/s) is 
confidential and 
contains proprietary information, some or all of which may be legally 
privileged. It is 
intended solely for the use of the individual or entity to which it is 
addressed. Access 
to this email by anyone else is unauthorized. If you are not the intended 
recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken in 
reliance
on it, is prohibited and may be unlawful.

more than 2 fulls on 10 tapes?

[Greg Troxel]

I'm sorry if this is a FAQ; I tried searching and didn't find anything.

I am still running 2.4.5p1 because I haven't updated the server side for
krb4 yet.

I have been running amanda for a very long time, and up until now on DDS
(1, 2 and then 3).  Most recently I had 15 tapes, dumpcycle 7 days, and
runspercycle 5 days, so I always had 2 and sometimes 3 fulls on tape.

I just got an LTO-2 drive (no changer), and I am setting up to use 10
tapes.  I'd like to tell amanda

  dumps happen 5 times per week (0005 tuesday to saturday)
  I have 10 tapes.
  I would like a level 0 every 4 tapes.

so that I will essentially always have 2 fulls safely on tape, even when
writing the tape with the next full dump, and even if the full dump is
one run late.

I tried:

dumpcycle 5 days
runspercycle 4
tapecycle 10 tapes

and balance showed:

 due-date  #fsorig kB out kB   balance
--
 7/02 Mon   36   221725898364704 -8.2%
 7/03 Tue   25   42117664   20905858   +129.5%
 7/04 Wed4   143132427170225-21.3%
--
TOTAL   65   78603495   36440787   9110196
  (estimated 4 runs per dumpcycle)
 (22 filesystems overdue, the most being overdue 2 days)

With dumpcycle set to 6 (and others as above), balance says:

 due-date  #fsorig kB out kB   balance
--
 7/02 Mon   22   110599154551488-50.0%
 7/03 Tue   14   26743813216-58.1%
 7/04 Wed   25   42117664   20905858   +129.5%
 7/05 Thu4   143132427170225-21.3%
--
TOTAL   65   78603495   36440787   9110196
  (estimated 4 runs per dumpcycle)
 (16 filesystems overdue, the most being overdue 1 day)

So, is the scheduler really going to be trying to write a full every 4
runs?  It seems there is some roundoff going on in the above
calculations (one 4- and one 4+).

I think what I'd really like is decoupling of conveying the schedule of
when dumps happen, and the number of fulls to keep on tape, more or
less.  I realize other people want to say "a full every week".

Something like:

operationcycle 7 days
runsperoperationcycle 5
dumpcycle 4 tapes
tapecycle 10

This would mean (avoiding thinking about unflushed dumps in holding
disk) that a full dump is due if there is not one on the most recently
written 3 tapes.

Perhaps I should have just used 12 tapes

Any clues appreciated.  I will be running 6/4/10 for now.



pgpyP7laBoxVB.pgp
Description: PGP signature

Re: client stopped getting backed up after June 18

[Julian C. Dunn]

On Sat, 2007-06-30 at 11:08 -0600, Charles Curley wrote:

> On Sat, Jun 30, 2007 at 12:20:43PM -0400, Julian C. Dunn wrote:
> > I have the following strange problem with a FreeBSD amanda server
> > running 2.5.1p3 and a Fedora 7 Linux client running the same. The last
> 
> See bug 244916 in Redhat's Bugzilla.

I tried the workaround, which is adding

flags   = IPv4

to /etc/xinetd.d/amanda on the client, but last night's backup failed
again. I'm wondering if the problem is really applicable to me, because
both the client and server already talk IPv6... unless Amanda has
problems with IPv6?

- Julian

-- 
[ Julian C. Dunn <[EMAIL PROTECTED]>  *  "You can throw confetti,   ]
[ WWW: www.aquezada.com/staff/julian   *  but you're still going ]
[ PGP: 91B3 7A9D 683C 7C16 715F*  through the motions, baby" ]
[  442C 6065 D533 FDC2 05B9*- Aimee Mann ]