--
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Sean Harvey OAO Corp harvey@nmc8.chinalake.navy.mil
Ridgecrest CA (619)939-2199
Apple surrenders
Netscape and Sun in Microsoft crosshairs
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
ORIGINAL QUESTION:
On Fri, 15 Aug 1997 sean@nmc13.chinalake.navy.mil wrote:
> Hi
>
> I am doing remote backups using the rdump and ufsdump commands. I do
> not like giving these hosts root access to my machine. Is there a way
> to do remote backups without the /.rhosts entry on the tape drive host?
> I'm thinking about some kind of suid command. Has anyone done it?
>
> Sean
>
> --
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
> Sean Harvey OAO Corp harvey@nmc8.chinalake.navy.mil
> Ridgecrest CA (619)939-2199
>
> Apple surrenders
> Netscape and Sun in Microsoft crosshairs
>
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>
THE FIX:
What I did was use an account common to the client and the host and make
it a member of the group sys. This gives the user read access to all files.
In SunOS you must add the user to the operator group. Also put .rhosts
entries in the both home directories of the account. This allows me to rsh
and run the rdump command.
THE REPLIES, THANK YOU ALL:
========================================================
Create a new account, say 'backup,' on both clients and the machine
with the tape drive. Add this user to the 'sys' group, and put
the .rhosts file in that user's home directory.
-- Tim EvansSean,
One thing you could try is Amanda 2.4.0b1.tar.gz or go with the stable 2.3.0.4 It works great locally and runs for remote backups great. The only big problem is you can't compile with optimizations on, it screwes up somewhere (with gcc 2.7.2.2) If you need any more info let me know.
Bob
ftp://pita.cs.umd.edu/pub/amanda Bob Bridgham
It's been awhile since I've done this. You can run dump as any user as long as they belong to the "sys" group. However you must be root when restoring, at least so restore can successfully do the chown. Of course you still need a .rhosts in the backup users home, just not a root.
Rick Reineman
You could start all dumps from the tape host using rsh with a special uid/gid that has access to raw devices. This means no /.rhosts on tape host, there's a user .rhosts on the machine being backed up. SunOS 4.x, for example, has the 'operator' group which has read access to all raw disk devices, if the machine to be backed up has an id belonging to this group, you could run the backup like this rsh machine -l specialid 'dump .....' | dd obs=xxx of=/dev/xxx Viet Hoang
Yes, it can be done, but not on Solaris 2.4, because of an operating system bug. On Solaris 2.5, it works fine. I'm using a dummy login, instead of "root", as the "owner" of the remote tape drives that ufsdump writes onto. The dummy login is named "beast", and instead of "/.rhosts" I use "/export/home/beast/.rhosts".
If you want complete details (my backup script and documentation), send me an e-mail.
Frank Pardo
You could write a .netlogin script that runs tar and compress/gzip, then ftp the file to the backup host,in a generic backup dir.
This could be executed under cron.
Jim Harmon The Telephone Connection jim@telecnnct.com Rockville, Maryland
When I was at Lockheed Martin, I didn't like it (root access from client to server) either. What I did was run backups as another UID (I think I called it operator), with a default group that had read-only access to the block device files. I think another scheme I used was to run scripts as root on the backup server(s) that used "rsh ufsdump ... dumphost:/dev/rmt/0n ..." or whatever. I'm afraid I don't remember any details, but if this sounds like a solution and you need to know how I did it, I could find out for you.
Michael Hill
You do no need to do dumps as root and have an .rhosts for root; a plain user with write access to the tape drive will do.
Suid won't work, you nede to do an rsh for remote dumps.
Casper
I use a separate account that has write access to the tape on the tape host, and read access to the disks on the local host. This account is called "backup", and is in group sys on the local host (since the raw disks are group sys readable).
This allows me to work with /etc/hosts.equiv, rather than /.rhosts. Not perfect, but better than root access.
Cheers, Ric (<ric@RTD.COM> "Ric Anderson", using RTD's public Internet access)
m (Dale Wiles)
I run my dumps as user 'operator', with restricted acces, who is in group 'sys'. Then I made the partitions readable by 'sys'.
Dale
(Michael Sullivan)
Use the user@machine:device syntax for the argument to the f option. The user doesn't require any special permissions, just the ability to access the=08tape device, as any ordinary user can.
>From Glenn.Satchell
There's two ways you can get around this:
1) In the script on the tapehost you run something like this
tapehost# rsh client ufsdump 0fb 126 - /usr | dd of=/dev/rmt/0n bs=126b
This way the client needs a /.rhosts entry for the tapehost but not the other way round.
2) client# ufsdump 0fb 126 dumpuser@tapehost:/dev/rmt/0n /usr
In this case dumpuser needs to be a valid user on both systems that has ~dumpuser/.rhosts set up but doesn't need to have root priviledges.
regards, -- Glenn Satchell
: Martin Huber
Option one: change the rols:
rsh -n somehost ufsdump 0ubf 126 - <fs> | dd bs=126b of=/dev/rmt/0cn
Now the unsecure host must have your hostname in /.rhosts
Option two: suggested in man ufsdump
ufsdump 0ubf 126 <usr>@<tapehost>:/dev/rmt/0cn
This will run rmt (see man rmt) on the machine <tapehost> as user <usr> elimiating the need of root access to <tapehost>
Martin
>From James.Ashton
The machine with the tape drive is going to have to trust the remote hosts to some extent so an rhosts entry of some kind will be necessary. What isn't necessary is for this to be a root rhosts file. Make the tape device accessible to some other user and run the remote dumps as this user. The trick will be making the raw partitions that you're dumping accessible to this same user. -- James Ashton
Mariel Feder
> Even though I don't like it either, I am using the entry in the /.rhosts. If you find another way, please let me know thanks mariel
(Philip Plane) Hi,
On the computer with the tape attached, create a user that can write to the tape device. Set up the .rhosts for the tape user to allow remote access from root on the remote machine. On the remote machine, do your dump to tapeuser@remotehost:tapedevice.
You may want to check out amanda, a backup program that handles dumping over the net from multiple computers very nicely. Available from ftp.cs.umd.edu:/pub/amanda
-- Philip Plane
Jens Fischer Hi Sean,
I have never tried, but something like the following should work:
ufsdump 0f - / | rsh -l <tapeuser> <tapehost> dd of=/dev/rmt/0c'
with <tapeuser> installed on <tapehost> and an entry like
dumphost root
in ~<tapeuser>/.rhosts on <tapehost>
Hope that helps
Kind Regards - Jens Fischer
Jim Kisthardt Sean:
The way I do it is this... My desktop SPARC 10 is the backup server with the tape drives (or robot or whatever). All machines that want to be backed up have to trust my backup server. It's the reverse of what you're doing. My backup script does somthing like this;
rsh <host_to_backup> ufsdump 0f - | dd b=126 o=/dev/rmt/0cn
This syntax isn't quite exactly right, but close. I don't have access to the actual syntax since it's late and I'm home right now. If you want the exact syntax and no one else gives it to you let me know and I'll send it to you.
Anyway, my server does an rsh call to every client unix machine that I want to backup. The ufsdump runs on that machine and sends its output to stdout (-) which gets piped back to the backup server into dd which sets the correct block size and writes to my local tape drive.
This way everyone has to trust my backup server and my backup server doesn't have to trust anyone. Also, no special proprietary client software to install. I've been using this process for years now and I'm very happy with it.
Hope this is helpful, dan System Admin World Color New Media
Also thanks to:
Anthony Worrall Sean Ward, Stephen Harris Stuart Beck
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:12:00 CDT