I'm trying to build a Kolab server for use at work and running into some problems. I'm hoping someone here has some expertise that they can offer to help me resolve some issues I'm having, especially if you've used Kolab or other software packages distributed with OpenPKG before.
The environment I'm working in is Debian, but the versions of Kolab in Debian (both etch/stable and lenny/testing) are older than I want to use, in order to have Kolab work well with the Horde webmail/calendaring applications. So the "source" distribution from Kolab is what I'm using. The way they package things is with a tool called OpenPKG, which essentially means that an application (kolab), and all supporting applications (cyrus, openldap, apache), and all supporting libraries (tons of the usual) are packaged in RPM files. Those RPM files are distributed with a script to setup a root folder (/kolab) and compile/install all those source RPMs into it. Everything lives in this neat little bubble with libraries all statically compiled into the binaries, never leaving the confines of /kolab. To say the least, I'm not a fan of this bubble approach. For all our servers, we have LDAP logins enabled for SSH logins, monitoring logins, etc. I don't expect that this new mail server should be any different, but if I enable LDAP logins on the system, many binaries segfault. Here's my explanation of what's happening. When you start a process, glibc is loaded as part of that process. glibc can also bring in other auxiliary libraries, as needed. In particular, any libraries used for NSS (libnss_ldap.so, for example) are loaded also to give the process it's identify. As a result of that, libldap_r.so is also loaded, because it's required to make use of libnss_ldap to make use of getting local user/group information from LDAP. When the process that is starting is a binary in the /kolab bubble, it has libldap_r.a compiled into it statically, albeit a slightly different version. This causes a duplication of all the library functions in the run-time process now. I've been trying to convince OpenPKG with a dummy package not to use the Kolab-distributed OpenLDAP sources, but to use the libraries that come with Debian to no avail. The dependencies spider out from there to things like sasl, gnutls, gcrypt, Has anyone tackled problems like this before? I'm about at my wit's end with this. -N _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
