With the advent of eDirectory 8.8, you can run multiple instances on the same server. For building labs, or scaling applications this is a wonderful feature.
With multiple instances on one server, however, you run into issues of port collision. eDirectory wants port 524 for NCP, 389 for LDAP, 636 for Secure LDAP, and so on. If you have two instances on the same server, you run into a collision.
For LDAP this is not a big deal, because most LDAP aware applications allow you to specify the port (often they require it). But often, it's not easy to point NCP-aware clients at alternate ports.
The simplest way I know of to fix this is bind two or more IP addresses to the server (multi-homed on one NIC is easiest - no need for multiple physical cards). Then as you set up each new eDirectory instance, assign it to a different IP address. This way, 524, 389, and 636 are available each time.
One minor issue is that for the first eDirectory instance, you probably did not assign it to a specific IP address. So, it is listening on 0.0.0.0, which is effectively all addresses. Once you start doing multiple instances, that becomes a problem.
The easiest way I know to fix this is in ConsoleOne:
1. For each instance, find the NCP Server object (where you installed the server into the tree) and find the LDAP Server object, usually nearby.
By default the LDAP Server, LDAP Group, httpstk config, SAS, SNMP Config, and Predicate Statistics objects, as well as default SSL Certificates are created in the same context. So unless you moved the server, they should be nearby. It should be named LDAP Server - <NAME OF SERVER> which is done so that there are no naming collisions.
2. Look at the LDAP Server object in Console 1.
3. Use the most useful tab, Other, to see the attributes for which there is no snap-in, and find the ldapInterfaces attribute.
It is probably empty, which in a single instance of eDirectory seems to be interpreted as "listen on all IPs".
4. In a multiple-instance server, add the IP address you want it bound to and restart eDirectory.
You can do this with any tool you want. The docs offer "ndsconfig", where you are expected to know the exact name of the attribute. I like ConsoleOne, since I can explore and see where the problem is and just go in and fix it. Of course it carries with it some risk, since
there is no validation of your data entry. So take care as always: test in a lab environment, and if it breaks, enjoy trying to fix it - that is the best way to learn!
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.