Hi

Automatically configuring etc/ldap/ldap.conf is not policy compliant for
the moment as one needs to edit a conffile.

A solution might be to include some file if it exists in the
configuration... or to ask some debconf questions...

Cheers

Luk

Hello Torsten

I'm one of the Debian-Edu Developers and we have since a long time a bug
against debian-edu-config, since we modify some conffiles of other
packages.
As you know we'll have to modify /etc/ldap/ldap.conf. The values we need to
change are:

SLAPD_SERVICES (we set it to: SLAPD_SERVICES="ldap:/// ldaps:///" )
and
SLAPD_OPTIONS (we set it to: SLAPD_OPTIONS="-4" )

would it be possible for you to include a patch from me /or from any other
debian-edu developer in order to fix this? (or to set these values as
default values?)

the patch would contain some debconf questions:
1.) which services should be enabled: [textfield] to enter something like
this: "ldap:///" or "ldaps:////" or "ldap:/// ldaps:///"
2.) which options should be passed to the slapd: [textfield]

Would you apply such a patch?
If yes I'll prepare one for you and submit it into this wishlist bug.

Greetings
Patrick Winnertz

Hi Patrick,

I am not really maintaining OpenLDAP for a while now. I got a new job
and relocated and did not spend much time on Debian lately.

You are talking about /etc/default/slapd, aren't you?

Good question, currently we are serving just ldap:///. Enabling
ldaps:/// as well would make sense. OTOH we should discuss disabling
external access by default.

Why disable IPv6 by default?

I feel it's not up to me to decide this giving that I have been largely
inactive for a while. Let's see what Steve, Russ and Matthijs have to
say about this.

I'd think that won't be a problem. It's the defaults that will probably
be different.

Greetings, Torsten

Hello,
Mh... could be X-). I've looked only into the bug report and not into the
openldap package until now.
Yes.. disabling by default would make sense.. But then I would expect
debconf questions about ldap or ldaps.
When I write the patch I'll set as default value nothing and it's possible
to overwrite this via the debconf questions.
Mh.. okay.. not such a good idea. I would suggest here a default value of
nothing. (In order to use ipv4 and ipv6. ).

These two simply questions would help us a lot. :)
Okay, so I'm looking forward for their answers :)

Greetings
Patrick

# Automatically generated email from bts, devscripts version 2.10.13
# this is actually a slapd issue per the bug log
reassign 370343 slapd
retitle 370343 make /etc/default/slapd automatically configurable

tag 370343 + patch
thanks

Hello openldap maintainers.
During the Debian Edu worksession in Extremadura I've created a patch in
order to preseed the default file of slapd.
Please note that this bug is a blocker bug of our very long standing issue
311188 which is sort of release critical.
So please consider to include the patch.

Thanks in advance

Greetings
Winnie, in behalf of the Debian Edu Team

tags 370343 -patch
thanks

Sorry, nack on this patch in its current form.

- The postinst dynamically creates files under /usr/share.  State files like
  this should only ever be created under /var/lib.
- Why are you using a home-grown md5sum solution instead of using ucf?  For
  an effective use of ucf, please see the samba-common package in
  testing/unstable.
- Why does SLAPD_SERVICES need to be edited at all in your environment -
  what are the settings that you're preseeding, and wouldn't it be better to
  try to identify a sensible default for this file?  I don't think the
  current behavior of this file *is* a sensible default, because ldapi:///
  is missing; but ldap:/// ldapi:/// should be a sensible default IMHO,
  excluding ldaps:/// because TLS should be sufficient for the common
  case.  You do mention in the bug report that you specifically care about
  enabling ldaps:///, can you explain why this is needed in your
  environment?  What clients do you have that can't use TLS?
- Likewise, why do you need to override the location of slapd.conf, as
  opposed to fixing up the standard slapd.conf for your needs?  This wasn't
  even mentioned before now in your bug report.
- Oh, and making SLAPD_SERVICES a multiselect breaks things for those users
  who want to bind to specific IPs.
- Finally, assuming all of the above are resolved, the text of the debconf
  templates contains a number of English errors that would need to be
  addressed prior to inclusion.

I'm sympathetic to your desire to have the slapd package usable
out-of-the-box for your environment, but I think there needs to be a clearer
rationale for the particular changes you're proposing.

This is no problem.. I can change it fast today.
Okay, I'll do
We need to include some additional schemes for debian-edu which wouldn't
make sense as default.
In order to have a look on our configuration file please have a look on:
http://svn.debian.org/wsvn/debian-edu/trunk/src/debian-edu-config/etc/ldap/slapd-debian-edu.conf?op=file&rev=0&sc=0
Oh okay... this should be easy to solve with another debconf question and
some sed magic.
Okay, I'll try to fix these issues.

Greetings
Winnie

Hi,

Steve, thanks for your helpful reply.

I suspect this is for historic reasons, can someone who actually knows the
history please confirm or deny this?!

If so, we should switch to ldap:/// today :-)


regards,
	Holger

Patrick Winnertz <winnie@debian.org> writes:

#333428 would be the way to solve including additional schema, no?  It
seems like a lot less effort.

For the additional schemas this wil be fine.. but as you might see we have
also modified the other things in the file.. not just included additional
schemas. So this would be in my eyes the only possibility to solve this
issue.

Greetings
Winnie

Hi Russ,

Yes, but that bug is stalled since 2006 :-/

Also, this is not enough to fix this for us (as in #370343), because we also
need to add "access to" entries to slapd.conf.


regards,
	Holger

Holger Levsen <holger@layer-acht.org> writes:

That's mostly because there are really no primary OpenLDAP package
maintainers (Steve will forgive me if he doesn't agree with this, but I'm
pretty sure he would), only people like Steve and I who care enough to be
secondary maintainers but only rarely have the time to do serious work and
other people who don't have any free time.

The package really needs more maintainers, and all other problems
essentially fall from there.

As long as you only need to add new things, not change anything that's
there, a more general solution along the same lines should work, I think.

Hi Russ,

/me nods. Did you consider more activly looking for new maintainer, like
filing a RFH bug (can check atm..)? I guess you probably have, so I suggest
blogging as well ;-)

We only add stuff, yes, so this would be excellent for us :-)


regards,
	Holger

Holger Levsen <holger@layer-acht.org> writes:

Blogging (usefully) requires that my blog be syndicated on Planet Debian,
which requires me to deal with my weird blogging setup so that Planet
wouldn't get all of my (uncut) book reviews, which is waiting for me to
figure out what software I'm going to use so that I can get off of an
ancient Movable Type....

Too many things in my life are like that right now.  :)

I have not filed an RFH bug.  My perception, possibly incorrect, is that
such bugs are largely useless.  They seem to accumulate without limit, and
it's not at all clear to me that anyone really looks at them.  But it's
possible that I'm being too cynical about it.

I haven't done more obvious and simple things like post to debian-devel,
either.

Steve, do you have an opinion here?

reassign 453392 openldap
reassign 370337 openldap
reassign 370343 openldap
reassign 452834 openldap
reassign 358829 openldap
thanks

The openldap2.3 package has been removed from Debian. We are reassigning
its bugs to the openldap package. Please have a look at them,
and close them if they don't apply to openldap anymore.

Don't hesitate to reply to this mail if you have any question.

Kind regards,
--
Marco Rodrigues