Original question:
> The subject pretty much says it all. I have a user who has her
>own tape drive and wants to be able to do incremental backups. I made
>her part of the "operator" group and wrote two scripts to handle the
>dumps for her. The level 0 dump works fine, but I can't get it
>to do incremental dumps. I've traced it down to fact that /etc/dumpdates
>is not being updated, even though I did include "u" as one of the options.
>And she is dumping a full partition, so dump is not defaulting to level 0.
>
>/etc/dumpdates is writeable by group "operator", and I did verify that
>this user could write to the file.
>
>What am I missing? I hope I'm not answering my own question, but I'm
>afraid to change this:
>
>hvsun21# ll -g /usr/etc/dump
>-rwsr-sr-x 1 root tty 57344 Jul 23 1992 /usr/etc/dump
> ^^^
>Is this my problem, or is it something else I've been too blind to
>see?
>
>Thanks for any help.
Well, I received a few responses, all of them fairly short, so
I'll just show them all (or at least the meat of them). I haven't
had time to get back to this problem, but now at least when I do
I have something to go on. Thanks to all who responded.
One other thing I forgot to mention, in case anyone else has some
insight, is that I'm on a SS2 w/ SunOS 4.1.3.
-- David Willard (willard@hvsun21.mdc.com) Unix Systems Analyst Programmer, McDonnell Douglas Aerospace Huntsville, AL======================= From: jpl@allegra.att.com (John P. Linderman)
Different versions of dump update /etc/dumpdates in different ways. Older versions wrote a temp file in /etc and renamed the result at the end. Nice and atomic, but it requires write permission in /etc. More recent releases use ftruncate and rewrite dumpdates in place. Less atomic, but all you need is write permission on dumpdates itself.
======================= From: mrmach@mtu.edu (Mark R. Mach)
Dump doesn't actually write into /etc/dumpdates by itself... You need to do something like this to do so.
Try using this command in the script that starts your dumps:
echo "/dev/<device> <level of dump> "`date` > /etc/dumpdates
======================= From: szh@zcon.com (Syed Zaeem Hosain)
> What am I missing? I hope I'm not answering my own question, but I'm > afraid to change this: > > hvsun21# ll -g /usr/etc/dump > -rwsr-sr-x 1 root tty 57344 Jul 23 1992 /usr/etc/dump > ^^^ > Is this my problem, or is it something else I've been too blind to > see?
I do not know exactly. On my machine the same file has group set to operator. So, maybe that is it.
======================= From: hkatz@nucmed.NYU.EDU (Henry Katz)
David,
I like to tinker so I used sudo instead of assigning groups and can do an incremental dump without any difficulties:
>[54] henry@immagini: sudo dump 2f test `pwd`/gnu > DUMP: Date of this level 0 dump: Tue Jun 15 00:17:46 1993 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping /dev/rsd1c (/usr2) to test > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 1058 blocks (529KB) on 0.01 tape(s). > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > DUMP: Tape rewinding > DUMP: 1142 blocks (571KB) on 1 volume > DUMP: DUMP IS DONE >[55] henry@immagini:
The perms, incidentally, are correct on dump.
======================= From: trinkle@cs.purdue.edu (Daniel Trinkle)
The dump program is setgid tty so it can write messages to the operator's tty when it is time to change tapes (when using multiple tapes for a dump), or some other error occurs.
The /etc/dumpdates file must be writable by the process. The process inherits the groups of the users, and the setgid group of the binary. Therefore, if you make the /etc/dumpdates file group writable by the user doing the backups, or put that user in group operator, your problem should be solved.
======================= From: etnibsd!vsh@uunet.UU.NET
I'm pretty sure this is correct:
The effective user/group of the dump program must also be able to write to the /etc directory, as it creates a new dumpdates file rather than overwriting the existing one.
======================= From: glenn@uniq.com.au (Glenn Satchell - Uniq Professional Services)
Has this user logged out and logged in again since you changed the groups? Group membership is set at login time only. You can check this by just using the command "groups" rather than "groups user". The loookup method is different. If you've put her in the NIS groups make sure that you made and pushed the netid map.
My permissions, SunOS 4.1.2:
$ ls -lg /usr/etc/dump -rwsr-sr-x 1 root tty 57344 Oct 24 1991 /usr/etc/dump $ ls -lg /etc/dumpdates -rw-rw-r-- 1 root operator 528 Jun 14 23:41 /etc/dumpdates
======================= From: A.D.Hoekstra@wb.utwente.nl (Andre Hoekstra)
Maybe (I'm no wizard myself) it is the sgid bit on dump? But then again I am not sure, because dump should run with uid/gid = user/operator (real ids) and euid/egid root/tty (effective ids). I believe the e?id is important, so /etc/dumpdates is alway writable to whoever executes dump.
I hope this doesn't confuse you. I know it is no solution too, but maybe it gives you some inout to the 'Eureka thought'
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:07:57 CDT