Am un server OpenLDAP 2.4 care rulează pe Ubuntu 18.04 LTS. De fiecare dată când fug
# slapcat -l test.ldif
fișierul meu slapd.log este trunchiat (adică mesajele de jurnal anterioare sunt șterse și altele noi sunt scrise la începutul fișierului).
De fapt, prima linie a slapd.log arată rezultatul lui slapcat:
# head /var/log/slapd.log
620ca0f1 Prima bază de date nu permite slapcat; folosind primul disponibil (2)
16 februarie 08:00:15 srv21449 slapd[2096]: conn=274238 op=552602 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
16 februarie 08:00:15 srv21449 slapd[2096]: conn=274238 op=552602 SRCH attr=1.1
Asta mă face să cred că trunchierea fișierului are loc chiar înainte ca slapcat să genereze orice ieșire.
Din câte am înțeles, slapcat nu are nimic de-a face cu înregistrarea în jurnal (care este făcută de daemonul slapd), așa că cred că îmi lipsește ceva... Aveți vreo idee?
Editare #1: Rulez comanda slapcat cu slapd rulând. Momentan, nu pot opri serviciul pentru a verifica dacă acest lucru s-ar întâmpla atunci când demonul nu rulează. Am citit înainte că acest lucru ar trebui evitat, dar din pagina de manual a lui slapcat:
Pentru unele tipuri de backend, slapd(8) nu ar trebui să ruleze (cel puțin,
nu în modul citire-scriere) când faceți acest lucru pentru a asigura consistența
Bază de date. Este întotdeauna sigur să rulați slapcat cu slapd-bdb(5),
backend-uri slapd-hdb(5) și slapd-null(5).
Rularea slapcat peste un slapd care rulează cu backend bdb (cazul meu) ar trebui să fie în siguranță
Editare #2 Investigând puțin mai departe, am încercat să folosesc auditctl pentru a monitoriza accesul la slapd.log adăugând o nouă regulă de audit:
# auditctl -w /var/log/slapd.log -k slapd
După ce rulez din nou slapcat, văd asta:
type=PROCTITLE msg=audit(1645437260.398:5558713): proctitle=736C6170636174002D6C00746573742E6C646966
type=PATH msg=audit(1645437260.398:5558713): item=1 name="/var/log/slapd.log" inode=131414 dev=fd:04 mode=0100640 ouid=0 ogid=4 rdev=00:00 name =NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=PATH msg=audit(1645437260.398:5558713): item=0 name="/var/log/" inode=131074 dev=fd:04 mode=040775 ouid=0 ogid=106 rdev=00:00 name_ftype=PARENT =0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0
type=CWD msg=audit(1645437260.398:5558713): cwd="/root"
type=SYSCALL msg=audit(1645437260.398:5558713): arch=c000003e syscall=257 success=yes exit=4 a0=ffffff9c a1=55e525c35410 a2=241 a3=1b6 item=uid60000000000000000000000 0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=903297 comm="slapcat" exe="/usr/sbin/slapcat" key="slapd"
Ultima linie a auditului arată că a existat un acces de către /usr/sbin/slapcat, deci confirmă că slapcat face de fapt ceva cu slapd.log. Încep să mă întreb dacă acesta este un comportament așteptat de la rularea slapcat „fierbinte” (adică să nu opresc serviciul slapd), chiar dacă nu prea are sens pentru mine...
