Confirmation for subscribe amanda-users
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list [EMAIL PROTECTED]. If you really want this action to be taken, please send the following commands (exactly as shown) back to [EMAIL PROTECTED]: auth e7c6df57 subscribe amanda-users [EMAIL PROTECTED] If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth e7c6df57 subscribe amanda-users \ [EMAIL PROTECTED] If you have any questions about the policy of the list owner, please contact [EMAIL PROTECTED]. Thanks! [EMAIL PROTECTED]
Confirmation for subscribe amanda-users
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list [EMAIL PROTECTED]. If you really want this action to be taken, please send the following commands (exactly as shown) back to [EMAIL PROTECTED]: auth e7c6df57 subscribe amanda-users [EMAIL PROTECTED] If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth e7c6df57 subscribe amanda-users \ [EMAIL PROTECTED] If you have any questions about the policy of the list owner, please contact [EMAIL PROTECTED]. Thanks! [EMAIL PROTECTED]
Confirmation for subscribe amanda-users
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list [EMAIL PROTECTED]. If you really want this action to be taken, please send the following commands (exactly as shown) back to [EMAIL PROTECTED]: auth e7c6df57 subscribe amanda-users [EMAIL PROTECTED] If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth e7c6df57 subscribe amanda-users \ [EMAIL PROTECTED] If you have any questions about the policy of the list owner, please contact [EMAIL PROTECTED]. Thanks! [EMAIL PROTECTED]
Confirmation for subscribe amanda-users
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list [EMAIL PROTECTED]. If you really want this action to be taken, please send the following commands (exactly as shown) back to [EMAIL PROTECTED]: auth e7c6df57 subscribe amanda-users [EMAIL PROTECTED] If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth e7c6df57 subscribe amanda-users \ [EMAIL PROTECTED] If you have any questions about the policy of the list owner, please contact [EMAIL PROTECTED]. Thanks! [EMAIL PROTECTED]
Confirmation for subscribe amanda-users
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list [EMAIL PROTECTED]. If you really want this action to be taken, please send the following commands (exactly as shown) back to [EMAIL PROTECTED]: auth e7c6df57 subscribe amanda-users [EMAIL PROTECTED] If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth e7c6df57 subscribe amanda-users \ [EMAIL PROTECTED] If you have any questions about the policy of the list owner, please contact [EMAIL PROTECTED]. Thanks! [EMAIL PROTECTED]
Confirmation for subscribe amanda-users
-- Someone (possibly you) has requested that your email address be added to or deleted from the mailing list [EMAIL PROTECTED]. If you really want this action to be taken, please send the following commands (exactly as shown) back to [EMAIL PROTECTED]: auth e7c6df57 subscribe amanda-users [EMAIL PROTECTED] If you do not want this action to be taken, simply ignore this message and the request will be disregarded. If your mailer will not allow you to send the entire command as a single line, you may split it using backslashes, like so: auth e7c6df57 subscribe amanda-users \ [EMAIL PROTECTED] If you have any questions about the policy of the list owner, please contact [EMAIL PROTECTED]. Thanks! [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
On 25 Jan 2002 at 10:37pm, [EMAIL PROTECTED] wrote My experience with tar (and perhaps things have changed with gnutar) is that is is not as judicious as dump when it comes to a complete restore. Things like block devices, modes, ownership and so on were not always restored exactly. Has this changed? That is, in the event of a disk crash, can one restore a complete file-system exactly as it was before the crash using gnutar (including file-systems with /dev fifo's and so on)? I have always had a good experience doing this with dump, but historically tar did not get it exactly right. tar will definitely get the data, modes, and ownership right. Things aren't going to be on the same inode (as they would be with dump), and I'm not sure about stuff like /dev -- it probably won't get that right. But, for my needs, all I care about *is* the data, modes, and ownership. All I back up is user data (for obvious reasons), config files (for reinstalls should a whole disk go), and logs (for security). With kickstart and a local distro mirror, I can have a system (re)installed and fully configured in 30 minutes (plus however long it takes to put the user data back). For me, that's quicker and easier than restoring the entire OS from tape. YMMV, of course. But that's my philosophy when it comes to Linux clients. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
... Things aren't going to be on the same inode (as they would be with dump) ... Not sure if I'm reading this right, but if you're implying that a restore from a backup image created with dump will bring things back with the same inode number, that's not right. The restore program that goes along with dump is just a user level program with no magic. It does normal file system open and write calls, then resets the various attributes like modification time (again, with normal OS calls). So files come back to whatever inode is handed out by the OS. and I'm not sure about stuff like /dev -- it probably won't get that right. I'm not getting into this argument again (been there, done that :-), but this was the very thing Dick was concerned about. I *thought* the combination of the way Amanda runs GNU tar and extra features of GNU tar itself brought most everything back properly. The important point here, of course, is that with **any** backup system you should test, test, test and then test some more. Amanda+gtar will either do what you want or it won't. If it won't, figure out what you need and adjust the procedures until you're covered. Joshua Baker-LePain John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
On Sat, 26 Jan 2002 at 10:56am, John R. Jackson wrote ... Things aren't going to be on the same inode (as they would be with dump) ... Not sure if I'm reading this right, but if you're implying that a restore from a backup image created with dump will bring things back with the same inode number, that's not right. The restore program that goes along with dump is just a user level program with no magic. It does normal file system open and write calls, then resets the various attributes like modification time (again, with normal OS calls). So files come back to whatever inode is handed out by the OS. Yeah, that's what I was saying, and apparently I was talking out of my a$$ -- sorry about that. I thought I recalled a discussion about dump reading at a lower level than tar (now that I think about it, maybe it was referncing xfsdump/tar vs. EAs), and went from there. You know, they say that the memory is the second thing to go. The first is, uh, something else. and I'm not sure about stuff like /dev -- it probably won't get that right. I'm not getting into this argument again (been there, done that :-), but this was the very thing Dick was concerned about. I *thought* the combination of the way Amanda runs GNU tar and extra features of GNU tar itself brought most everything back properly. Once again, I sit corrected. The important point here, of course, is that with **any** backup system you should test, test, test and then test some more. Amanda+gtar will either do what you want or it won't. If it won't, figure out what you need and adjust the procedures until you're covered. Amen. Thanks for setting me straight, John. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
Joshua, My experience with tar (and perhaps things have changed with gnutar) is that is is not as judicious as dump when it comes to a complete restore. Things like block devices, modes, ownership and so on were not always restored exactly. Has this changed? That is, in the event of a disk crash, can one restore a complete file-system exactly as it was before the crash using gnutar (including file-systems with /dev fifo's and so on)? I have always had a good experience doing this with dump, but historically tar did not get it exactly right. Dick On 25 Jan 2002 at 2:25am, [EMAIL PROTECTED] wrote I am running the dump which was installed with redhat 7.0: dump-0.4b19-4.rpm As an aside (well, as two asides): 1) You want to update that. dump picked up a new maintainer around the time of RedHat6.2/7.0, and has been progressing quite a bit since then, but... 2) You may want to consider using tar. Many on this list (myself included) have run into random 'data timeouts' using dump on 2.4 kernels. Moving to tar gets rid of those issues. Of course, now that you've got it working (thanks for stepping in John) this probably isn't what you want to hear. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: *** sendsize: debug 1 pid 10396 ruid 33 euid 33 start time Thu Jan 24 03:54:22 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 10396 finish time Thu Jan 24 03:54:23 2002 ** However, when I run dump manually on wookie, it runs with no problem and: /sbin/dump 0Ssf 1048576 - /dev/sda2 displays: 9334784 I have read the FAQ and the question regarding this issue did not seem to apply. The filesystem is very small and I didn't really understand the rest. I am in the testing phase and this is the only filesystem I am attempting to dump in an attempt to isolate the problem. I am running Red Hat Linux 7.2 and amanda-2.4.2p2 on the client and host. Can anyone help? I can post any files needed to help diagnose the problem. Thanks, Dick
Re: Confirmation for subscribe amanda-users
On 24 Jan 2002 at 11:10am, [EMAIL PROTECTED] wrote I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . I see two problems above. First, you need to apply the advfs patch from the patches page at amanda.org -- it fixes the 'unable to translate LABEL' errors above. Second, dump isn't being run with the proper permissions. What group is the amanda user in? And what does 'ls -l /dev/sda2' say? However, when I run dump manually on wookie, it runs with no problem and: Running dump as which user? If the amanda user, then what does your /etc/xinetd entry for amanda look like? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . I see two problems above. First, you need to apply the advfs patch from the patches page at amanda.org -- it fixes the 'unable to translate LABEL' errors above. Will do. Second, dump isn't being run with the proper permissions. What group is the amanda user in? From /etc/group: disk:x:6:root,rwk,amanda And what does 'ls -l /dev/sda2' say? brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 Also, amcheck *does* run successfully. Please advise and thank you for your help! Dick However, when I run dump manually on wookie, it runs with no problem and: Running dump as which user? If the amanda user, then what does your /etc/xinetd entry for amanda look like? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ** sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 ** amandad*debug says: ** amandad: debug 1 pid 8614 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 amandad: version 2.4.2p2 amandad: build: VERSION=Amanda-2.4.2p2 amandad:BUILT_DATE=Thu Jan 24 16:50:09 MST 2002 amandad:BUILT_MACH=Linux wookie.americom.com 2.2.16-22enterprise #1 SMP Tue Aug 22 16:29:32 EDT 2000 i686 unknown amandad:CC=gcc amandad: paths: bindir=/usr/local/bin sbindir=/usr/local/sbin amandad:libexecdir=/usr/local/libexec mandir=/usr/local/man amandad:AMANDA_TMPDIR=/tmp/amanda AMANDA_DBGDIR=/tmp/amanda amandad:CONFIG_DIR=/usr/local/etc/amanda DEV_PREFIX=/dev/ amandad:RDEV_PREFIX=/dev/ DUMP=/sbin/dump amandad:RESTORE=/sbin/restore SAMBA_CLIENT=/usr/bin/smbclient amandad:GNUTAR=/bin/gtar COMPRESS_PATH=/usr/bin/gzip amandad:UNCOMPRESS_PATH=/usr/bin/gzip MAILER=/usr/bin/Mail amandad:listed_incr_dir=/usr/local/var/amanda/gnutar-lists amandad: defs: DEFAULT_SERVER=wookie.americom.com amandad:DEFAULT_CONFIG=DailySet1 amandad:DEFAULT_TAPE_SERVER=wookie.americom.com amandad:DEFAULT_TAPE_DEVICE=/dev/null HAVE_MMAP HAVE_SYSVSHM amandad:LOCKING=POSIX_FCNTL SETPGRP_VOID DEBUG_CODE amandad:AMANDA_DEBUG_DAYS=4 BSD_SECURITY USE_AMANDAHOSTS amandad:CLIENT_LOGIN=amanda FORCE_USERID HAVE_GZIP amandad:COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast amandad:COMPRESS_BEST_OPT=--best UNCOMPRESS_OPT=-dc got packet: Amanda 2.4 REQ HANDLE 000-20720708 SEQ 1011917624 SECURITY USER amanda SERVICE sendsize OPTIONS maxdumps=1;hostname=wookie.internal.americom.com; DUMP /boot 0 1970:1:1:0:0:0 -1 sending ack: Amanda 2.4 ACK HANDLE 000-20720708 SEQ 1011917624 bsd security: remote host gorn.americom.com user amanda local user amanda amandahosts security check passed amandad: running service /usr/local/libexec/sendsize amandad: sending REP packet: Amanda 2.4 REP HANDLE 000-20720708 SEQ 1011917624 OPTIONS maxdumps=1; /boot 0 SIZE -1 amandad: got packet: Amanda 2.4 ACK HANDLE 000-20720708 SEQ 1011917624 amandad: pid 8614 finish time Thu Jan 24 17:13:44 2002 ** killpgrp*debug says: ** killpgrp: debug 1 pid 8616 ruid 33 euid 0 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/killpgrp: version 2.4.2p2 sending SIGTERM to process group 8616 child process exited with status 1 ** The amcheck program succeeds. Is there anything I can run on the client to indicate why it is failing? Thanks, Dick I am getting the following error from amdump: FAILURE AND STRANGE DUMP SUMMARY: wookie.int /boot lev 0 FAILED [disk /boot offline on wookie.internal.americom.com?] On wookie, the file sendsize.20020124035422.debug says: running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . I see two problems above. First, you need to apply the advfs patch from the patches page at amanda.org -- it fixes the 'unable to translate LABEL' errors above. Will do. Second, dump isn't being run with the proper permissions. What group is the amanda user in? From /etc/group: disk:x:6:root,rwk,amanda And what does 'ls -l /dev/sda2' say? brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 Also, amcheck *does* run successfully. Please advise and thank you for your help! Dick However, when I run dump manually on wookie, it runs with no problem and: Running dump as which user? If the amanda user, then what does your /etc/xinetd entry for amanda look like? -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Confirmation for subscribe amanda-users
[EMAIL PROTECTED] wrote: I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ** sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 ** The only *problem* is that dump can't open /dev/sda2 for reading. Try: su -c amanda id If that doesn't tell you that amanda is in whatever group owns the disk, that's your problem, and you need to verify that the (numeric) group id used in /etc/passwd is the group that owns the disk. Marty -- Marty Shannon, RHCE, Independent Computing Consultant mailto:[EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
# su -c amanda id uid=33(amanda) gid=6(disk) groups=6(disk) # ls -l /dev/sda2 brw-rw1 root disk 8, 2 Aug 24 2000 /dev/sda2 # ls -ln /dev/sda2 brw-rw1 06 8, 2 Aug 24 2000 /dev/sda2 # grep disk /etc/group disk:x:6:root,rwk,amanda # grep amanda /etc/passwd amanda:x:33:6:Amanda user:/var/lib/amanda:/bin/bash Also, I can run dump manually (on the client) as the amanda user and it runs with no problem: # sys su amanda -c '/sbin/dump 0Ssf 1048576 - /dev/sda2' 9334784 What do you make of it? The only *problem* is that dump can't open /dev/sda2 for reading. Try: su -c amanda id If that doesn't tell you that amanda is in whatever group owns the disk, that's your problem, and you need to verify that the (numeric) group id used in /etc/passwd is the group that owns the disk. [EMAIL PROTECTED] wrote: I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ** sendsize: debug 1 pid 8615 ruid 33 euid 33 start time Thu Jan 24 17:13:43 2002 /usr/local/libexec/sendsize: version 2.4.2p2 calculating for amname '/boot', dirname '/boot' sendsize: getting size via dump for /boot level 0 sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot /dev/sda2: Permission denied while opening filesystem . (no size line match in above dump output) . asking killpgrp to terminate sendsize: pid 8615 finish time Thu Jan 24 17:13:44 2002 ** The only *problem* is that dump can't open /dev/sda2 for reading. Try: su -c amanda id If that doesn't tell you that amanda is in whatever group owns the disk, that's your problem, and you need to verify that the (numeric) group id used in /etc/passwd is the group that owns the disk. Marty -- Marty Shannon, RHCE, Independent Computing Consultant mailto:[EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
I installed advfs.diff on the client (wookie) and reran the test dump but the sendsize*dump file still says: ... sendsize: running /sbin/dump 0Ssf 1048576 - /dev/sda2 running /usr/local/libexec/killpgrp DUMP: Warning: unable to translate LABEL=/ DUMP: Warning: unable to translate LABEL=/boot Note that it's not sendsize whining about LABEL=, it's dump itself. My guess is your version of dump needs to be updated, and it wouldn't surprise me to hear that that also fixes the permission denied problem. Dick John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Confirmation for subscribe amanda-users
One other thing. Joshua asked what your amandad xinetd entry looked like. In particular, you need groups yes (or something like that) to make xinetd put amandad in all the alternate groups (why they didn't make this the default is beyond me). Without that, amandad will only be run in its primary group, which is not disk and thus has no access. When you use su, you get all the alternate groups, so that's why it works from there. I have a TODO list item to log the alternate groups in the debug file, which would help diagnose this problem, but it's harder than you might think (it used to be a non-standard system call, so portability is a problem). John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
