LDAP Tool Box

Hi Nick,

you just have to get Source RPMs from the download area, and use them to rebuild RPMs. All sources are in the .src.rpm

Thanks Clément,

I understand this process builds RPMs for the associated releases (available up to 2.4.28).

But how can we create an "LTB-compatible" src.rpm for the current (development) OpenLDAP source code (later than 2.4.28)?

Thanks again,
Nick

From the source RPM, update the .spec to change OpenLDAP version. And put the new version in SOURCES/.

Thanks Clément,

I see that installing (rpm -ivh) the .src.rpm creates the tree (everything owned by root):

/usr/src/redhat
|-- BUILD
|-- RPMS
|   |-- noarch
|   `-- x86_64
|-- SOURCES
|   |-- DB_CONFIG
|   |-- ltb-project-openldap-initscript-1.4.tar.gz
|   |-- ltb-project-openldap-ppolicy-check-password-1.1.tar.gz
|   |-- openldap-2.4.28.tgz
|   |-- openldap.logrotate
|   `-- openldap.sh
|-- SPECS
|   `-- openldap-ltb.spec
`-- SRPMS

Here is the process:

# rpm -ivh openldap-ltb-2.4.28-2.el5.src.rpm 
   1:openldap-ltb           warning: user clement does not exist - using root
warning: group clement does not exist - using root
warning: user clement does not exist - using root
warning: group clement does not exist - using root
warning: user clement does not exist - using root
warning: group clement does not exist - using root
warning: user clement does not exist - using root
warning: group clement does not exist - using root
########################################### [100%]
warning: user clement does not exist - using root
warning: group clement does not exist - using root
warning: user clement does not exist - using root
warning: group clement does not exist - using root
warning: user clement does not exist - using root
warning: group clement does not exist - using root

Questions (sorry for my ignorance):

1. Do I need to d/load BDB separately? If so, where do I place it?
2. Do I need to create RPMs as a non-root user? If so, I will chown the tree and su to the other user and then start building?
3. Which command do we issue to build (after changing the version in .spec file and replacing with the new source tgz)?
4. Building only creates new RPMs or also installs them? I would like to install them manually.

Thanks for your help,
Nick

Nick Milas wrote:

1. Do I need to d/load BDB separately? If so, where do I place it?

Yes, you need LTB BDB RPM to build LTB OpenLDAP RPM (see BuildRequires)

2. Do I need to create RPMs as a non-root user? If so, I will chown the tree and su to the other user and then start building?

No, but this is recommended.

3. Which command do we issue to build (after changing the version in .spec file and replacing with the new source tgz)?

See http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Creating_RPMs_from_the_spec_file

4. Building only creates new RPMs or also installs them? I would like to install them manually.

Build just build :)

Thank you for your valuable help.

Some more questions (we are getting closer to the end now!):

1. Can I move the whole /usr/src/redhat tree elsewhere (e.g. in /home/userx/src/redhat) and build in there? Do I need to change anything in the spec files? (The tree now includes BDB, per your instructions.)
2. I guess the building process also directly creates an openldap-ltb-debuginfo RPM (plus overlays and check-password RPMs)?

Thanks,
Nick

Nick Milas wrote:

Thank you for your valuable help.

Some more questions (we are getting closer to the end now!):

1. Can I move the whole /usr/src/redhat tree elsewhere (e.g. in /home/userx/src/redhat) and build in there? Do I need to change anything in the spec files? (The tree now includes BDB, per your instructions.)

No, you need to set your buildroot in your rpmmacro file. Please read some doc on how to use rpmbuild.

2. I guess the building process also directly creates an openldap-ltb-debuginfo RPM (plus overlays and check-password RPMs)?

See #117. You need redhat-rpm-config package to do this.

OK, I've managed to build new RPMs! Thanks for the help.

Now, I'm running on a test box without problems, and I'm thinking of putting this build on production for real-life testing.

BUT, would it be easy to downgrade in case of any unexpected problem(s), without having to completely uninstall and re-install?

I can upgrade easily with (as you can see, I named this build 2.4.29b2):

# rpm -Uvh openldap-ltb-2.4.29b2-2.x86_64.rpm \
openldap-ltb-contrib-overlays-2.4.29b2-2.x86_64.rpm \
openldap-ltb-debuginfo-2.4.29b2-2.x86_64.rpm 

over the previous LTB version (which I did on the test box), but could I somehow easily return to earlier LTB RPMs? How?

Thanks,
Nick

OK, I got it. I see that, for example:

rpm -Uvh --oldpackage openldap-ltb-2.4.28-2.el5.x86_64.rpm \
openldap-ltb-contrib-overlays-2.4.28-2.el5.x86_64.rpm \
openldap-ltb-debuginfo-2.4.28-2.el5.x86_64.rpm

...works fine!

Regards,
Nick

You can also use:

yum downgrade openldap-ltb

but this requires to have RPMs in a yum repository

Anyway, I close this issue.

Please allow me to re-open this issue, to ask something.

I've copied the RPMs (which I have built) on another box and tried to install.

After that, the following happened. As you see, there are some things (openldap-servers, openldap-servers-overlays) remaining from a much older installation on the same box, which I had not cleaned up.

It looks strange that there were some conflicts, since the new RPMs should not affect anything in the default /etc/openldap/ directory.

As you see, I removed the package for which I got yum complaints, and installation proceeded successfully.

Yet, there were some actions performed on some files in directory: /etc/openldap/schema/ which I wouldn't expect, and I thought you might want to check.

Can you please inform me if I did something wrong or I missed something during the build process, or this has to do with something on your (LTB Project) part?

Thank you.

[root@ldap 2.4.29b2]# rpm -Uvh openldap-ltb-2.4.29b2-2.x86_64.rpm openldap-ltb-debuginfo-2.4.29b2-2.x86_64.rpm
error: Failed dependencies:
        openldap-servers = 2.3.43-12.el5_7.10 is needed by (installed) openldap-servers-overlays-2.3.43-12.el5_7.10.x86_64
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# yum erase openldap-servers-overlays
Loaded plugins: downloadonly, fastestmirror, priorities
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package openldap-servers-overlays.x86_64 0:2.3.43-12.el5_7.10 set to be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================================================================================================
 Package                                         Arch                         Version                                     Repository                       Size
================================================================================================================================================================
Removing:
 openldap-servers-overlays                       x86_64                       2.3.43-12.el5_7.10                          installed                       358 k

Transaction Summary
================================================================================================================================================================
Remove        1 Package(s)
Reinstall     0 Package(s)
Downgrade     0 Package(s)

Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing        : openldap-servers-overlays                                                                                                                1/1 

Removed:
  openldap-servers-overlays.x86_64 0:2.3.43-12.el5_7.10                                                                                                         

Complete!
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# rpm -Uvh openldap-ltb-2.4.29b2-2.x86_64.rpm openldap-ltb-debuginfo-2.4.29b2-2.x86_64.rpm
Preparing...                ########################################### [100%]
   1:openldap-ltb           warning: /etc/default/slapd created as /etc/default/slapd.rpmnew
warning: /etc/logrotate.d/openldap created as /etc/logrotate.d/openldap.rpmnew
########################################### [ 50%]
   2:openldap-ltb-debuginfo ########################################### [100%]
warning: /etc/openldap/schema/misc.schema saved as /etc/openldap/schema/misc.schema.rpmsave
warning: /etc/openldap/schema/cosine.schema saved as /etc/openldap/schema/cosine.schema.rpmsave
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# service slapd start
slapd: [INFO] Using /etc/default/slapd for configuration
slapd: [INFO] Launching OpenLDAP configuration test...
slapd: [OK] OpenLDAP configuration test successful
slapd: [INFO] No db_recover done
slapd: [INFO] Launching OpenLDAP...
slapd: [OK] File descriptor limit set to 1024
slapd: [OK] OpenLDAP started
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# service slapd status
slapd: [INFO] Using /etc/default/slapd for configuration
slapd: [INFO] LDAP Tool Box OpenLDAP init script version 1.4
slapd: [INFO] Process OpenLDAP is running
slapd: [INFO] Listening to services ldap://*:389 ldaps://*:636
slapd: [INFO] Detected suffix: dc=noa,dc=gr
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# 
[root@ldap 2.4.29b2]# tail -14 /var/log/openldap.log
Feb 11 21:30:43 ldap slapd[1022]: [INFO] Using /etc/default/slapd for configuration
Feb 11 21:30:43 ldap slapd[1024]: [INFO] Launching OpenLDAP configuration test...
Feb 11 21:30:43 ldap slapd[1047]: [OK] OpenLDAP configuration test successful
Feb 11 21:30:43 ldap slapd[1057]: [INFO] No db_recover done
Feb 11 21:30:43 ldap slapd[1058]: [INFO] Launching OpenLDAP...
Feb 11 21:30:43 ldap slapd[1059]: [OK] File descriptor limit set to 1024
Feb 11 21:30:43 ldap slapd[1060]: @(#) $OpenLDAP: slapd 2.4.29 (Feb  6 2012 23:14:45) $         swbuilder@vdev.noa.gr:/home/swbuilder/rpmbuild/BUILD/openldap-2.4.29b2/servers/slapd 
Feb 11 21:30:43 ldap slapd[1061]: slapd starting 
Feb 11 21:30:44 ldap slapd[1065]: [OK] OpenLDAP started
Feb 11 21:30:59 ldap slapd[1087]: [INFO] Using /etc/default/slapd for configuration
Feb 11 21:30:59 ldap slapd[1089]: [INFO] LDAP Tool Box OpenLDAP init script version 1.4
Feb 11 21:30:59 ldap slapd[1092]: [INFO] Process OpenLDAP is running
Feb 11 21:30:59 ldap slapd[1093]: [INFO] Listening to services ldap://*:389 ldaps://*:636
Feb 11 21:30:59 ldap slapd[1153]: [INFO] Detected suffix: dc=noa,dc=gr

Hi Nick,

all seems normal. LTB RPMs obsoletes openldap-servers, so the yum install will remove it (and so you need to remove the -overlays too)

The other messages from /etc/openldap are just saying that old configuration files are saved, this is also normal.

So, for me, this issue can be closed, ok?

But, may I ask why the LTB RPM installation writes in /etc/openldap/schema/ ?

Isn't it enough to write in /usr/local/openldap/etc/openldap/schema/ ?

I am just trying to understand.

Thanks,
Nick

Nick Milas wrote:

But, may I ask why the LTB RPM installation writes in /etc/openldap/schema/ ?

Isn't it enough to write in /usr/local/openldap/etc/openldap/schema/ ?

LTB RPM do not write in /etc/openldap/schema/, the messages you see are from the RPM uninstallation of openldap-servers.

OK, I see.

openldap-servers-2.3.43 RPM was implicitly removed (erased) during LTB RPM installation.

It is strange to me that there was no explicit report of that package removal during installation.

By the way, is it necessary to remove this package? OK, it becomes obsolete, but what if there is running LDAP installation (using that package) and we want to migrate manually, only after setting up LTB Openldap completely. Why force this uninstallation?

For example, I have on one test system Buchan's ldap2.4 RPMs, Symas Silver RPMs and LTB RPMs installed and configured at the same time, and I can start at any time any of the three installations as a completely independent LDAP Server. Would it cause problems to have the CentOS standard openldap-servers RPMs installed at the same time as well (and be able to run this LDAP Server independently, as required)?

Thanks,
Nick

Nick Milas wrote:

For example, I have on one test system Buchan's ldap2.4 RPMs, Symas Silver RPMs and LTB RPMs installed and configured at the same time, and I can start at any time any of the three installations as a completely independent LDAP Server. Would it cause problems to have the CentOS standard openldap-servers RPMs installed at the same time as well (and be able to run this LDAP Server independently, as required)?

I think the problem is with the init script installed in /etc/init.d/slapd, which replace the one from openldap-servers

No, the init script of the standard package is called ldap.

Ok, could you test to remove the Obsoletes in the .spec, and see if there are no conflicts between LTB RPMs and the openldap-servers RPMs ? In this case, it can be interessant to allow to have both on the system.

OK, I created 64bit RPMs using current OPENLDAP_REL_ENG_2_4 from git (openldap-OPENLDAP_REL_ENG_2_4-5432ce3.tar.gz) which I renamed as openldap-2.4.30b1.tgz.

I commented-out the Obsoletes directive.

Then I installed on a test server with openldap-servers, openldap-servers-overlays and openldap-clients (the standard versions 2.3.43 on CentOS 5.7):

# rpm -ivh berkeleydb-ltb-4.6.21.NC-4.patch4.x86_64.rpm openldap-ltb-2.4.30b1-2.x86_64.rpm openldap-ltb-debuginfo-2.4.30b1-2.x86_64.rpm 
warning: berkeleydb-ltb-4.6.21.NC-4.patch4.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 6d45bfc5
Preparing...                ########################################### [100%]
   1:berkeleydb-ltb         ########################################### [ 33%]
   2:openldap-ltb           ########################################### [ 67%]
groupadd: group ldap exists
useradd: user ldap exists
   3:openldap-ltb-debuginfo ########################################### [100%]

I tried to start the default ldap server:

# service ldap start
Checking configuration files for slapd:  bdb_db_open: Warning - No DB_CONFIG file found in directory /var/lib/ldap: (2)
Expect poor performance for suffix dc=my-domain,dc=com.
config file testing succeeded
                                                           [  OK  ]
Starting slapd:                                            [  OK  ]
# service ldap stop
Stopping slapd:                                            [  OK  ]

Then I tried to run the default slapd server:

# service slapd start
slapd: [INFO] Using /etc/default/slapd for configuration
slapd: [INFO] Launching OpenLDAP configuration test...
slapd: [OK] OpenLDAP configuration test successful
slapd: [INFO] No db_recover done
slapd: [INFO] Launching OpenLDAP...
slapd: [OK] File descriptor limit set to 1024
slapd: [OK] OpenLDAP started
# service ldap stop
Stopping slapd:                                            [  OK  ]

Everything seems OK.

Ok, what I see is that we use the ldap user and group, which is the same as the openldap-servers. If we remove LTB RPM, ldap user and group will be deleted from the system, so it can damage the current openldap-servers installation.

We also change the default path to have ldap clients directly accessible, which may conflicts with current ldap client (package openldap-clients).

What do you think?

I guess that may be why the default Symas installation is under the root user/group and not ldap:ldap.

Yet, Buchan's RPMs use ldap:ldap. I don't know how they treat user/group ldap when uninstalling.

In all cases where I have installed an OpenLDAP package, I never uninstall it, so I have limited experience!

I would think that the approach which entails the least risk would be to leave user/group ldap when uninstalling LTB. Even if no other LDAP package which uses ldap user/group is left on a system, it would not really hurt to have an ldap user/group as a left over.

I don't know what other packages (e.g. Symas) do with the system ldap-clients path (I guess they change it too). If you want me to check, please let me know how to check it on CentOS! Where is the default path to the ldap clients specified?

The least invasive practice (not necessarily the best) would be to leave the default path intact, because I think the standard ldap-clients and openldap packages are never removed from a system, due to a large number of serious dependencies.

An addition:

Interestingly (as you noticed from my earlier post, in which I did it by mistake), we start the slapd service using "service slapd start" and the service may stop not only with "service slapd stop" but also with "service ldap stop"!

I don't know if slapd could/should use some technique to avoid being affected by running (intentionally or not) "service ldap stop".

On the other hand, the opposite does not happen: if ldap service is running, the command "service slapd stop" cannot stop it.

Nick Milas wrote:

I would think that the approach which entails the least risk would be to leave user/group ldap when uninstalling LTB. Even if no other LDAP package which uses ldap user/group is left on a system, it would not really hurt to have an ldap user/group as a left over.

I agree with this.

I don't know what other packages (e.g. Symas) do with the system ldap-clients path (I guess they change it too). If you want me to check, please let me know how to check it on CentOS! Where is the default path to the ldap clients specified?

Show the PATH:

echo $PATH

Knwo which client is really used by default:

which ldapsearch

The least invasive practice (not necessarily the best) would be to leave the default path intact, because I think the standard ldap-clients and openldap packages are never removed from a system, due to a large number of serious dependencies.

For LDAP clients I do not agree, as new versions can provide interesting features (like LDIF line wrapping for ldapsearch for example)

Nick Milas wrote:

An addition:

Interestingly (as you noticed from my earlier post, in which I did it by mistake), we start the slapd service using "service slapd start" and the service may stop not only with "service slapd stop" but also with "service ldap stop"!

I don't know if slapd could/should use some technique to avoid being affected by running (intentionally or not) "service ldap stop".

On the other hand, the opposite does not happen: if ldap service is running, the command "service slapd stop" cannot stop it.

This is because the default ldap script kill all slapd processes. In our script, we only kill our slapd process.

I found that the Symas RPM does not change the default ldapsearch path, while Buchan's RPM also doesn't change it but I think it overwrites the system executables with the new ones.

In my opinion, your approach to change the default ldap-client with the LTB's is correct.

Nick

Great, I opened #401, and will now close this issue.