Package: gforge-ldap-openldap
Version: 3.1-31
Severity: wishlist

I wouldn't regard this as a bug in gforge; it is more of a support issue, but
I was not sure of how else an answer may be found on this.

At some point in time, my host's main OpenLDAP database became corrupted.
The directory on the database has been used only by GForge, and so, the
problem has not resulted in an interruption of other services, but it
results in that I cannot upgrade the GForge ldap package, and a package
dependant on it, and I cannot use any of the GForge web services.

While I haven't checked on it, but I'm under the assumption that the SQL
records maintained by the GForge services are still intact.

My question is, basically: Is there an existing, plausible way to
re-initialize the LDAP directory used by GForge, as on the contents of the
SQL database used by GForge? I realize that some scripting between an SQL
client and an LDAP client may be operable for such; I am not sure if there
may be any existing work, in that regard.

Apart from the above, I hope to ask another question about GForge on Debian.
I wonder if you would be aware of how there would be determined any
information about the availability and, along with the GForge debian
packages, a reasonable means for installation of the SOAP or
command-line-interface plugins supposed to be available for GForge? My
impression is that either of those plugins may be of use for integration of
clients with GForge, and may be of help for ensuring compatability across
systematically different project hosts. (I am not aware of how mature the
codebases for the plugins may be, in either situation.)

Thank you.

-
Sean Champ

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i586)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.8
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages gforge-ldap-openldap depends on:
ii  debconf                       1.4.57     Debian configuration management sy
ii  debianutils                   2.14.2     Miscellaneous utilities specific t
ii  gforge-common                 3.1-31     Collaborative development tool - s
ii  gforge-db-postgresql [gforge- 3.1-31     Collaborative development tool - d
ii  ldap-utils                    2.1.30-3   OpenLDAP utilities
ii  libdbd-pg-perl                1.32-2     a PostgreSQL interface for Perl 5
ii  libdbi-perl                   1.48-1     Perl5 database interface by Tim Bu
ii  libnss-ldap                   238-1      NSS module for using LDAP as a nam
ii  perl                          5.8.8-6    Larry Wall's Practical Extraction
ii  slapd                         2.1.30-3   OpenLDAP server (slapd)

gforge-ldap-openldap recommends no packages.

-- debconf information excluded

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Yes it is, in fact the debian package is hourly making a db dump, make a
ldif file from this (using sql2ldif) and inject this in the ldap db. The
problem is probably you have to adjust sql2ldif to fit with the ldap
schema that had some changes between sarge and etch.
In recent gforge package we prefer to use nss-pgsql  instead of
nss-ldap, so we don't need anymore to use ldap
nevertheless it's still possible to continue to make the dump/update
process if you need ldap for some other reason.

I didn't see any debian packaging of this, putting the files in the
right place should work until this is packaged. I never tested this, you
may find some help on irc.freenode.net #gforge

--
To UNSUBSCRIBE, email to debian-bugs-dist-REQU...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org