Gil, I'm confused, why would suid be needed on ufsdump - isn't it run beneith the amanda program (/usr/local/libexec/) rundump which is suid ?
For recovery, personally I use amrestore and pipe it to the required utility so as long as I can figure that out (and its imbedded into the first block on of the archive) its not a big deal. On Thu, Feb 24, 2005 at 01:14:03PM -0500, Gil Naveh wrote: > Thanks for the help, > > At this point it seems that the best way for us is to switch from ufsdump to > gnutar. > But before doing so - what will happen with the backups that I did so far? > (I backed our data on a tape drive). > Does ufsdump and gnutar stores the data the same way? (Does ufsdump level > 0,1... is identical to gnutar level 0,1...) Or does it store the data on a > different format? > Does Gnutar is going to store the data twice or is it going to overwrite the > data that was stored by ufsdump? > > Any other concerns that I should keep in mind before switching from ufsdump > to gnutar? > > Thanks, > gil > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Todd Kover > Sent: Thursday, February 24, 2005 12:37 PM > To: amanda-users@amanda.org > Subject: Re: Amanda - unable to create temporary directory > > > > Jon LaBadie said: > > > On my system /usr/sbin/ufsdump is a symbolic link to > /usr/lib/fs/ufs/ufsdump. > > The latter program is root-owned, set-uid. Perhaps yours has been > altered. > > > > $ ls -l /usr/lib/fs/ufs/ufsdump > > -r-sr-xr-x 1 root bin 83820 Apr 12 2004 /usr/lib/fs/ufs/ufsdump > > We actually strip the setuid bit on ufsdump and this seems to work in > most circumstances. > > We had this problem every night on one specific solaris 9 system, and > no other sol9 or sol8 systems (and our amanda client is installed via a > package, so it's the same across all machines). The solaris boxes are > also installed from the same jumpstart images, so they should all behave > the same. > > This error comes from ufsdump, and near as I've been able to tell, > ufsdump is creating a directory named something like '.rlg.zyaaGR in > each of /tmp and /var/tmp (and failing to be able to in / since it's not > running as root, the jibberish after .rlg. changes with each run). This > directory is called with mode 000 and then ufsdump attempts to create a > file in it, which fails and generates that error message. > > I wasn't able to get ufsdump to behave better (nor did I look for > a patch or try to reset ufsdump to being setuid again) but on that > specific system we had amanda incorrectly configured to backup something > other than the mountpoint of the filesystem, but something inside the > filesystem (that is, instead of /export/home it was /export/home/foo/bar > where the filesystem was mounted on /export/home). > > Switching this to the mountpoint made the error go away. There may be > some limitations in ufsdump that cause you only be able to use ufsdump > this way if you're root (though sounsd lke a bug). > > If you're doing this, and doing it on purpose, I'd suggest using gnutar > instead of dump since incremental dumps don't work right except on > filesystem boundaries. > > If you're not doing this and actually backing up a mountpoint, then > maybe the above info will help track it down. (perhaps the setuid bit, > as Jon suggests). > > -Todd > --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support (v) 518 486-1697 Wadsworth Center (f) 518 473-6384 NYS Department of Health Help Desk 518 473-0773