[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

bts2ldap-Gateway is coming up again


the bts2ldap-Gateway is slowly coming up again. There are however some
drawbacks at the moment.

What it does:
aba@sol:~$ ldapsearch -h master.debian.org -p 10101 -x -b dc=testbts '(&(street=mgetty)(!(l=woody)))'
version: 2

# filter: (&(street=mgetty)(!(l=woody)))
# requesting: ALL

# 26372, testbts
dn: cn=26372,dc=testbts
objectClass: organizationalPerson
description: mgetty: AutoPPP should not set utmp entry
cn: 26372

You can see one major drawback: The current openldap2 doesn't allow
usage without schemas. So I couldn't stick with the previous
attribute names for the moment, but decided to abuse the
organizationalPerson (that's part of the core schema). However, Debian
has an allocated space for attributes, and if we decide to promote the
gateway to an official tool, I'll work on using proper attribute
names ASAP.

For the moment, the following attribute names are used:
bugID       cn
subject     description
severity    destinationIndicator
status      postalAddress
tag         l
package     street
submitter   postOfficeBox

I tried to get the tool working with a standard openldap2 (the version
in sid / the backport of that to woody). That has almost happend,
however, I need the possibility of doing the search in the
shell-backend, see Bug #236584. The way of doing this has the great
advantage that you can filter any way you like.

Another drawback is that the script needs to either work on a "own"
index file, can't cope with bug titles or is _really_ slow. This is
because the standard index file doesn't have bug titles. I decided for
the own file for now; this file is updated once a hour, and works with
the backup data on master. It would also be possible to either add
that information to the official index, or to transform the tool to a
c-backend and remove the bug title from the searchable attributes
(that would also allow to use the official index).

And of course, this is just a prototype. Any error may happen. There
are definitly there some possibilities to make it better, but IMHO
it's ok for a prototype now. And also of course, documentation is

Comments and suggestions are welcome.

   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Reply to: