The BDII log file should explain why objects are not accepted;
for example, due to a badly formatted attribute. The default
location of the log file is
/var/log/bdii/bdii-update.log
, but the
location is configured by the BDII_LOG_FILE
option in the /opt/bdii/etc/bdii.conf
file.
The BDII log files may show entries like:
2011-05-11 04:04:58,711: [WARNING] dn: o=shadow 2011-05-11 04:04:58,711: [WARNING] ldapadd: Invalid syntax (21) 2011-05-11 04:04:58,711: [WARNING] additional info: objectclass: value #1 invalid per syntax
This problem comes when BDII is attempting to inject new
information. Unfortunately, the information isn’t detailed
enough for further investigation. To obtain more detailed
information from BDII, switch the
BDII_LOG_LEVEL
option in
/opt/bdii/etc/bdii.conf
to
DEBUG
. This will provide more information in
the BDII log file.
Logging at DEBUG
level has another effect;
BDII no longer deletes some temporary files. These temporary
files are located in the directory controlled by the
BDII_VAR_DIR
option. This is /var/run/bdii
by default.
There are several temporary files located in the /var/run/bdii
directory. When BDII
decides which objects to add, modify and remove, it creates
LDIF instructions inside temporary files
add.ldif
, modify.ldif
and delete.ldif
respectively. Any problems
in the attempt to add, modify and delete LDAP objects are
logged to corresponding error files: errors with
add.ldif
are logged to
add.err
, modify.ldif
to
modify.err
and so on.
Once information in BDII has stablised, the only new, incoming
objects for BDII come from those objects that it was unable to
add previously. This means that add.ldif
will contain these badly formatted objects and
add.err
will contain the corresponding
errors.