itnm_status command gives up/down status for all ITNM related process, eg:
[root@testinghost]# itnm_status ncp
ncp_ctrl RUNNING PID=5598 NCOMS
ncp_store RUNNING PID=6300 NCOMS
ncp_class RUNNING PID=6304 NCOMS
ncp_model RUNNING PID=6553 NCOMS
ncp_disco WAIT_HB PID=6652 NCOMS
ncp_d_helpserv RUNNING PID=6305 NCOMS
ncp_config RUNNING PID=6307 NCOMS
ncp_poller(default) RUNNING PID=6736 NCOMS
nco_p_ncpmonitor RUNNING PID=6352 NCOMS
ncp_g_event RUNNING PID=6653 NCOMS
ncp_webtool RUNNING PID=6353 NCOMS
ncp_virtualdomain RUNNING PID=6936 NCOMS
following is a list of possible status and their meanings:
WAITING: the process is waiting for all depending process to be in RUNNING status.
WAIT_HB: the process is up, ncp_ctrl is yet to receive heartbeat from the process.
Note: only process that can send heartbeat to ncp_ctrl can be managed.
From archive: July 2011 X
Yulei.Liu.AU 270001E5WU 4,821 Views
Object server can be configured to authenticate with external source, for example LDAP or Microsoft Active Directory or Linux Plug-able Authentication Model.
Objectserver has an Out-Of-Box automation called disable_user that can disable users after 5 failed consecutive login failure. this is a security feature of object server.
in an environment where Objectserver is configured to authenticate with external sources, it is desirable to leave disabling of external account to it's authentication source, this is to maintain a central place for account management and also simplify the unlocking process.
I've changed the default 'disable_users' as following, to disable locking of external users in objectserver. I've marked the change in RED
create or replace trigger disable_user
comment 'Disable users when they fail to log on after n consecutive failures'
on signal login_failed
set failurecount = 5;
set userfound = false;
for each row disable_user in alerts.login_failures where
disable_user.UserName = %signal.username
if ( disable_user.FailureCount >= failurecount )
-- Zero the failure count - to ensure they aren't disabled immediately the user is re-enabled.
set disable_user.FailureCount = 0;
set disable_user.LastFailure = getdate();
-- Disable the user.
alter user %signal.username set enabled false;
-- Put an event into alerts.status.
insert into alerts.status (Identifier, Summary, Node, Manager, Type, Severity, FirstOccurrence, LastOccurrence, AlertGroup, OwnerUID) values ('Disabling user '+%signal.username+' from host '+%signal.node+' failure count exceeded', 'Disabling user '+%signal.username+' from host '+%signal.node+' failure count exceeded', %signal.node, 'SecurityWatch', 1, 5, %signal.at, %signal.at, %signal.process, 65534);
elseif ( disable_user.FailureCount < failurecount )
-- Increment the failure count for the user
set disable_user.FailureCount = disable_user.FailureCount+1;
set disable_user.LastFailure = getdate();
set userfound = true;
-- If the user wasn't in the table, add them now.
if ( userfound = false )
for each row existing_user in security.users where
existing_user.UserName = %signal.username and (existing_user.UsePAM=false)
insert into alerts.login_failures ( UserName, LastFailure, FailureCount ) values ( %signal.username, getdate(), 1 );
Yulei.Liu.AU 270001E5WU 2,784 Views
Similar approach has been used to find out firewall ports that need to be open between probe and AMS 5520 OAD, they are:
4459 or 44578443 or 8080
5002 or 5001
I had some trouble recently connecting nco_p_alcatel_sam_5620_v8 to a SAM instance in a controlled environment . although the probe connect to SOAP port fine and get can existing alarms, it fails to connect to the JMS port, which is for sub-sequential alarms. the same probe with same setting works fine if the probe and SAM is in one LAN. so this must be a firewall issue.
I used tcpdump to capture all traffics on the good probe, and found all the ports that the probe has send a SYN on, they are:
8443 or 8080 depending on if HTTPS or HTTP is used.
note: the command I used is:
tcpdump -i eth2 host SAMHOSTNAME and 'tcp[tcpflags] & tcp-syn == tcp-syn'
hope this helps.
Note: I've learned a new way of identifying those blocked firewall from my friend James, if you run following command quick enough you should be able to see what's wrong:
netstat -an|grep SYN