The integration problem with RSSO 220.127.116.11 has been actually fixed within Discovery 18.104.22.168 (DRUD1-19482 - Integration with RSSO 9.1.02 is not supported) - see Defects resolved in this version - BMC Discovery 11.1 - BMC Documentation.
OK, thanks for the clarification.
There is still a problem:
RSSO support will not work because the appliance is not in domain zkb.ch
Server, Certificat, LDAP are all OK. Both the Discovery appliance and the RSSO servers are in the domain zkb.ch. I do not understand this error message! As you mention, with my version it should be OK.
Bad day today. Rien ne va plus!
If this is a standalone appliance, I feel the problem may be that the current /usr/tideway/etc/cluster.conf file contains a wrong value for <address> field. If yes, delete the file and restart cluster services. A new file will be generated with a correct value.
We don't have cluster. It's a standalone cons box.
Why does it feature a cluster.conf file when running in standalone mode?
Can I delete this file altogether?
If not, what do I need to change?
Whatever I change, is a future update going to reset to default value like many other config params?
The WARNING is quite threatening. I am not going to change anything unless I know exactly what,
I'm not in the mood of recovering my appliance, even in development environment!
<?xml version="1.1" encoding="UTF-8"?>
<!-- WARNING: Manual editing of this file should only be undertaken
after consulting BMC support! Incorrect changes WILL result
in the loss of data and the system may be unrecoverable! -->
Cluster manager service and the related cluster.conf file are there so that you can implement a cluster if you want.
As I wrote it "delete the file and restart cluster services. A new file will be generated with a correct value".
OK. wrong interpretation. I thought you meant to delete if running a cluster... Sorry, too
many things going the wrong way right now.
But as a standalone box, cluster services are not running. I don't know what I should restart.
[tideway@sfa3100 log]$ sudo service tideway status
ADDM application services are running
Security service: 21518 [ OK ]
Model service: 21572 [ OK ]
Vault service: 21691 [ OK ]
Discovery service: 21739 [ OK ]
Mainframe Provider service: 21809 [ OK ]
SQL Provider service: 21875 [ OK ]
CMDB Sync (Exporter) service: 21946 [ OK ]
CMDB Sync (Transformer) service: 22024 [ OK ]
Reasoning service: 22223 [ OK ]
Tomcat service: 22821 [ OK ]
Reports service: 22957 [ OK ]
External API service: 23011 [ OK ]
Application Server service: 23067 [ OK ]
Cluster services actually do run:
sudo service cluster status
I was not aware of cluster sercices running on non clustered appliances.
The content of the etc/cluster.conf now looks ok, and the GUI says all green.
I checked a couple of other appliances, on some the cluster.conf looks correct,
on some other it looks like the incorrect one. Is this a file that gets set/reset
upon Discovery/OS upgrades? Just wondering.
Anyway, thanks for your help.
2 of 2 people found this helpful
I would say the problem is that this file is not updated while changing the hostname of the appliance. This is a real problem for standalone machine where only manual deletion of the file fixes the problem, whereas on cluster, cluster management page allow you to change member address.
Fortunately, this problem for standalone appliance will be fixed in coming versions of BMC Discovery (on cluster service restart, the address on cluster.conf is checked and corrected if need be).
Thanks for you explanation. And great to hear it will be fixed in a upcoming version!