[Dovecot] dovecot tring to load sql modules
Dovecot is issuing:
Aug 12 17:09:27 athlon1 dovecot: Dovecot v1.0.rc6 starting up Aug 12 17:09:27 athlon1 dovecot: Generating Diffie-Hellman parameters for the first time. This may take a while.. Aug 12 17:09:28 athlon1 dovecot: Auth process died too early - shutting down Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
That's because I installed the RPM from atrpms.net using "--nodeps".
The RPM requires the above SQL library module, among others (inc.
postgresql and sqlite). However:
- Why do I need ANY SQL library??? I want PAM to do the authorization.
- If I have to use SQL, I want Dovecot to use PostgreSQL (which I have installed and am using in another application).
I hope the above is a dumb question, because that means the fix is easy. No, I'd rather not build my own; that's why I picked an RPM.
Running Fedora Core 1.
-- Dean
Oops, here's my dovecot.conf:
protocol imap { # imap_client_workarounds = tb-extra-mailbox-sep }
protocol pop3 { # pop3_uidl_format = %08Xu%08Xv }
auth default { mechanisms = plain passdb pam { } userdb passwd { } user = root }
Dean Gibson (Mail Administrator) wrote:
Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
That's because I installed the RPM from atrpms.net using "--nodeps". The RPM requires the above SQL library module, among others (inc. postgresql and sqlite). However:
- Why do I need ANY SQL library??? I want PAM to do the authorization.
Because the atrpm's version is apparently compiled with MySQL support. Rebuild without it or install the MySQL client libraries (alternatively, you might want to try *cough* another distribution *cough* :) ).
I hope the above is a dumb question, because that means the fix is easy. No, I'd rather not build my own; that's why I picked an RPM.
Find a RPM that is compiled without MySQL support.
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
On Sun, Aug 13, 2006 at 11:10:50AM +0200, Jan Kundrát wrote:
Dean Gibson (Mail Administrator) wrote:
Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
That's because I installed the RPM from atrpms.net using "--nodeps". The RPM requires the above SQL library module, among others (inc. postgresql and sqlite). However:
- Why do I need ANY SQL library??? I want PAM to do the authorization.
So, where is the problem? Just don't use the mysql support. You won't dump exim/sendmail/postfix because they have ldap support you don't use, do you? The same is true for this package. It has a set of built in features and you just activate them or not.
Otherwise if dovecot has say 10 features to turn on or off you would end with 2^10 = 1024 different binary rpms. ...
Because the atrpm's version is apparently compiled with MySQL support. Rebuild without it or install the MySQL client libraries (alternatively, you might want to try *cough* another distribution *cough* :) ).
There is no other distribution. :)
I hope the above is a dumb question, because that means the fix is easy. No, I'd rather not build my own; that's why I picked an RPM.
Find a RPM that is compiled without MySQL support.
Why?
Axel.Thimm at ATrpms.net
Axel Thimm wrote:
So, where is the problem? Just don't use the mysql support. You won't dump exim/sendmail/postfix because they have ldap support you don't use, do you?
I would probably compile them without this feature :)
The same is true for this package. It has a set of built in features and you just activate them or not.
Otherwise if dovecot has say 10 features to turn on or off you would end with 2^10 = 1024 different binary rpms. ...
Yup, that's a design feature/limitation of binary packages.
I hope the above is a dumb question, because that means the fix is easy. No, I'd rather not build my own; that's why I picked an RPM. Find a RPM that is compiled without MySQL support.
Why?
Because original poster said he doesn't want to install MySQL libraries.
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
On Sun, Aug 13, 2006 at 11:59:20AM +0200, Jan Kundrát wrote:
Axel Thimm wrote:
So, where is the problem? Just don't use the mysql support. You won't dump exim/sendmail/postfix because they have ldap support you don't use, do you?
I would probably compile them without this feature :)
Yes, I know, a gentoo non-smoker would build a car from scratch to avoid having an ashtray inside. I'm a non-smoker, too, but then my wife turned out ot be one, so I'm glad there was an ashtray in the car and I hadn't had to rebuild a new car. ;)
Axel.Thimm at ATrpms.net
Axel Thimm wrote:
Yes, I know, a gentoo non-smoker would build a car from scratch to avoid having an ashtray inside. I'm a non-smoker, too, but then my wife turned out ot be one, so I'm glad there was an ashtray in the car and I hadn't had to rebuild a new car. ;)
The Gentoo non-smoker wouldn't build his own car, he would just call the manufacturer and ask him not to assemble the ashtray but put a tray instead. He would get the car after a longer delay but the price would be the same :-P.
(Last reply from me on this thread, just to point a basic misunderstanding. No more noise will follow, unless I get extremely angry :) )
Cheers, -jkt
-- cd /local/pub && more beer > /dev/mouth
On August 13, 2006 11:44:41 AM +0200 Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Sun, Aug 13, 2006 at 11:10:50AM +0200, Jan Kundrát wrote:
Dean Gibson (Mail Administrator) wrote:
Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
That's because I installed the RPM from atrpms.net using "--nodeps". The RPM requires the above SQL library module, among others (inc. postgresql and sqlite). However:
- Why do I need ANY SQL library??? I want PAM to do the authorization.
So, where is the problem? Just don't use the mysql support. You won't dump exim/sendmail/postfix because they have ldap support you don't use, do you? The same is true for this package. It has a set of built in features and you just activate them or not.
I agree with both sides!
Packaging deps are limited by source code modularity. E.g. if dovecot did authorization via plugins, there could be a dovecot-auth-sql rpm which would allow building against mysql but avoiding the runtime dependency where not needed. Where such modularity does not exist, the builder needs to account for either the most common use or the broadest use, at the discretion of the packager or perhaps decided by policy. So I'd say the rpm is appropriately packaged given dovecot constraints. BTW, postfix LDAP support is modular (via a commonly available patch), so it can be built for LDAP but doesn't require it at runtime.
At the same time, I agree with the complaint about not pulling in deps that you don't want. It seems rather thick headed to say "just add mysql, postgresql and sqlite, I say it's ok therefore what's the problem". A better response would be, "packaging limitations require building against mysql et al. to support a larger userbase, if that doesn't suit you, build your own rpm, it's quite easy".
-frank
On Sun, Aug 13, 2006 at 12:42:19PM -0700, Frank Cusack wrote:
On August 13, 2006 11:44:41 AM +0200 Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Sun, Aug 13, 2006 at 11:10:50AM +0200, Jan Kundrát wrote:
Dean Gibson (Mail Administrator) wrote:
Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
That's because I installed the RPM from atrpms.net using "--nodeps". The RPM requires the above SQL library module, among others (inc. postgresql and sqlite). However:
- Why do I need ANY SQL library??? I want PAM to do the authorization.
So, where is the problem? Just don't use the mysql support. You won't dump exim/sendmail/postfix because they have ldap support you don't use, do you? The same is true for this package. It has a set of built in features and you just activate them or not.
I agree with both sides!
No, you don't :)
Packaging deps are limited by source code modularity. E.g. if dovecot did authorization via plugins, there could be a dovecot-auth-sql rpm which would allow building against mysql but avoiding the runtime dependency where not needed. Where such modularity does not exist, the builder needs to account for either the most common use or the broadest use, at the discretion of the packager or perhaps decided by policy. So I'd say the rpm is appropriately packaged given dovecot constraints. BTW, postfix LDAP support is modular (via a commonly available patch), so it can be built for LDAP but doesn't require it at runtime.
At the same time, I agree with the complaint about not pulling in deps that you don't want. It seems rather thick headed to say "just add mysql, postgresql and sqlite, I say it's ok therefore what's the problem".
This is twisting my words, I explained why the matter is as it is, I didn't relay anyone on blind trust.
A better response would be, "packaging limitations require building against mysql et al. to support a larger userbase, if that doesn't suit you, build your own rpm, it's quite easy".
No, it's not packaging limitations, it's how dynamic linking works, so if you like it's limitations in Linux/glibc. And we can't possibly have all code in the world do conditionalized dlopening expecting to possibly fail due to absent libs.
In the few cases where it makes sense the default dynamic linking procedure is put out of place and done manually as you suggest. This is mostly done when the additional functionality is built separately from the main project, which is not the case here, or when there should be no hard dependency between parts for various reasons. Manually dlopening libs breaks a lot of other technology like prelinking so it's usage is really scarce.
If you want a perfectly tailored system you can't use prebuilt binaries, but need to build it yourself using configure/make/make install or a distribution like gentoo. But you lose the testing coverage as anyone has his own special version built with his own special parameters and exhibits his own special bugs.
Enough said, we're talking about an issue that is not broken. ... :)
Axel.Thimm at ATrpms.net
On 13.8.2006, at 23.15, Axel Thimm wrote:
No, it's not packaging limitations, it's how dynamic linking works, so if you like it's limitations in Linux/glibc. And we can't possibly have all code in the world do conditionalized dlopening expecting to possibly fail due to absent libs.
In the few cases where it makes sense the default dynamic linking procedure is put out of place and done manually as you suggest. This is mostly done when the additional functionality is built separately from the main project, which is not the case here, or when there should be no hard dependency between parts for various reasons.
Dovecot does support dynamically loading different SQL drivers as
plugins, and I don't really see much reason not to build the binary
packages that way. For some reason no-one has done that though. IIRC
Debian's reason was that they didn't want to bloat their package
count more than necessary.
http://wiki.dovecot.org/CompilingSource
Manually dlopening libs breaks a lot of other technology like prelinking so it's usage is really scarce.
In this case I don't think prelinking is all that useful. Dovecot's
not usually running in a desktop computer so boot up time isn't that
important. Dovecot-auth also is a long running process so the linking
has to be done only at startup.
imap-login and pop3-login would benefit the most from being
prelinked. Is this being done by anyone? :) I'm not actually sure how
it's even done, could/should I do it by default?
On Mon, Aug 14, 2006 at 01:05:54AM +0300, Timo Sirainen wrote:
imap-login and pop3-login would benefit the most from being
prelinked. Is this being done by anyone? :) I'm not actually sure how
it's even done, could/should I do it by default?
In FC it's done for quite some time, I think starting with FC1, e.g. since 2003, by now it should be an active mechanism on most Linux distributions.
As an upstream author or a packager you don't have to do anything special - it's done by a nightly script for all libs, there are no extra steps needed per package/library. It's also a global operation since it requires a computation of non-overlapping (random) load addresses of all installed libraries.
Axel.Thimm at ATrpms.net
On August 13, 2006 10:15:30 PM +0200 Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Sun, Aug 13, 2006 at 12:42:19PM -0700, Frank Cusack wrote:
On August 13, 2006 11:44:41 AM +0200 Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Sun, Aug 13, 2006 at 11:10:50AM +0200, Jan Kundrát wrote:
Dean Gibson (Mail Administrator) wrote:
Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
That's because I installed the RPM from atrpms.net using "--nodeps". The RPM requires the above SQL library module, among others (inc. postgresql and sqlite). However:
- Why do I need ANY SQL library??? I want PAM to do the authorization.
So, where is the problem? Just don't use the mysql support. You won't dump exim/sendmail/postfix because they have ldap support you don't use, do you? The same is true for this package. It has a set of built in features and you just activate them or not.
I agree with both sides!
No, you don't :)
Yes I do.
- packaging is limited, you can't satisfy everyone if source code isn't modular enough
- you shouldn't be required to pull in deps from limited packaging capabilities
Packaging deps are limited by source code modularity. E.g. if dovecot did authorization via plugins, there could be a dovecot-auth-sql rpm which would allow building against mysql but avoiding the runtime dependency where not needed. Where such modularity does not exist, the builder needs to account for either the most common use or the broadest use, at the discretion of the packager or perhaps decided by policy. So I'd say the rpm is appropriately packaged given dovecot constraints. BTW, postfix LDAP support is modular (via a commonly available patch), so it can be built for LDAP but doesn't require it at runtime.
At the same time, I agree with the complaint about not pulling in deps that you don't want. It seems rather thick headed to say "just add mysql, postgresql and sqlite, I say it's ok therefore what's the problem".
This is twisting my words, I explained why the matter is as it is, I didn't relay anyone on blind trust.
No, you didn't just explain why it is, you berated the OP for not installing the dependencies.
A better response would be, "packaging limitations require building against mysql et al. to support a larger userbase, if that doesn't suit you, build your own rpm, it's quite easy".
No, it's not packaging limitations,
Of course it is. What if you could package multiple variants together in one package, selectable at install time?
it's how dynamic linking works, so if you like it's limitations in Linux/glibc. And we can't possibly have all code in the world do conditionalized dlopening expecting to possibly fail due to absent libs.
In the few cases where it makes sense the default dynamic linking
Of which LDAP, SQL, etc. seems one of those cases to me.
procedure is put out of place and done manually as you suggest. This is mostly done when the additional functionality is built separately from the main project, which is not the case here, or when there should be no hard dependency between parts for various reasons.
And one of those reasons, quite valid, is for system dependency reasons.
Manually dlopening libs breaks a lot of other technology like prelinking so it's usage is really scarce.
prelinking seems marginal to me, and in addition it's only done on Linux, not the other platforms that dovecot supports. But I accept that folks may consider prelinking useful.
Another alternative is to create stub libraries for LDAP et al. It would even be neat to have some flag that tells the runtime linker to pretend those libraries are there but return failure from all function calls, however since you can't know the semantics of any library that seems like asking too much.
-frank
On Mon, Aug 14, 2006 at 09:58:42AM -0700, Frank Cusack wrote:
I agree with both sides!
No, you don't :)
Yes I do.
You don't agree with me, do you? If you do, then you agree on the above, too, so you don't agree, but still you say you do, but then if you do, <repeat until you get dizzy>
Yes, it's a paradoxon and you're caught right in the middle of it :)
- packaging is limited, you can't satisfy everyone if source code isn't modular enough
- you shouldn't be required to pull in deps from limited packaging capabilities
packaging != linking
It seems rather thick headed to say "just add mysql, postgresql and sqlite, I say it's ok therefore what's the problem".
This is twisting my words, I explained why the matter is as it is, I didn't relay anyone on blind trust.
No, you didn't just explain why it is, you berated the OP for not installing the dependencies.
I didn't write a book on it, but I did explain that fulfilling everyone's request on modularity results in infinitely many different builds.
A better response would be, "packaging limitations require building against mysql et al. to support a larger userbase, if that doesn't suit you, build your own rpm, it's quite easy".
No, it's not packaging limitations,
Of course it is. What if you could package multiple variants together in one package, selectable at install time?
Please don't confuse packaging with linking. packaging is just putting the pieces together. The OP screwed up his system because the linking dependencies were ripped apart (which were mirrored into package dependencies). The same thing would had happened if he had built himself into /usr/local and later decided to remove mysql libs.
Same "bug", no packaging involved => unrelated to "packaging limitations"
prelinking seems marginal to me, and in addition it's only done on Linux, not the other platforms that dovecot supports. But I accept that folks may consider prelinking useful.
Right, there are Unices out there that also don't known what dynamic linking is and you need to go static. Is that really an argument in your favour? :)
Another alternative is to create stub libraries for LDAP et al. It would even be neat to have some flag that tells the runtime linker to pretend those libraries are there but return failure from all function calls, however since you can't know the semantics of any library that seems like asking too much.
Igit. BTW what exactly are you trying to fix? And why are we wasting bandwidth? I need to write down on the border 100 times "don't get involved on non-issues".
Axel.Thimm at ATrpms.net
On August 15, 2006 3:12:56 AM +0200 Axel Thimm Axel.Thimm@ATrpms.net wrote:
On Mon, Aug 14, 2006 at 09:58:42AM -0700, Frank Cusack wrote:
- packaging is limited, you can't satisfy everyone if source code isn't modular enough
- you shouldn't be required to pull in deps from limited packaging capabilities
packaging != linking
Right, and this is not a linker/linking limitation.
-frank
On Sun, 13 Aug 2006, Axel Thimm wrote:
On Sun, Aug 13, 2006 at 11:10:50AM +0200, Jan Kundrát wrote:
Dean Gibson (Mail Administrator) wrote:
Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory
- Why do I need ANY SQL library??? I want PAM to do the authorization.
So, where is the problem? Just don't use the mysql support. You won't
[...]
Otherwise if dovecot has say 10 features to turn on or off you would end with 2^10 = 1024 different binary rpms. ...
It does not have to be this way... Auth module could use plug-ins for each kind of authorization - all independent from each other. Of course it needs more efforts than writing an universal authenticator, and it is up to Timo.
However, since mysql/ldap/other libraries do not require too much space and actually one would need them because of other hard-linked software (exim, postfix, etc.) - I think there is no point in putting so much effort just for creating another plug-in system...
Greetz,
Jacek Osiecki joshua@ceti.pl GG:3828944 Poland
On Sat, Aug 12, 2006 at 06:36:38PM -0700, Dean Gibson (Mail Administrator) wrote:
Dovecot is issuing:
Aug 12 17:09:27 athlon1 dovecot: Dovecot v1.0.rc6 starting up Aug 12 17:09:27 athlon1 dovecot: Generating Diffie-Hellman parameters for the first time. This may take a while.. Aug 12 17:09:28 athlon1 dovecot: Auth process died too early - shutting down Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
That's because I installed the RPM from atrpms.net using "--nodeps".
Never, ever, really never rape rpm/dpkg/etc by cutting off dependencies. These dependencies are there for a reason, for example because the binary was built against mysql libs. You can't just cut them off (unless they were dlopened like some plugins do)
The RPM requires the above SQL library module, among others (inc. postgresql and sqlite). However:
- Why do I need ANY SQL library??? I want PAM to do the authorization.
That's what you want, what about your colleague next door? What about the LDAP admin next building? What about me doing sasl?
We all have different ways of using dovecot or any other larger software piece. You don't have to use mysql. But if the package has been built with mysql support you need to at least leave the libs on the system ...
- If I have to use SQL, I want Dovecot to use PostgreSQL (which I have installed and am using in another application).
It's just a matter of configuration. Killing the libs is not an option. Leave all required libs in and just use what you want to use.
I hope the above is a dumb question, because that means the fix is easy. No, I'd rather not build my own; that's why I picked an RPM.
The fix is to _never_ use --nodeps in rpm and other package managers, and to simply add the mysql libs and ignore their presence.
Unless you are setting up an embedded system and are running out of space there is no reason not to allow mysql libs to install.
Running Fedora Core 1.
-- Dean
-- Axel.Thimm at ATrpms.net
Hello Dean,
Dean Gibson (Mail Administrator), 13.08.2006 (d.m.y):
Dovecot is issuing:
Aug 12 17:09:27 athlon1 dovecot: Dovecot v1.0.rc6 starting up Aug 12 17:09:27 athlon1 dovecot: Generating Diffie-Hellman parameters for the first time. This may take a while.. Aug 12 17:09:28 athlon1 dovecot: Auth process died too early - shutting down Aug 12 17:09:28 athlon1 dovecot: auth(default): dovecot-auth: error while loading shared libraries: libmysqlclient.so.10: cannot open shared object file: No such file or directory Aug 12 17:09:28 athlon1 dovecot: child 28705 (auth) returned error 127
That's because I installed the RPM from atrpms.net using "--nodeps".
Hm.
The RPM requires the above SQL library module, among others (inc. postgresql and sqlite). However:
So why don't you install these dependencies?
- Why do I need ANY SQL library??? I want PAM to do the authorization.
Because your dovecot has been built with mysql support and so has been linked against the corresponding libraries.
Regards, Christian Schmidt
-- Der Versuch, den Himmel auf Erden zu produziern, produzierte stets die Hölle. -- Karl Popper
participants (7)
-
Axel Thimm
-
Christian Schmidt
-
Dean Gibson (Mail Administrator)
-
Frank Cusack
-
Jacek Osiecki
-
Jan Kundrát
-
Timo Sirainen