On Tuesday 23 July 2002 12:10, Dave Belfer-Shevett wrote:
>Hiya folks, me again.
>
>I've made huge strides in getting amanda set up on 'tub', our
> hinky cool Solaris box that is driving the Overland tape changers
> (mmm. AIT-3. Nothing like 5+terabytes of storage available)
>
>I'm running into some pesky permission and configuration issues
> though. I'm going to put aside the fact that I can't get the tape
> changer going right now... getting one dump running to one tape
> will be a great start, I'll fiddle with the changer later.
>
>I have .amandahosts set up right, and amcheck now runs with the
> following messages. I only have one entry in the disklist file,
> and that's for 'tub's local root partition...
>
>[operator@tub]:~$ amcheck tub
>Amanda Tape Server Host Check
>-----------------------------
>Holding disk /dumps: 69886570 KB disk space available, that's
> plenty amcheck-server: slot 1: date 20020723 label qbn-backup01
> (active tape) amcheck-server: slot 2: slot 2 is empty
>amcheck-server: slot 3: slot 3 is empty
>amcheck-server: slot 4: slot 4 is empty
>amcheck-server: slot 0: slot 0 is empty
>ERROR: new tape not found in rack
> (expecting a new tape)
>NOTE: skipping tape-writable test
>NOTE: info dir /usr/adm/amanda/tub/curinfo/tub/_dev_dsk_c0t0d0s1:
> does not exist
>Server check took 81.639 seconds
>
>Amanda Backup Client Hosts Check
>--------------------------------
>ERROR: tub: [could not access /dev/rdsk/c0t0d0s1
> (/dev/dsk/c0t0d0s1): Permission denied]
>ERROR: tub: [can not read/write /etc/dumpdates: Permission denied]
>Client check: 1 host checked in 0.088 seconds, 2 problems found
>
>(brought to you by Amanda 2.4.2p2)
>
>Question: appartently amanda is simply trying to run 'dump', but
> can't because it doesn't have root access. Well duh, its logging
> in as 'operator'. Is there some setuid stuff i'm missing
> somewhere, so that the amanda app can actually run dump and
> updated /etc/dumpdates?
>
>Second - the message is saying there's a labelled tape in the
> drive (qbn-backup01) which I created with 'amlabel'. But it
> seems to think that's not a writable tape, its expecting a new
> one. Can I tell amanda "no, that's your tape. Go toss data on
> it!" or am I misunderstanding how tape labelling / allocation
> work?
Has it written data to that tape previously? In which case it will
not re-write to that tape until 'tapecycle' other tapes have been
used in order.
And it sounds like you have all sorts of perms problems. These all
go away if the correct build order is done, to wit:
unpack amanda, then as root, chown -R amanda:disk(or whatever you
have set for amanda's username and group membership)
name_of_unpacked_dir.
Become amanda, and cd to that directory and do whatever steps you
normally do to build amanda. I use a script with all the options
to run ./configure as then its not up to me to remember all that
gritty stuff from build to build. That script I use here looks
like this:
#!/bin/sh
make clean
rm -f config.status config.cache
./configure --with-user=amanda \
--with-group=disk \
--with-owner=amanda \
--with-tape-device=/dev/nst0 \
--with-changer-device=/dev/sg1 \
--with-gnu-ld \
--prefix=/usr/local \
--with-debugging=/tmp/amanda-dbg/ \
--with-tape-server=192.168.1.3 \
--with-amandahosts \
--with-configdir=/usr/local/etc/amanda
------------------------------
adjust to suit your system of course.
While still as user amanda, make it.
exit to user root and cd back into this directory, and do the 'make
install'. The installer will take care of all the perms if you do
it in that order.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.08% setiathome rank, not too shabby for a WV hillbilly
