4.6. Configurazione di slapd

4.6.1. Ottimizzazioni

Non è nostra intenzione, qui, illustrare la configurazione base di slapd, per la quale si rimanda alla "OpenLDAP Administration Guide", in particolare al Capitolo 6: "The slapd configuration file" . Intendiamo invece approfondire le modifiche apportate ad una tipica configurazione base per ottenere maggiore stabilità e performance: quasi ogni operazione sui server comporta una richiesta LDAP, dunque si intuisce facilmente che il funzionamento complessivo del sistema dipende strettamente dall'efficacia di slapd.

Il problema può essere affrontato con due approcci differenti, che non si escludono ma si complementano: da una parte, si può tentare di ridurre il più possibile il numero delle richieste (ad esempio utilizzando meccanismi di caching), dall'altra è necessario ottimizzare attentamente la configurazione di slapd in modo da ottenere prestazioni sufficienti.

Come esempio della prima strategia,a si cerca di alleggerire il server dalle (numerosissime) richieste NSS: anzitutto conviene specificare files prima di ldap in /etc/nssswitch.conf per risolvere subito almeno gli utenti di sistema; l'altra condizione fondamentale è l'esecuzione del demone di caching NSS nscd.

Per quel che riguarda l'ottimizzazione di slapd invece, queste sono le considerazioni che abbiamo fatto:

• è assolutamente necessario creare, nel database LDAP, un indice per ciascuno degli attributi su cui si prevede di fare una query. Questo ad esempio è il frammento rilevante di slapd.conf, nella sezione database:

          index objectClass,status eq
          index sn,uid,mail,alias,cn eq,pres
          index host,uidNumber eq,pres
          index mailForwardingAddress eq,pres
          index mailAlternateAddress eq,pres

  Quando viene effettuata una query con un filtro che comprende un attributo per cui non è stato specificato un indice, il server deve esaminare singolarmente ciascun oggetto nel database: questa situazione è da evitare a tutti i costi.

• può servire aumentare il più possibile la dimensione della cache degli oggetti di slapd, un valore indicativo (che consente di mantenere l'intero database in memoria, se non è troppo grande) può essere appunto il numero di direttive presenti nel database (ottenibile approssimativamente con slapcat | wc -l):

          cachesize 50000
  	    

• aumentare il numero di threads e configurare un timeout per chiudere le connessioni che dovessero rimanere "appese" può essere utile se il carico sul server LDAP dovesse essere tale da determinare dei timeout sui client:

          threads 64
          idletimeout 300

  Un'altra cosa che si può voler fare in questo caso, nell'eventualità che le connessioni LDAP locali utilizzino i socket TCP anziché UNIX, è ampliare il range delle porte effimere, ad esempio ponendo in /etc/sysctl.conf

          net/ipv4/ip_local_port_range=20000 65535

  (cosa questa che complessivamente è un bene sui server in generale).

• Infine si possono modificare alcuni parametri specifici di Berkeley DB creando un file denominato DB_CONFIG nella directory dove risiedono i database (su Debian, /var/lib/ldap). Anche qui conviene aumentare le dimensioni della cache dei valori, su sistemi moderni ad esempio 50Mb non sono un problema:

          set_cachesize 0 52428800 0

  Si può poi specificare che la creazione di files temporanei avvenga su un filesystem tmpfs:

          set_tmp_dir /dev/shm

  Ma forse la cosa più importante, anche se leggermente rischiosa, è disabilitare il log delle transazioni in scrittura sui server slave:

          set_flags DB_TXN_NOSYNC

  Il log delle transazioni garantisce l'integrità dei dati al prezzo di un certo impatto sulle prestazioni: sulle macchine slave possiamo pensare di sacrificare questa sicurezza, avendo comunque a disposizione la copia principale se si verificassero problemi.

4.6.2. ACL

La parte forse più complessa della configurazione del server LDAP è la creazione delle ACL (liste di controllo di accesso) necessarie a permetterne il funzionamento. Ciò in parte è dovuto al fatto che la forma con cui bisogna scrivere queste regole è particolarmente contorta... Per un dato uid richiesto e un dato uid richiedente, OpenLDAP considererà la prima regola (in ordine di apparizione nel file di configurazione) che si applica all'oggetto richiesto, per poi applicare la prima ACL che viene specificata (ancora una volta, in ordine di apparizione) che sia compatibile con il richiedente. Ad esempio, questa è la ACL per controllare l'accesso all'attributo userPassword:

access to attrs=userPassword
  by dn="cn=manager,o=anarchy" write
  by group/groupofnames/member=\
        "cn=admins,ou=Group,dc=infra,dc=org,o=Anarchy" write
  by dn="cn=ring0op,ou=Operators,dc=infra,dc=org,o=Anarchy" read
  by dn="cn=ring1op,ou=Operators,dc=infra,dc=org,o=Anarchy" read
  by dn="cn=dovecot,ou=Operators,dc=infra,dc=org,o=Anarchy" read
  by anonymous auth
  by self write
  by * none
	

Le ACL vanno dunque inserite nel file slapd.conf a partire dalla più specifica (per la parte access to) alla meno specifica.