Switching to GNUTAR - RE: Amanda - unable to create temporary directory
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
Re: Switching to GNUTAR - RE: Amanda - unable to create temporary directory
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 HealthHelp Desk 518 473-0773
Re: Switching to GNUTAR - RE: Amanda - unable to create temporary directory
On Thu, Feb 24, 2005 at 02:16:36PM -0500, Brian Cuttler wrote: 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 ? It is not an amanda requirement, it is the way the system supplies ufsdump. I suspect it is so that things like /etc/dumpdates can be updated. Though I'm not sure /etc/dumpdates gets updated when ufsdump is run by an ordinary user. I'm pretty sure that if run by an ordinary user ufsdump would switch id's to do the actual reading of files so that the ordinary user does not get to backup files they are not allowed to see under normal circumstances. But there may be a few tasks that require root privleges outside of the actual dumping. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Switching to GNUTAR - RE: Amanda - unable to create temporary directory
On Thu, Feb 24, 2005 at 01:14:03PM -0500, Gil Naveh wrote: 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). If you change the program in your dumptype from DUMP to GNUTAR, you will not be able to use amrecover to get your data back from the earlier backups. Newer backups yes, older ones no. You could use amrestore and the appropriate dump program or you could temporarily reset the program parameter while you do your amrecover. 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? Same way as far as dumplevels are concerned, but the storage format is totally different. Does Gnutar is going to store the data twice or is it going to overwrite the data that was stored by ufsdump? I don't get what you are asking by the twice question. But amanda does not overwrite things because you change a parameter. Only when a tape gets reused will the old dump data be overwritten. Any other concerns that I should keep in mind before switching from ufsdump to gnutar? Unix systems keep 3 timestamps for each file. Because a dump program avoids accessing the files via the normal filesystem calls, these time stamps are not altered by backing up a file. Tar does work with normal filesystem calls. At least one of the 3 timestames will be affected, either the last time the file was read (shows with ls -la) or the last time the file properties were changed (shows with ls -lc). If you do choose to make the switch, I suggest you do it a few DLE's at a time. Change their dumptypes and then uses amadmin to force a level 0 dump for that DLE the next run. A tar level 1 or 2 will not be much use with a ufsdump level 0. -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: Still can't get you delete superfluous stuff and to bottom or inline post huh? -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
