I have PIM 12.8SP1(2391) Endpoint installed on SunOS 11.3 SRU31.6. I was able to login selang command line but recently I am getting following errors-
root@Host01:~# selangERROR: Initialization failed, EXITING!(localhost)ERROR: Connection failedHost is unreachable
Some times, I can do login to selang command line prompt and gets following error-
AC> su u123456(localhost)ERROR: Internal error
I tried to restart PIM services, rebuild sebuildla DB as well as SEOSDB but no luck. Can someone help me to resolve this issue.
Thanks in advance.
Is this a new installation? Perhaps you did not reset the encryption key? I can reproduce the first issue at will:
bash-3.00# ./install_base -force_encrypt -autocfg -command Proceed
I went to ‘host’ from the ServerA machine -> ServerB machine and I received this:
AC> host ServerB(ServerB)ERROR: Connection failedHost is unreachable
bash-3.00# sechkey -d test123CA ControlMinder sechkey v188.8.131.522 - internal key changerCopyright (c) 2013 CA. All rights reserved.
Searching '/opt/CA/AccessControl/lib/libcrypt' for key...Found and replaced.Searching '/opt/CA/AccessControl/bin/seload' for key...Found and replaced.Searching '/opt/CA/AccessControl/lib/libcryptscr.o' for key...Found and replaced.
AC> host ServerB(ServerB)Successfully connectedINFO: Target host's version is 12.81-0 (1912)
So, you have to force_encrypt on the 12.8 SP1 install on the endpoint. After, you will need to reset the encryption key and it will allow the 'host' connection from ServerA to ServerB and ServerB to ServerA.
Please check if you are using the same encryption standard on each endpoint. Within your /etc/seos.ini, you can check these values:
; This token indicates which password encryption method the local system; uses to distribute user passwords.; Valid values are: '1' - Compatibility mode - working with older; versions of eAC, hence we use 'crypt' like we used to,; or '2' - MD5 hashing - when working in Linux only environment use; 'crypt' with MD5 salt, or '3' - bidirectional mode - where we encrypt; the passwords with our own bidirectional encryption.; Default Value: 1passwd_distribution_encryption_mode = 1
; This token indicates in which password encryption method the local system; stores user passwords.; Valid values are: crypt md5 sha256 sha512; Default Value: cryptpasswd_local_encryption_method = crypt
If this still does not help, please open a case and we will help resolve your issue.
Thank you for response and your time. Certainly I would have tried it but in my case communication is on same server(locally). I am connecting to local SEOSD not the remote SEOSD. Your help is highly appreciated.
If you are trying to use the local seosd to launch selang then maybe ‘localhost’ is not getting to the loopback 127.0.0.1 address. It appears something is blocking our local connection.
# nslookup localhostServer: IP_hereAddress: IP_here
Non-authoritative answer:Name: localhost.localhost.comAddress: 127.0.0.1
If this does not help, I can create a case to help investigate this further. I hope this helps.
nslookup localhost resolves 127.0.0.1. still does not works. I have support ticket opened '01139681' for this.
I checked case 01139681 and saw that port 8891 is not available. You cannot telnet to localhost using port 8891 - meaning this port is blocked on znsfccapps29.
CA ControlMinder uses only port 8891. You can change the default port number by modifying the /etc/services file settings. To modify the default port number, add the following line, then restart CA ControlMinder daemons:
seoslang2 port-number/ tcp
However, we recommended that you do not change this port (seagent Daemon - CA Privileged Identity Manager - 12.9.02 - CA Technologies Documentation).
I hope this helps.
I checked for any blocking of port 8891 but I do not have it blocked. Some how seagent service getting stopped automatically. It was working fine in past.
[root@gomer02~]# netstat -tulpn | grep 8891
[root@gomer02~]# seloadCA Privileged Access Manager Server Control seload v14.01.0.412 - Loader UtilityCopyright (c) 2016 CA. All rights reserved.26 Jul 2018 10:21:38> WAKE_UP : Server going up26 Jul 2018 10:21:38> INFO : Filter mask: 'WATCHDOG*' is registered26 Jul 2018 10:21:38> INFO : Filter mask: 'INFO : Setting PV*' is registered26 Jul 2018 10:21:38> INFO : Filter mask: 'INFO : DB*' is registered26 Jul 2018 10:21:38> INFO : Filter mask: '*seosd.trace*' is registered26 Jul 2018 10:21:38> INFO : Filter mask: '*FILE*secons*(*/log/*)*' is registeredStarting seosd. PID = 5288.Checking database ...Starting seagent. PID = 5291seagent: Loading database image...Starting seoswd. PID = 5304seagent: Initialization phase completedExecuting [daemons] command: /opt/CA/AccessControlShared/lbin/report_agent.sh/opt/CA/AccessControlShared/bin/ReportAgentERROR: Report Agent already running.Executing [daemons] command: /opt/CA/AccessControlShared/lbin/agent_manager.sh/opt/CA/AccessControlShared/bin/AgentManager startAgentManager is already running.
[root@gomer02~]# netstat -tulpn | grep 8891tcp 0 0 0.0.0.0:8891 0.0.0.0:* LISTEN 5291/seagent
You should be able to verify if seagent is using port 8891 when we are loaded into the kernel extension.
The only other suggestion that I can think of is to ensure the communication password is the same on all servers.
Appreciate your time and help to get my issue resolved. Regarding selaod, we see below error.
seagent: Loading database image...seagent: Failed to load database image
I have already tried to re-index all seosdb as well as rebuild seosdb in new location but did not help me to resolve the issue.
I have seen this issue when older packages are installed on newer kernels because those older packages do not have any additional supported system calls.
I think this would be better handled in a case where we could do specific information gathering on the problematic host in which the forum is not a suitable environment for such types of inquiries. If you would like, I can create a case for you and we can go over this together.
Thank you for your time and help. I have already a ticket opened and following there. If necessary I'll let you know.
I am following up on the community post you created where you are unable to connect to the selang console. After we spoke earlier today, you said that rebooting the machine ultimately resolved the issue. You are able to successfully connect to the selang console. I am marking this post as 'Resolved' for any other end-users who experience this same issue.