On Wednesday 11 June 2003 01:53, Mike Eldridge wrote:
>On Tue, Jun 10, 2003 at 05:31:20PM -0400, Gene Heskett wrote:
>> >> There has to be some reason the services won't start, so please
>> >> post an 'ls -l' of the /usr/local/libexec directory. Also an
>> >> 'ls -l' of the amanda src directory, and a 'cat' of your
>> >> configuration script.
>> >
>> >/usr/local/libexec:
>> >
>> >-rwxr-xr-x 1 root disk 53526 May 31 20:29 amandad
>> >-rwsr-x--- 1 root disk 43360 May 31 20:29 calcsize
>> >-rwsr-x--- 1 root disk 37539 May 31 20:29 killpgrp
>> >-rwxr-xr-x 1 root disk 4855 May 31 20:29
>> > patch-system -rwsr-x--- 1 root disk 34567 May 31
>> > 20:29 rundump -rwsr-x--- 1 root disk 35854 May 31
>> > 20:29 runtar -rwxr-xr-x 1 root disk 59150 May 31
>> > 20:29 selfcheck -rwxr-xr-x 1 root disk 115915 May
>> > 31 20:29 sendbackup -rwxr-xr-x 1 root disk 73858
>> > May 31 20:29 sendsize -rwxr-xr-x 1 root disk 33725
>> > May 31 20:29 versionsuffix
>>
>> Okaayy, wrong perms, and where did the rest of it go?
>
>these are the perms that amanda's installation used. as it works
>flawlessly on other machines, i did not attempt to change them.
> amandad *is* executable by the amanda user. the other utilities
> are suid. as tar is being used (rather than a fs-specific dump
> utility that accesses the device), simply being a member of group
> disk will not suffice to backup the filesystem. so i will need to
> change permissions around.
>
>i will setup permissions to suit the setup, but i highly doubt this
> is the source of the problem.
>
>as for "the rest of it", it was never there as i configured using
>--without-server.
>
Ahh, so... The listed dir i snipped below is from my server, not my
client.
[...]
>>
>> >~/src/amanda-2.4.4:
>>
>> That looks good, all owned by mike, which is alright IF mike
>> is a member of group 'disk' (I think), BUT you are not so
>> shown here...
>
>uh, no, i'm not (and will not ever be) a member of group disk. what
>does the source have to do with the binaries?
Probably less than I'm reading into it, but since my user 'amanda' is
a member of the group 'disk' as recommended someplace in the docs,
then my unpacking at as the user amanda gives those ownerships.
>
>> I'm gonna snip it since my wordwrap wrecked it anyway.
>> [...]
>>
>> >/usr/local/etc/amanda/normal/amanda.conf:
>> >
>> > # amanda configuration file
>> >
>> > # configuration name
>> > org "DailyBackup"
>> >
>> > # general options
>> > mailto "diz AT hiphopanonymous DOT org"
>> > dumpuser "amanda"
>> > logdir "/var/log/amanda"
>> > tapelist "/var/lib/amanda/tapelist"
>> >
>> > # cycle information
>> > dumpcycle 7
>> > tapecycle 1
>>
>> One tape? You'll need at least dumpcycle + one, and preferably
>> (since there is no runspercycle spec here, the assumption by
>> amanda is everyday, so runspercycle=dumpcycle I believe) 2 or
>> more 'runspercycle' tapes in the rotation. Thats at least 14.
>>
>> This is so that you have a system full at any time
>> as long as the last runspercycle backups are available.
>
>they don't *have* 14 tapes. i suppose i'll just have to change
>dumpcycle to 0 and run it weekly. i'll convince them to purchase at
>*least* one additional tape, if not the 14 needed for the cycle.
Good Grief, Mike!! I have this picture of their banking system being a
slot cut in the top of a can that used to have log cabin syrup in it.
And of course they'll fry *you* if it doesn't work when *they* won't
make the investment. I think I'd want out if they don't want to pony
up for the tapes. Cut your losses and run. You don't need the
liability. I can say that of course, since I'm just a home user,
doing my own offtimes amaturish system setups. I can't sue anybody
but me if I screw up :)
>> > filemark 100 kbytes
>> > speed 4 mbps
>> > }
>> >
>> > # dump type definition for use in archiving the local
>> > machine's drive define dumptype normal-local {
>> > comment "local, normal backup, no software compression"
>> > dumpcycle 7
>>
>> strange place for a dumpcycle spec??
>
>it's listed in the amanda documentation. perhaps i want different
>dumpcycles for different machines...
Could be, I just never thought of it that way.
>> > compress none # never use software compression
>> > holdingdisk no # this is local, don't use the holding disk
>>
>> why not? Excluse it yes, but do use it. Amanda will stream to
>> tape if you do, but may shoeshine the drive, wasting tape and wear
>> and tear on the drive if you don't.
>
>my reasoning, from amanda(8):
>
> holdingdisk "boolean"
> Default: yes. Whether a holding disk should be used for
> these backups or whether they should go directly to tape. If
> the holding disk is a portion of another file system that Amanda is
> backing up, that file system should refer to a dumptype with
> holdingdisk set to no to avoid backing up the holding disk into
> itself.
It can also be "excluded" from that recursion, which to me is
prefereable. The compresion writes big enough buffers that the disk
won't be thrashed too badly.
>perhaps someone should make some changes...
>
>[snip]
>
>> When thats done, see if xinetd still has a tummy ache
>> when restarted. I'm betting this will be the dose of
>> pepto-bismal it needs.
>
>i fail to see how this will correct my problem as i have 3 other
>machines (including the tape server) that work flawlessly under
> inetd.
>
>however, i will give your pedantic suggestion a try.
Well, there are other, more expert users than I here, and if they have
a better idea, please feel free to jump in and make me look foolish,
it won't be either the first nor the last time. They occasionally
let me hang myself just for the 'grin factor' :-)
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
|
