Migration 32 to 64 bit
Hi, I'm planning the migration of our main cyrus server. Actually the server is running cyrus imap 2.2.3 on a SuSE 9.1 i586, with about 130Gb of mailboxes. My idea is moving to OpenSuse 10.3 with cyrus 2.3.8 on 64bit System. I googled a bit, but i couldn't find anything useful; i would like to know if there are issues moving from 32bit to 64bit and/or moving from 2.2.3 to 2.3.8 In particular i would like to minimize users impact, preserving mailstores, subscriptions and all seen status. Any hints/comments/precautions??? Thanks G.Ravasio Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
OpenLDAP search base/cyrus admin dn/DIT layout.
Hi, I'm using Cyrus with saslauthd/OpenLDAP. This is how my dit is now (test environment): [root] .ou=people ..several user entries ..cyrus admin dn ..ou=moodle ...ou=moodleinstall01 ...copy of some of the entries of ou=people with some modifications I'm using one cyrus admin dn, since I'm using only one imap server at the moment. When I have more cyrus servers using this ldap, each one will have its own cyrus admin dn. /etc/saslauthd.conf: LDAP_BIND_DN: uid=cyrus,ou=people,dc=xx,dc=xx,dc=xx,dc=xx LDAP_SEARCH_BASE: ou=people,dc=xx,dc=xx,dc=xx,dc=xx LDAP_FILTER: uid=%u I would like to have an OU for the directory administrative tasks, and have the DN's related to Cyrus there. That does not seem to be possible, I can't get it to work: 1) If I set the search base for the directory root, so I can put the cyrus admin DN on one OU and the user entries on another like: [root] .ou=adm ..cyrus admin dn .ou=people ..several user entries used by cyrus/saslauthd ..ou=moodle ...ou=moodleinstall01 ...copy of some of the entries of ou=people with some modifications LDAP_BIND_DN: uid=cyrus,ou=adm,dc=xx,dc=xx,dc=xx,dc=xx LDAP_SEARCH_BASE: dc=xx,dc=xx,dc=xx,dc=xx LDAP_FILTER: uid=%u the cyrus admin dn bind succeeds but saslauthd complains about having two DN's matching the UID attribute (remember I have copies of the user entries for the moodle service, since each moodle installation has/can see -only- the users using that moodle install (otherwise moodle adds -all- users it sees, which I don't want, on ou=people there will be more than 50k users, and each moodle has about 500 users) and because of the duplicated match the bind for the user connecting to the imap server fails. 2) If I set the search base for OU=people, and the cyrus admin DN is on some other place, say the root of the DIT, or some OU other the OU=people, the initial cyrus admin bind fails, I believe it's because of the search base being a place from where you cannot see the OU=adm subtree. What am I missing? thanks, Lauro This message was sent using IMP, the Internet Messaging Program. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Cyrus Muder
Hi All, Is your postfix running chrooted? If yes check in master.cf that at least lmtp is not running chrooted. I was trying murder on Fed box and came across this on http://cyrusimap.web.cmu.edu/imapd/install-murder.html Delivering mail To deliver mail to your Murder, configure your MTA just as you did before, but instead of connecting directly to lmtpd, it should connect to lmtpproxyd. You can connect to the lmtpproxyd running on the frontend machines, or you can install master and lmtpproxyd on your SMTP servers. My cyrus.conf does seem to have frontend lmtp cmd=lmtpproxyd -a listen=*:lmtp prefork=1 master lmtp cmd=lmtpd listen=*:lmtp prefork=1 lmtpunix cmd=lmtpd listen=/var/imap/socket/lmtp prefork=1 backend lmtp cmd=lmtpd -a listen=*:lmtp prefork=1 lmtpunix cmd=lmtpd listen=/var/imap/socket/lmtp prefork=1 The debug logs I get in cyrus is Nov 26 16:41:48 location postfix/lmtp[29178]: match_list_match: location.exampledomain.com: no match Nov 26 16:41:48 location postfix/lmtp[29178]: flush_add: site location.exampledomain.com id 7A25311E5AB status 4 Nov 26 16:41:48 location postfix/lmtp[29178]: smtp_loop: got 1 of 1 end-of-data replies Nov 26 16:41:48 location postfix/lmtp[29178]: name_mask: resource Nov 26 16:41:48 location postfix/lmtp[29178]: name_mask: software Nov 26 16:41:48 location postfix/lmtp[29178]: scache_clnt_save_dest: dest_label=lmtp:[192.168.50.77]:24 dest_prop=4096 endp_label=lmtp:[192.168.50.77]:24 Nov 26 16:41:48 location postfix/lmtp[29178]: send attr request = save_dest Nov 26 16:41:48 location postfix/lmtp[29178]: send attr ttl = 2 Nov 26 16:41:48 location postfix/lmtp[29178]: send attr label = lmtp:[192.168.50.77]:24 Nov 26 16:41:48 location postfix/lmtp[29178]: send attr property = 4096 Nov 26 16:41:48 location postfix/lmtp[29178]: send attr label = lmtp:[192.168.50.77]:24 Nov 26 16:41:48 location postfix/lmtp[29178]: private/scache: wanted attribute: status Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute name: status Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute value: 0 Nov 26 16:41:48 location postfix/lmtp[29178]: private/scache: wanted attribute: (list terminator) Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute name: (end) Nov 26 16:41:48 location postfix/lmtp[29178]: scache_clnt_save_endp: endp=lmtp:[192.168.50.77]:24 prop=3?192.168.50.77:24?192.168.50.77?192.168.50.77?6144?15?1196075807?4096 fd=16 Nov 26 16:41:48 location postfix/lmtp[29178]: send attr request = save_endp Nov 26 16:41:48 location postfix/lmtp[29178]: send attr ttl = 2 Nov 26 16:41:48 location postfix/lmtp[29178]: send attr label = lmtp:[192.168.50.77]:24 Nov 26 16:41:48 location postfix/lmtp[29178]: send attr property = 3?192.168.50.77:24?192.168.50.77?192.168.50.77?6144?15?1196075807?4096 Nov 26 16:41:48 location postfix/lmtp[29178]: private/scache: wanted attribute: dummy Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute name: dummy Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute value: (end) Nov 26 16:41:48 location postfix/lmtp[29178]: private/scache: wanted attribute: (list terminator) Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute name: (end) Nov 26 16:41:48 location postfix/lmtp[29178]: private/scache: wanted attribute: status Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute name: status Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute value: 0 Nov 26 16:41:48 location postfix/lmtp[29178]: private/scache: wanted attribute: (list terminator) Nov 26 16:41:48 location postfix/lmtp[29178]: input attribute name: (end) Nov 26 16:41:48 location postfix/lmtp[29178]: deliver_request_final: send: -1 Nov 26 16:41:48 location postfix/lmtp[29178]: send attr status = Nov 26 16:41:48 location postfix/lmtp[29178]: send attr diag_type = Nov 26 16:41:48 location postfix/lmtp[29178]: send attr diag_text = Nov 26 16:41:48 location postfix/lmtp[29178]: send attr mta_type = Nov 26 16:41:48 location postfix/lmtp[29178]: send attr mta_mname = Nov 26 16:41:48 location postfix/lmtp[29178]: send attr action = Nov 26 16:41:48 location postfix/lmtp[29178]: send attr reason = Nov 26 16:41:48 location postfix/lmtp[29178]: send attr status = 4294967295 Nov 26 16:41:48 location postfix/lmtp[29178]: master_notify: status 1 Nov 26 16:41:48 location postfix/lmtp[29178]: connection closed Wanted to know as to how to debug lmtpproxyd. and wondering what I'm doing wrong here... Derwyn Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Migration 32 to 64 bit
On Nov 26, 2007 11:04 AM, Giuseppe Ravasio [EMAIL PROTECTED] wrote: Hi, I'm planning the migration of our main cyrus server. Actually the server is running cyrus imap 2.2.3 on a SuSE 9.1 i586, with about 130Gb of mailboxes. My idea is moving to OpenSuse 10.3 with cyrus 2.3.8 on 64bit System. I googled a bit, but i couldn't find anything useful; i would like to know if there are issues moving from 32bit to 64bit and/or moving from 2.2.3 to 2.3.8 In particular i would like to minimize users impact, preserving mailstores, subscriptions and all seen status. Any hints/comments/precautions??? The rule of thumb is: copy all the data and try if it works (on a testing system) , and look in the log file for error messages ! If it don't work, solve problems one by one. Some thinks to take care: - the new features on 2.3.8 you want to use, or the changes you want to make for yourself. - change of the directory hashing. - Their is a lot of db : man imapd.conf | grep db * some of them can be forgotten, and will be recreated at first start like duplicate_db, tlscache_db * other could be migrated silently or don't need migration (maybe all skiplist files) * other will require a dump on the old system and the use of an intermediate file format before to be restored on the new one. (probably most of the berkeley db files). Use ctl_mboxlist for mailboxes.db and try cvt_cyrusdb with flat format for others. * to know the db format you use for any files, look for defaul in man imapd.conf, check if you overwritten it in your imapd.conf and get confirmation using file utility. Regards Thanks G.Ravasio Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html -- Alain Spineux aspineux gmail com May the sources be with you Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Vacation
Hello, i'm answering on this thread because it is the most recent one and I have the same problem like many other people here with vacation and sieve. I found this thread: http://www.imc.org/ietf-mta-filters/mail-archive/msg00898.html about vacation working if localpart of reveivers emailaddress is in upper case. I tried it (:addresses [[EMAIL PROTECTED],]) and it worked. The mail from vacation then has also a From:[EMAIL PROTECTED] sender address with localpart in upper case. The question is, at which part of the email workflow does this conversion take place? I use sendmail as MTA, and the configuration for local mail delivery is as follows: define(`confLOCAL_MAILER', `cyrusv2') define(`CYRUSV2_MAILER_ARGS', `FILE /var/run/cyrus/socket/lmtp')dnl MAILER(`cyrusv2') Is this a sendmail or a cyrus (configuration) issue? Kind Regards, Holger Haas FreiNet Gesellschaft fuer Informationsdienste mbH Loerracher Strasse 5a, D-79115 Freiburg Telefon: +49-761-496-1700, Fax: +49-761-496-1790 http://www.freinet.de Registergericht AG Freiburg i. Br. - HRB 4758 Geschaeftsfuehrung: Manfred Neufang USt-Id-Nr.:DE142316038 - FA Freiburg Stadt - Steuernummer 06425/40959 Sparkasse Freiburg-Noerdlicher Breisgau - BLZ 680 501 01 - Konto 10105414 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: OpenLDAP search base/cyrus admin dn/DIT layout.
On 26 Nov 2007, at 05:49, Lauro Costa G. Borges wrote: the cyrus admin dn bind succeeds but saslauthd complains about having two DN's matching the UID attribute (remember I have copies of the user entries for the moodle service, since each moodle installation has/can see -only- the users using that moodle install Perhaps remove permission for uid=cyrus,ou=people,... to see ou=moodle. (It doesn't seem to me that ou=moodle belongs under ou=people, but that doesn't really solve your problem.) :wes Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Murder in replicated mode
On Sat, Nov 24, 2007 at 07:58:03PM -0500, Wesley Craig wrote: On 24 Nov 2007, at 11:05, Diego Woitasen wrote: I didn't put these lines because rh-cluster1 is the master server. I have only two machines, rh-cluster1 (master) and rh-cluster2 (slave). Is really necessary that rh-cluster1 mupdate_server parameter point to itself? I'll try that on Monday, but don't make sense for me. I can see why it wouldn't make sense. However, the imapd process doesn't know it should communicate changes to the mupdate master unless you have those lines configured. :wes Good point :) It's working now. I will publish the results of my testing in a few days. I can't find to much information about this setup. Regards diegows -- -- Diego Woitasen Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: LARGE single-system Cyrus installs?
Note that ext3 effectively does the same thing as ZFS on fsync() - because the journal layer is block based and does no know which block belongs to which file, the entire journal must be applied to the filesystem to achieve the expected fsync() symantics (at least, with data=ordered, it does). Well, does not know which block belongs to which file sounds weird. :) With data=ordered, the journal holds only metadata. If you fsync() a file, ordered means that ext3 syncs the data blocks first (with no overhead, just like any other filesystem, of course it knows what blocks to write), then the journal. Now, yes, the journal possibly contains metadata updates for other files too, and the ordered semantics requires the data blocks of those files to be synced as well, before the journal sync. I'm not sure if a fsync() flushes the whole journal or just up to the point it's necessary (that is, up to the last update on the file you're fsync()ing). The ext3 journalling layer only knows about blocks. When using data=ordered, only metadata *blocks* are tracked by the journalling layer. The journalling layer does not know which data blocks correspond to which metadata block, so everything is forced out. Most other journalling file systems operate within the filesystem abstraction, and journal atomic filesystem operations, which leaves them better able to implemented sane fsync() symantics. data=writeback is what some (most) other journalled filesystems do. Metadata updates are allowed to hit the disk _before_ data updates. So, on fsync(), the FS writes all data blocks (still required by fsync() semantics), then the journal (or part of it), but if updates of other files metadata are included in the journal sync, there's not need to write the corresponding data blocks. They'll be written later, and they'll hit the disk _after_ the metadata changes. This is possible because those other journals operate at the filesystem, not block level. If power fails in between, you can have a file whose size/time is updated, but contents not. That's the problem with data=writeback, but it should be noted that's pretty normal for other journalled filesystems, too. It applies only to files that were not fsync()'ed. And, in this case, you're no worse off than you would have been with a traditional filesystem such as UFS. I think that if you're running into performance problems, and your system is doing a lot of fsync(), data=orderer is the worst option. You're assuming fsync() behaviour changes with the other data= options - have you looked into it? I'm wary because the ext3 guys have a long history of simply not getting what fsync() is for, what it's supposed to do, and why it's important. I recently asked Andrew Morton whether fsync() behaviour changed with data= options, but he couldn't remember, and I haven't had time to look into it myself. data=journal is fsync()-friendly in one sense, it does write *everything* out, but in one nice sequential (thus extremely fast) shot. Later, data blocks will be written again to the right places. It doubles the I/O bandwith requirements, but if you have a lot of bandwidth, it may be a win. We're talking sequential write bandwidth, which is hardly a problem. This is true, right up until the point you fill the journal... 8-) data=writeback is fsync() friendly in the sense that it writes only the data blocks of the fsync()'ed file plus (all) metadata. It's the lowest overhead option. If you have a heavy sustained write traffic _and_ lots of fsync()'s, then data=writeback may be the only option. I think some people are scared by data=writeback, but they don't realize it's just what other journalled FS do. I'm not familiar with ReiserFS, it think it's metadata-only as well. Certainly data journalling is the exception, rather than the rule. Off the top of my head, I can't think of another mainstream filesystem that does it (aside from the various log-structured filesystems such as Waffle and Reiser4). data=ordered is good, for general purpose systems. For any application that uses fsync(), it's useless overhead. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Murder in replicated mode
On 26 Nov 2007, at 20:31, Diego Woitasen wrote: It's working now. I will publish the results of my testing in a few days. I can't find to much information about this setup. Yours is the first site that I've encountered with that particular setup. I like it :) Especially for a small site. Cyrus would be improved if cyrus sync was easy to deploy in a similar way, i.e., with two servers total. I'd really like it if the smallest Cyrus system could automatically include replication of all data. :wes Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: LARGE single-system Cyrus installs?
Certainly data journalling is the exception, rather than the rule. Off the top of my head, I can't think of another mainstream filesystem that does it (aside from the various log-structured filesystems such as Waffle and Reiser4). AFAIK you get it with UFS + gjournal, dunno if that counts as main stream though :) Gjournal sounds like it's block level, like ext3, so would suffer the same sorts of shortcomings in this application. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/ Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: LARGE single-system Cyrus installs?
On Tue, 27 Nov 2007, Andrew McNamara wrote: Certainly data journalling is the exception, rather than the rule. Off the top of my head, I can't think of another mainstream filesystem that does it (aside from the various log-structured filesystems such as Waffle and Reiser4). AFAIK you get it with UFS + gjournal, dunno if that counts as main stream though :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
