Re: Backup strategy for large mailbox stores
a) iSCSI doesn't automatically mean SATA - virtually all iSCSI enclosures on the market will accept either SAS or SATA. SAS and SATA were designed that way. b) iSCSI *can* add a bunch of latency, but not necessarily. It depends on what's doing the iSCSI processing. Higher-end 1GbE and 10GbE cards do iSCSI processing in "silicon". On 2/19/2010 10:06 AM, Vincent Fox wrote: > You're the first person I've read using iSCSI though doesn't > that add a bunch of latency? And 7200 RPM SATA to boot. -- Phil Brutsche p...@optimumdata.com 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: Performance and cheap storage
Greg A. Woods wrote: > That's good to hear! Thanks for the refs. No prob, just note that they are substantial $$$ compared to an FC card (you're not saving any money with these babies) and those are the only 2 that have any aspirations of supporting anything outside of Windows - there is a third 10G card available that is decidedly Windows only. > I'd be more inclined to think the QLogic card will be supported in > *BSD systems sooner than the Adaptec. That is my assessment as well. -- Phil Brutsche [EMAIL PROTECTED] Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Performance and cheap storage
Greg A. Woods wrote: > not yet in smart controllers that simply make it look like a more > traditional storage device thus off-loading all the protocol handling > to a dedicated control processor I should point out that those controllers exist, but are rare and have limited OS support: Adaptec's 7211C gigabit iSCSI HBAs (http://www.adaptec.com/en-US/products/iscsi/) or QLogic's QLA4050C iSCSI HBA (http://qlogic.com/products/iscsi_products_hba.asp), for example. BTW, like most of Adaptec's other controllers the 7211[CF] is effectively Windows-only, and the QLogic controller is very likely too new to work with most platforms Cyrus runs on. It's not that the QLogic card won't ever work with (say) FreeBSD, it's that FreeBSD's driver's most likely aren't up-to-date enough to work with the card at this point. Without one of those cards iSCSI is a CPU hog. Sadly, a second CPU (or an upgrade to dual-core CPU) is cheaper... -- Phil Brutsche [EMAIL PROTECTED] Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: hardware recommendations for MURDER?
Vincent Fox wrote: > My personal leaning is towards Sun hardware with RHEL4 but I wanted > to get some fresh opinions. Thought this topic worth a rehash since > 2004 data is useful but not current enough IMO. RHEL5 is "just" around the corner (it's due for release in 6 mo). It's something I would wait for if I could... >> (sun just announce a 3u dual proc 16G ram box with 24TB of disk >> space for ~$70k for example) Hrm, yes, the Sun Fire X4500. A 4U system BTW. Problem is, it's SATA only - no SCSI/SAS. It would make a fine file server, but for an email system for 50k users? If *I* was looking at Sun I would go for some X4100s or X4200s for the back-ends and some X4100s for the front-ends. I wouldn't get the X2100s - they're cheap, but they don't have redundant power. That's a dealbreaker. Unfortunately Sun makes you pay a substantial premium for dual core CPUs... I would use either the StorageTek 3320 or the StorageTek 3510 for my storage requirements - the former is SCSI-attached, the other is fiber-channel. Both are 2U chassis that will accept up to 12 U320 SCSI hard drives. > I admit a fear of multi-terabyte filesystems and their long check > times when things go south. Perhaps there is some configuration of > this that is safe? Modern systems with journaling file systems don't need a fsck on an unclean shutdown - you have more problems with the integrity of your data than the integrity of the metadata. ext3 is perfectly safe, but you better make darn sure you use the 'sync' mount option with XFS or JFS, otherwise they'll eat your data on an unclean shutdown. Since you mention you're going with RHEL4 it's a moot point - the only supported journaling FS is ext3 ;) -- Phil Brutsche [EMAIL PROTECTED] Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: hardware recommendations for MURDER?
Vincent Fox wrote: > So lt looks like we are migrating our University to a murder setup. > We are about 50,000+ users, with currently a number of mailstores > (UWash) and users directly addressing them. > > We are looking towards adding new hardware for an MUPDATE box and > some frontends. Anyone have recommendations on these? Sparc/Solaris > versus X86/Linux? single-CPU versus duals? storage? > > I poked around in the mailing lists, didn't find anything really > current. And we all know how our users email usage has gone up in the > last couple of years. For the servers themselves I would go Linux on x86 using the hardware vendor of your choice. The back-ends would probably be better off with dual CPUs, but keep in mind that those will be *dual-core* dual-CPU systems. Go with an AMD Opteron or Intel 5100-series Xeon if you can, they'll give you better performance than the older stuff. It goes without saying that the disks should be SCSI/SAS, but the direct-attached SCSI vs SAN debate depends on how much ucdavis is willing to spend. IMO if you go with an iSCSI SAN you should definitely get a second physical CPU in each backend - without an iSCSI accelerator card like the Adaptec 7211C it's a CPU hog if you have heavy I/O, and accelerator cards that work outside of Windows are pretty rare. I don't imagine the front-ends would do a whole lot of heavy lifting, so a single CPU will be fine, but a dual-core CPU would be great if you're going to enable SSL. OS-wise I would go with RedHat Enterprise or Novell's SuSE Enterprise, but if you are more of a *BSD guy that will work as well. -- Phil Brutsche [EMAIL PROTECTED] Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Mailstore filesystem
Søren Schimkat wrote: > Hi guys > > I'm about to migrate from Solaris with Sendmail / uw to Redhat > Enterprise Linux with Postfix / Cyrus. Everything seems to work just > fine, but one unsolved question remains: Which filesystem should I choose? > > I really would like to use ext3 .. because it's works great and seems > rock solid, but i'm scareed shitless of inode starvation. Any thoughts > on that one? > > Which filesystem would you recomend? ext3, hands down. It's rock-solid and well-tested and won't eat the *entire* FS after a crash (*cough* ReiserFS *cough*) The real biggie... it won't eat your mail spool if you have an unexpected crash (*cough* XFS, JFS, ReiserFS without journaled data *cough*) IMO inode starvation is a non-issue with ext3, or any other file system for that matter. We have a 100GB RAID5 (5x 36GB) for our mail spool containing approx 65GB of data and approx 5.9 million messages (well, really 3.9 million once you count the single-instance message store)... our disk space is being used up faster than the FS inodes. -- Phil Brutsche [EMAIL PROTECTED] Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: HOWTO: Mailbox Restore
Wil Cooley wrote: > On Fri, 2005-09-16 at 10:25 +0200, Dawid van Wyngaard wrote: > > >>Got it figured out. All my NNN. files lost the "." at the end of the file >>for some or other reason. Simply rename the existing NNN to NNN. and then >>doing a reconstruct it works. > > > That's bizarre. Which filesystem is this, ext3? The software doing the backup and restore may have stripped off the periods. -- Phil Brutsche [EMAIL PROTECTED] Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Duplicated messages in INBOX
[EMAIL PROTECTED] wrote: > I was hired for updating the server, i choosed Fedora and Cyrus; now > the problem is that from time to time, some users download the same > messages again (because they are not old enough to being deleted) so, > that way, they got the same message more than twice. Outlook doesn't like the POP3 UID values generated by Cyrus. I'm afraid that outside of dumping Outlook for something else there isn't anything that can be done about it. IIRC Outlook Express suffers from a similar affliction. > I've tried to move them to IMAP, i configured a cron to delete > automatically all messages from server they are 10 days old (0 0 * * > * /usr/lib/cyrus-imapd/ipurge -X -f -d 10) But, a new problem raised, > it's when the server deletes the messages, it's been deleted in the > IMAP client too. The idea, is remain a copy in the IMAP client, but > being deleted from the server. Any suggestion for this very special > case? That is the way IMAP works. They deleted messages on POP3 server to reclaim disk space since a copy of the message was stored on the email client. Since *all* messages are stored on the IMAP server you don't need to delete anything. Removing the cron job to purge 10-day old messages will partially solve this problem. Getting your client to think in terms of server-side mail storage will be the rest of the solution. -- Phil Brutsche [EMAIL PROTECTED] --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Backend-storage on NFS?
Sten Fredriksson wrote: Would it still be "big no no" if back ends store their mail on NFS mounted storage but not sharing and use some sort of heartbeat (keepalived / heatbeat etc) to take over the ip and mount up the storage. Or is NFS even if not sharing mail storage is not supported and/or recommended at all? In my understanding NFS has been big a "big no no" period - precisely because of the reason addressed in the RH patch. RH may have the patch, but that doesn't mean the patch has been accepted into the mainline kernel or has been pulled into SuSE's kernel, or that NFS behavior is client- and server- specific. It just might work with sufficiently-patched RHEL systems... but that doesn't mean anything for Solaris, *BSD, or any other OS that supports NFS. Hence the advice that "NFS is a big no no" in the FAQ. It really doesn't matter if a single machine is using the volume or multiple machines are using the volume - the file locking mmap()/read()/write() combinations still don't work correctly. You still end up with a corrupted mail store requiring the use of 'reconstruct'. -- Phil Brutsche [EMAIL PROTECTED] --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Backend-storage on NFS?
Natalino Picone wrote: What about using GFS instead of NFS ? I think this will make you able to aggregate disks on different servers into which you should hold the cyrus spool. [...] While you could theoretically share the volumes between 2 (or more) computers directly for active/active failover, you run into many of the same problems as with NFS (mmap not working right over the cluster file system, etc). It would also require the use of the pre-alpha Cyrus IMAP 2.3 code. GFS is exactly the sort of thing I had in mind when I said "cluster file system". There is still no guarantee it will work - the various file locking and mmap()/read()/write() combinations Cyrus uses need to work right regardless of what the underlying file system is - UFS vs ext3 vs NFS vs GFS vs whatever else you can name. Various people have tried different clustering file systems from different vendors, and most of them have run into problems with locking and mmap()/read()/write(). Check the list archives. Really, this has been covered several times in the past. Check the list archives. -- Phil Brutsche [EMAIL PROTECTED] --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Outlook Express and IMAP folders
Aleksandar Milivojevic wrote:
> In Outlook Express, folder for storing sent email is hard coded as top
> level folder "Sent Items". User can not change it.
The folder name *can* be changed:
Tools -> Accounts... -> Select mail account ->
Click "Properties" button -> Select "IMAP" tab ->
Enter folder name for "Sent Items"
However, the folder you use for your sent mail ("Sent Items" is the
default) *must* be a top-level folder, period, regardless of whether you
have altnamespace and/or unixheirarchysep enabled.
--
Phil Brutsche
[EMAIL PROTECTED]
---
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Outlook Express, Cyrus, and altnamespace
Aleksandar Milivojevic wrote: > Question. Is enabling altnamespace the only way to fully support > Outlook Express clients? Yes. Note that you will need to set "allowallsubscribe: yes" in imapd.conf if you want any hope of accessing shared folders from OE and some versions of Outlook. -- Phil Brutsche [EMAIL PROTECTED] --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: imap scalability
Andrew Morgan wrote: > Wasn't there an entry in the Cyrus Wiki at one point for a list of the > current hardware configs that people were using with Cyrus? I can't seem > to find it now... http://acs-wiki.andrew.cmu.edu/twiki/bin/view/Cyrus/SampleCyrusHardware -- Phil Brutsche [EMAIL PROTECTED] --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Migrating Cyrus-IMAP to a different server?
Jordi Pallares wrote: Hy, I've try to use it too but i have a lot of errors like this "Message contains invalid header" and the message don't pass to the cyrus. There are corrupted messages in the source data store. What are you doing with it? I had to edit the mailboxes manually :( (I was migrating from UW-IMAP to Cyrus at the time) -- Phil Brutsche [EMAIL PROTECTED] --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Remote User's SMTP relay authorization
Kendrick Vargas wrote: The only problem you might have with "on the road" is that ISP's tend to block outbound port 25 access, and rightly so, to avoid worm/virus/spam propagation. I got around that by setting up an alternate SMTP port which is different from the default of 25 (like 1025, or 2025, etc..) which ONLY does SMTP AUTH relay. RFC 2476 defines port 587 as a message submission port for such occasions. -- Phil Brutsche [EMAIL PROTECTED] --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Performance question...
Etienne Goyer wrote: First, you need DB4.2 if you have anything SMP or multithreaded :) Ok, this is getting interesting. Are there known with db3 on SMP system? We use the stock db3 rpm from RedHat 7.3 (3.3.11) on an SMP machine, and we seem to have database corruption problem on mailboxes.db. It's probably related to why hmh uses skiplist for mailboxes.db in his Debian packages of Cyrus 2.1, and why Rob Siemborski recommends skiplist for the mailbox and seen state databases, as he notes in the Wiki: http://acs-wiki.andrew.cmu.edu/twiki/bin/view/Cyrus/WhatDatabaseBackend -- Phil Brutsche [EMAIL PROTECTED] --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Authentication error SOLVED
Christiano Anderson wrote: Hey guys, I've finally found out the problem, and believe, it's really a bug, either of Cyrus or SASL 2. [...] But it's a bug, and it must be fixed ASAP. The bug is in LDAP, and the fix is OpenLDAP 2.1 (as a Debian 3.0 user - like me - you have OpenLDAP 2.0). The version of OpenLDAP you are using is linked against an older (and binary incompatible) SASL, and won't compile with a newer version. OpenLDAP 2.1 works with SASL 2.1 and is confirmed (by me and others, check the list archives) to fix the problem. I've tried both using SASL via PAM and via LDAP direcly. Same problem. I don't know why that problem happens. There is no an appearant cause. Basically, you have: Cyrus 2.1 -> SASL 2.1 -> OpenLDAP 2.0 -> SASL 1.5 -> segmentation fault. -- Phil Brutsche [EMAIL PROTECTED]
Re: Postfix, SASL/SASL2 and LDAP
Diego Rivera wrote: My question is: am I totally screwed? Will I be forced to go to OpenLDAP 2.1.X and recompile EVERYTHING that touches LDAP (especially hoping that 2.1.X is backward-compatible with 2.0.X)? You're not the only person to get bitten by this (nss_ldap uses OpenLDAP 2.0 which uses SASL 1.x, which causes segfaults in anything using SASL 2.1). Note this comment from README.Debian.gz, from the Cyrus IMAP 2.1.x Debian packages: o "The Debian libldap2 and cyrus-imapd packages are both compiled using the SASL library. If you use cyrus-imapd together with libnss-ldap, or saslauthd together with libpam-ldap, the resulting double calls to SASL library functions can trigger a double-free bug which may cause the calling process to crash. To avoid such a crash, you must recompile the libldap2 package --without-cyrus-sasl." -- http://bugs.debian.org/145766 [EMAIL PROTECTED] I didn't expect SASL 2.1 to still have this annoying problem] My understanding of the situation is that you have 2 options: 1) Upgrade to OpenLDAP 2.1 which uses SASL 2.1 2) Re-compile OpenLDAP 2.0 to not link against SASL Either way you'll need to maintain custom binaries. Option 1 definitely works, but is a non-trivial change. Option 2 may the easier of the two for you. -- Phil Brutsche [EMAIL PROTECTED]
Re: Huge Inbox
Jules Agee wrote: You didn't say what platform you're using... if you are running Cyrus with the mailstore on a traditional UFS or ext3 filesystem you might start seeing the filesystem become a bottleneck if a single mailbox has a lot of messages. I have found that setting "noatime" in the file system mount options makes a big difference. -- Phil Brutsche [EMAIL PROTECTED]
Re: PostgreSQL backend: a waste of time?
Noll Janos wrote: Hy! I think that's a very good idea, but we found that MySQL is much faster than Postgres, when there are no complex queries (this is the case here), so it might be a better idea to use MySQL. Or better yet, support both. Some people already use a SQL database (Postgres, in my case) and don't want to waste time trying to learn & set up another. A weird, maybe even stupid idea: if Nicola is going to "port" the patch to another database, port it to unixODBC. -- Phil Brutsche [EMAIL PROTECTED]
Re: add user script?
Tarjei Huse wrote:
> Hi,
>
> does anyone have a simple {add|delete}-user script that adds/deletes a user
> to/from cyrus-imapd? I need something to start with. Just a script that adds a
> user mailbox and maybe other default mailboxes.
I have a perl script seems does the job for me. Note that I use this with
Cyrus 2.1.x. I have a separate Tcl script if you happen to use 1.5.x or 1.6.x.
It assumes that perl is /usr/bin/perl, and that "unixhierarchysep: no" is in
imapd.conf.
Don't forget to change the variables $adminuser, $adminpw, and $server at
the beginning of the script to reflect your configuration.
Use it like this:
"cyrus-users.pl list" will list the users in the system
"cyrus-users.pl add " will add the specified user's INBOX, and
create a few default mailboxes.
I haven't gotten to the point where I need to delete a user, but it
shouldn't be too hard to add that.
It can be downloaded from http://www.optimumdata.com/~phil/cyrus-users.pl.
--
Phil Brutsche
[EMAIL PROTECTED]
