OpenLDAP クラスタを実装しようとしている間、ミラーリングモードで 2 つのバックエンド LDAP サーバーを設定しました。
LDAPサービス（iRedMail）を使用するアプリケーションは、LDAPサーバーと同じシステムで実行されます。このアプリケーションでは、CONFIG-DB方式ではなく、以前のslapd.conf方式のLDAP構成が必要です。そのため、slapd.confファイルにミラーリングパラメータを追加しました。ファイルは、最初のバックエンドノードで次のようになります。
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/calentry.schema
include /etc/openldap/schema/calresource.schema
include /etc/openldap/schema/amavisd-new.schema
include /etc/openldap/schema/iredmail.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# The syncprov overlay
moduleload syncprov.la
disallow bind_anon
require LDAPv3
loglevel 0
access to attrs="userPassword,mailForwardingAddress,employeeNumber"
by anonymous auth
by self write
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by dn.exact="cn=vmailadmin,dc=myCompany,dc=de" write
by users none
access to attrs="cn,sn,gn,givenName,telephoneNumber"
by anonymous auth
by self write
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by dn.exact="cn=vmailadmin,dc=myCompany,dc=de" write
by users read
access to attrs="objectclass,domainName,mtaTransport,enabledService,domainSenderBccAddress,domainRecipientBccAddress,domainBackupMX,domainMaxQuotaSize,domainMaxUserNumber,domainPendingAliasName"
by anonymous auth
by self read
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by dn.exact="cn=vmailadmin,dc=myCompany,dc=de" write
by users read
access to attrs="domainAdmin,domainGlobalAdmin,domainSenderBccAddress,domainRecipientBccAddress"
by anonymous auth
by self read
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by dn.exact="cn=vmailadmin,dc=myCompany,dc=de" write
by users none
access to attrs="mail,accountStatus,domainStatus,userSenderBccAddress,userRecipientBccAddress,mailQuota,backupMailAddress,shadowAddress,memberOfGroup,member,uniqueMember,storageBaseDirectory,homeDirectory,mailMessageStore,mailingListID"
by anonymous auth
by self read
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by dn.exact="cn=vmailadmin,dc=myCompany,dc=de" write
by users read
access to dn="cn=vmail,dc=myCompany,dc=de"
by anonymous auth
by self write
by users none
access to dn="cn=vmailadmin,dc=myCompany,dc=de"
by anonymous auth
by self write
by users none
access to dn.regex="domainName=([^,]+),o=domains,dc=myCompany,dc=de$"
by anonymous auth
by self write
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by dn.exact="cn=vmailadmin,dc=myCompany,dc=de" write
by dn.regex="mail=[^,]+@$1,o=domainAdmins,dc=myCompany,dc=de$" write
by dn.regex="mail=[^,]+@$1,ou=Users,domainName=$1,o=domains,dc=myCompany,dc=de$" read
by users none
access to dn.subtree="o=domains,dc=myCompany,dc=de"
by anonymous auth
by self write
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by dn.exact="cn=vmailadmin,dc=myCompany,dc=de" write
by users read
access to dn.subtree="o=domainAdmins,dc=myCompany,dc=de"
by anonymous auth
by self write
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by dn.exact="cn=vmailadmin,dc=myCompany,dc=de" write
by users none
access to dn.regex="cn=[^,]+,dc=myCompany,dc=de"
by anonymous auth
by self write
by users none
access to *
by anonymous auth
by self write
by users read
database monitor
access to dn="cn=monitor"
by dn.exact="cn=Manager,dc=myCompany,dc=de" read
by dn.exact="cn=vmail,dc=myCompany,dc=de" read
by * none
database mdb
suffix dc=myCompany,dc=de
directory /var/lib/ldap/myCompany.de
rootdn cn=Manager,dc=myCompany,dc=de
rootpw {SSHA}V5/UQXm9SmzRGjKK2zAKB79eFSaysc2wG9tPIg==
sizelimit unlimited
maxsize 2147483648
checkpoint 128 3
mode 0700
index objectclass,entryCSN,entryUUID eq
index uidNumber,gidNumber,uid,memberUid,loginShell eq,pres
index homeDirectory,mailMessageStore eq,pres
index ou,cn,mail,surname,givenname,telephoneNumber,displayName eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index shadowLastChange eq,pres
index member,uniqueMember eq,pres
index domainName,mtaTransport,accountStatus,enabledService,disabledService eq,pres,sub
index domainAliasName eq,pres,sub
index domainMaxUserNumber eq,pres
index domainAdmin,domainGlobalAdmin,domainBackupMX eq,pres,sub
index domainSenderBccAddress,domainRecipientBccAddress eq,pres,sub
index accessPolicy,hasMember,listAllowedUser,mailingListID eq,pres,sub
index mailForwardingAddress,shadowAddress eq,pres,sub
index backupMailAddress,memberOfGroup eq,pres,sub
index userRecipientBccAddress,userSenderBccAddress eq,pres,sub
index mobile,departmentNumber eq,pres,sub
#Mirror Mode
serverID 001
# Consumer
syncrepl rid=001 \
provider=ldap://rm2.myCompany.de \
bindmethod=simple \
binddn="cn=vmail,dc=myCompany,dc=de" \
credentials="gtV9FwILIcp8Zw8YtGeB1AC9GbGfti" \
searchbase="dc=myCompany,dc=de" \
attrs="*,+" \
type=refreshAndPersist \
interval=00:00:01:00 \
retry="60 +"
# Provider
overlay syncprov
syncprov-checkpoint 50 1
syncprov-sessionlog 50
mirrormode on
2番目のノードの構成ファイルは、次の2つの点でのみ異なります。
[...]
#Mirror Mode
serverID 002
[...]
# Consumer
[...]
provider=ldap://rm2.myCompany.de \
[...]
前述したように、ミラーリングは本当にうまく機能します。
これで、認証メカニズムとしてLDAPを使用するWebアプリケーションであるLDAPクライアントへの単一の接続アドレスが必要です。
これを達成するためにOpenLDAPプロキシを使用できることを読んだ。 LDAPクライアント（ここではWebアプリケーション）は、複数のバックエンドLDAPサーバーから認証データを取得するLDAPプロキシに接続します。
私は古代の方法の代わりにCONFIG-DBを使用するOpenLDAPプロキシを設定しました。 slapd.confファイルは次のとおりです。
include /etc/openldap/schema/corba.schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/duaconf.schema
include /etc/openldap/schema/dyngroup.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/java.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/openldap.schema
include /etc/openldap/schema/ppolicy.schema
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
modulepath /usr/lib/openldap
modulepath /usr/lib64/openldap
moduleload back_ldap.la
loglevel 0
database ldap
readonly yes
protocol-version 3
rebind-as-user
uri "ldap://rm1.myCompany.de:389"
suffix "dc=myCompany,dc=de"
uri "ldap://rm2.myCompany.de:389"
suffix "dc=myCompany,dc=de"
主な問題：
slaptestを使用してCONFIG-DBを生成すると、コマンドは失敗し、次のように主張します。
5dc44107 /etc/openldap/slapd.conf: line 48: suffix already served by this backend!.
slaptest: bad configuration directory!
slaptestコマンドは次のとおりです。
slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/
私が見つけたすべてのガイドは他のLDAPバックエンドサーバーにサブドメインプレフィックスを使用しているため、この概念を完全に理解していない可能性があります。
uri "ldap://rm1.myCompany.de:389"
suffix "dc=myCompany,dc=de"
uri "ldap://rm2.myCompany.de:389"
suffix "dc=myCompany,dc=de"
彼らは以下を使います：
uri "ldap://rm1.myCompany.de:389"
suffix "dc=ou1,dc=myCompany,dc=de"
uri "ldap://rm2.myCompany.de:389"
suffix "dc=ou2,dc=myCompany,dc=de"
私が理解していないのは、バックエンドサーバーにそれぞれou1とou2がないことです。 DNが一致しない場合、バックエンドLDAPでエントリをどのように見つけることができますか？
この問題に加えて、LDAPプロキシに対するLDAPクエリが成功したことを確認するために一時的に2番目のURIをコメントアウトしましたが、2番目の問題が発生しました。
2番目の用語：
両方のバックエンドLDAPサーバーに対して直接ldapsearchを実行すると（順番に）、すべてのLDAPユーザーが列挙されます。
LDAPプロキシに対して同じldapsearchを実行すると、「vmail」ユーザーのみが列挙されます。直接クエリと同じユーザーを一覧表示する必要があると思います。
ldapsearchコマンドは次のとおりです。
ldapsearch -D "cn=vmail,dc=myCompany,dc=de" -w gtV9FwILIcp8Zw8YtGeB1AC9GbGfti -p 389 -h 192.168.0.92 -b "dc=myCompany,dc=de" -s sub "(objectclass=person)"
私は何を逃したことがありませんか？
ご配慮ありがとうございます！
ありがとう、フロリアン