У меня есть сервер OpenLDAP 2.4, работающий на Ubuntu 18.04 LTS. Каждый раз, когда я бегу
# slapcat -l test.ldif
мой файл slapd.log усекается (т. е. предыдущие сообщения журнала удаляются, а новые записываются в начало файла).
На самом деле первая строка slapd.log показывает вывод slapcat:
# глава /var/log/slapd.log
620ca0f1 Первая база данных не поддерживает slapcat; используя первый доступный (2)
16 февраля, 08:00:15 srv21449 slapd[2096]: conn=274238 op=552602 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
16 февраля, 08:00:15 srv21449 slapd[2096]: conn=274238 op=552602 SRCH attr=1.1
Это наводит меня на мысль, что усечение файла происходит еще до того, как slapcat сгенерирует какой-либо вывод.
Насколько я понимаю, slapcat не имеет ничего общего с логированием (которое делает демон slapd), поэтому я полагаю, что что-то упускаю... Есть какие-нибудь идеи?
Редактировать №1: Я запускаю команду slapcat с работающим slapd. На данный момент я не могу остановить службу, чтобы проверить, произойдет ли это, когда демон не работает. Раньше я читал, что этого следует избегать, но на справочной странице slapcat:
Для некоторых типов бэкенда ваш slapd(8) не должен быть запущен (по крайней мере,
не в режиме чтения-записи), когда вы делаете это, чтобы обеспечить согласованность
база данных. Всегда безопасно запускать slapcat с командой slapd-bdb(5),
slapd-hdb(5) и slapd-null(5).
Запуск slapcat поверх работающего slapd с бэкендом bdb (мой случай) должен быть безопасным
Редактировать № 2 Изучив немного больше, я попытался использовать auditctl для мониторинга доступа к slapd.log, добавив новое правило аудита:
# auditctl -w /var/log/slapd.log -k slapd
После повторного запуска slapcat я вижу это:
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 nametype =НОРМАЛЬНОЕ 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 nametype=PARENT cap_fp =0000000000000000 cap_fi=00000000000000000 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 items=2 ppid=69682 pid=73954 auid=1000 uid= 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"
Последняя строка аудита показывает, что был доступ со стороны /usr/sbin/slapcat, что подтверждает, что slapcat действительно что-то делает с slapd.log. Я начинаю спрашивать себя, является ли это просто ожидаемым поведением при запуске slapcat в «горячем» режиме (т. е. без остановки службы slapd), даже если для меня это не имеет особого смысла...
