MANAGESIEVE commands
Dear cyrus friends, Is there a list of possible MANAGESIEVE commands to be used with the sivtest program? sivtest -t PublicPrivate.key -a user -m PLAIN localhost possible commands: LISTSCRIPTS GETSCRIPT user.sieve LOGOUT However and for example: PUTSCRIPT user.sieve NO Did not specify legal script data length I don't know what the correct syntax is and, even worse, I don't know where to look it up? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Auto create folders
Dear Andrew and Cyrus-imap friends, On Fri, Jan 23, 2015 at 10:32:51AM -0800, Andrew Morgan wrote: On Fri, 23 Jan 2015, John Mok wrote: Hi, I have been using Cyrus IMAP 2.4.17 on Debian 7 with Kerberos / GSSAPI authentication. I would like to auto-create one or more folders upon mailbox creation, e.g. a spam folder to store potential spam mails for spamassassin learning. On the other hand, how to prevent such folders from deletion by users? Thanks a lot. How do you create mailboxes now? We create mailboxes using a Perl script, and that script also creates a junk-mail folder with an annotation to delete messages older than 30 days. You can also alter the folder's permissions to prevent users from deleting them. Do you mind to share the script with us? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: saslauthd and multiple dc levels
Dear Gabriele and Cyrus friends, On Tue, Dec 23, 2014 at 03:22:18PM +0100, Gabriele Bulfon wrote: Hi, I recently stumbled upon this issue, where I can't find a solution. Same cyrus/sasl server, serving multiple 2 level domains (dc=domain,dc=com). Sasl configuration is like: ldap_search_base: ou=People,dc=%2,dc=%1 ldap_filter: uid=%u Enter a new domain, but this time it's a 3 level one (dc=dpt,dc=domain,dc=com). Sasl configuration should be like: ldap_search_base: ou=People,dc=%3,dc=%2,dc=%1 ldap_filter: uid=%u How can I let saslauthd support both configurations? Google didn't find an answer to this, just a lot of confused discussions. Any help? :) Gabriele. What happens if you set snip ldap_search_base: dc=%2,dc=%1 ldap_filter: uid=%u /snip ? also set snip ldap_verbose: on /snip, to get more output. Maybe you need to play with snip ldap_scope: sub /snip as well. All settings in your saslauthd.conf file -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: saslauthd and multiple dc levels
Hello Dan, On Tue, Dec 23, 2014 at 08:50:07AM -0600, Dan White wrote: On 12/23/14 15:22 +0100, Gabriele Bulfon wrote: Hi, I recently stumbled upon this issue, where I can't find a solution. Same cyrus/sasl server, serving multiple 2 level domains (dc=domain,dc=com). Sasl configuration is like: ldap_search_base: ou=People,dc=%2,dc=%1 ldap_filter: uid=%u Enter a new domain, but this time it's a 3 level one (dc=dpt,dc=domain,dc=com). Sasl configuration should be like: ldap_search_base: ou=People,dc=%3,dc=%2,dc=%1 ldap_filter: uid=%u How can I let saslauthd support both configurations? Is the server OpenLDAP? If so, using olcAuthzRegexp would be a far more flexible way to handle this scenario. Within saslauthd's ldap config, use 'ldap_use_sasl' without specifying a search filter or base. Within slapd, your regex rules could perform a subtree search, or a simple string replacement for each domain. See http://www.openldap.org/doc/admin24/sasl.html and slapd-config(5). I don't understand how this works. ldap_use_sasl in saslauthd.conf tells saslauthd to contact OpenLDAP server via sasl protocol directly. Is this correct? And what happens then? How do saslauthd and slapd communicate and how is authentication performed? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: restore from cyrdump
Hello Patrick and Cyrus friends, I have used imapsync to transfer the imap data from computer1 to computer2. Though this was more difficult than expected. The following worked: /usr/local/bin/imapsync --host1 computer1.example.org --user1 MyName --port1 143 --password1 MASKED --tls1 --authmech1 PLAIN --host2 computer2.example.org --user2 MyName --port2 143 --password2 MASKED --tls2 --authmech2 PLAIN The following did not work: /usr/local/bin/imapsync --host1 computer1.example.org --user1 MyName --port1 993 --password1 MASKED --tls1 --authmech1 PLAIN --host2 computer2.example.org --user2 MyName --port2 993 --password2 MASKED --tls2 --authmech2 PLAIN Though, both computers are listening on 143 and 993. I always assumed that I needed for 993 for imaps and 143 for tls/ssl, so I was always wondering why tls/ssl did work on 993 with for example mutt, my mail client. Therefore I assumed that the ports 143 and 993 were equal for the cyrus-imap server side. Actually, now I'm thinking about it, I never forced the cyrus-imap server to respond to encrypted connections only. I hope and think that the server will refuse unencrypted connections for the authmech1 PLAIN LOGIN etc. Are the responses to connection requests on port 143 different from port 993 for cyrus-imapd? Are plain passwords allowed over unencrypted connections? On Tue, Dec 09, 2014 at 02:23:04PM -0600, Patrick Goetz wrote: On 12/09/2014 09:03 AM, Willy Offermans wrote: Now I want to restore the data of user.$USER on a different server. How should I proceed? To move a single user to a new server, in the past I've used imapsync to good effect (http://imapsync.lamiral.info/): imapsync --host1 my_old_server --authmech1 LOGIN --user1 pgoetz --password1 x --host2 my_new_server --authmech2 PLAIN --user2 pgg --password2 x In terms of a general backup scheme, since I have no idea how to set up a replication server, I've been toying with using imapsync for general backups to another (otherwise unused) imap server. I think the only way to do this for the entire mail store is to create a cyrus-backup user that has read access to all folders on the primary server and read/write access to the backup mail server. However, I haven't tested this and don't know if this will work properly. Also, as suggested by Marcus Schopen, this is liable to be quite slow, as each user has be to synced individually AFAIK. (I'm pretty sure the last time I used imapsync it was free, but the author appears to now be selling it.) Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: restore from cyrdump
Hello Patrick and Cyrus friends, On Tue, Dec 09, 2014 at 02:27:09PM -0600, Patrick Goetz wrote: On 12/09/2014 09:36 AM, Bron Gondwana wrote: Is there nobody with a good suggestion? Not really. Most people seem to be using LVM snapshots. OK, I'll bite. Since a couple of times I've had to restore mail using reconstruct after having lost all the metadata, I'm wondering what the point is of either cyrdump or ctl_mboxlist list if you can't restore the mail spool from their outputs? What does cyrdump do, anyway? I would expect it to also backup all the metadata; else it amounts to tar'ing up ~/cyrus/user. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus It is indeed interesting to figure out that there is a tool to dump mail data into a file, but there is no tool to perform the opposite. Can at least someone point out the procedure how to restore the mail folder of user.$USER from the cyrdump and ctl_mboxlist files? Are these files even sufficient for a total restore? I'm not sure what you mean with ``all the metadata'', but there are user flags saved into the cyrdump file as well. I never performed the whole cycle of dump and restore (probably nobody did so far), so I cannot tell you that all metadata is available in the dump file. See my question above! I'm contemplating about the relevance of cyrdump and ctl_mboxlist route. Of course the snapshot route or imapsync offer different and maybe easier routes to achieve the same goal: Transfer mail data from server A to server B, but maybe there are situations where cyrdump and ctl_mboxlist show their merits. For example, if someone does not have the possibility to run an imap server on server B. But what is definitely missing in the cyrus-imapd documentation is a chapter about backup and restore. The possible different routes should be addressed. It might be sufficient to draw the red line and refer to different documentation. And if cyrdump-ctl_mboxlist-route is not (yet) the way to go, then please state this as well. It can save time and frustration. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: restore from cyrdump
Hello Cyrus Friends, On Sun, Dec 07, 2014 at 01:01:52PM +0100, Willy Offermans wrote: Dear Cyrus friends, I want to simulate a possible crash of the company's mail server. At the moment the server works smoothly, but you never know... It is best to be prepared for it and to have possibilities to restore critical data. E-mail info was appointed to be one of the critical data. So I picked one user and cyrdump his data into a file. ``cyrdump -v user.$USER /tmp/$USER.dump'' If I make a quick scan of the file, it looks like a dump of mails of the user. Moreover, there is flag info per mail subfolder. There is info about subfolders and there is info about the mail IDs in each subfolder. Summarized, there is all the info needed to reconstruct the user's mailfolder and mails. I created the mailbox lists su - cyrus -c ctl_mboxlist -d /tmp/mailboxes.txt Now I want to restore the data of user.$USER on a different server. How should I proceed? I might write a script to reconstruct the data from the $USER.dump file, but I guess there is already a tool to do so. However I'm not aware of such tool and moreover I cannot find any info on http://www.cyrusimap.org/ concerning this. Can someone help me out? To my opinion, the restore procedure should be well documented. -- Is there nobody with a good suggestion? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
restore from cyrdump
Dear Cyrus friends, I want to simulate a possible crash of the company's mail server. At the moment the server works smoothly, but you never know... It is best to be prepared for it and to have possibilities to restore critical data. E-mail info was appointed to be one of the critical data. So I picked one user and cyrdump his data into a file. ``cyrdump -v user.$USER /tmp/$USER.dump'' If I make a quick scan of the file, it looks like a dump of mails of the user. Moreover, there is flag info per mail subfolder. There is info about subfolders and there is info about the mail IDs in each subfolder. Summarized, there is all the info needed to reconstruct the user's mailfolder and mails. I created the mailbox lists su - cyrus -c ctl_mboxlist -d /tmp/mailboxes.txt Now I want to restore the data of user.$USER on a different server. How should I proceed? I might write a script to reconstruct the data from the $USER.dump file, but I guess there is already a tool to do so. However I'm not aware of such tool and moreover I cannot find any info on http://www.cyrusimap.org/ concerning this. Can someone help me out? To my opinion, the restore procedure should be well documented. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Using memcached for authentication
Hello Ram and Cyrus-imap friends, On Wed, Jul 09, 2014 at 01:32:50PM +0530, Ram wrote: Currently I use pam with pam_mysql for authenticating cyrus accounts But I frequently run into the issue of mysql connections exceeding limit. Can I simply use something like Memcached or Redis to authenticate users You could also simply increase the connections limit in MySQL. I cannot get to my notes at the moment, but I'm pretty sure that you find the needed info somewhere on the net. duckduckgo is your friend as long as Google is tracking your interests. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Using memcached for authentication
Hello Ram and Cyrus-imap friends, On Wed, Jul 09, 2014 at 03:06:16PM +0530, Ram wrote: On 07/09/2014 02:49 PM, Willy Offermans wrote: Hello Ram and Cyrus-imap friends, On Wed, Jul 09, 2014 at 01:32:50PM +0530, Ram wrote: Currently I use pam with pam_mysql for authenticating cyrus accounts But I frequently run into the issue of mysql connections exceeding limit. Can I simply use something like Memcached or Redis to authenticate users You could also simply increase the connections limit in MySQL. I did .. I have now set it to unreasonable limits. But I think that is not a good idea anyway. Most of these these webmail products they really jam the imap servers with too many authentication requests I run cyrus-sasl with caching on but still see too many connections going to mysql servers , when actually they are not needed at all I cannot get to my notes at the moment, but I'm pretty sure that you find the needed info somewhere on the net. duckduckgo is your friend as long as Google is tracking your interests. If this is the case, then one should look to these authentication requests as well. If they are not necessary, then the amount of requests should be drastically decreased. As a matter of fact, our imap-server also requests a lot of authentications. It will be about 200 times an hour per user. I noticed this before and I never understood why, but it also never led to an unworkable situation. So I did not spent much time on it. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Using memcached for authentication
Hello Cyrus-imap friends, On Wed, Jul 09, 2014 at 12:05:02PM +0200, Willy Offermans wrote: Hello Ram and Cyrus-imap friends, On Wed, Jul 09, 2014 at 03:06:16PM +0530, Ram wrote: On 07/09/2014 02:49 PM, Willy Offermans wrote: Hello Ram and Cyrus-imap friends, On Wed, Jul 09, 2014 at 01:32:50PM +0530, Ram wrote: Currently I use pam with pam_mysql for authenticating cyrus accounts But I frequently run into the issue of mysql connections exceeding limit. Can I simply use something like Memcached or Redis to authenticate users You could also simply increase the connections limit in MySQL. I did .. I have now set it to unreasonable limits. But I think that is not a good idea anyway. Most of these these webmail products they really jam the imap servers with too many authentication requests I run cyrus-sasl with caching on but still see too many connections going to mysql servers , when actually they are not needed at all I cannot get to my notes at the moment, but I'm pretty sure that you find the needed info somewhere on the net. duckduckgo is your friend as long as Google is tracking your interests. If this is the case, then one should look to these authentication requests as well. If they are not necessary, then the amount of requests should be drastically decreased. As a matter of fact, our imap-server also requests a lot of authentications. It will be about 200 times an hour per user. I noticed this before and I never understood why, but it also never led to an unworkable situation. So I did not spent much time on it. I had another look to it and figured out that the amount of requests strongly depends on the used e-mail client. In that case it is worth to investigate the option imapproxyd in more detail, since the choice of e-mail client cannot be dictated. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Database error
Dear Niels and cyrus-imap friends, On Mon, Jun 02, 2014 at 07:58:43PM +0200, Niels Dettenbach wrote: Hi Wiel, Am Montag, 2. Juni 2014, 16:44:14 schrieben Sie: I already suspected something like that. but I miss some more detailed info. Following plan A: How can I update DB data? What are the tools to use? What is the content of /var/imap/db anyway? Can it be disposed of and will it be regenerated automagically? Following plan B: How do I export and import the data. Is there a db_dump and db_import? At least, this route would allow me to make a judgement about the data. Take a look at i.e.: http://www.cyrusimap.org/docs/cyrus-imapd/2.4.12/install-upgrade.php and/or: http://www.banquise.org/software/how-to-recover-from-cyrus-when-you-have-some-db-errors/ make a simple skiplist file from your mailboxes index db file with the cvt_cyrusdb tool - i.e. (fit the pathes!). I usually execute cyrus commands under the cyrus user of that system (typically cyrus) by sudo or su cyrus: /usr/cyrus/bin/cvt_cyrusdb /var/imap/mailboxes.db berkeley \ /var/imap/mailboxes.db.new skiplist mv /var/imap/mailboxes.db.new /var/imap/mailboxes.db This could be used independently from your DB version and is very handy if you have to rebuild your mailbox database from the ground (backup). A hard version is to delete the databases and let regenerate it new from cyrus. Make shure that you have the mailbox index file (mailboxes.db as skiplist and as a backup - and pls make a full backup of your /var/lib/cyrus database directory structure): - STOP/KILL all cyrus processes su - cyrus cd /var/lib/cyrus rm db/* rm db.backup1/* rm db.backup2/* rm deliver.db rm tls_sessions.db - START cyrus reconstruct or cyrreconstruct -r user.* (depending from under how name the reconstruct command is available) cheerioh, Niels. -- After an unplanned and unforeseen reboot, the problem disappeared. To me it seems that the '/var/imap/db' directory was recreated automagically during reboot. As the actual problem started after an update of FreeBSD ports, I have the impression that the update procedure for cyrus-imap and berkely db is not failure free. If the update for berkely db is so crucial for cyrus-imap, then arrangements for that should be settled. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 Mobile: +49 1575 414 60 55 e-mail: wi...@offermans.rompen.nl Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Database error
Dear cyrus-imap friends, I encountered the following error in the message log file: Jun 2 16:01:01 donald lmtpunix[52339]: DBERROR db6: BDB1539 Build signature doesn't match environment Jun 2 16:01:01 donald lmtpunix[52339]: DBERROR: dbenv-open '/var/imap/db' failed: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch Jun 2 16:01:01 donald lmtpunix[52339]: DBERROR: init() on berkeley Jun 2 16:01:02 donald lmtpunix[52339]: USAGE willy user: 0.021687 sys: 0.00 Jun 2 16:02:39 donald lmtpunix[52339]: USAGE willy user: 0.00 sys: 0.013762 However, cyrus-imap seems to work properly. Does anyone recognize the error message and have a solution to it? Is there a way to synchronize DB_VERSIONs? I'm running cyrus-imap on FreeBSD 10.0-STABLE and did an update of ports recently. Good change that db was updated as well, but I do not know for certain. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 Mobile: +49 1575 414 60 55 e-mail: wi...@offermans.rompen.nl Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Database error
Hello Niels and cyrus-imap friends, On Mon, Jun 02, 2014 at 04:33:14PM +0200, Niels Dettenbach wrote: Hi Willy, Am Montag, 2. Juni 2014, 16:18:32 schrieb Willy Offermans: Jun 2 16:01:01 donald lmtpunix[52339]: DBERROR: dbenv-open '/var/imap/db' failed: BDB0091 DB_VERSION_MISMATCH: Database environment version mismatch ...usually means that your DB data is for an older version. You have to: - update your DB to the newer version or - export the old databases to text / plain files and reimport it into the new one I already suspected something like that. but I miss some more detailed info. Following plan A: How can I update DB data? What are the tools to use? What is the content of /var/imap/db anyway? Can it be disposed of and will it be regenerated automagically? Following plan B: How do I export and import the data. Is there a db_dump and db_import? At least, this route would allow me to make a judgement about the data. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 Mobile: +49 1575 414 60 55 e-mail: wi...@offermans.rompen.nl Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: To all port maintainers: libtool
Dear Tijl and FreeBSD friends, On Thu, May 08, 2014 at 12:24:20AM +0200, Tijl Coosemans wrote: Hi, I've been asked to write something about USES=libtool to clarify a few things about what it does and why. First: what is libtool? Libtool is a build script that acts as a wrapper around a compiler. You can compile code or link a library (or executable) with libtool and it will invoke the right compiler, linker and other commands for you. It supports multiple languages, compilers and platforms and simplifies writing makefiles when used in combination with automake. Many ports use it. The problems with libtool on FreeBSD. Libraries created with libtool have three version numbers X.Y.Z. How they are calculated is not straightforward but that's not important right now. The important thing is that the major version number X is the only one that really matters. An executable that links to libA will ask for libA.so.X and doesn't care about Y and Z. Only when the major version number of a library changes does everything that link to it need to be recompiled. On FreeBSD however libtool uses X+Y as major version number which means that changes in Y also require rebuilding all ports that depend on the library. A second problem is that libtool flattens the dependency tree. When you link an executable or library with libA while libA in turn links to libB then libtool will make the executable or library also link with libB. This means that when the major version number of libB changes, the executable or library will also have to be rebuilt. Some libraries get propagated into hundreds and even thousands of ports this way while only a few actually use them directly. These two problems make major version number changes too frequent and too painful, not only for users who build their own ports, but also for package users, because too many packages need to be rebuilt, mirrored and downloaded every week than strictly necessary. A third problem is with ports that have USE_AUTOTOOLS=libtool in their Makefile. Normally the libtool script is generated by the configure script so it uses the compiler, linker and other tools that you configure a port with. Ports with USE_AUTOTOOLS=libtool however use /use/local/bin/libtool. This is the libtool script generated by the configure script of devel/libtool. This mechanism was meant for ports that ship with a version of libtool that doesn't work properly, but the problem is that such ports aren't necessarily built with the same tools as devel/libtool. An upcoming feature that allows cross-building ports and that will be used to provide ARM packages is currently blocked by this because these ports don't use the right cross compiler and linker. The solution. All ports that use libtool need to have USES=libtool added to their Makefile and USE_AUTOTOOLS=libtool removed. USES=libtool will patch the port to address the problems above along with a few smaller problems with older versions of libtool that some ports still ship with. USES=libtool also replaces USE_GNOME=ltverhack so that should be removed as well. In fact, all libtool related hacks and patches that a port contains can probably be removed (typically patches or post-patch commands for files like ltconfig, ltmain.sh and configure). The easiest way to know if a port uses libtool is to build it first. You can then search the work directory for a file named libtool: # cd some/port # make # find work -name libtool Another giveaway is the installation of files with .la extension. USES=libtool modifiers :keepla and :oldver. One of the ways libtool propagates links is through .la libraries. These are ordinary text files that contain some meta-data about a library, including a record of all dependencies. These files are normally not needed and USES=libtool removes them from the staging area. For the rare cases where a port does need these files USES=libtool:keepla can be used. In this case .la files are kept but the dependency record is cleared so dependencies won't be propagated to other ports. Another important reason to keep .la files is that in this transition period other ports may still contain references to them in the dependency record of their .la files. These ports first need to have some form of USES=libtool added to their Makefile such that these references are removed. So, as long as there are dependent ports that install .la files but do not have some form of USES=libtool, a port must use USES=libtool:keepla. Finally, because the major version number goes from X+Y to X, if Y is non-zero, the library version will go backwards. This is not a problem in the sense of API compatibility (because of the way libtool versioning works everything between X and X+Y is backwards compatible and a new release that isn't backwards compatible will see its major version number jump to newX=oldX+oldY+1), but
Re: imapd seems to serve up emails with empty attachments.
Hallo Jeroen, On Tue, Mar 11, 2014 at 09:25:57AM +0100, Jeroen Baten wrote: Hi, There is something I do not understand at the moment. I copy an email to two different folders. On the filesystem level a diff tells me they are exactly the same. Using a recent Thunderbird to view the attachments in one message it is fine, in the other Thunderbird complains about an empty attachment. What is wrong or how can I fix this? I am running Ubuntu 12.04 with cyrus imapd 2.4.12-2 Any and all help is highly appreciated. Kind regards, Jeroen Baten -- Are you sure that this is a cyrus problem? It seems to me that this is more a Thunderbird problem. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: imapd seems to serve up emails with empty attachments.
Hallo Jeroen, On Tue, Mar 11, 2014 at 10:44:12AM +0100, Jeroen Baten wrote: Hello Willy, Since both messages are served up by cyrus I thought that would cause the problem. Just installed evolution and gave it a try. Damn, you are right! :-) Weird though. Will continue the investigation in the TB direction. Kind regards, Jeroen Baten op 11-03-14 09:37, Willy Offermans schreef: Hallo Jeroen, On Tue, Mar 11, 2014 at 09:25:57AM +0100, Jeroen Baten wrote: Hi, There is something I do not understand at the moment. I copy an email to two different folders. On the filesystem level a diff tells me they are exactly the same. Using a recent Thunderbird to view the attachments in one message it is fine, in the other Thunderbird complains about an empty attachment. What is wrong or how can I fix this? I am running Ubuntu 12.04 with cyrus imapd 2.4.12-2 Any and all help is highly appreciated. Kind regards, Jeroen Baten -- Are you sure that this is a cyrus problem? It seems to me that this is more a Thunderbird problem. Good that you located the source of error. Are you using replication or cyrus aggregator (murder) to accomplish duplication of your message(s)? If yes, I'm interested in your experiences and setups. I have almost finished the setup of my new FreeBSD server, but I want to improve on a couple of services, such as cyrus-imapd, openldap and dhcp, openldap and openvpn, etc. So I'm looking to concepts, examples, and experiences of other people. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Backend reboot replication lost
Hello Michael and cyrus friends,
On Fri, Feb 28, 2014 at 01:07:45PM +0100, Michael Menge wrote:
Hi
Quoting Willy Offermans wi...@offermans.rompen.nl:
Dear cyrus friends,
Once more my backend server was rebooted. I did not find any messages in my
logs nor did I receive any screen messages, that the replication was
stopped. I wonder what will happen in a production environment, when the
server reboots without my notice. Replication will fail and I will not be
able to guarantee full recovery. To my opinion this is unacceptable.
Best would be to incorporate a message system about failure in the
sync_client code.
I found some entries in the logs of the backend server about access of the
replication user: every 10 minutes the user logs on to the backend server.
Most probably to replicate the mails. I might use this behavior as a sign
of a working replication mechanism. It is only indirect, but it tells me
that there is at least some activity from the client to the backend. I
wonder why the user is logging on every 10 minutes. Does it mean that the
mails, received for the last 9 minutes or so, are not replicated?
I'm not very experience in coding, but I will try to dig into the
sync_client code and see how things are organised.
I restarted the replication by executing ``sync_client -r'' on the client.
I do not even know if this is the right step to take to reactivate
replication. Can someone confirm? I can see in the logs of the backend,
that the replication user logs on every 10 minutes again. I take that as a
positive sign, that ``sync_client -r'' restarts the replication, but I have
no clue about inconsistencies or other possible checks.
If you have configured rolling replication, every change will be logged
to the {configdirectory}/sync/log file. The 'sync_client -r' will check
for this file, move it to {configdirectory}/sync/log-pid, process the file
and checks again for a new {configdirectory}/sync/log
If 'sync_client -r' is not running has crashed {configdirectory}/sync/log
will grow. So by checking the filesize of the log you know if you replic is
up to date.
If sync_client stops, and there is a log-pid file present,
you run sync_client -r -f {configdirectory}/sync/log-pid
and check that the exit code. If it is 0 you can remove the
log-pid file and restart 'sync_cliet -r', if not check the logs
for errors.
The backend rebooted once more. This will still happen several times, I'm
afraid, for reasons not related to cyrus. It gives me the opportunity to
play with replication.
There were several log files in /var/imap/sync:
log
log-4508
log-74001
log-5600
(I do not remember the exact numbers)
I removed the old log-pid files, leaving log-4508 and log file. I assumed
that the old log-pid remained after previous reboots.
I had a look into log file. It was a listing about my mail boxes, seemingly
randomly, and with double entries. I assumed the entries were connected
to the reception of incoming mails. However, I have no clue how the entries are
related to the replication process. Maybe someone can shed light on this.
I followed your procedure:
a) sync_client -r -f /var/imap/sync/log-4508
b) sync_client -r
I worked seemingly well. No messages whatsoever. So without any other
proof, I take this for success.
I like to note three things:
1) This procedure should be written somewhere in the manual.
2) There is still a need for double check of successful replication.
3) There is still a need for a message about failure of replication, caused
by reboot or other connection lost.
--
Met vriendelijke groeten,
With kind regards,
Mit freundlichen Gruessen,
De jrus wah,
Willy
*
W.K. Offermans
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Backend reboot replication lost
Dear cyrus friends, Once more my backend server was rebooted. I did not find any messages in my logs nor did I receive any screen messages, that the replication was stopped. I wonder what will happen in a production environment, when the server reboots without my notice. Replication will fail and I will not be able to guarantee full recovery. To my opinion this is unacceptable. Best would be to incorporate a message system about failure in the sync_client code. I found some entries in the logs of the backend server about access of the replication user: every 10 minutes the user logs on to the backend server. Most probably to replicate the mails. I might use this behavior as a sign of a working replication mechanism. It is only indirect, but it tells me that there is at least some activity from the client to the backend. I wonder why the user is logging on every 10 minutes. Does it mean that the mails, received for the last 9 minutes or so, are not replicated? I'm not very experience in coding, but I will try to dig into the sync_client code and see how things are organised. I restarted the replication by executing ``sync_client -r'' on the client. I do not even know if this is the right step to take to reactivate replication. Can someone confirm? I can see in the logs of the backend, that the replication user logs on every 10 minutes again. I take that as a positive sign, that ``sync_client -r'' restarts the replication, but I have no clue about inconsistencies or other possible checks. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Willy * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: sync_client errors
Dear Marcus, On Tue, Feb 25, 2014 at 08:20:39PM +0100, Marcus Schopen wrote: Am Dienstag, den 25.02.2014, 12:39 +0100 schrieb Willy Offermans: Dear Friends, On Mon, Feb 24, 2014 at 01:17:30PM +0100, Willy Offermans wrote: Dear cyrus Friends, I'm testing the replication option of cyrus. I have rebooted the ``master'' several times yesterday, but for reasons __not__ related to cyrus. Today I figured out that replication was not working as expected. I tried to restart replication by ``service imapd restart'' on both servers. I noticed some action, but replication stopped once more. I found the following in my logs. A snippet from my logs: snip ... Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22755 modseq:38813 last_updated:1393151348 internaldate:1393144202 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22755 modseq:38809 last_updated:1393167405 internaldate:1393144202 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22756 modseq:38813 last_updated:1393151348 internaldate:1393144788 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22756 modseq:38809 last_updated:1393167405 internaldate:1393144788 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22757 modseq:38813 last_updated:1393151348 internaldate:1393145814 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22757 modseq:38809 last_updated:1393167405 internaldate:1393145814 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:4057 modseq:38831 last_updated:1393167452 internaldate:1348384486 flags:( Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:4057 modseq:6809 last_updated:1348464157 internaldate:1348384486 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 2 (75fa289b62e23664f3cc00a11254191f65e50163) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22378 modseq:38842 last_updated:1393187494 internaldate:1392368284 flags:( Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22378 modseq:38160 last_updated:1392369039 internaldate:1392368284 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22742 (639836573eacee96d0a61c086b39c155e63b6dfa) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22743 modseq:38813 last_updated:1393151348 internaldate:1393095204 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22743 modseq:38809 last_updated:1393167405 internaldate:1393095204 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22744 (c85e24343dd16d5fd655ac674067382572318e29) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22745 (6df887eaa626a616e19def3affe42078d57d498b) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22746 (0698384acd5a6a8a06eae3cce1d279e0057f1935) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22747 (29d274001b7040613246d44d6848087df431f716) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22748 (e1860bb01952383639b74fb02ccc9f50674a3077) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22749 (439b4c69a007cf092c005e481dfa30bc3e1c2d95) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22750 (4da4738844df0aa502b33b392dc974954c0be05f) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22751 (40b39f7b075fec8288da1a63d63e83fc11c42b50) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22752 (c8428171c53dc75194e87fa14e9e2749b6bb95d4) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22753
Re: sync_client errors
Hello Bron and Cyrus Friends, On Wed, Feb 26, 2014 at 08:41:15AM +1100, Bron Gondwana wrote: Sorry, on holiday. Phone only. Looks like you might have corruption at one end, try reconstructing both ends. Also make sure you're not changing things on the replicas. On Tue, Feb 25, 2014, at 10:39 PM, Willy Offermans wrote: Dear Friends, On Mon, Feb 24, 2014 at 01:17:30PM +0100, Willy Offermans wrote: Dear cyrus Friends, I'm testing the replication option of cyrus. I have rebooted the ``master'' several times yesterday, but for reasons __not__ related to cyrus. Today I figured out that replication was not working as expected. I tried to restart replication by ``service imapd restart'' on both servers. I noticed some action, but replication stopped once more. I found the following in my logs. A snippet from my logs: snip ... Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22755 modseq:38813 last_updated:1393151348 internaldate:1393144202 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22755 modseq:38809 last_updated:1393167405 internaldate:1393144202 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22756 modseq:38813 last_updated:1393151348 internaldate:1393144788 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22756 modseq:38809 last_updated:1393167405 internaldate:1393144788 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22757 modseq:38813 last_updated:1393151348 internaldate:1393145814 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22757 modseq:38809 last_updated:1393167405 internaldate:1393145814 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:4057 modseq:38831 last_updated:1393167452 internaldate:1348384486 flags:( Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:4057 modseq:6809 last_updated:1348464157 internaldate:1348384486 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 2 (75fa289b62e23664f3cc00a11254191f65e50163) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22378 modseq:38842 last_updated:1393187494 internaldate:1392368284 flags:( Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22378 modseq:38160 last_updated:1392369039 internaldate:1392368284 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22742 (639836573eacee96d0a61c086b39c155e63b6dfa) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22743 modseq:38813 last_updated:1393151348 internaldate:1393095204 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22743 modseq:38809 last_updated:1393167405 internaldate:1393095204 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22744 (c85e24343dd16d5fd655ac674067382572318e29) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22745 (6df887eaa626a616e19def3affe42078d57d498b) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22746 (0698384acd5a6a8a06eae3cce1d279e0057f1935) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22747 (29d274001b7040613246d44d6848087df431f716) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22748 (e1860bb01952383639b74fb02ccc9f50674a3077) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22749 (439b4c69a007cf092c005e481dfa30bc3e1c2d95) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22750 (4da4738844df0aa502b33b392dc974954c0be05f) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22751 (40b39f7b075fec8288da1a63d63e83fc11c42b50) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists
Re: frequently corrupt tis_sessions.db files
Dear Steve and Cyrus friends, On Tue, Feb 25, 2014 at 11:03:30AM -0800, Stephen Ingram wrote: I'm running a very small murder setup using Simon Matter's RPM packages on CentOS 6.x. Frequently, the tis_sessions.db file on the update master becomes corrupt such that one or more of the nodes can no longer establish a connection. Of course, this results in folders not reserved properly on the master and a long list of issues from there. Each time I see the behavior in the logs: tlsv1 alert decrypt error in SSL_accept() - fail STARTTLS negotiation failed: imap1.xxx.xxx Connection reset by peer, closing connection Stopping cyrus-imapd, removing tls_sessions.db and then restarting cyrus-imapd always solves the problem. Is the tls database typically this unreliable (can't imagine why as it's the same db used for the mail, right?) and perhaps I should just not cache these connections or is there something else that could be wrong? Steve Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus How do you know that tls_sessions.db is corrupt? Is this really the right order: 1) tls_sessions.db becomes corrupt 2) tlsv1 alert decrypt error in SSL_accept() - fail STARTTLS negotiation failed: imap1.xxx.xxx Connection reset by peer, closing connection To me, the one is independent of the other, meaning that a corrupted tls_sessions.db is not related to STARTTLS and a STARTTLS negotiation failed does not necessarily leads to a corrupted tls_sessions.db. Maybe I'm missing crucial information. I hope someone can clarify this. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, Willy * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Powered by (__) \\\'',) \/ \ ^ .\._/_) www.FreeBSD.org Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
sync_client segmentation fault
Dear cyrus friends, I'm not very lucky with the setup of replication. I got a Segmentation fault on a different client: MySecondClient# ll -d /var/db/pkg/cyrus-* drwxr-xr-x 2 root wheel 9 Feb 9 2013 /var/db/pkg/cyrus-imapd-2.3.16_3 drwxr-xr-x 2 root wheel 10 May 27 2011 /var/db/pkg/cyrus-sasl-2.1.23_3 drwxr-xr-x 2 root wheel 9 May 7 2011 /var/db/pkg/cyrus-sasl-saslauthd-2.1.23 MySecondClient# /usr/local/cyrus/bin/sync_client -u truus -r Segmentation fault MySecondClient# ldd /usr/local/cyrus/bin/sync_client /usr/local/cyrus/bin/sync_client: libsasl2.so.2 = /usr/local/lib/libsasl2.so.2 (0x8006fa000) libgssapi.so.9 = /usr/lib/libgssapi.so.9 (0x800812000) libkrb5.so.9 = /usr/lib/libkrb5.so.9 (0x80091a000) libasn1.so.9 = /usr/lib/libasn1.so.9 (0x800a5f000) libroken.so.9 = /usr/lib/libroken.so.9 (0x800b89000) libcrypt.so.4 = /lib/libcrypt.so.4 (0x800c97000) libcom_err.so.4 = /usr/lib/libcom_err.so.4 (0x800db) libdb41.so.1 = /usr/local/lib/libdb41.so.1 (0x800eb2000) libpcre.so.0 = /usr/local/lib/libpcre.so.0 (0x801069000) libpcreposix.so.0 = /usr/local/lib/libpcreposix.so.0 (0x8011a5000) libssl.so.5 = /usr/lib/libssl.so.5 (0x8012a7000) libcrypto.so.5 = /lib/libcrypto.so.5 (0x8013f1000) libz.so.4 = /lib/libz.so.4 (0x801683000) libmd.so.4 = /lib/libmd.so.4 (0x801797000) libc.so.7 = /lib/libc.so.7 (0x8018a3000) What can I do about a Segmentation fault? Shall I deinstall and reinstall? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, Willy * Dr. W.K. Offermans CAT Fellow CAT Catalytic Center Institut f�r Technische und Makromolekulare Chemie RWTH Aachen Worringerweg 1, Raum 38C-150 D-52074 Aachen, Germany Phone: +49 241 80 28592 Fax:+49 241 80 22593 Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl e-mail: willy.offerm...@catalyticcenter.rwth-aachen.de Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: sync_client errors
Dear Friends, On Mon, Feb 24, 2014 at 01:17:30PM +0100, Willy Offermans wrote: Dear cyrus Friends, I'm testing the replication option of cyrus. I have rebooted the ``master'' several times yesterday, but for reasons __not__ related to cyrus. Today I figured out that replication was not working as expected. I tried to restart replication by ``service imapd restart'' on both servers. I noticed some action, but replication stopped once more. I found the following in my logs. A snippet from my logs: snip ... Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22755 modseq:38813 last_updated:1393151348 internaldate:1393144202 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22755 modseq:38809 last_updated:1393167405 internaldate:1393144202 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22756 modseq:38813 last_updated:1393151348 internaldate:1393144788 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22756 modseq:38809 last_updated:1393167405 internaldate:1393144788 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22757 modseq:38813 last_updated:1393151348 internaldate:1393145814 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22757 modseq:38809 last_updated:1393167405 internaldate:1393145814 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:4057 modseq:38831 last_updated:1393167452 internaldate:1348384486 flags:( Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:4057 modseq:6809 last_updated:1348464157 internaldate:1348384486 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 2 (75fa289b62e23664f3cc00a11254191f65e50163) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22378 modseq:38842 last_updated:1393187494 internaldate:1392368284 flags:( Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22378 modseq:38160 last_updated:1392369039 internaldate:1392368284 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22742 (639836573eacee96d0a61c086b39c155e63b6dfa) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22743 modseq:38813 last_updated:1393151348 internaldate:1393095204 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22743 modseq:38809 last_updated:1393167405 internaldate:1393095204 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22744 (c85e24343dd16d5fd655ac674067382572318e29) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22745 (6df887eaa626a616e19def3affe42078d57d498b) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22746 (0698384acd5a6a8a06eae3cce1d279e0057f1935) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22747 (29d274001b7040613246d44d6848087df431f716) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22748 (e1860bb01952383639b74fb02ccc9f50674a3077) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22749 (439b4c69a007cf092c005e481dfa30bc3e1c2d95) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22750 (4da4738844df0aa502b33b392dc974954c0be05f) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22751 (40b39f7b075fec8288da1a63d63e83fc11c42b50) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22752 (c8428171c53dc75194e87fa14e9e2749b6bb95d4) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22753 (19d7127f51a9f54db9dc5c5caa49d1bfbc86bb07) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22754 (c99fde22cfb9fdd85c20f24b9154059f8c2c97f7) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20
sync_client errors
Dear cyrus Friends, I'm testing the replication option of cyrus. I have rebooted the ``master'' several times yesterday, but for reasons __not__ related to cyrus. Today I figured out that replication was not working as expected. I tried to restart replication by ``service imapd restart'' on both servers. I noticed some action, but replication stopped once more. I found the following in my logs. A snippet from my logs: snip ... Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22755 modseq:38813 last_updated:1393151348 internaldate:1393144202 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22755 modseq:38809 last_updated:1393167405 internaldate:1393144202 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22756 modseq:38813 last_updated:1393151348 internaldate:1393144788 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22756 modseq:38809 last_updated:1393167405 internaldate:1393144788 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22757 modseq:38813 last_updated:1393151348 internaldate:1393145814 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22757 modseq:38809 last_updated:1393167405 internaldate:1393145814 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:4057 modseq:38831 last_updated:1393167452 internaldate:1348384486 flags:( Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:4057 modseq:6809 last_updated:1348464157 internaldate:1348384486 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 2 (75fa289b62e23664f3cc00a11254191f65e50163) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22378 modseq:38842 last_updated:1393187494 internaldate:1392368284 flags:( Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22378 modseq:38160 last_updated:1392369039 internaldate:1392368284 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22742 (639836573eacee96d0a61c086b39c155e63b6dfa) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22743 modseq:38813 last_updated:1393151348 internaldate:1393095204 flags:(\Seen) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: replica uid:22743 modseq:38809 last_updated:1393167405 internaldate:1393095204 flags:(Old) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22744 (c85e24343dd16d5fd655ac674067382572318e29) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22745 (6df887eaa626a616e19def3affe42078d57d498b) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22746 (0698384acd5a6a8a06eae3cce1d279e0057f1935) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22747 (29d274001b7040613246d44d6848087df431f716) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22748 (e1860bb01952383639b74fb02ccc9f50674a3077) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22749 (439b4c69a007cf092c005e481dfa30bc3e1c2d95) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22750 (4da4738844df0aa502b33b392dc974954c0be05f) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22751 (40b39f7b075fec8288da1a63d63e83fc11c42b50) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22752 (c8428171c53dc75194e87fa14e9e2749b6bb95d4) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22753 (19d7127f51a9f54db9dc5c5caa49d1bfbc86bb07) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCERROR: only exists on replica user.username 22754 (c99fde22cfb9fdd85c20f24b9154059f8c2c97f7) Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: record mismatch with replica: user.username more recent on master Feb 24 13:02:20 MyClient sync_client[74031]: SYNCNOTICE: master uid:22755 modseq:38813 last_updated:1393151348 internaldate:1393144202 flags:(\Seen) Feb 24 13:02:20
Re: cyradm cannot connect to cyrus imap server
Dear Cyrus Friends, On Thu, Feb 20, 2014 at 04:12:29PM -0600, Scott Lambert wrote: On Thu, Feb 20, 2014 at 10:35:42AM +0100, Willy Offermans wrote: Dear Cyrus Friends, I need your help to solve the following: I'm setting up cyrus on my new FreeBSD 10.0 server. I have used the following package: cyrus-imapd24-2.4.17_4 If I test my setup with imtest, I get connection to the imap server. MyName@MyComputer:~$ imtest -m login -u username -a username -s localhost It works However, if I try to connect via cyradm, I cannot login. MyName@MyComputer:~$ cyradm --user username localhost Password: verify error:num=19:self signed certificate in certificate chain cyradm: cannot authenticate to server with as username You specified your authentication mechanism to be login with imtest. You did not specify an authentication mechanism with cyradm. Perhaps it would work if you try : cyradm --auth login --user username localhost That is only a guess. -- Scott LambertKC5MLE Unix SysAdmin lamb...@lambertfam.org Indeed, I needed to specify an authentication mechanism and then I could use the command line interface of cyradm: cyradm --user username --auth PLAIN localhost If we are at this point anyway, I was wondering what I need to do to use another authentication mechanism. Is this possible? And what do I need to consider? The IMAP server response with the following authentication mechanism: AUTH=SCRAM-SHA-1 AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=PLAIN AUTH=LOGIN If I login with SCRAM-SHA-1: MyName@MyComputer:~$ cyradm --user username --auth SCRAM-SHA-1 localhost Password: verify error:num=19:self signed certificate in certificate chain cyradm: cannot authenticate to server with SCRAM-SHA-1 as username In the logs: Feb 21 09:48:36 MyComputer imap[17576]: badlogin: localhost [127.0.0.1] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] I'm pretty sure that the user is registered in the ldap database. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
replication does not work
Dear cyrus friends, I like to use the replication feature of cyrus. On the backend I changed the cyrus.conf file. I added: syncservercmd=/usr/local/cyrus/bin/sync_server listen=csync to the SERVICES. On the client side I changed the imapd.conf file and cyrus.conf file in the following way. cyrus.conf: I added syncclientcmd=/usr/local/cyrus/bin/sync_client -l -r to the START section. imapd.conf: I added sync_host: MyComputer.example.com sync_authname: username sync_log: 1 sync_password: secret I also did some changes to the services file to add csync and portnumbers. If I run ClientComputer# synctest -u username -a username -t '' -m PLAIN MyComputer.example.com S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM S: * STARTTLS S: * COMPRESS DEFLATE S: * OK MyComputer Cyrus sync server v2.4.17 C: STARTTLS S: OK Begin TLS negotiation now verify error:num=19:self signed certificate in certificate chain TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN S: * OK MyComputer Cyrus sync server v2.4.17 Please enter your password: C: AUTHENTICATE PLAIN sdjaskjfksfhsdfksfdasdkkfjsfdaksjkfjksfjksfjlfjkfjkj S: OK Success (tls protection) Authenticated. Security strength factor: 256 So everything seems to be fine However if I restart imapd on the client, I do not get any synchronization. I found the following message in the logs of the client: Feb 20 16:01:42 ClientComputer sync_client[36229]: couldn't authenticate to backend server: authentication failure I found the following message in the logs of the backend: Feb 20 16:01:39 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:39 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:01:57 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:57 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:02:30 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:02:30 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:03:33 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:03:33 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:05:36 MyComputer syncserver[15136]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:05:36 MyComputer syncserver[15136]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Or if I directly call for sync_client: MyComputer# /usr/local/cyrus/bin/sync_client -o -l -S 192.168.X.Y -r MyComputer# Can not connect to server '192.168.X.Y' I guess I'm missing the authentication mechanism for the sync_client, but I'm not sure. Can someone help me out? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm cannot connect to cyrus imap server
Hallo Dan, On Fri, Feb 21, 2014 at 08:50:41AM -0600, Dan White wrote: On 02/21/14 10:50 +0100, Willy Offermans wrote: Indeed, I needed to specify an authentication mechanism and then I could use the command line interface of cyradm: cyradm --user username --auth PLAIN localhost If we are at this point anyway, I was wondering what I need to do to use another authentication mechanism. Is this possible? And what do I need to consider? The IMAP server response with the following authentication mechanism: AUTH=SCRAM-SHA-1 AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=PLAIN AUTH=LOGIN If I login with SCRAM-SHA-1: MyName@MyComputer:~$ cyradm --user username --auth SCRAM-SHA-1 localhost Password: verify error:num=19:self signed certificate in certificate chain cyradm: cannot authenticate to server with SCRAM-SHA-1 as username In the logs: Feb 21 09:48:36 MyComputer imap[17576]: badlogin: localhost [127.0.0.1] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] I'm pretty sure that the user is registered in the ldap database. DIGEST-MD5, CRAM-MD5, and SCRAM-SHA-1 all require cyrus sasl to have access to the shared secret (clear text password) to complete authentication. If you're using LDAP to store your user credentials, you'll need to use the ldapdb auxprop plugin and store users' clear text passwords in userPassword. Presumably you're using 'sasl_pwcheck_method: saslauthd' currently, which is sufficient for PLAIN and LOGIN authentication. If you choose not to go the ldapdb route, I recommend specifying a sasl_mech_list to limit your mechanisms to PLAIN and LOGIN (and EXTERNAL if you intend to do starttls client authentication). If you don't do that, in your current setup, most clients will attempt to first authenticate using a shared secret mechanism (including cyradm in your initial attempt), which will always fail on that attempt. -- Dan White Thank you a lot for the clarification. I did some search on the internet myself and I got some increased understanding myself. I changed the imapd.conf on the imap server and added: sasl_mech_list: PLAIN LOGIN to the settings. This solved several issues. So I can already confirm your suggestion for solution. But many thnx anyway. You are pointing to EXTERNAL, next to PLAIN and LOGIN. I do not understand this mechanism yet. At the moment I believe I have PLAIN password wrapped into TLS. So I already do starttls client authentication. What will EXTERNAL do? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm cannot connect to cyrus imap server
Hello Dan, On Fri, Feb 21, 2014 at 09:22:55AM -0600, Dan White wrote: On 02/21/14 16:11 +0100, Willy Offermans wrote: You are pointing to EXTERNAL, next to PLAIN and LOGIN. I do not understand this mechanism yet. At the moment I believe I have PLAIN password wrapped into TLS. So I already do starttls client authentication. What will EXTERNAL do? TLS client authentication is a scenario where you perform TLS authentication where the client also has a certificate. The server can then use the contents of the client certificate to derive the username (with no password, per se). For example, 'cyradm --tlskey file'. The EXTERNAL mechanism should not be offered unless TLS client authentication was successful during the starttls step. -- Dan White This sounds interesting. I thought that TLSVerifyClient demand in slapd.conf was forcing this behavior. I like to read more about the EXTERNAL mechanism. Do you recommend some reading? At the moment I will stick to PLAIN and play with replication, serving multiple domains etc. -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: replication does not work
Dear cyrus friends, On Fri, Feb 21, 2014 at 03:48:20PM +0100, Willy Offermans wrote: Dear cyrus friends, I like to use the replication feature of cyrus. On the backend I changed the cyrus.conf file. I added: syncservercmd=/usr/local/cyrus/bin/sync_server listen=csync to the SERVICES. On the client side I changed the imapd.conf file and cyrus.conf file in the following way. cyrus.conf: I added syncclientcmd=/usr/local/cyrus/bin/sync_client -l -r to the START section. imapd.conf: I added sync_host: MyComputer.example.com sync_authname: username sync_log: 1 sync_password: secret I also did some changes to the services file to add csync and portnumbers. If I run ClientComputer# synctest -u username -a username -t '' -m PLAIN MyComputer.example.com S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM S: * STARTTLS S: * COMPRESS DEFLATE S: * OK MyComputer Cyrus sync server v2.4.17 C: STARTTLS S: OK Begin TLS negotiation now verify error:num=19:self signed certificate in certificate chain TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) S: * SASL SCRAM-SHA-1 DIGEST-MD5 CRAM-MD5 NTLM PLAIN LOGIN S: * OK MyComputer Cyrus sync server v2.4.17 Please enter your password: C: AUTHENTICATE PLAIN sdjaskjfksfhsdfksfdasdkkfjsfdaksjkfjksfjksfjlfjkfjkj S: OK Success (tls protection) Authenticated. Security strength factor: 256 So everything seems to be fine However if I restart imapd on the client, I do not get any synchronization. I found the following message in the logs of the client: Feb 20 16:01:42 ClientComputer sync_client[36229]: couldn't authenticate to backend server: authentication failure I found the following message in the logs of the backend: Feb 20 16:01:39 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:39 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:01:57 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:01:57 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:02:30 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:02:30 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:03:33 MyComputer syncserver[15127]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:03:33 MyComputer syncserver[15127]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Feb 20 16:05:36 MyComputer syncserver[15136]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Feb 20 16:05:36 MyComputer syncserver[15136]: badlogin: ClientComputer.example.com [192.168.0.15] SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get auxprops] Or if I directly call for sync_client: MyComputer# /usr/local/cyrus/bin/sync_client -o -l -S 192.168.X.Y -r MyComputer# Can not connect to server '192.168.X.Y' I guess I'm missing the authentication mechanism for the sync_client, but I'm not sure. Can someone help me out? I can answer my own question. I was indeed missing the authentication mechanism. I added sasl_mech_list: PLAIN LOGIN to imapd.conf on the back-end server and the replication worked. So I wonder how I can tell sync_client which authentication mechanism to use? It seems like a feature request to me? or a hidden option to the sync_client executable. I'm playing with replication now and testing what happens if one deletes e-mails on the back-end server and not on the client. Will these mails be restored on the back-end by replication and when? -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, De jrus wah, Wiel * W.K. Offermans Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: wi...@offermans.rompen.nl Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: cyradm cannot connect to cyrus imap server
Hello Dan and Cyrus Friends,
On Thu, Feb 20, 2014 at 08:38:42AM -0600, Dan White wrote:
On 02/20/14 10:35 +0100, Willy Offermans wrote:
I'm setting up cyrus on my new FreeBSD 10.0 server. I have used the following
package: cyrus-imapd24-2.4.17_4
If I test my setup with imtest, I get connection to the imap server.
MyName@MyComputer:~$ imtest -m login -u username -a username -s localhost
verify error:num=19:self signed certificate in certificate chain
TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256
bits)
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=SCRAM-SHA-1
AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=PLAIN AUTH=LOGIN SASL-IR]
MyComputer Cyrus IMAP v2.4.17 server ready
Please enter your password:
C: L01 LOGIN username {13}
S: + go ahead
C: omitted
S: L01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA
MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN
MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY
THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN
QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY LOGINDISABLED AUTH=SCRAM-SHA-1
AUTH=DIGEST-MD5 AUTH=CRAM-MD5 AUTH=NTLM AUTH=PLAIN AUTH=LOGIN
COMPRESS=DEFLATE IDLE] User logged in
SESSIONID=MyComputer-11451-1392884061-1
Authenticated.
Security strength factor: 256
From the message log file:
Feb 19 09:00:11 MyComputer imaps[3437]: imapd:Loading hard-coded DH
parameters Feb 19 09:00:11 MyComputer imaps[3437]: starttls: TLSv1 with
cipher DHE-RSA-AES256-SHA (256/256 bits new) no authentication
Feb 19 09:00:11 MyComputer imaps[3437]: OTP unavailable because can't
read/write key database /etc/opiekeys: Permission denied
Feb 19 09:00:15 MyComputer imaps[3437]: badlogin: localhost [127.0.0.1]
plaintext username SASL(-13): authentication failure: checkpass failed
Feb 19 09:00:30 MyComputer imaps[3437]: starttls: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits new) no authentication
Feb 19 09:00:30 MyComputer imaps[3437]: OTP unavailable because can't
read/write key database /etc/opiekeys: Permission denied
Feb 19 09:00:39 MyComputer imaps[3437]: login: localhost [127.0.0.1]
username plaintext+TLS User logged in
SESSIONID=MyComputer-3437-1392800430-1
Feb 19 09:02:18 MyComputer imaps[3437]: USAGE username user: 0.007544 sys:
0.022632
However, if I try to connect via cyradm, I cannot login.
MyName@MyComputer:~$ cyradm --user username localhost
Password:
verify error:num=19:self signed certificate in certificate chain
cyradm: cannot authenticate to server with as username
Does the output really say this (empty username)? I'm assuming you just
removed it when pasting it.
No Dan, I did not remove anything. I just replaced the actual username by
username. There is a whitespace between with and as in the output!
from the message log file:
Feb 19 09:02:41 MyComputer imap[3440]: OTP unavailable because can't
read/write key database /etc/opiekeys: Permission denied
Feb 19 09:02:48 MyComputer imap[3440]: badlogin: localhost [127.0.0.1]
SCRAM-SHA-1 [SASL(-13): user not found: unable to canonify user and get
auxprops]
Feb 19 09:02:51 MyComputer imap[3440]: badlogin: localhost [127.0.0.1]
DIGEST-MD5 [SASL(-13): user not found: unable to canonify user and get
auxprops]
Feb 19 09:02:55 MyComputer imap[3440]: imapd:Loading hard-coded DH parameters
Feb 19 09:02:55 MyComputer imap[3440]: starttls: TLSv1 with cipher
DHE-RSA-AES256-SHA (256/256 bits new) no authentication
Feb 19 09:02:55 MyComputer imap[3440]: OTP unavailable because can't
read/write key database /etc/opiekeys: Permission denied
In imapd.conf, set:
sasl_mech_list: PLAIN LOGIN EXTERNAL
to remove some extraneous error messages. Try specifying a mechanism
(--auth=PLAIN) in your cyradm command.
--
Dan White
I did this and it worked:
MyName@MyComputer:~$ cyradm --user username --auth PLAIN localhost
verify error:num=19:self signed certificate in certificate chain
Password:
localhost
Many thnx for your help!
--
Met vriendelijke groeten,
With kind regards,
Mit freundlichen Gruessen,
Wiel
*
W.K. Offermans
Home: +31 45 544 49 44
Mobile: +31 681 15 87 68
e-mail: wi...@offermans.rompen.nl
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
