Openldap: migrazione dalla configurazione classica alla nuova cn=config

2

openldap

Chi usa openLDAP si sara’ accorto che dalla versione 2.4 la configurazione e’ stata completamente stravolta passando dall’avere tutto in un unico file di configurazione, slapd.conf, ad una struttura ad albero tipica del database ldap.
Di seguito sono riportati i passi per configurare un consumer/proxy utilizzando il nuovo formato di configurazione cn=config.

Topologia.

Il sistema descritto in questo articolo consta di 3 server ldap, due di questi si trovano in rete di tipo trust (quindi affidabile) ed uno in dmz (ossia una rete demilitarizzata, che non contiene cioè dati sensibili).

Tali macchine verranno nominate server1, server2 e server3:

  • server1 sarà il master, che, usando la nuova terminologia di openldap, diventa provider;
  • server2 sarà il consumer, colui cioè che chiede aggiornamenti al provider e funzionerà da proxy, comunicando gli aggiornamenti al server3 che risiede in dmz;
  • server3 risiederà in dmz;

Perché utilizzare un proxy? Per simulare il comportamento del vecchio slurpd, la componente che garantiva la replica del database ldap mediante una connessione dal provider al consumer. Il sistema di replica e’ cambiato, ora e’ il consumer che inizia la connessione col provider per avere gli aggiornamenti.
Finché i server stanno nella stessa rete non esiste nessun problema, ma se un server risiede in dmz e uno è nella rete trust non e’ opportuno aprire un passaggio tra le due reti, si dovrà quindi simulare il comportamento del vecchio slurpd e cioè sarà il consumer/proxy ad iniziare la connessione col server in dmz. Il traffico sarà quindi dalla rete trust alla rete dmz, come e’ gusto che sia, e non dalla rete dmz alla rete trust.

server1 e server3 montano una distribuzione Debian Lenny quindi la configurazione di slapd non è cambiata, mentre nel server2 invece è stato effettuato un aggiornamento da Debian Lenny a Debian Squeeze, che ha quindi implicato l’aggiornamento all’ultima versione del pacchetto openldap, che ha imposto il riadattamento della vecchia configurazione nel nuovo formato.

Opzionale: importare gli schema.

Se, oltre agli schema già inclusi di default, si volessero includere degli altri schema, come ad esempio phamm.schema bisognerà operare come segue:

  • All’interno della directory /etc/ldap/schema sarà necessario creare un file, ad esempio schema_convert.conf ed inserire le seguenti righe:
    include core.schema
    include cosine.schema
    include inetorgperson.schema
    include phamm.schema
  • Creare una directory di appoggio, ad esempio ldif_out, ed utilizzare il comando slaptest per popolare la directory:
    # mkdir ldif_out
    # slaptest -f  schema_convert.conf -F ldif_out.
  • All’interno della directory ldif_out/cn=config/cn=schema modificare il file cn={x}phamm.ldif (al posto di x ci sarà un numero) eseguendo le seguenti modifiche:
    dn: cn={x}phamm

    verrà modificato in:

    dn: cn=phamm,cn=schema,cn=config, cn={x}phamm diventa cn=phamm

    infine, le ultime righe del file andranno cancellate:

    structuralObjectClass: olcSchemaConfig
    entryUUID: dded7120-64a0-102f-86a3-0507262554d4
    creatorsName: cn=config
    createTimestamp: 20101005074946Z
    entryCSN: 20101005074946.106061Z#000000#000#000000
    modifiersName: cn=config
    modifyTimestamp: 20101005074946Z

    Salvando quindi il file.

  • A questo punto sarà necessario lanciare il comando ldapadd:

    # ldapadd -Y EXTERNAL -H ldapi:/// -f ldif_out/cn\=config/cn\=schema/cn\=\{x\}phamm.ldif

    In modo da importare definitivamente lo schema.

Configurazione consumer per la replica:

Per configurare il server2 (consumer) sarà necessario creare un file nominato, ad esempio, syncpreplDbHdb.ldif all’interno della directory /etc/slapd.d con il seguente contenuto:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcSyncRepl
olcSyncrepl: rid=001 provider=ldap://server1:389 bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxx” keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=example,dc=com" scope=sub schemachecking=off type=refreshAndPersist retry="60 10 300 +"

Come si può notare è stata utilizzata un’utenza ad hoc per la replica: cn=replicant,dc=example,dc=com. Attraverso il comando slapadd, sarà possibile includere la nuova configurazione all’interno del database ldap:

ldapadd -Y external -H ldapi:/// -f syncreplDbHdb.ldif.

La configurazione prosegue con l’aggiunta dei moduli necessari alla replica e la creazione degli indici.

Per aggiungere i moduli syncprov.la e back_ldap.la, necessari alla replica, basterà creare un file nominato, ad esempio, modules.ldif il cui contenuto dovrà essere:

n.b. il modulo back_ldap e’ necessario solo al consumer che opera anche come proxy.

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov.la
-
add: olcModuleLoad
olcModuleLoad: back_ldap.la

Aggiungendo, come già fatto, il file ldif attraverso il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f modules.ldif.

L’aggiunta degli indici prevede la creazione di un file nominato, ad esempio, indexes.ldif con il seguente contenuto:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq
-
add: olcDbIndex
olcDbIndex: entryCSN eq

per poi lanciare, come di consueto, il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f indexes.ldif.

Overlay syncprov (sync provider)

Gli overlay sono componenti software che servono per aggiungere funzionalità al database senza che sia necessario riscrivere un nuovo backend per gestirle, è possibile pensarlo come ad una sorta di plugin.

L’overlay syncprov deve essere definito per ogni macchina che funge da provider, siccome il consumer definito nell’articolo e’ anche il provider di se stesso, in quanto comunica gli aggiornamenti al database ldap che e’ il proxy (definito sotto), è necessario definire l’overlay synprov anche per il consumer.

Creare un file, ad esempio overlayDbHdb.ldif, con il seguente contenuto:

dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionlog: 100

come ormai chiaro, sarà necessario lanciare nuovamente il comando ldapadd:

# ldapadd -Y external -H ldapi:/// -f overlayDbHdb.ldif

Aggiunta del database ldap:

Per completare la configurazione sarà necessario aggiungere il database ldap. Il database ldap serve per fare in modo che il server agisca da proxy ed effettui il forward delle richieste ad un altro server ldap, in questo caso verso server3 in dmz.

Il database ldap verrà creato come di consueto attraverso un file nominato databaseLdap.ldif con il seguente contenuto:

dn: olcDatabase=ldap,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: ldap
olcHidden: TRUE
olcSuffix: dc=example,dc=com
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRestrict: bind
olcRestrict: add
olcRestrict: modify
olcRestrict: rename
olcRestrict: delete
olcRestrict: search
olcRestrict: compare
olcRestrict: extended
olcRootDN: cn=admin,dc=example,dc=com
olcSyncrepl: rid=002 provider=ldap://localhost:389 bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxxx" keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=example,dc=com" scope=sub schemachecking=off type=refreshAndPersist retry="60 10 300 +"
olcDbURI: "ldap://server3:389"
olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="cn=replicant,dc=example,dc=com" credentials="xxxx" keepalive=0:0:0

ed importato quindi con ldapadd:

# ldapadd -Y external -H ldapi:/// -f databaseLdap.ldif

Infine sarà necessario aggiungere l’overlay syncprov anche al database ldap, creando un file overlayDbLdap.ldif:

dn: olcOverlay=syncprov,olcDatabase={2}ldap,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

eseguendo nuovamente il comando ldapadd:

# ldapadd -Y EXTERNAL -H ldapi:/// -f overlayDbLdap.ldif

Si completa così la configurazione di un consumer/proxy.

Conclusioni

Sulla base delle informazioni di questo articolo è possibile ricavare in autonomia la procedura per aggiornare anche il provider ed il server in dmz.
Nei successivi articoli verranno illustrate le configurazione complete degli altri server, in modo da completare l’argomento dell’upgrade di openldap.