New subject: What is the correct way to make schema changes across all replicas?

15 Sep 2023


      Hi Folks,
At the moment, I'm investigating using pwm to allow user password reset 
self service.  pwm requires a schema change to add its own attributes.  
I'm afraid I've never been clear on what the correct procedure is for 
make schema changes and I've been unable to find a blurb on this in the 
RH IdM docs.
There seems to be a couple of possible ways of going about this using 
ldapmodify or dropping ldif files directly under 
/etc/dirsrv/slapd-<foo>/schema. However, that requires templating the 
ldif with server specific changes.
Seeing as the files under /usr/share/ipa appear to be templated via 
ipa-ldap-updater and the man page states:
Additionally, ipa-ldap-updater can update the schema based
    on LDIF files.  Any missing object classes and attribute types are
    added, and differing ones are updated to  match  the
            LDIF  file.   To  enable this behavior, use the
    --schema-file options.  Schema files should be in LDIF format, and
    may only specify attributeTypes and objectClasses attributes of
            cn=schema.
I attempted to template the pwm schema changes as follows:
dn: cn=schema
    objectclass: top
    objectclass: ldapSubentry
    objectclass: subschema
    cn: schema
    aci: (target="ldap:///cn=schema")(targetattr !="aci")(version
    3.0;acl "anonymous, no acis"; allow (read, search, compare) userdn =
    "ldap:///anyone";)
    aci: (targetattr="*")(version 3.0; acl "Configuration Administrators
    Group"; allow (all)
    groupdn="ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)
    aci: (targetattr="*")(version 3.0; acl "Configuration
    Administrator"; allow (all)
    userdn="ldap:///uid=admin,cn=users,cn=accounts,$SUFFIX";)
    aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all)
    groupdn = "ldap:///fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX";)
    attributetypes: ( 1.3.6.1.4.1.35015.1.2.1 NAME 'pwmEventLog'  SYNTAX
    1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'user defined' )
    attributetypes: ( 1.3.6.1.4.1.35015.1.2.2 NAME 'pwmResponseSet' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'user defined' )
    attributetypes: ( 1.3.6.1.4.1.35015.1.2.3 NAME 'pwmLastPwdUpdate' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE X-ORIGIN 'user
    defined' )
    attributetypes: ( 1.3.6.1.4.1.35015.1.2.4 NAME 'pwmGUID'  SYNTAX
    1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
    attributetypes: ( 1.3.6.1.4.1.35015.1.2.4 NAME 'pwmToken'  SYNTAX
    1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
    attributetypes: ( 1.3.6.1.4.1.35015.1.2.6 NAME 'pwmOtpSecret' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'user defined' )
    attributetypes: ( 1.3.6.1.4.1.35015.1.2.7 NAME 'pwmData'  SYNTAX
    1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'user defined' )
    objectclasses: ( 1.3.6.1.4.1.35015.1.1.1 NAME 'pwmUser' DESC '' SUP
    top AUXILIARY MAY ( pwmEventLog $ pwmResponseSet $ pwmLastPwdUpdate
    $ pwmGUID $ pwmToken $ pwmOtpSecret $ pwmData ) X-ORIGIN 'user
    defined' )
However, trying to use `ipa-ldap-updater` in this manner suggested by 
the manpage fails:
# ipa-ldap-updater --schema-file ./99pwm.ldif
    Unexpected error - see /var/log/ipaupgrade.log for details:
    IOError: [Errno socket error] [Errno -2] Name or service not known
    The ipa-ldap-updater command failed. See /var/log/ipaupgrade.log for
    more information
The error message is complaining about the socket... which I've 
confirmed from the ipaupgrade.log is the correct path to the dirsrv 
socket (and dirsrv is otherwise functioning).
Is this an abuse of, or bug in, ipa-ldap-updater?  Is it possible to 
simply drop templated ldif files under /usr/share/ipa/ and have them be 
processed similarly to /usr/share/ipa/updates/?
Any guidance would be greatly appreciated.
-Josh
--