On Wed, 2014-12-31 at 13:50 -0800, Quanah Gibson-Mount wrote: its looking for cn=Subschema, which does not exist on the instance that wont start, does not exist on the MMR mirror instance, and cannot be added to the MMR mirror instance. 54a5a578 send_ldap_result: conn=-1 op=0 p=0 54a5a578 >>> dnNormalize: <cn=Subschema> 54a5a578 <<< dnNormalize: <cn=subschema> 54a5a578 read_config: no serverID / URL match found. Check slapd -h arguments.

On Thu, 2015-01-01 at 22:35 +0100, Michael Ströder wrote: because it is irrelevant. as i stated, the listeners start: 54a5c33d daemon_init: listen on ldapi:/// 54a5c33d daemon_init: listen on ldap:/// 54a5c33d daemon_init: 2 listeners to open... ldap_url_parse_ext(ldapi:///) 54a5c33d daemon: listener initialized ldapi:/// ldap_url_parse_ext(ldap:///) 54a5c33d daemon: listener initialized ldap:/// 54a5c33d daemon_init: 2 listeners opened ldap_create 54a5c33d slapd init: initiated server. 54a5c33d slap_sasl_init: initialized! moreover, the parameters i use are the defaults also, the man page says they are perfectly acceptable also, two other separate running instances use the same parameters also, the MMR mirror to this instance is using the same parameters also, this now defunct instance used them previously without issue, and they have not been changed. also, i have validated the DNS names also, i have used ldap://<A Record>, ldap://<CNAME Record>/, and ldap://<IP Address>/, all of which fail with the same error also, i have added the A and CNAME Record info to /etc/hosts, and it still failed in the same way, in the same place and with the same error. clearly, the above proves that the parameters i am using are not the problem.

On Thu, 2015-01-01 at 23:17 +0100, Michael Ströder wrote: stated where? -h URLlist slapd will by default serve ldap:/// (LDAP over TCP on all interfaces on default LDAP port). That is, it will bind using INADDR_ANY and port 389. The -h option may be used to specify LDAP (and other scheme) URLs to serve. For example, if slapd is given -h "ldap://127.0.0.1:9009/ ldaps:/// ldapi:///", it will listen on 127.0.0.1:9009 for LDAP, 0.0.0.0:636 for LDAP over TLS, and LDAP over IPC (Unix domain sockets). Host 0.0.0.0 represents INADDR_ANY (any interface). A space separated list of URLs is expected. The URLs should be of the LDAP, LDAPS, or LDAPI schemes, and generally without a DN or other optional parameters (excepting as discussed below). Support for the latter two schemes depends on selected configuration options. Hosts may be specified by name or IPv4 and IPv6 address formats. Ports, if specified, must be numeric. The default ldap:// port is 389 and the default ldaps:// port is 636. For LDAP over IPC, name is the name of the socket, and no port is required, nor allowed; note that directory separators must be URL-encoded, like any other characters that are special to URLs; so the socket /usr/local/var/ldapi must be specified as ldapi://%2Fusr%2Flocal%2Fvar%2Fldapi The default location for the IPC socket is /var/run/ldapi The listener permissions are indicated by "x-mod=-rwxrwxrwx", "x-mod=0777" or "x-mod=777", where any of the "rwx" can be "-" to suppress the related permission, while any of the "7" can be any legal octal digit, according to chmod(1). The listeners can take advantage of the "x-mod" extension to apply rough limitations to operations, e.g. allow read operations ("r", which applies to search and compare), write operations ("w", which applies to add, delete, modify and modrdn), and execute operations ("x", which means bind is required). "User" per‐ missions apply to authenticated users, while "other" apply to anonymous users; "group" permissions are ignored. For example, "ldap:///????x-mod=-rw-------" means that read and write is only allowed for authenticated connections, and bind is required for all opera‐ tions. This feature is experimental, and requires to be manually enabled at configure time. serverID <integer> [<URL>] Specify an integer ID from 0 to 4095 for this server (limited to 3 hexadecimal digits). The ID may also be specified as a hexadecimal ID by prefixing the value with "0x". These IDs are required when using multimaster replication and each master must have a unique ID. Note that this requirement also applies to separate masters contributing to a glued set of databases. If the URL is provided, this directive may be specified multiple times, providing a complete list of participating servers and their IDs. The fully qualified hostname of each server should be used in the supplied URLs. The IDs are used in the "replica id" field of all CSNs generated by the specified server. The default value is zero. Example: serverID 1 also, i did try that, as i put A, CNAME and IP values into the ldap://<...>/ URL, and all three failed.

On Fri, 2015-01-02 at 10:22 +0100, Michael Ströder wrote: so this was communicated quieter than a church mouse's whisper in some obscure corner, as there is no documentation update in man pages, admin guide or changelog. i quickly searched for a reference in the release notes online, and did not find anything concrete, either. to me, if a "FATAL" error with a change in a setting like this is being introduced, those making the change should be screaming it from the rooftops, not putting onus on the community that did not know the change was made. i see no such behavior in any of the docs. moreover, why am i able to start an instance, configure it while running and even have replication working in the "broken" state of not having the -h parameters configured correctly, only to have the instance break upon restart? if the conditions are wrong, they should not work in any configuration, no? logic fail. now, you have this new behavior that requires DNS resolution. well, i am trying to put my DNS zone data into the directory, using bind-dyndb-ldap, so the BIND/named daemon is dependent on LDAP. But LDAP is dependent on BIND/named. chicken and egg. i have 2 nameservers. one wont start becuase LDAP wont start because DNS wont start because LDAP wont start because... and i get vertigo. a tcpdump on the second nameserver validates that the logic fail continues. there is no attempt to resolve the LDAP URL or serverID on the second configured nameserver. so further down the rabbit hole of frustration and failure i go. put the effing entry in /etc/hosts. well that only goes so far. the instance is at least able to bring up the listeners, but i still run into the problem where the -h parameter list now does have the right values, but the instance wont start. what is now broken and how do i work around this failed logic.