[Freeipa-users] Re: What is the correct way to make schema changes across all replicas?

[Rob Crittenden]

Joshua Hoblitt via FreeIPA-users wrote:
>  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 
You don't need the objectclass and cn attributes here. cn=schema already
exists.

>      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";) 
Don't put your acis under cn=schema. They need to live where the data
lives. I'd drop your aci read restriction too, it isn't necessary.

>      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 
I think this should be 1.2.5. It's a dup of the previous value.

>      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' ) 
I know nothing about pwm but it seems like some of these values
duplicate what is already in IPA.

>  
>  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/? 
Just dropping files in place will be run by ipa-ldap-update and you
might see the same issue.

Just a raw ipa-ldap-updater run at all? Perhaps check for SELinux AVCs.
It does a ldapi bind using the socket. I've never seen that fail before.

rob

>  
>  Any guidance would be greatly appreciated.
>  
>  -Josh
>  
>  --
>  
>  _______________________________________________
>  FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedorahosted.org/archives/list/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>