Yes the secondary system (axscnv2) was cloned from the primary (axscnv1). As I
said, this is the first time we're attempting to use the secondary systems
framework to forward events to TEC, so thats why we're just now noticing this
problem. We do only copy the NetView databases weekly so the problem probably
is due to the original system cloning.
Yes I did try the commands listed below, but that didn't seem to work.
Could you direct me as to what books (chapters) I specifically need to look at.
Thanks........Lucy
"James Shanks" <James_Shanks@TIVOLI.COM> on 06/08/99 03:19:54 PM
Please respond to "Discussion of IBM NetView and POLYCENTER Manager on NetView"
<NV-L@UCSBVM.ucsb.edu>
To: NV-L@UCSBVM.ucsb.edu
cc: (bcc: Lucy Premus/Bsg/MetLife/US)
Subject: Re: NETVIEW SERVER IP ADDRESS CHANGE
Lucy -
I'm not sure how you got into this situation because you don't need to
tranfer the TMR server stuff from one machine to another to do what you are
doing. Why did you do that? You should just be moving
/usr/OV/databases/openview and running reset_ci like users have always
done. So how did the Framework stuff get moved? Did you clone one box
from the other rather than install NetView twice?
My append was for someone permanently moving from one box to another. Once
done that should not have to be down again.
What you want to do is to move just the NetView stuff, not the Tivoli
framework stuff, from box to another . And now you need to get out the
Framework books and look them over because you need to tell the oserv that
he is on a different box . Did you try running the oserv command listed
below on axscnv2 or not? Just like reset_ci it depends upon axscnv2
knowing that he is axscnv2 . Does hostname give you the right result?
James Shanks
Tivoli (NetView for UNIX) L3 Support
Lucy Premus <lpremus@METLIFE.COM> on 06/08/99 02:45:51 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: NETVIEW SERVER IP ADDRESS CHANGE
James, attached is a response you gave back in March with respect to what
needs
to be done when changing the IP address of your NetView server. In
particular I
am concerned with the effect is has on the Tivoli Framework and what needs
to be
done to rectifiy that.
Actually our situation is a little different. Yes the address of the
NetView
server is changing, however it changes weekly. I'll explain. We have 2
NetView
servers (axscnv1 and axscnv2). A primary and a secondary. Every week we
copy
the NetView databases from the primary to the secondary and as part of the
process (within a script) we've been running the reset_ci command to
reconcile
the address difference. However, we haven't really needed to use the
Tivoli
desktop capabilities, until now. We are trying to configure our secondary
NetView system to forward events to our TMR server (on another system). It
doesn't seem to be working and I have a hunch its due to the change of
address
problem. The reason I'm saying this is that when you bring up the desktop
on
our secondary NetView system the policy region name refers to our primary
system
(ie. axscnv1). It seems that everything else associated with this
references
axscnv1 instead of axscnv2. For example the /var/spool/Tivoli/?????.db
file on
the secondary system has axscnv1.db instead of axscnv2.db.
I'm a true rookie when it comes to the Tivoli framework stuff, so hopefully
what
I'm saying makes some sense to you. Any ideas???
Anyone feel free to respond. Thanks.................Lucy
---------------------- Forwarded by Lucy Premus/Bsg/MetLife/US on 06/08/99
02:33
PM ---------------------------
(Embedded image moved to file: pic03865.pcx) Linda Parry
06/02/99 02:09 PM
To: Lucy Premus/Bsg/MetLife/US@MetLife
cc:
Subject: Re: NETVIEW SERVER IP ADDRESS CHANGE
---------------------- Forwarded by Linda Parry/Bsg/MetLife/US on 06/02/99
02:03
PM ---------------------------
(Embedded
image moved James Shanks <James_Shanks @ TIVOLI.COM>
to file: 03/17/99 01:41 PM
pic18134.pcx)
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView
<NV-L@UCSBVM.ucsb.edu>
To: NV-L @ UCSBVM.ucsb.edu
cc: (bcc: Linda Parry/Bsg/MetLife/US)
Subject: Re: NETVIEW SERVER IP ADDRESS CHANGE
/usr/OV/service/reset_ci is the answer, as several folks have noted, and it
is documented in the Diagnosis Guide. It is a script so you can see what
it does.
But if you are running NetView V5 or V5.1 then you will also have to
change the IP Address used by the oserv for the Framework, or you will not
have a a working Tivoli desktop (the thing you get when you type "tivoli").
If the only reason you installed the Framework was for NetView, and your
NetView box is also the TMR server and the only managed node in its domain,
then reset_ci will attempt to fix that for you, as well as the NetView
address. But this doesn't always work. If not, then you can try this
command as root:
oserv -k $DBDIR -N ali
Note that since it uses $DBDIR you must have sourced the Tivoli environment
first
(issue . /etc/Tivoli/setup_env.sh and don't forget that leading "dot
space")
If your NetView server is not the TMR server or is part of a larger Tivoli
domain, then you should consult the Framework users guide about what to do,
and typically you must do this BEFORE you change the IP address that the
oserv depends on.
James Shanks
Tivoli (NetView for UNIX) L3 Support
"Ken Garst." <KGarst@GIANTOFMARYLAND.COM> on 03/17/99 12:25:33 PM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on
NetView <NV-L@UCSBVM.UCSB.EDU>
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks)
Subject: Re: NETVIEW SERVER IP ADDRESS CHANGE
To change the IP address of the Netview server is easy. On an AIX host,
just use smitty inet and enter the new ip address for the adapter.
However, you must tell Netview about this change by issuing the command
reset_ci, which in turn attaches the new ipaddr=hostname to the maps. If
you are running the Netview client with local maps, you must change the
hostname associated with the local map back to the client's hostname by
issuing the command mapadmin -u <mapname>:<client_hostname> on either the
server or client.
Finally, all devices sending traps to Netview must have the new ipaddress
entered as a trap destination into their snmpd.conf files and their snmpd
daemons refreshed. This is nontrivial. On Bay Networks switches, hubs and
routers, this means rebooting them and loss of communications until the
reboot takes effect.
Good luck!
kg
kgarst@giantofmaryland.com
pic03865.pcx
Description: Binary data
pic18134.pcx
Description: Binary data
|