Page MenuHomePhabricator

LDAP data not correctly provisioned when building new Striker VM with Vagrant
Closed, ResolvedPublic

Description

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"

Event Timeline

(adding the final entries by hand makes Striker work, so that's a useful workaround)

ou=sudoers,cn=tools,ou=projects,ou=People,dc=wmftest,dc=net
seems a bit odd - shouldn't that be ou=sudoers,cn=tools,ou=projects,dc=wmftest,dc=net (i.e., without the ou=People inbetween)? As cn=tools,ou=projects,dc=wmftest,dc=net is an entity, and so is ou=People,dc=wmftest,dc=net, but ou=projects,ou=People,dc=wmftest,dc=net is not. But my LDAP knowledge is limited, so it's a bit difficult to figure out :-)

bd808 added a project: MediaWiki-Vagrant.
bd808 subscribed.

I need to review the whole role for migrating to Stretch, so I'll try to fix this up at the same time. At one point I was going to make a proper set of Puppet defines to manage the ldap tree and then I got lazy. This might be a good excuse to revisit that decision and make things a bit more robust.

Change 481557 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[mediawiki/vagrant@master] striker: Fix typo in LDAP bootstrap data

https://gerrit.wikimedia.org/r/481557

Change 481557 merged by jenkins-bot:
[mediawiki/vagrant@master] striker: Fix typo in LDAP bootstrap data

https://gerrit.wikimedia.org/r/481557

There are other pending changes that will need to land before Striker provisions cleanly on a Debian Stretch MediaWiki-Vagrant deploy, but this particular problem should be fixed now.