The LDAP scripts errored out during initial VM creation and did not re-run. Trying to login to Striker leads to:
2018-01-14T14:22:44Z [4318d6c33adc4c92afa5e84774725342] django_auth_ldap WARNING: Caught LDAPError while authenticating admin: NO_SUCH_OBJECT({'desc': 'No such object', 'matched': 'ou=servicegroups,dc=wmftest,dc=net'},)
By modifying \puppet\modules\role\templates\striker\ldap_check.erb to /bin/false, vagrant provision re-runs the LDAP script:
==> default: Error: /usr/bin/ldapadd -x -D "cn=admin,dc=wmftest,dc=net" -w "vagrant_admin" <<LIDF ==> default: dn: ou=servicegroups,dc=wmftest,dc=net ==> default: objectclass: organizationalUnit ==> default: ou: servicegroups ==> default: objectClass: top ==> default: description: Tools ==> default: ==> default: dn: ou=people,ou=servicegroups,dc=wmftest,dc=net ==> default: objectClass: organizationalUnit ==> default: objectClass: top ==> default: ou: people ==> default: ==> default: dn: ou=projects,dc=wmftest,dc=net ==> default: objectClass: organizationalUnit ==> default: objectClass: top ==> default: description: OU for openstack projects and global groups ==> default: ou: projects ==> default: ==> default: dn: uid=admin,ou=People,dc=wmftest,dc=net ==> default: objectClass: person ==> default: objectClass: inetOrgPerson ==> default: objectClass: organizationalPerson ==> default: objectClass: ldapPublicKey ==> default: objectClass: posixAccount ==> default: objectClass: shadowAccount ==> default: objectClass: top ==> default: cn: Admin ==> default: sn: Admin ==> default: uid: admin ==> default: mail: ldapadmin@local.wmftest.net ==> default: userPassword: vagrant ==> default: uidNumber: 1001 ==> default: gidNumber: 1001 ==> default: homeDirectory: /home/admin ==> default: loginShell: /bin/bash ==> default: ==> default: dn: cn=wmf,ou=groups,dc=wmftest,dc=net ==> default: objectClass: groupOfNames ==> default: objectClass: posixGroup ==> default: objectClass: top ==> default: cn: wmf ==> default: gidNumber: 5000 ==> default: member: uid=admin,ou=People,dc=wmftest,dc=net ==> default: ==> default: dn: cn=project-tools,ou=groups,dc=wmftest,dc=net ==> default: objectClass: groupOfNames ==> default: objectClass: posixGroup ==> default: objectClass: top ==> default: cn: project-tools ==> default: gidNumber: 5001 ==> default: member: uid=admin,ou=People,dc=wmftest,dc=net ==> default: ==> default: dn: cn=tools,ou=projects,dc=wmftest,dc=net ==> default: objectClass: extensibleObject ==> default: objectClass: groupOfNames ==> default: objectClass: top ==> default: cn: tools ==> default: member: uid=admin,ou=People,dc=wmftest,dc=net ==> default: ==> default: dn: ou=sudoers,cn=tools,ou=projects,ou=People,dc=wmftest,dc=net ==> default: objectClass: organizationalUnit ==> default: objectClass: top ==> default: ou: sudoers ==> default: ==> default: dn: cn=tools.admin,ou=servicegroups,dc=wmftest,dc=net ==> default: objectClass: groupOfNames ==> default: objectClass: posixGroup ==> default: objectClass: top ==> default: cn: tools.admin ==> default: gidNumber: 5002 ==> default: member: uid=admin,ou=People,dc=wmftest,dc=net ==> default: ==> default: dn: cn=tools.example,ou=servicegroups,dc=wmftest,dc=net ==> default: objectClass: groupOfNames ==> default: objectClass: posixGroup ==> default: objectClass: top ==> default: cn: tools.example ==> default: gidNumber: 5003 ==> default: member: uid=admin,ou=People,dc=wmftest,dc=net ==> default: LIDF ==> default: returned 68 instead of one of [0] ==> default: Error: /Stage[main]/Role::Striker/Exec[Add Striker LDAP data]/returns: change from notrun to 0 failed: /usr/bin/ldapadd -x -D "cn=admin,dc=wmftest,dc=net" -w "vagrant_admin" <<LIDF
where exit code 68 means "already exists". If I remember correctly, this was also the issue during the initial run, but I don't understand why that would be the case.
Running parts of the LDAP data one by one shows that
dn: ou=servicegroups,dc=wmftest,dc=net dn: ou=people,ou=servicegroups,dc=wmftest,dc=net dn: ou=projects,dc=wmftest,dc=net dn: uid=admin,ou=People,dc=wmftest,dc=net dn: cn=wmf,ou=groups,dc=wmftest,dc=net dn: cn=project-tools,ou=groups,dc=wmftest,dc=net dn: cn=tools,ou=projects,dc=wmftest,dc=net
are all provisioned correctly, but:
vagrant@mediawikivagrant:/vagrant/logs/striker$ /usr/bin/ldapadd -x -D "cn=admin,dc=wmftest,dc=net" - w "vagrant_admin" dn: ou=sudoers,cn=tools,ou=projects,ou=People,dc=wmftest,dc=net objectClass: organizationalUnit objectClass: top ou: sudoers adding new entry "ou=sudoers,cn=tools,ou=projects,ou=People,dc=wmftest,dc=net" ldap_add: No such object (32) matched DN: ou=People,dc=wmftest,dc=net
The final two entries can then be added by hand:
vagrant@mediawikivagrant:/vagrant/logs/striker$ /usr/bin/ldapadd -x -D "cn=admin,dc=wmftest,dc=net" - w "vagrant_admin" dn: cn=tools.admin,ou=servicegroups,dc=wmftest,dc=net objectClass: groupOfNames objectClass: posixGroup objectClass: top cn: tools.admin gidNumber: 5002 member: uid=admin,ou=People,dc=wmftest,dc=net adding new entry "cn=tools.admin,ou=servicegroups,dc=wmftest,dc=net" vagrant@mediawikivagrant:/vagrant/logs/striker$ /usr/bin/ldapadd -x -D "cn=admin,dc=wmftest,dc=net" - w "vagrant_admin" dn: cn=tools.example,ou=servicegroups,dc=wmftest,dc=net objectClass: groupOfNames objectClass: posixGroup objectClass: top cn: tools.example gidNumber: 5003 member: uid=admin,ou=People,dc=wmftest,dc=net adding new entry "cn=tools.example,ou=servicegroups,dc=wmftest,dc=net"