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>

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:

1. E' utile avere sempre una console funzionante
2. La configurazione di SSL/TLS sulla console

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

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

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

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.

echo 'export DSUID=nome.istanza.ds' >> ~/.bash_profile
source ~/.bash_profile

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

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

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 &

Per migliorare le performance di 389ds, secondo le istruzioni della 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

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

(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

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

Definire la quantità di RAM che viene assegnata alle cache (vedi nota tra le FAQ a fine pagina)

sed -i 's/^nsslapd-cache-autosize: .*$/nsslapd-cache-autosize: 30/' /etc/dirsrv/slapd-$DSUID/dse.ldif

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

Fermare 389ds e verificare lo stato del servizio

systemctl stop dirsrv.target ; systemctl status dirsrv@$DSUID.service

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

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

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 Aggiornare il DB dei certificati delle CA nel 389-ds

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

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

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

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
   

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).

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=&)

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

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

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" ( wiki del 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

Istruzioni disponibili nel wiki del 389-ds

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

 kinit -k -t /etc/dirsrv/dsm1.keytab ldap/dsm1.infn.it@INFN.IT
 klist

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 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.

Documentazione originale in 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

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

Inviare la richiesta di certificato alla propria CA ed installare il certificato firmato

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.

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*