OC SS7 config/startup problems

[Alan Phillips_2]

I am trying to get a new Opencall SS7 installation going and am having numerous problems that I think are most likely related to my configuration. This being my first experience with OC SS7, I'm pretty lost.

I've created a configuration and when I run cfgCheck against that config, it produces the following output (condensed):

Execute the script:
cfgCheck -config /etc/opt/HP-AIN/config

==> Collecting configuration information of the platform
===> Checking the hosts access
===> Checking the configuration of system 'capella'
---> Checking the /etc/hosts file
Warning : file '/etc/resolv.conf' exists on system 'capella'
Error : can not access the /etc/hosts on system 'capella'
---> Checking the OC SS7 global configuration file
Error : can not access the global.conf file on system 'capella'
---> Checking the OC SS7 FT processes configuration file
Error : can not access the ftc.conf file on system 'capella'
---> Checking the lock files associated to the OC SS7 event collectors
---> Checking the OC SS7 hardware configuration file
Warning : can not access the ss7.hw file on system 'capella'
===> Checking the coherence between the different systems of the platform
---> Collecting information from system 'capella'
Error : can not access the sys.SS7_Stack_1.mtp for stack type 'WAA' on system 'capella'
Error : can not access the sys.SS7_Stack_1.sccp for stack type 'WAA' on system 'capella'
Error : can not access the sys.SS7_Stack_1.tcap for stack type 'WAA' on system 'capella'
---> Checking the coherence between the global configuration files
---> Checking the coherence between the FT processes configuration files
---> Checking the coherence between the typeDB files
---> Checking the coherence between the TSU/TSC configuration files
End of plaform configuration checking


In my attempt to figure this out, I ran swverify. The output contained numerous errors and warnings. Many of them concerned timestamp and file size, but I don't have a clue why there would be a discrepancy.

Also, I've checked the etc/hosts, etc/resolv.conf and etc/nsswitch.conf files and do not see anything that looks wrong, but maybe someone else can see something, so here they are:

hosts:
127.0.0.1 localhost loopback
x.x.x.x capella

resolv.conf:
domain x.x.x.x # IP addr of local dns ???
nameserver x.x.x.x # IP addr of local dns

nsswitch.conf:
hosts: files [NOTFOUND=continue] dns


If there is additional info that would help, I will try to get it.

Thank you,
Alan Phillips

[Bill McNAMARA_1]

You need to add the user ss7admin to roots .rhosts and vice versa:

ie:
as root:
echo "capella ss7admin" > /.rhosts
echo "capella ss7admin" > ~ss7admin/.rhosts
echo "capella root" > ~ss7admin/.rhosts

This will correct your problem.
At least once you've got the user ss7admin. In the 3.2 the user becomes ocadmin.

You should refer to the docs or end up in a world of pain.
http://docs.hp.com/hpux/telecom/

Later,
Bill

[Bill McNAMARA_1]

Ok, there are a few other things.

The cfgCheck should only be run after a valid configuration (SAM -> HPOC SS7 Configuration) has been created. Otherwise, all those files, like the ss7.hw and links to Stack colour (WBB) etc will not be made. I'll come back to that...
The DNS issue is really only an issue when you use the OC SS7 in built HA mechanisms in a duplex platform (ie with 2 TSUs and 2 hosts)
I guess you're using a simplex platform - note if you're looking for HA in system, a new product will be released shortly based on linux that yours truly is working on.. fantastic. Your DNS resolution of file first is good.

Ok, back to the config.
First thing to do is Creat a config.. say how many stacks you want, what color they are, install the platform license (to authorise link capacity). This configured the FTC (fault tolerant controller) to monitor the Stack for unexpected failure and restart if necessary... this is controlled via the ftc.conf that is not currently accesible.

The ss7.hw is then created when you click on the auto-discover signaling hardware. You then create link definitions (ie what port they're on - on which TSC). Then after link creation the stacks will start. However not much will happen because you haven't configured the stack properties such as DPC, LPC, SLCs etc. This you do when the stack has started: ss7Start (as ss7admin user) (wait 1 minute) (ps -ef | grep HPSS) ss7MgrStart then refer to the doc....

log files that are more appropriate are activated via (as root)
stopnettl
cleanttl
startnettl
wlog (X environment required)
wmsg (X environment required)

you can record log files to file:
nlog > /tmp/nlog.log
nmsg > /tmp/wmsg.log

Do you have support on this?
Who are you?!
Typically most customers will not be doing this by themselves, there should be onsite services configuring your network for proper network compliance/conformance. Certain files namely for MTP,TCAP, ISUP and SCCP require manual file modification for your particular network.
The service doesn't cost much for 1 week training and on site setup and will save you so much bother in the long run. On your own it'll take longer to understand it all as you go along.

I can give you the email of the support team that deal with this if it interest you.
Otherwise the doc approach in the previous mail is the way to go.

Later,
Bill

[Alan Phillips_2]

Bill,

Thank you for your responses. The first one regarding the .rhosts files did resolve my problem. I had previously created a configuration and attempted to start it, but had errors. Now I can start the SS7 stack as well as the Platform Monitor and SS7 Monitor - now I'm proceeding with configuring the other
things - LPC, DPCs, links, etc.

To answer your question, we (ITS) are a telecom software company that has a partner relationship (ISV) with HP. We are currently looking at developing and/or porting some of our apps on the OC SS7 platform. The box we're using had the OC SS7 software (most of it, at least) installed and a configuration created by HP Americas Integration Center, then it was sent to us. Now we're starting to learn it and play with it.

Thanks very much for your help!
Alan Phillips

[Bill McNAMARA_1]

That's great! Well done.
If you've any other questions fire away!