| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 523.1 | | DECWET::RWALKER | Roger Walker - Media Changers | Tue Mar 25 1997 07:33 | 1 |
| You need to update /nsr/res/servers to include the new system.
|
| 523.2 | | DECWET::ONO | Software doesn't break-it comes broken | Tue Mar 25 1997 08:41 | 8 |
| There is a procedure in the Addendum that describes how to do
this. In the V4.2A manual, it starts at page 77.
You may need to edit the nsr.res file and change the occurrences
of @old-server to @new-server. It seems that the new server is
not being allowed to access certain files.
Wes
|
| 523.3 | new server name is same as old | NETRIX::"[email protected]" | Jason Wold | Tue Mar 25 1997 09:53 | 4 |
| and I even used the same IP address. I will take a look at the addendum.
Jason
[Posted by WWW Notes gateway]
|
| 523.4 | | DECWET::ONO | Software doesn't break-it comes broken | Tue Mar 25 1997 10:54 | 14 |
| Looks like my assumptions in .2 were incorrect.
Is this index the only one that fails, or are there others?
Have you checked the protections on the NetWorker binaries? Some
of them should have the suid bit set. ls -l /usr/bin/save should
show a link to the kit directory (/usr/opt/<something>). Take
that path and do an ls -l /usr/opt/<something>/*save*. All of
these files should have the suid bit set.
Is this backup being run via a scheduled savegroup, or is it
being run either manually or via a cron job?
Wes
|
| 523.5 | problem with addendum procedure | NETRIX::"[email protected]" | Jason Wold | Tue Mar 25 1997 11:03 | 17 |
| I am following the procedure for migrating my network environment as
reccomended in .2. When I get to the part where I am to run
uasm -s -f /tmp/directive . | ( cd /mnt; uasm -rv )
It copies the file mm/wissvids.dat and then stalls. nsrmmdbasm starts up as
if
it is going to copy the mm/mmvolume file but it is sleeping and there is no
network traffic between the two machines. I waited about half an hour and the
mmvolume did not even start copying and the system is completely idle. If I
kill the process and start over I get the same results.
Do I have to use uasm to copy /nsr? dump/restore or piped tar will not work
right?
Jason
[Posted by WWW Notes gateway]
|
| 523.6 | reply to .4 | NETRIX::"[email protected]" | Jason Wold | Tue Mar 25 1997 11:12 | 23 |
| All manual and scheduled backups fail with the same behavior while trying to
save the index.
I had originally copied all of the index files with tar and not uasm as stated
in the addendum but I am running into problems with the procedure in the
addendum. (see note 523.5) Not sure if this is the problem I am going from
an DEC 3000/500 model to a AlphaStation 255. It looked to me like the uasm
stuff was for going from one architecture to another so I don't think this
would
be the problem. Correct me if I am wrong.
All of the binaries have the correct permissions, as they should because I
installed them all from the original kit and not by copying them from the old
server.
I do have more patches installed on the new server than on the old one.
I think I will try uninstalling some of the patches on the new server for lack
of
anything else to try.
Jason
[Posted by WWW Notes gateway]
|
| 523.7 | problem narrowed down??? | NETRIX::"[email protected]" | Jason Wold | Tue Mar 25 1997 14:28 | 16 |
| We think the problem is that we can not get the mmvolume file copied over
correctly. We are unable to use the method posted in the addendum because
nsrmmdbasm does not appear to work correctly.
nsrmmdbasm -si mmvolume
does not produce any output.
uasm -si mmvolume
does but the resulting file is still not correct. Any hints on how to get
nsrmmdbasm to do its thing?
Thanks,
JAson
[Posted by WWW Notes gateway]
|
| 523.8 | problem solved.... | NETRIX::"[email protected]" | Jason Wold | Tue Mar 25 1997 16:16 | 17 |
| We never got the nsrindexasm or the nsrmmdbasm working for the copy but
it appears that just copying the files using uasm with the holey option works.
Actually just copying the files apears to work but since the files are holey
our
database grew a bit larger by using regular copy or tar.
Chalk another one up for user error...
The error posted in .0 was due to the fact that our nsrexecd was not starting
properly and we did not check it thouroughly enough. Sorry if anyone wasted
too much time on this (like us). We did find the problems with asm's
mentioned
above though.
Anyway, thanks for all the help.
Jason
[Posted by WWW Notes gateway]
|