openldap install bare bones need default DIT separate package

Thanks for the bug report. I believe this might be considered for karmic+1/

Regards
chuck

Sorry to say so,

this should be done before Karmic is released. After spending a lot of time trying to configure openldap I downgraded the packages to the Intrepid version to get a working test ldap on my machine.

Being able to run dpkg-reconfigure slapd and than having the first choice being bare bone or enter the values as before. This should only be a minor change of the command sequence.

TNX for taking it into consideration.

The current plan is to stay with a bare-bone slapd package. A default DIT (with associated modules and schema) should be provided as a separate package, probably in the Lucid time frame.

I am also having troubles with setting up OpenLDAP in Karmic. I understand the recent changes are part of a bigger goal. However, novice users like me desperately need some documentation on how to get a simple directory database up and running. I have already put in a forum message on this at <http://ubuntuforums.org/showthread.php?t=1295934> and filed a bug against the ubuntu-docs at <https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/459403>.

I understand that we need to use the "sudo ldapadd -Y EXTERNAL -H ldapi:/// ..." command to update the cn=config. But can we get some working sample files in the man pages or in the Ubuntu docs? None of the samples I have found have worked (see my forum posts for more info).

Sorry for being very straight here (I'm german) but:

Yes there are people out there with no phd in programming (and not planing to get one) that simlpy want to use openldap out of the box. Install -> setup -> use!

I am new to ubuntu and I am trying to switch a productive environment from windows backend to unbuntu. So I got some books and a lot of howtos from the net. Installed the software and followed any of these howtos. And wonder what happend: I got completely lost in error messages... So lets ask the net on ubuntu karmic server sldap and:

Uuups sorry nothing there (you can find some lost people like me that are desperatly trying to find out why all manuals and howtos dont work, but thats it). No howto there, no description what changed (and why) and how to deal with the situation.

That does make me wonder if I took the right decission in switching - at least that windows stuff has documentation available that matches the software.

So please: Make a usable how to available ASAP (=today not tomorrow)!!! And have it published where someone will look for it (ubuntu.com or ubuntuusers.de for my fellow germans).

mob,

I understand your frustration as I was in the same boat a couple weeks ago. As I mentioned already, I have filed a bug against Ubuntu docs for this. Your message may be more appropriate over there: <https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/459403>.

Also, I have posted a howto on the Ubuntu Forums at <http://ubuntuforums.org/showpost.php?p=8161118&postcount=6>.

Alissa

Alissa, thanks a ton. You are a life-saver.
I'm a Linux newbie and wanted to setup a sample ldap server to test. It took me the whole of today to stumble upon Alissa's post to get something working.
I'd very much like OpenLDAP to work out of the box. And documentation to support the version of OpenLDAP that's released.

I've just written another HowTo that I'll gladly throw into the mix: http://ubuntuforums.org/showthread.php?t=1313472

By the way: it is really a shame that there is no official word from canonical on this. Not even an official tutorial on how to deal with the new situation. It's nice that canonical is slowly seeing the importance of an LDAP-based (heck, even Kerberos-based) network infrastructure, but this whole situation should have been handled more carefully.

I am in the same boat. I had a perfectly working ldap setup with two replicating servers on Jaunty. I made the stupid decision to upgrade to Karmic and lo and behold the configuration broke! After a couple of days of trying to find a solution to this problem, i looked at the files in /etc/ldap/slapd.d/ and looked at the files that had changed. I found that the upgrade inserted some weird acl line to restrict access except by root. This was preventing phpldapadmin from working.

I removed the acl manually from the two files that had it (sorry, i don't remember the name of the files) and that restored the base search functionality but now, I have strange replication problems. Things are inconsistent. If I add a user to one server, it may or may not replicate to the other server. Its madness... All of it was working 100% before. What did you guys do in Karmic???

There is another bug in php 5 that prevents phplapadmin from working but there is a fix for that particular bug.

I don't know if the replication problems are related to me manually removing the darn acl line from the two files. I guess I should have used the ldapmodify command. I am new at this ldap stuff with cn=config. I liked it way better when we had slapd.conf file to quickly change things.

If anyone has any insight on what might be wrong with syncrepl in karmic, please let us know.

On Thu, Nov 12, 2009 at 05:50:29AM -0000, Alberto wrote:
> I am in the same boat. I had a perfectly working ldap setup with two
> replicating servers on Jaunty. I made the stupid decision to upgrade to
> Karmic and lo and behold the configuration broke! After a couple of days
> of trying to find a solution to this problem, i looked at the files in
> /etc/ldap/slapd.d/ and looked at the files that had changed. I found
> that the upgrade inserted some weird acl line to restrict access except
> by root. This was preventing phpldapadmin from working.
>
> I removed the acl manually from the two files that had it (sorry, i
> don't remember the name of the files) and that restored the base search
> functionality but now, I have strange replication problems. Things are
> inconsistent. If I add a user to one server, it may or may not replicate
> to the other server. Its madness... All of it was working 100% before.
> What did you guys do in Karmic???
>

Please file a new bug about your specific issue.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Please, provide a working default configuration with the common schemas (inetOrgUser, sambaUser, maybe virtual mail domains).

Do we really need to argue the benefits an easy-to-install network LDAP server? As of 9.04 the client installation was very straight-forward... but right now the fastest way to get a usable Ubuntu LDAP server is to install eBox, which comes with hundreds of megs of stuff that we really don't need.

Even though I know how to configure a slapd server by hand, doesn't mean I want to waste my time doing it.

Why is this marked as a duplicate of a documentation bug? There are documentation issues here, to be sure, but this is also a "useful configuration missing by default" bug, which isn't covered by #463684.

Same for me. I don't think this is a documentation bug only.

The lack of a simple way of setting up a working basic ldap-service is a serious problem. I've basically resigned to either using a really old package that's not broken in this way or just forgetting about ldap in ubuntu.

What's the reasoning behind upgrading a package from "too old" to "unusable" ?

And it also won't be fixed in any meaningful way in Lucid, or do I read that "Declined for Lucid" wrong?

Really, I'm appalled. Last time I saw such a broken-as-installed package was in an ancient SuSE install. When you removed the DIT code from the package, why TF did you not roll a *simple* slapd-dit package (or whatever one would have called it)?

On Fri, Mar 19, 2010 at 01:50:37PM -0000, Jürgen Erhard wrote:
> When you removed the DIT code
> from the package, why TF did you not roll a *simple* slapd-dit package
> (or whatever one would have called it)?

That's the plan: creating a slapd-dit package that would provide the same DIT
as before. I just haven't got the time to do it yet.

Patches are welcomed.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

Is the package "slapd-dit" planed to be included in Lucid?
Or will it at least be in the "OpenLDAP Edgers PPA"?

Thanks!

On Tue, Mar 23, 2010 at 11:14:20PM -0000, Tobias Bradtke wrote:
> Is the package "slapd-dit" planed to be included in Lucid?

It probably is too late for Lucid as FeatureFreeze is in effect.

> Or will it at least be in the "OpenLDAP Edgers PPA"?
>

There isn't such a PPA AFAIK. However anyone can create a PPA to publish such a
package...

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

In my opionion, the new (useless) slapd package should not have shipped until the accompanying slapd-dit was ready. It basically broke LDAP for everyone but experts, and now Mathias doesn't have time to fix it.

Mathias, can you make slapd-dit a priority? It's been several months since a usable slapd has been available for Ubuntu.

Apologies in advance for the useless rant, but whose idea was it to strip out the default ldap config?

I second the comments of everyone here that laments the time when slapd just worked.
The cn=config change was difficult to swallow, but in the interest of progress, OK, fine. This release however is completely unusable out of the box. How can Ubuntu be so close to a final release of an LTS version and not be able to support an LDAP authentication server without massive amounts of googling and cursing? Why does everyone need to be an LDAP specialist to get it to work.

This is not a documentation problem. It is a completely broken package problem. After spending ages troubleshooting a migration from a working LDAP config to a new LDAP instance on Karmic I gave up. I'm going to install a Windows DC and use likewise. Openldap is now my most hated piece of software: previously it was windows, so congratulations.

Just to get a feel for the state here, is there currently any work done at all for this slapd-dit package?

Why is this marked as "Won't fix"? Is Ubuntu planning a new LTS release with no LDAP? That'll go over well. Has anyone in canonocal mgmt even seen this? Or is it a nasty little surprise they'll get from the enterprisey first reviewer?

I'm trying to plan for a development platform that was going to be 10.4 based, but needs ldap first out.
Is there a workaround that can be used with pbuilder based chroots? All the hacks I've seen so far require that one have slapd already running on the target machine. What if one is building an inert filesystem for NFS boot ?
How are we supposed to get ldap installed and initialized with no debconf support to prime the database?
Yes there are no docs on how to do this but I would argue strongly against this being a doc issue. This is plain incomplete. This move should have waited until the slapd-dit package was complete.
Can this be rolled back until it's ready?

The current state of slapd makes 10.4 unusable for us.

Has anyone tried building a previous ldap source drop on 10.4?

What's the last known working slapd package version?

I might give the slapd downgrade option a shot before giving up and going over to Debian. They even have dom0 kernels that are less than 2 years old...

I'd suggest to have a look at the openldap-dit project on LP:

https://launchpad.net/openldap-dit/

What is the functional state of openldap-dit? (https://launchpad.net/openldap-dit/)

It hasn't seen any activity since 2009-12-02 and there are no milestones and no available downloads. The trunk show last modified 20 weeks ago.

Is it functional, or the early stages of work in progress? The former may work wheres the latter is hardly a solution for the current problem.

I assume one need to use bzr to pull off the source and build it?

Anyone else tried this yet?

Can someone change this from wishlist to something more likely to get fixed?

After every new release of ubuntu (the last I am trying now is 10.10) I try openldap. Unfortunately every time I end up with the same result. It does not work. I type in "dpkg-reconfigure slapd" and the result is the same as mentioned at the top of this bug report - no password asked configuration exits after first few questions. The only solution I found so far is to switch to http://directory.apache.org/

I posted this comment for another bug, but it is already closed :(.

Yeah, the fact that this isn't even being worked on since this problem was reported over a year ago is pretty embarrassing. It definitely seems like critical Ubuntu server issues are largely ignored.

This bug was fixed in the package openldap - 2.4.23-6ubuntu1

---------------
openldap (2.4.23-6ubuntu1) natty; urgency=low

  * Merge from Debian unstable:
    - Install a default DIT (LP: #442498).
    - Document cn=config in README file (LP: #370784).
    - remaining changes:
      + AppArmor support:
        - debian/apparmor-profile: add AppArmor profile
        - use dh_apparmor:
          - debian/rules: use dh_apparmor
          - debian/control: Build-Depends on debhelper 7.4.20ubuntu5
        - updated debian/slapd.README.Debian for note on AppArmor
        - debian/slapd.dirs: add etc/apparmor.d/force-complain
      + Enable GSSAPI support (LP: #495418):
        - debian/patches/gssapi.diff, thanks to Jerry Carter (Likewise):
          - Add --with-gssapi support
          - Make guess_service_principal() more robust when determining
            principal
        - debian/patches/series: apply gssapi.diff patch.
        - debian/configure.options: Configure with --with-gssapi
        - debian/control: Added libkrb5-dev as a build depend
      + debian/rules: Enable -DLDAP_CONNECTIONLESS to build CLDAP (UDP) support
        in the openldap library, as required by Likewise-Open (LP: #390579)
      + Don't build smbk5pwd overlay since it uses heimdal instead of krb5:
        - debian/control:
          - remove build-dependency on heimdal-dev.
          - remove slapd-smbk5pwd binary package.
        - debian/rules: don't build smbk5pwd slapd module.
      + debian/{control,rules}: enable PIE hardening
      + ufw support (LP: #423246):
        - debian/control: suggest ufw.
        - debian/rules: install ufw profile.
        - debian/slapd.ufw.profile: add ufw profile.
      + Enable nssoverlay:
        - debian/patches/nssov-build, debian/series, debian/rules:
          Apply, build and package the nss overlay.
        - debian/schema/extra/misc.ldif: add ldif file for the misc schema
          which defines rfc822MailMember (required by the nss overlay).
      + debian/rules, debian/schema/extra/:
        Fix configure rule to supports extra schemas shipped as part
        of the debian/schema/ directory.
      + debian/rules, debian/slapd.py: Add apport hook. (LP: #610544)
      + debian/slapd.init.ldif: don't set olcRootDN since it's not defined in
        neither the default DIT nor via an Authn mapping.
      + debian/slapd.scripts-common: adjust minimum version that triggers a
        database upgrade. Upgrade from maverick shouldn't trigger database
        upgrade (which would happen with the version used in Debian).
      + debian/slapd.scripts-common: add slapcat_opts to local variables.
        Remove unused variable new_conf.
      + debian/slapd.script-common: Fix package reconfiguration.
        - Fix backup directory naming for multiple reconfiguration.
      + debian/slapd.default, debian/slapd.README.Debian:
        use the new configuration style.

openldap (2.4.23-6) unstable; urgency=high

  * Check for an empty directory to prevent an rm -f /*. (Closes: #597704)

openldap (2.4.23-5) unstable; urgency=high

  [ Steve Langasek ]
  * High-urgency upload for RC bugfix.
  * debian/slapd.scripts-common: fix gratuitou...

This is great news to finally get OpenLdap back working smoothly in Ubuntu. Cannot wait to plug authentifications back on LDAP without fearing to break everything with an update. Any chance to get it soon on Maverick through maverick-backports?

Bigs thanks for this work!

Please can we get this in lucid as a backport since it's an LTS release?

Seconded. Please provide a backport to lucid!