User Tools

Site Tools


cn:ccr:aai:howto:389ds-1.3-install-rhel7

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
cn:ccr:aai:howto:389ds-1.3-install-rhel7 [2018/03/01 16:13]
anzel@infn.it
cn:ccr:aai:howto:389ds-1.3-install-rhel7 [2022/04/21 06:27] (current)
monducci@infn.it [Reset password Directory Manager tramite socket]
Line 1: Line 1:
 +====== RHEL7: Installazione di 389 Directory Server 1.3.6 e successive ======
  
 +//ultima verifica documento: 22 feb. 2018//
 +
 +
 +** NOTA BENE **
 +Gli esempi citati in questa guida si intendono per 389 Directory Server 1.3.6.x e successive su CentOS 7.x
 +
 +In caso di installazione con diverse versioni alcuni path o nomi dei pacchetti potrebbero differire.
 +
 +// E’ inoltre vivamente consigliato che IP address, IP Name e Hostname della macchina siano coerenti. //
 +
 +   hostnamectl status
 + 
 +ed eventualmente
 +
 +   hostnamectl  set-hostname <FQHN>
 +
 +===== Componenti del 389-ds =====
 +
 +Il 389-DS è composto da vari pacchetti che si possono installare separatamente
 + 
 +  * 389-ds-base (e relative librerie) la cui versione è la 1.3 e si trova nel repository "base" della distribuzione CentOS7
 +  * 389-admin (e relative utilities) la cui versione è la 1.1 ed ha il 389-ds-base tra le sue dipendenze. Si trova nel repository EPEL
 +  * 389-ds-console la cui versione è la 1.2 ed ha il 389-admin (e quindi anche il 389-ds-base) tra le sue dipendenze. Si trova nel repository EPEL
 +  * 389-dsgw la cui versione è la 1.1 ed ha il 389-admin (e quindi anche il 389-ds-base) tra le sue dipendenze. Si trova nel repository EPEL
 +  * 389-ds la cui versione è la 1.2 e contiene tutti i pacchetti di cui sopra.
 +
 +In linea di principio non è necessario avere tutti i pacchetti su tutti i server (basta un solo server con 389-ds-console e 389-admin). Noi installeremo tutto su tutti per due motivi:
 +  - E' utile avere sempre una console funzionante 
 +  - La configurazione di SSL/TLS sulla console
 +
 +
 +
 +===== Preparazione del sistema =====
 +
 +
 +
 +Modificare i parametri kernel in /etc/sysctl.conf:
 +
 +  echo "fs.file-max = 256000" >> /etc/sysctl.conf
 +  echo "net.ipv4.ip_local_port_range = 1024 65000" >> /etc/sysctl.conf
 +  echo "net.ipv4.tcp_keepalive_time = 300" >> /etc/sysctl.conf
 +  echo "vm.swappiness = 10" >> /etc/sysctl.conf
 +
 +Ricaricare sysctl:
 +
 +  sysctl --system
 +  
 +Modificare i limits in /etc/security/limits.conf inserendo la linea:
 +
 +  echo "* soft nofile 32768" >> /etc/security/limits.conf      
 +  echo "* hard nofile 63536" >> /etc/security/limits.conf
 +  echo "* soft nproc  4096" >> /etc/security/limits.conf     
 +  echo "* hard nproc 16384" >> /etc/security/limits.conf     
 +
 +Effettuare log-out e log-in in modo da ricaricare i limits.
 +
 +Installare cyrus-sasl e le librerie necessarie per INFN-AAI
 +
 +  yum -y install cyrus-sasl cyrus-sasl-devel cyrus-sasl-gssapi cyrus-sasl-plain cyrus-sasl-lib
 +
 +
 +Installazione del client LDAP standard di Linux:
 +  yum -y install openldap-clients
 +
 +===== Firewall =====
 +
 +L'installazione di default di CentOS 7.x abilita il firewalld. E' necessario aggiungere le regole che permettano l'accesso alle porte utilizzate dal 389DS
 +
 +  firewall-cmd --permanent --add-port=389/tcp
 +  firewall-cmd --permanent --add-port=636/tcp
 +  firewall-cmd --permanent --add-port=9830/tcp
 +
 +E renderle attive facendo ripartire il servizio
 +
 +  firewall-cmd --reload
 +
 +
 +===== Installazione 389-ds =====
 +
 +
 +Abilitare il repository yum EPEL
 +
 +  yum -y install epel-release
 +  yum clean all
 +
 +Inatallare il 389-DS con tutte le sue dipendenze
 +
 +  yum -y install 389-ds
 +
 +
 +Modificare i limits che sistema assegna al processo, modificando il file /etc/sysconfig/dirsrv.systemd:
 +
 +  echo "LimitNOFILE=32768" >> /etc/sysconfig/dirsrv.systemd
 +  echo "LimitNPROC=16384" >> /etc/sysconfig/dirsrv.systemd
 +
 +Rendere effettive le modifiche facendo ricaricare le configurazioni dal daemon di systemctl
 +
 +  systemctl daemon-reload
 +
 +
 +===== Setup di 389-ds =====
 +
 +Creare l’utente ds:
 +
 +  useradd -r -s /bin/false ds
 +
 +
 +Lanciare il setup di 389-ds
 +
 +  /usr/sbin/setup-ds-admin.pl
 +
 +Scegliere l’opzione 3 in modo da personalizzare l’installazione:
 +  * Configurare come utente/gruppo "ds";
 +  * Controllare il root suffix;
 +  * Tutto il resto può essere lasciato al default.
 +
 +** Attenzione **: In questa fase verra' chiesto il nome dell'istanza del DS, di default corrisponde all'hostname senza dominio. // Si consiglia di lasciare il default e impostare la variabile DSUID in ~/.bash_profile. // Di seguito si farà infatti riferimento a tale valore con $DSUID.
 +
 +<code>
 +echo 'export DSUID=nome.istanza.ds' >> ~/.bash_profile
 +source ~/.bash_profile
 +</code>
 +
 +Impostare la partenza dei servizi di 389-ds al boot
 +
 +  systemctl enable dirsrv.target
 +  systemctl enable dirsrv-admin.service
 +
 +Fermare 389ds e verificare lo stato del servizio
 +
 +  systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +
 +===== Directory Manager password  =====
 +
 +E' utile memorizzare la password del Directory Manager in un file accessibile solo a root:
 +
 +  echo "<DirectoryManagerPassword>" > /root/.ssh/dmpw
 +  chmod 400 /root/.ssh/dmpw
 +
 +
 +===== 389 Directory Server Console =====
 +
 +Da questo momento e' possibile lanciare la console di gestione del Directory Server, attraverso la quale e' possibile fare ogni tipo di configurazione e gestire i dati della Directory.
 +
 +Per eseguire la console (a Directory Server attivo):
 +
 +  389-console -x nologo -a http://localhost:9830/ -u "cn=Directory Manager" -y /root/.ssh/dmpw &
 +
 +
 +===== Performance =====
 +
 +
 +Per migliorare le performance di 389ds, secondo le istruzioni della [[https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/performance_tuning_guide/file-descriptors|guida RedHat]] originale, bisogna incrementare il massimo numero di file descriptor a disposizione del server.
 +
 +Questo si può effettuare modificando il file ''/etc/dirsrv/slapd-$DSUID/dse.ldif'' e ''/etc/sysconfig/dirsrv''
 +
 +<code>
 +sed -i 's/^nsslapd-localuser: .*$/nsslapd-localuser: ds\nnsslapd-maxdescriptors: 16384\nnsslapd-reservedescriptors: 8192/' /etc/dirsrv/slapd-$DSUID/dse.ldif
 +sed -i 's/^#* *ulimit -n.*$/ulimit -n 16384/' /etc/sysconfig/dirsrv
 +</code>
 +
 +(nota: i parametri nsslapd-maxdescriptors e nsslapd-reservedescriptors non sono rportati per default nel file dse.ldif perche' utilizzati i valori di default).
 +
 +
 +Eliminare il limite di entry nelle ricerche
 +
 +<code>
 +sed -i 's/^nsslapd-sizelimit: .*$/nsslapd-sizelimit: -1/' /etc/dirsrv/slapd-$DSUID/dse.ldif
 +sed -i 's/^nsslapd-lookthroughlimit: .*$/nsslapd-lookthroughlimit: -1/' /etc/dirsrv/slapd-$DSUID/dse.ldif
 +</code>
 +
 +
 +Definire la quantità di RAM che viene assegnata alle cache (vedi nota tra le FAQ a fine pagina)
 +
 +<code>
 +sed -i 's/^nsslapd-cache-autosize: .*$/nsslapd-cache-autosize: 30/' /etc/dirsrv/slapd-$DSUID/dse.ldif
 +</code>
 +
 +Far ripartire 389ds e verificare lo stato del servizio
 +  systemctl start dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +Controllare che il limite "Max open files" sia effettivo:
 +  cat /proc/`pidof ns-slapd`/limits
 +
 +
 +
 +===== Modifica dello schema =====
 +
 +Fermare 389ds e verificare lo stato del servizio
 +
 +  systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +
 +=== Schema per supporto autofs e nis ===
 +
 +
 +Attivare lo schema rfc2307bis ([[https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Schema_Reference/Directory_Server_Object_Class_Reference.html]])
 +
 +  rm -f /usr/share/dirsrv/schema/10rfc2307.ldif
 +  cp -p /usr/share/dirsrv/data/10rfc2307bis.ldif /usr/share/dirsrv/schema/
 +
 +
 +Disabilitare la definizione della ObjectClass nisMap (OID 1.3.6.1.1.1.2.13) dallo schema rfc2307 (in quanto è incompatibile con quella dello schema rfc2307bis)
 +
 +  sed -i 's/^objectClasses: \(.*1\.3\.6\.1\.1\.1\.2\.13.*$\)/#\1/' /usr/share/dirsrv/schema/10rfc2307.ldif
 +
 +
 +
 +=== Estensione schema per INFN-AAI e federazioni ===
 +
 +
 +Scaricare gli schema personalizzati INFN-AAI:
 +
 +  cd /etc/dirsrv/slapd-$DSUID/schema
 +  curl http://wiki.infn.it/_media/cn/ccr/aai/doc/97schac.ldif > 97schac.ldif
 +  curl http://wiki.infn.it/_media/cn/ccr/aai/doc/98infn.ldif > 98infn.ldif
 +  curl http://wiki.infn.it/_media/cn/ccr/aai/doc/61edumember.ldif > 61edumember.ldif
 +  chown ds:ds 98infn.ldif 97schac.ldif 61edumember.ldif
 +  chmod 440 98infn.ldif 97schac.ldif 61edumember.ldif
 +
 +
 +Far ripartire 389ds e verificare lo stato del servizio
 +  systemctl start dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +===== Configurazione SSL/TLS per il Directory Server =====
 +
 +**NOTA**: In coda al documento e' disponibile in alternativa la procedura grafica per la Configurazione SSL/TLS.
 +
 +Fermare il 389DS e verificare lo stato del servizio
 +
 +  systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +Impostare la password per il DB dei certificati
 +
 +  cd /etc/dirsrv/slapd-$DSUID
 +  modutil -dbdir . -changepw "NSS Certificate DB"
 +
 +Creare un il file con la password del DB dei certificati:
 +
 +  cd /etc/dirsrv/slapd-$DSUID
 +  vi pin.txt
 +
 +Inserire:
 +
 +  Internal (Software) Token:PASSWORD
 +
 +Impostare i permessi:
 +
 +  chown ds:ds pin.txt
 +  chmod 600 pin.txt
 +
 +Far ripartire 389ds e verificare lo stato del servizio
 +
 +  systemctl start dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +  
 +
 +Convertire il certificato con chiave privata del server in formato pkcs12 in un file temporaneo. **Non impostare una password**.
 +
 +  openssl pkcs12 -export -inkey ds_server_key.pem -in ds_server_crt.pem -out /tmp/crt.p12 -nodes -name 'server-cert'
 +
 +Importare il certificato con chiave privata del server nel DB di 389-ds. Verrà richiesto di inserire la password per l'accesso al "NSS Certificate DB" impostata precedentemente. La prima password che viene chiesta è quella del DB di 389-ds, la seconda è invece quella eventualmente impostata nell’export (premere semplicemente invio, se non è stata impostata la password per il p12).
 +
 +  cd /etc/dirsrv/slapd-$DSUID
 +  pk12util -i /tmp/crt.p12 -d .
 +  rm /tmp/crt.p12
 +
 +
 +E' necessario importare nel DB dei certificati **TUTTI** i certificati delle CA dalle quali ci serviamo. 
 +
 +Le istruzioni sono in [[cn:ccr:aai:howto:389ds-certificates|]]
 +
 +Verificare quindi che nel "NSS Certificate DB" ci siano tutti i certificati
 +
 +  certutil -d /etc/dirsrv/slapd-$DSUID -L
 +
 +Configurare il client ldap di default di linux (openldap) inserendo la chiave pubblica della CA nella directory /etc/pki/CA/certs/ e creare gli hash link eseguendo:
 +
 +  cacertdir_rehash /etc/pki/CA/certs/
 +
 +Impostare la directory anche nella configurazione del client ldap:
 +
 +  echo "TLS_CACERTDIR /etc/pki/CA/certs/" >> /etc/openldap/ldap.conf
 +
 +
 +
 +Far ripartire 389-ds e verificare lo stato del servizio
 +
 +  systemctl restart dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +
 +  
 +===== Abilitare l'encryption per il 389-DS  =====
 +
 +Se non già attiva, far partire la console
 +
 +   389-console -x nologo -a http://localhost:9830/ -u "cn=Directory Manager" -y /root/.ssh/dmpw &
 +   
 +Nel primo tab "Servers and Applications" espandere l’albero di sinistra, cliccare con il tasto destro su "Directory Server" e scegliere "Open" -> tab Configuration -> Encryption
 +
 +Abilitare le opzioni "Enable SSL for this server" e "Use this Cipher Family: RSA"
 +Assicurarsi che in Certificate ci sia "server-cert", altrimenti uscire e rientrare nella console.
 +
 +
 +Far ripartire 389-ds e verificare lo stato del servizio
 +
 +  systemctl restart dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +
 +===== Configurazione Mapping dei certificati x509 =====
 +
 +Per consentire l’autenticazione con certificati x509 è necessario configurare un mapping tra i subject dei certificati e le entry del DS.
 +
 +Nel file /etc/dirsrv/slapd-$DSUID/certmap.conf troviamo la possibilità di impostare l’attributo del DS in cui 389-ds troverà il subject x509. Le sole righe non commentate dovranno essere:
 +
 +  certmap default         default
 +  default:CmapLdapAttr    infnCertSubjectDN
 +
 +
 +Far ripartire 389-ds e verificare lo stato del servizio
 +
 +  systemctl restart dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +
 +
 +===== Configurazione Kerberos client =====
 +
 +Installare il client Kerberos sui server LDAP
 +
 +  yum -y install krb5-workstation
 +  
 +
 +Modificare opportunamente il file di configurazione /etc/krb5.conf, in particolare
 +
 +  * nella stanza [libdefaults]
 +    * e' consigliato fare sempre riferimento al DNS
 +    * per compatibilita' con il pregresso e' necessario abilitare la crittografia debole:
 +
 +   dns_lookup_realm = true
 +   dns_lookup_kdc = true
 +   allow_weak_crypto = true
 +
 +  * è inoltre necessario specificare il REALM di default che deve essere INFN.IT nel caso in cui la struttura NON abbia un REALM Kerberos locale.
 +
 +  default_realm = INFN.IT
 +
 +  * Ovviamente, nel caso di server LDAP installato in una sede con REALM Kerberos locale, deve essere indicato tale REALM e, per permettere l'autenticazione nativa Kerberos via GSSAPI, deve essere configurata la cross-authentication (mandare una e-mail ad **afs-admin <at> lists.infn.it** )
 +
 +  default_realm = LE.INFN.IT
 +
 +  * nella stanza [realms] specificare le informazioni relativi al realm di default; nel caso del realm INFN.IT le informazioni da riportare sono le seguenti:
 +
 +  [realms]
 +    INFN.IT = {
 +     kdc = afs2.infn.it:88
 +     kdc = afs1.infn.it:88
 +     kdc = afs3.infn.it:88
 +     kdc = k5.infn.it:88
 +     kpasswd_server = k5.infn.it
 +     admin_server = k5.infn.it:749
 +     default_domain = infn.it
 +   }
 +
 +
 +  * nella stanza [domain_realm], per consentire la cross-autenticazione tra i realm INFN, indicare nell'ordine di seguito riportato almeno i seguenti:
 +
 +  [domain_realm]
 +    .infn.it = INFN.IT
 +    infn.it  = INFN.IT
 +    .le.infn.it = LE.INFN.IT
 +    le.infn.it  = LE.INFN.IT
 +    .lnf.infn.it = LNF.INFN.IT
 +    lnf.infn.it  = LNF.INFN.IT
 +    .pi.infn.it = PI.INFN.IT
 +    pi.infn.it  = PI.INFN.IT
 +    .lngs.infn.it = LNGS.INFN.IT
 +    lngs.infn.it  = LNGS.INFN.IT
 +    .mi.infn.it = MI.INFN.IT
 +    mi.infn.it  = MI.INFN.IT
 +    .mib.infn.it = MI.INFN.IT
 +    mib.infn.it  = MI.INFN.IT
 +     
 +
 +===== Configurazione SASL / GSSAPI =====
 +
 +Installare il pacchetto che permette l'autenticazione gssapi con 389ds:
 +  yum install cyrus-sasl-gssapi.x86_64
 +
 +Generare il krb5 keytab di servizio (via warc o con modalita' locali) e copiarlo in /etc/dirsrv/$DSUID.keytab
 +
 +Assicurarsi che solo l’utente ds possa accedervi:
 +  chown ds /etc/dirsrv/$DSUID.keytab
 +  chmod 400 /etc/dirsrv/$DSUID.keytab
 +  
 +Aggiungere al file /etc/sysconfig/dirsrv il path al keytab:
 +
 +  echo "KRB5_KTNAME=/etc/dirsrv/$DSUID.keytab" >> /etc/sysconfig/dirsrv
 +  
 +Nella Management Console definire i SASL Mapping:
 +  * Nel primo tab "Servers and Applications" espandere l’albero di sinistra e cliccare con il tasto destro su "Directory Server"
 +  * Si aprirà la Management Console
 +  * Cliccare sul tab "Configuration"
 +  * Cliccare sul nome del server a sinistra e a destra scegliere il tab "SASL Mapping"
 +  * Selezionare e cancellare (tasto Delete) le regole esistenti.
 +
 +
 +**Fermare** 389ds e verificare lo stato del servizio
 +
 +  systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +
 +Aggiungere le seguenti righe al file ''/etc/dirsrv/slapd-$DSUID/dse.ldif'', **sostituendo tutte le occorrenze di DEFAULT.REALM** con il realm di default indicato nel file /etc/krb5.conf (grep default_realm /etc/krb5.conf). 
 +
 +<code>
 +dn: cn=20-krb5_people_default_realm,cn=mapping,cn=sasl,cn=config
 +objectClass: top
 +objectClass: nsSaslMapping
 +cn: 20-krb5_people_default_realm
 +nsSaslMapRegexString: ^[^@]+$
 +nsSaslMapBaseDNTemplate: ou=people, dc=infn, dc=it
 +nsSaslMapFilterTemplate: (infnKerberosPrincipal=&@DEFAULT.REALM)
 +
 +dn: cn=20-krb5_people_other_realm,cn=mapping,cn=sasl,cn=config
 +objectClass: top
 +objectClass: nsSaslMapping
 +cn: 20-krb5_people_other_realm
 +nsSaslMapRegexString: ^.+@.+$
 +nsSaslMapBaseDNTemplate: ou=people, dc=infn, dc=it
 +nsSaslMapFilterTemplate: (infnKerberosPrincipal=&)
 +
 +dn: cn=30-krb5_services_default,cn=mapping,cn=sasl,cn=config
 +objectClass: top
 +objectClass: nsSaslMapping
 +cn: 30-krb5_services_default_realm
 +nsSaslMapRegexString: ^[^@]+/[^@+]+$
 +nsSaslMapBaseDNTemplate: ou=services, dc=infn, dc=it
 +nsSaslMapFilterTemplate: (infnKerberosPrincipal=&@DEFAULT.REALM)
 +
 +dn: cn=30-krb5_services_other_realm,cn=mapping,cn=sasl,cn=config
 +objectClass: top
 +objectClass: nsSaslMapping
 +cn: 30-krb5_services_other_realm
 +nsSaslMapRegexString: ^.+/.+@.+$
 +nsSaslMapBaseDNTemplate: ou=services, dc=infn, dc=it
 +nsSaslMapFilterTemplate: (infnKerberosPrincipal=&)
 +
 +dn: cn=40-krb5_hosts_default_realm,cn=mapping,cn=sasl,cn=config
 +objectClass: top
 +objectClass: nsSaslMapping
 +cn: 40-krb5_hosts_default_realm
 +nsSaslMapRegexString: ^host/[^@]+$
 +nsSaslMapBaseDNTemplate: ou=hosts, dc=infn, dc=it
 +nsSaslMapFilterTemplate: (infnKerberosPrincipal=&@DEFAULT.REALM)
 +
 +dn: cn=40-krb5_hosts_other_realm,cn=mapping,cn=sasl,cn=config
 +objectClass: top
 +objectClass: nsSaslMapping
 +cn: 40-krb5_hosts_other_realm
 +nsSaslMapRegexString: ^host/.+@.+$
 +nsSaslMapBaseDNTemplate: ou=hosts, dc=infn, dc=it
 +nsSaslMapFilterTemplate: (infnKerberosPrincipal=&)
 +
 +
 +</code>
 +
 +**Fare attenzione a lasciare una riga vuota alla fine del file**
 +
 +Far ripartire 389-ds e verificare lo stato del servizio
 +
 +  systemctl restart dirsrv.target ; systemctl status dirsrv@$DSUID.service
 +
 +===== Configurazione plugin Kerberos Password back-end =====
 +
 +
 +Per compilare e configurare il plugin Kerberos5 per 389-ds eseguire le seguenti operazioni:
 +
 +Installare il compilatore, i sorgenti di Kerberos e di openldap:
 +
 +  yum install gcc krb5-devel 389-ds-base-devel libss-devel git
 +
 +  * Ottenere il codice sorgente
 +
 +  git clone https://baltig.infn.it/dmaselli/389ds-krb5-plugin.git
 +
 +  * Compilare ed installare
 +
 +<html>
 +<font color="red"><i>
 +22/2/2018: Rilevato e risolto problema di compilazione.<br>
 +In attesa che la modifica sia riportata nel pacchetto disponibile su //baltig// e' necessario 
 +aggiungere -DHAVE_INTTYPES_H alla stringa di definizione degli CFLAGS nel Makefile, che dovra' quindi essere la seguente:
 +
 +CFLAGS = -Wall -fPIC $(INCLUDE_FLAGS) -ggdb -DKRB5PLUGIN -D_REENTRANT -DHAVE_INTTYPES_H
 +
 +Compilato con questi CFLAGS ed installato, funziona regolarmente.
 +</i></font>
 +</html>
 +
 +
 +  cd 389ds-krb5-plugin
 +  make clean
 +  make
 +  make install
 +
 +
 +===== INFN-AAI =====
 +
 +Pe poter ricevere la replica del ramo nazionale DC=INFN,DC=IT e del ramo locale DC=<sede>,DC=INFN,DC=IT dai master di INFN-AAI è necessario inviare al supporto di INFN-AAI <aai-support@lists.infn.it> un mail contenente 
 +  * il FQDN del vostro nuovo server LDAP 
 +  * la password dell'utente CN="Directory Manager" che sarà utilizzata per la configurazione delle repliche. 
 +
 +Una volta configurate, le repliche saranno effettuate con autenticazione via Certificato X.509 e quindi a configurazione effettuata potrete modificare la password di CN="Directory Manager" ([[http://directory.fedoraproject.org/wiki/Howto:ResetDirMgrPassword| wiki del 389-ds]]).
 +
 +
 +
 +===== FAQ =====
 +
 +==== "BRASARE" 389-ds ====
 +
 +  cd ~
 +  yum remove "389*"
 +  rm -rf /etc/dirsrv /var/lib/dirsrv /var/log/dirsrv /usr/lib64/dirsrv /usr/share/dirsrv /var/lock/dirsrv
 +  
 +==== Modificare la password di CN="Directory Manager" ====
 +
 +Istruzioni disponibili nel [[http://directory.fedoraproject.org/wiki/Howto:ResetDirMgrPassword| wiki del 389-ds]]
 +
 +
 +==== ERRORE "attrcrypt_unwrap_key" ====
 +
 +attrcrypt_unwrap_key: failed to unwrap key for cipher AES:
 +
 +https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/ssl-and-attr-encryption.html
 +
 +
 +==== Verificare che il keytab sia quello corretto ====
 +
 +   kinit -k -t /etc/dirsrv/dsm1.keytab ldap/dsm1.infn.it@INFN.IT
 +   klist
 +
 +
 +==== Tuning RAM da assegnare alla Cache ====
 +
 +Il 389 Directory Server può valutare le dimensioni della cache ottimizzandole rispetto alle risorse hardware. A partire dalla versione 10.1.1 di RedHat Enterprise Directory Server (che corrisponde alla versione 1.3.? di 389DS) tale funzionalità è abilitata per default.
 +
 +Come si può leggere  nella [[https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/performance_tuning_guide/memoryusage#DB_and_entry_cache_RAM_usage|Documentazione RedHat]] originale, i due attributi che regolano la quantità di RAM che viene assegnata alle cache sono:
 +
 +  * nsslapd-cache-autosize
 +  * nsslapd-cache-autosize-split
 +
 +ed i loro valori di default, definiti all'interno della entry,
 +
 +  cn=config,cn=ldbm database,cn=plugins,cn=config
 +  
 +sono:
 +
 +  nsslapd-cache-autosize: 10
 +  nsslapd-cache-autosize-split: 40
 +  
 +Il primo indica la percentuale di RAM libera (libera in fase di startup del 389DS) da dedicare alle cache (database-cache ed entry-cache) mentre il secondo indica la percentuale di cache da dedicare al database-cache (il complemento a 100 sarà assegnato all'entry-cache).
 +
 +Date le dimensioni dell'info-db, su un server con 4GB di RAM, il valore di default di nsslapd-cache-autosize risulta essere basso. Su un server che sia solo server LDAP si può tranquillamente dedicare il 30% della RAM alle cache, quindi:
 +
 +  systemctl stop dirsrv.target
 +  sed -i 's/^nsslapd-cache-autosize: .*$/nsslapd-cache-autosize: 30/' /etc/dirsrv/slapd-$DSUID/dse.ldif
 +  systemctl start dirsrv.target
 +  systemctl status dirsrv@$DSUID.service -l
 +
 +e nel log si può vedere se questa assegnazione di RAM è sufficiente:
 +
 +  ...omissis... - NOTICE - ldbm_back_start - found 3882016k physical memory
 +  ...omissis... - NOTICE - ldbm_back_start - found 3399568k available
 +  ...omissis... - NOTICE - ldbm_back_start - cache autosizing: db cache: 465841k
 +  ...omissis... - NOTICE - ldbm_back_start - cache autosizing: NetscapeRoot entry cache (2 total): 393216k
 +  ...omissis... - NOTICE - ldbm_back_start - cache autosizing: infn-db entry cache (2 total): 393216k
 +  ...omissis... - NOTICE - ldbm_back_start - total cache size: 1207895588 B;
 +  ...omissis... - INFO - dblayer_start - Resizing db cache size: 127205900 -> 381617700
 +  ...omissis... - INFO - slapd_daemon - slapd started.  Listening on All Interfaces port 389 for LDAP requests
 +  ...omissis... - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests
 +
 +Nel caso in cui l'assegnazione di RAM non bastasse, troverete una linea del tipo
 +
 +  ...omissis... - NOTICE - ldbm_back_start - infn-db: entry cache size 134217728 B is less than db size 153378816 B; We recommend to increase the entry cache size nsslapd-cachememsize.
 +
 +
 +==== Configurazione SSL/TLS per il Directory Server - Procedura grafica ====
 +
 +Documentazione originale in [[https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10.1/html/Administration_Guide/managing-certs.html#Managing_SSL-Obtaining_and_Installing_Server_Certificates|Documentazione RedHat]]
 +
 +E' necessario installare il certificato per il 389-DS e quello della CA che lo ha firmato, nel DB dei certificati.
 +
 +
 +Far partire la console
 +
 +  389-console -x nologo -a http://localhost:9830/ -u "cn=Directory Manager" -y /root/.ssh/dmpw &
 +
 +Nel primo tab "Servers and Applications" espandere l’albero di sinistra, cliccare con il tasto destro su "Directory Server" e scegliere "Open"
 +
 +Andare in Console -> tab "Tasks" -> Manager Certificates
 +
 +
 +{{:cn:ccr:aai:howto:set_security_device_password.png?200 |Set Security Device Password}} La prima volta che viene attivato questo task, viene richiesto di inserire la password per la protezione del DB dei certificati. Impostare la password, che dovrà poi essere inserita in un file che il 389-DS legge alla partenza.
 +
 +
 +Tramite il tasto "Request..." completare la procedura di richiesta di certificato, definendo il subject ed il tipo di encryption
 +
 +{{:cn:ccr:aai:howto:certificate_request_wizard_1.png?200|}}
 +
 +{{:cn:ccr:aai:howto:certificate_request_wizard_2a.png?200|}}
 +
 +{{:cn:ccr:aai:howto:certificate_request_wizard_2b.png?200|}}
 +
 +{{:cn:ccr:aai:howto:certificate_request_wizard_3.png?200|}}
 +
 +{{:cn:ccr:aai:howto:certificate_request_wizard_4.png?200|}}
 +
 +{{:cn:ccr:aai:howto:certificate_request_wizard_5.png?200|}}
 +
 +
 +Inviare la richiesta di certificato alla propria CA ed installare il certificato firmato
 +
 +{{:cn:ccr:aai:howto:certificate_install_wizard_4.png?200 |}} {{ :cn:ccr:aai:howto:certificate_install_wizard_2.png?200 |}} {{ :cn:ccr:aai:howto:certificate_install_wizard_3.png?200|}} {{:cn:ccr:aai:howto:certificate_install_wizard_4.png?200|}}
 +
 +Installare il certificato della CA che ha firmato il certificato del 389-DS
 +
 +  389-console -x nologo -a http://localhost:9830/ -u "cn=Directory Manager" -y /root/.ssh/dmpw &
 +
 +Nel primo tab "Servers and Applications" espandere l’albero di sinistra, cliccare con il tasto destro su "Directory Server" e scegliere "Open"
 +
 +Andare in Console -> tab Tasks -> Manager Certificates -> tab CA Certs
 +Tramite il tasto "Install" installare il certificato della CA che ha rilasciato il certificato server, di tutta la chain e delle CA che si vuole autorizzare.
 +
 +
 +==== "BRASARE" 389-ds ====
 +
 +  cd ~
 +  yum remove "389*"
 +  rm -rf /etc/dirsrv /var/lib/dirsrv /var/log/dirsrv /usr/lib64/dirsrv /usr/share/dirsrv /var/lock/dirsrv /etc/sysconfig/dirsrv* /etc/tmpfiles.d/dirsrv*