|Applies To||RSA ACE/Server 5.0 (no longer supported as of 8-15-2004)|
|Issue||Tips on configuring an ACE/Server 5.0 environment for proper hostname resolution.|
|Resolution||Tips for dealing with network issues:|
1. Look in the configuration record, the sdconf.rec, by running sdinfo. There is a new field, "This Server". This hostname is what the ACE/Server considers itself to be. If this is not right problems can arise. You can reset this value once the network is properly configured by running sdsetup -config and carriage returning through the prompts on UNIX or by running the configuration management gui on NT. On a UNIX replica you will need to run sdconfig -config. In order to run this command you first must set the USR_ACE and VAR_ACE environment variables.
2. Look in the replica table and compare the replica names against the "This Server" Field in each replica's sdconf.rec. These need to be identical. If they are not, resolve all network issues before re-configuring.
3. If you are having problems with replica package installation open up the sdrepnodes.txt file in the replica_package/license directory. There is a list of replicas that this package is intended for. This name should be consistent with the "This Server" Field on the replica on which you are installing the replica package.
4. It is okay to use short names as long as you always uses short names. Consistency in host name resolution is the single most important thing for ACE/Server 5.0 host resolution.
5. When you encounter what appears to be a hostname issue you should define the following. The hostname resolution system you are using, (i.e. hosts file, DNS, etc.), get an output of your sdconf.rec, your replica table, your hosts file, any sdrepnodes.txt file, and any error conditions you are seeing. These can be used by an RSA Security Customer Support Representative to analyze the failure.
6. Check that the Primary's hostname in each sdconf.rec matches the name of the primary in the replica table.
7. Check that the ports match up. This is commonly misconstrued as a hostname problem. Make sure that the port specified in the primary's replica table matches the port specified in the replica's replica table.
8. If you must dump and reload your database to reset their Primary's hostname and address, do this in merge mode. There is a new hot fixed load utility, for all platforms, that fixes several load related hostname issues (scheduled to ship with patch 2). To receive that hot fix contact RSA Customer Service. To re-load a bad db, dump it, make a new db, add the primary again now that host name resolution is properly configured on your network, add an admin using sdcreadm, and then load in merge mode (you will get errors on the old primary and the old admin- this is expected). This will create the exact same DB as before but it will either add the old primary as a replica (which can be deleted) or not at all (the old and new names collided). It will also clear any agent hosts who had the old primary as an acting master/acting slave. These will have to be re-configured, but the agent hosts will still be loaded (this is also fixed in the hot fixed load utility).
9. If you see a syslog or event log message from the lock manager that reads: Lockmanager connection received from unknown host: This is probably a hostname resolution problem (it could also be a rogue aceserver install on a test bed or something- not likely). The replica with is not consistently configured on the network.
10. Each replica has a port ranging from securidprop_00 to securidprop_10. We ask that these services be places in the services file. The only process that uses the services file to resolve these port names is sdrepmgmt, the utility that sets up the replica table. The actual ACE/Server process that uses these ports ONLY looks in the replica table for them. So if two machines aren't talking, and you think the hostnames are correct, do a "sdrepmgmt list" on both machines and compare ports for the replica in question.
|Legacy Article ID||a6546|