[Dovecot] linking problems of dovecot 2.0.3
Hello, I'm currently packaging dovecot 2.0.3 under Mandriva Linux. It has been using LDFLAGS="-Wl,--as-needed -Wl,--no-undefined" for shared libraries for over two years[1]. And I've found there are lots of linking problems with dovecot 2.0.3. After some investigation, I've made small patch regarding dovecot 2.0.3, posted here: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/dovecot/branches/dovecot2/current/SOURCES/dovecot-2.0.3-linkage.patch Even after applying mentioned patch, it still produce following errors: make[3]: Entering directory `/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common' /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fstack-protector-all -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wstrict-aliasing=2 -export-dynamic -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -o libdovecot-login.la -rpath /usr/lib64/dovecot liblogin.la ../lib-dict/libdict.la ../lib-dovecot/libdovecot.la -lrt libtool: link: gcc -shared -Wl,--as-needed -Wl,--whole-archive ./.libs/liblogin.a ../lib-dict/.libs/libdict.a -Wl,--no-whole-archive -Wl,--as-needed -Wl,--no-undefined -Wl,-z -Wl,relro -Wl,-O1 -Wl,--build-id-Wl,-rpath -Wl,/tmp/dovecot/BUILD/dovecot-2.0.3/src/lib-dovecot/.libs -Wl,-rpath -Wl,/usr/lib64/dovecot -L/usr/lib64/ -lssl -lcrypto -ldl -lpthread ../lib-dovecot/.libs/libdovecot.so -lrt -Wl,-soname -Wl,libdovecot-login.so.0 -o .libs/libdovecot-login.so.0.0.0 ./.libs/liblogin.a(client-common.o): In function `get_var_expand_table': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common.c:372: undefined reference to `login_binary' ./.libs/liblogin.a(client-common.o): In function `client_create': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common.c:50: undefined reference to `client_vfuncs' ./.libs/liblogin.a(client-common-auth.o): In function `client_auth_parse_args': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common-auth.c:111: undefined reference to `login_binary' /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common-auth.c:99: undefined reference to `login_binary' ./.libs/liblogin.a(client-common-auth.o): In function `client_auth_begin': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/client-common-auth.c:491: undefined reference to `login_binary' ./.libs/liblogin.a(login-settings.o): In function `login_settings_read': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/login-settings.c:195: undefined reference to `login_binary' ./.libs/liblogin.a(main.o): In function `login_access_lookup_next': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:185: undefined reference to `login_binary' ./.libs/liblogin.a(main.o):/tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:338: more undefined references to `login_binary' follow ./.libs/liblogin.a(main.o): In function `main': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:358: undefined reference to `login_process_preinit' ./.libs/liblogin.a(main.o): In function `main_init': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:308: undefined reference to `clients_init' ./.libs/liblogin.a(main.o): In function `main_deinit': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/main.c:317: undefined reference to `clients_deinit' ./.libs/liblogin.a(sasl-server.o): In function `anvil_check_too_many_connections': /tmp/dovecot/BUILD/dovecot-2.0.3/src/login-common/sasl-server.c:187: undefined reference to `login_binary' collect2: ld returned 1 exit status Could somebody take a look? Thanks. [1]: http://wiki.mandriva.com/en/Underlinking
[Dovecot] dovecot-2.0.3 : Am I missing anything here ?
I'm just asking if there is anything else that needs to be added at all. I seem to have everything linked in from soup to nuts but I want to be sure that a basic or essential feature is not being overlooked for forgotten : [titan] elfdump -d .libs/auth | grep NEED [0] NEEDED 0x3084libdovecot.so.0 [1] NEEDED 0x3055libpam.so.1 [2] NEEDED 0x306alibpthread.so.1 [3] NEEDED 0x3094libkrb5.so.3 [4] NEEDED 0x30a1libk5crypto.so.3 [5] NEEDED 0x30b2libcom_err.so.3 [6] NEEDED 0x30c2libldap-2.4.so.2 [7] NEEDED 0x30d3libsasl2.so.2 [8] NEEDED 0x30e1libgssapi_krb5.so.2 [9] NEEDED 0x30f5libssl.so.0.9.8 [10] NEEDED 0x3105libcrypto.so.0.9.8 [11] NEEDED 0x3118liblber-2.4.so.2 [12] NEEDED 0x3129libresolv.so.2 [13] NEEDED 0x3138libgen.so.1 [14] NEEDED 0x3144libpq.so.5 [15] NEEDED 0x314flibsqlite3.so.0 [16] NEEDED 0x315flibz.so [17] NEEDED 0x3167libdl.so.1 [18] NEEDED 0x3172libnsl.so.1 [19] NEEDED 0x317elibsocket.so.1 [20] NEEDED 0x318dlibintl.so.8 [21] NEEDED 0x319alibiconv.so.2 [22] NEEDED 0x307alibc.so.1 [23] NEEDED 0x31a8librt.so.1 [24] NEEDED 0x31b3libmysqlclient.so.16 [35] VERNEED 0x8057770 [36] VERNEEDNUM 0x3 [titan] [titan] ldd .libs/auth libdovecot.so.0 => (file not found) libpam.so.1 => /usr/lib/libpam.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libkrb5.so.3 => /opt/csw/lib/libkrb5.so.3 libk5crypto.so.3 => /opt/csw/lib/libk5crypto.so.3 libcom_err.so.3 => /opt/csw/lib/libcom_err.so.3 libldap-2.4.so.2 => /opt/csw/lib/libldap-2.4.so.2 libsasl2.so.2 => /opt/csw/lib/libsasl2.so.2 libgssapi_krb5.so.2 => /opt/csw/lib/libgssapi_krb5.so.2 libssl.so.0.9.8 => /opt/csw/lib/libssl.so.0.9.8 libcrypto.so.0.9.8 =>/opt/csw/lib/libcrypto.so.0.9.8 liblber-2.4.so.2 => /opt/csw/lib/liblber-2.4.so.2 libresolv.so.2 =>/usr/lib/libresolv.so.2 libgen.so.1 => /usr/lib/libgen.so.1 libpq.so.5 =>/opt/csw/postgresql83/lib/i386/libpq.so.5 libsqlite3.so.0 => /opt/csw/lib/libsqlite3.so.0 libz.so => /opt/csw/lib/libz.so libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libintl.so.8 => /opt/csw/lib/libintl.so.8 libiconv.so.2 => /opt/csw/lib/libiconv.so.2 libc.so.1 => /usr/lib/libc.so.1 librt.so.1 =>/usr/lib/librt.so.1 libmysqlclient.so.16 => /opt/csw/mysql51/lib/i386/mysql/libmysqlclient.so.16 libcmd.so.1 => /usr/lib/libcmd.so.1 libkrb5support.so.0 => /opt/csw/lib/libkrb5support.so.0 libintl.so.1 => /usr/lib/libintl.so.1 libgcc_s.so.1 => /opt/csw/lib/libgcc_s.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libaio.so.1 => /usr/lib/libaio.so.1 libm.so.1 => /usr/lib/libm.so.1 libthread.so.1 =>/usr/lib/libthread.so.1 That looks to be a massive list. I'm always worried that some "feature" is being forgotten by me. Any thoughts from the gurus ? -- Dennis
Re: [Dovecot] v2.0.3 released
* Timo Sirainen : > On 18.9.2010, at 20.50, Arkadiusz Miskiewicz wrote: > > > On Friday 17 of September 2010, Timo Sirainen wrote: > >> http://dovecot.org/releases/2.0/dovecot-2.0.3.tar.gz > >> http://dovecot.org/releases/2.0/dovecot-2.0.3.tar.gz.sig > > > > If ssl it off then it still tries to open cert files - does this makes > > sense? > > Unfortunately I haven't figured out any reasonable way to prevent it. > > > ssl_cert = > > > > > ssl_key = > The add some special code just for these SSL settings, which feels annoyingly > ugly. >From a programmers view of point certainly, but it's something students and even myself run in all the time setting up Dovecot. p...@rick -- state of mind Digitale Kommunikation http://www.state-of-mind.de Franziskanerstraße 15 Telefon +49 89 3090 4664 81669 München Telefax +49 89 3090 4666 Amtsgericht MünchenPartnerschaftsregister PR 563
Re: [Dovecot] v2.0.3 released
On 18.9.2010, at 20.50, Arkadiusz Miskiewicz wrote: > On Friday 17 of September 2010, Timo Sirainen wrote: >> http://dovecot.org/releases/2.0/dovecot-2.0.3.tar.gz >> http://dovecot.org/releases/2.0/dovecot-2.0.3.tar.gz.sig > > If ssl it off then it still tries to open cert files - does this makes sense? Unfortunately I haven't figured out any reasonable way to prevent it. > ssl_cert = > > ssl_key =
Re: [Dovecot] v2.0.3 released
On Friday 17 of September 2010, Timo Sirainen wrote: > http://dovecot.org/releases/2.0/dovecot-2.0.3.tar.gz > http://dovecot.org/releases/2.0/dovecot-2.0.3.tar.gz.sig If ssl it off then it still tries to open cert files - does this makes sense? doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 12: ssl_cert: Can't open file /var/lib/openssl/certs/imap.pem: No such file or directory # doveconf -n |grep ssl ssl = no ssl_cert = http://ftp.pld-linux.org/
Re: [Dovecot] mbox vs maildir
On 18/09/2010 18:43, Jim Pazarena wrote: I've had clients 'request' nested folders, and it would seem that maildir is designed with that ability while with mbox it is difficult and.or impossible to implement (nested can be achieved; but not nested AND populated in each nest level). You can, under mbox, have mailboxes containing messages which are also the parents of other mailboxes, though it requires special configuration. Two approaches are described at http://wiki2.dovecot.org/MboxChildFolders My question is, is one format 'better' than the other? It would take a fair bit of time to convert my system to maildir and I would want to feel comfortable that this would be a true 'upgrade' in abilities, rather than simply a change to accommodate nested folders. Maildir and mbox both have advantages and disadvantages. If you are thinking about re-assessing your mail store strategy, you might also want to consider single-dbox and multi-dbox. http://wiki2.dovecot.org/MailboxFormat/dbox Bill
[Dovecot] Dovecot LDA, virtual users, multiple uids: No luck
Hi, I'm trying to get Dovecot's deliver to create and use mailboxen with one uid per user. Reading the wiki, I decided to go with the sudo attempt, but I'm stuck because deliver fails to create the intermediate directories. The auth.log has this on the matter: sudo: dovelda : TTY=unknown ; PWD=/var/spool/postfix ; USER=root ; COMMAND=/usr/lib/dovecot/deliver -f t...@bogus.oeko.net -d d...@example.com Using strace on 'deliver', I get this: # su - dovelda $ echo "blubber" |sudo strace /usr/lib/dovecot/deliver -f t...@bogus.oeko.net -d d...@example.com ... geteuid() = 0 getgid()= 0 setgid(2000)= 0 setgroups(1, [2000])= 0 setuid(2100)= 0 setuid(0) = -1 EPERM (Operation not permitted) getgid()= 2000 getegid() = 2000 setgid(0) = -1 EPERM (Operation not permitted) close(6)= 0 geteuid() = 2100 geteuid() = 2100 and subsequently, creating the directories fails. The values in the underlined lines above, 2100 and 2000, are from the database entry of the user I want to deliver the email to. My /etc/sudoers has this for dovelda: dovelda ALL=NOPASSWD:/usr/lib/dovecot/deliver dovelda ALL=NOPASSWD:/usr/bin/strace I'm using a Debian/Lenny system with amd64 and this package for Dovecot: # dpkg -l 'dovecot*' Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii dovecot-common 1:1.2.13-1~bpo secure mail server that supports mbox and ma ii dovecot-imapd 1:1.2.13-1~bpo secure IMAP server that supports mbox and ma Kind regards, --Toni++
Re: [Dovecot] moving 1.2.13 system to another hard drive
On 18/09/2010 18:06, Paul Scott wrote: Having said that, having mail delivered to mbox files under /var/mail, but other folders under Maildir might not be the best configuration: * to get Dovecot to be able to handle that setup means having two different mailbox formats which means a namespace configuration, * your INBOX is going to an mbox under /var/mail, which is fraught with potential locking problems (unless this has somehow magically been taken care of for you). You may be better off getting all mail delivered straight to Maildir, thereby making everything Maildir. That's what I thought was happening since it was happening on the previous setup. OTOH mutt sees the old INBOX but doesn't see the other folders anymore. I am not an expert on mutt but I believe mutt needs to be specifically configured to see mail under Maildir. This would then make your Dovecot configuration simpler, and also remove the potential locking problems of using mbox. I don't know how to do that. Everything was under Maildir in the previous system and I don't know why it doesn't seem to be now. To have mail under Maildir, you need to define a local policy that says that mail should be stored this way. By "define a local policy", I mean something like "sit down and decide to do it in a particular way". Configurations of various softwares (MTA, IMAP software etc.) should then be made to reflect that policy. For best practice, you should then run tests to make sure that your various softwares are behaving according to the policy you defined before. Any ideas for debugging this certainly simple problem for some of you. Please try to describe a specific symptom or specific symptoms you are experiencing. Dovecot doesn't seem to be putting mail in the Maildir INBOX. Which "putting mail" scenario are you thinking of? 1. Where a message is saved into a folder via IMAP 2. Where a message is delivered into a Dovecot-managed mailstore by the Dovecot LDA or Dovecot LMTP If you have not configured your MTA to use Dovecot as its LDA then Dovecot won't be responsible for mail delivery, and so mail won't be delivered according to the Dovecot configuration. The likely default would be for the MTA to deliver mail itself, in which case mail will be delivered according to the MTA's configuration. Now I see log messages which may make things much clearer. It may be about passwords which are the same on the new system as the old. Sep 18 09:55:31 bliss dovecot: imap-login: Disconnected (auth failed, 4 attempts): user=, method=PLAIN, rip=68.0.135.186, lip=192.168.1.102 Authentication doesn't seem to be working. This is almost certainly fixable. But I think you need to get a broad grasp of how you want mail to be stored on your system and how you can achieve that before getting into this fine detail. Please provide the output of "dovecot -n". p...@bliss:~$ sudo dovecot -n # 1.2.13: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-686 i686 Debian squeeze/sid log_timestamp: %Y-%m-%d %H:%M:%S ssl: no disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login mail_privileged_group: mail mail_location: maildir:~/Maildir mbox_write_locks: fcntl dotlock auth default: passdb: driver: pam userdb: driver: passwd It might also be an idea to say what MTA you are using. AFAIK: exim4 Good. You can configure Exim 4 to deliver mail to Maildir under ~/Maildir --- it is all documented in the Exim 4 docs. Alternatively you can configure Exim 4 to deliver mail using Dovecot. This is documented in the Dovecot wiki. Bill
[Dovecot] mbox vs maildir
I've had clients 'request' nested folders, and it would seem that maildir is designed with that ability while with mbox it is difficult and.or impossible to implement (nested can be achieved; but not nested AND populated in each nest level). My question is, is one format 'better' than the other? It would take a fair bit of time to convert my system to maildir and I would want to feel comfortable that this would be a true 'upgrade' in abilities, rather than simply a change to accommodate nested folders. Thanks,
Re: [Dovecot] moving 1.2.13 system to another hard drive
On Sat, Sep 18, 2010 at 04:52:31PM +0100, William Blunn wrote: > On 18/09/2010 01:15, Paul Scott wrote: > >I have just set up a new system on a new hard drive on the same > >computer. fetchmail is correctly putting mail in > >/var/mail/. > > Whilst I am no expert on fetchmail, as far as I know fetchmail does > not deliver mail itself but rather passes it on to an MTA. So I > think it may be your MTA that is delivering mail to mbox files in > /var/mail. Thanks for that reminder. > >I have copied my entire Maildir directory from the old hard drive. > >I have made what changes I understood to dovecot.conf. > > > >Dovecot was working on the other drive even though I'm not > >completely sure how I got it working before. > > How about looking at the old Dovecot configuration under /etc on the > old drive? I have done that several times. > Having said that, having mail delivered to mbox files under > /var/mail, but other folders under Maildir might not be the best > configuration: > > * to get Dovecot to be able to handle that setup means having two > different mailbox formats which means a namespace configuration, > > * your INBOX is going to an mbox under /var/mail, which is fraught > with potential locking problems (unless this has somehow magically > been taken care of for you). > > You may be better off getting all mail delivered straight to > Maildir, thereby making everything Maildir. That's what I thought was happening since it was happening on the previous setup. OTOH mutt sees the old INBOX but doesn't see the other folders anymore. > This would then make your Dovecot configuration simpler, and also > remove the potential locking problems of using mbox. I don't know how to do that. Everything was under Maildir in the previous system and I don't know why it doesn't seem to be now. > >Any ideas for debugging this certainly simple problem for some of you. > > Please try to describe a specific symptom or specific symptoms you > are experiencing. Dovecot doesn't seem to be putting mail in the Maildir INBOX. Now I see log messages which may make things much clearer. It may be about passwords which are the same on the new system as the old. Sep 18 09:55:31 bliss dovecot: imap-login: Disconnected (auth failed, 4 attempts): user=, method=PLAIN, rip=68.0.135.186, lip=192.168.1.102 > Please provide the output of "dovecot -n". p...@bliss:~$ sudo dovecot -n # 1.2.13: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-5-686 i686 Debian squeeze/sid log_timestamp: %Y-%m-%d %H:%M:%S ssl: no disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable: /usr/lib/dovecot/imap-login mail_privileged_group: mail mail_location: maildir:~/Maildir mbox_write_locks: fcntl dotlock auth default: passdb: driver: pam userdb: driver: passwd > It might also be an idea to say what MTA you are using. AFAIK: exim4 > For The Avoidance Of Doubt, I am not 'taking on your case', but > merely providing one step of suggestions. This was very helpful. I still not sure exactly the password problem is but that probably narrows it down for now. Please reply to the list (i.e. not to me). Certainly, Many thanks, Paul
Re: [Dovecot] moving 1.2.13 system to another hard drive
On 18/09/2010 01:15, Paul Scott wrote: I have just set up a new system on a new hard drive on the same computer. fetchmail is correctly putting mail in /var/mail/. Whilst I am no expert on fetchmail, as far as I know fetchmail does not deliver mail itself but rather passes it on to an MTA. So I think it may be your MTA that is delivering mail to mbox files in /var/mail. I have copied my entire Maildir directory from the old hard drive. I have made what changes I understood to dovecot.conf. Dovecot was working on the other drive even though I'm not completely sure how I got it working before. How about looking at the old Dovecot configuration under /etc on the old drive? Having said that, having mail delivered to mbox files under /var/mail, but other folders under Maildir might not be the best configuration: * to get Dovecot to be able to handle that setup means having two different mailbox formats which means a namespace configuration, * your INBOX is going to an mbox under /var/mail, which is fraught with potential locking problems (unless this has somehow magically been taken care of for you). You may be better off getting all mail delivered straight to Maildir, thereby making everything Maildir. This would then make your Dovecot configuration simpler, and also remove the potential locking problems of using mbox. Any ideas for debugging this certainly simple problem for some of you. Please try to describe a specific symptom or specific symptoms you are experiencing. Please provide the output of "dovecot -n". It might also be an idea to say what MTA you are using. For The Avoidance Of Doubt, I am not 'taking on your case', but merely providing one step of suggestions. Please reply to the list (i.e. not to me). Bill
Re: [Dovecot] moving 1.2.13 system to another hard drive
On 9/17/2010 8:15 PM, Paul Scott wrote: Dovecot was working on the other drive even though I'm not completely sure how I got it working before. So... you got it working before 'somehow', but you're not sure how, and then... Any ideas for debugging this certainly simple problem for some of you. you ask for help without even giving specifics on what exactly isn't working - like error messages, log snippets exhibiting errors, doveonc -n output showing your configs from both systems, etc? Interesting... you think we are a bunch of sages and seers in here? ;)
Re: [Dovecot] Maildir premission denied
On 9/17/2010 2:35 PM, Omer Ahmed wrote: Hi Sirs,I am using ubuntu OS, with dovecot and postfix, I can send emails receive email but not access them. I have the errorSep 17 21:21:31 myserver-name dovecot: POP3(virtualu...@mydomain.tld): stat(/var/mail/virtualu...@mydomain.tld) failed: Permission denied (euid=1001(upload) egid=1001(upload) missing +x permI don't know why it is using euid 1001, my var/mail folder uid:gid is 500:500and here are my settings:# 1.1.11: /etc/dovecot/dovecot.conf# OS: Linux 2.6.31-14-server x86_64 Ubuntu 9.10 ext3log_timestamp: %Y-%m-%d %H:%M:%Sprotocols: imap imaps pop3 pop3sdisable_plaintext_auth: nologin_dir: /var/run/dovecot/loginlogin_executable(default): /usr/lib/dovecot/imap-loginlogin_executable(imap): /usr/lib/dovecot/imap-loginlogin_executable(pop3): /usr/lib/dovecot/pop3-loginmail_privileged_group: mailmail_uid: 500mail_gid: 500mail_location: Maildir:/var/mail/%umail_executable(default): /usr/lib/dovecot/imapmail_executable(imap): /usr/lib/dovecot/imapmail_executable(pop3): /usr/lib/dovecot/pop3mail_plugin_dir(default): /usr/lib/dovecot/modules/imapmail_plugin_dir(imap): /usr/lib/dovecot/modules/imapmail_plugin_dir(pop3): /usr/lib/dovecot/modules/pop3auth default: passdb:driver: pam passdb: driver: sqlargs: /etc/dovecot/dovecot-sql.conf userdb:driver: passwd userdb:driver: sqlargs: /etc/dovecot/dovecot-sql.conf Waiting for ur life saving replies You would dramatically increase your chances for help if you would properly format your email. Sending everything on one never ending unwrapped line is NOT the way to do it.
Re: [Dovecot] v2.0.3 released
On 18.9.2010, at 3.00, Daniel L. Miller wrote: > SIS not ready for primetime yet? Well, no one's really been testing it much.. I'll include it in 2.0.4 anyway with warnings about potential unstability.
