Re: Funding Cyrus High Availability
On Thu, 2004-09-16 at 18:56 -0400, Ken Murchison wrote: I think this would cause performance to suffer greatly. I think what we want is lazy replication, where the client gets instant results from the machine its connected to, and the replication is done in the background. I believe this is what David's implementation does. Question: Are people looking at this as both redundancy and performance, or just redundance? There has to be some balance between the two, of course. What exactly would that balance be? A while back I had some ideas of lazy replication between geographically separate nodes in a mail cluster, to solve a problem that a customer was having. I think I posted something on this very list back then. There was some research, but the costs involved in actually implementing the thing were too big, and the time to do it was too short. The idea was to get rid of the single-master structure of Murder, and have an assymetric structure where each node in the mail cluster can act as primary for one or several domains, and as secondary for one or several domains, at the same time. Synchronization could flow in either direction. Each domain would have one primary server and some number of secondary servers -- redundancy could be increased by adding slaves and performance could be increased by placing them close to users in the network topology. Placing slaves in a geographically remote location would act as a sort of hot backup -- if one server breaks then you just replace it and let it synchronize with an available replica. Basically, think DNS here, and add the ability to inject messages at any node. Let's say you have five servers and three offices (customers) -- you'd set up one server in your own facilities, one server in a co-location facility, and one server in each of your customers' facilities. You configure the server in your network -- which acts as a kind of administration point -- and in the co-location network to handle all domains and each server in the customers' facilities to handle mail only for their domain(s). You then create domains and mailboxes on the server close to you in the network topology. The mailboxes will be lazy- replicated to the correct locations. Using suitable DNS records, you can have mail delivered directly to each customer's server, and it would lazy-replicate to your servers. Your servers would act as MX backups when the customer's network is down, and the mail would be lazy- replicated to them when they reappear on the network. Also, you could support dial-up users by having them connect to the co-located server instead of having to open firewalls etc. to the customer's network, which is potentially behind a much slower link. So to answer your question, I believe that by selecting a suitable structure, you could actually address both performance and redundancy at the same time. (Although I realize I've broadened the terms beyond what you probably meant originally.) In any case, I'd be willing to join the fundraising, but before that I'd like to see an exact specification of what is actually being implemented. I imagine that the specification could be drafted here on this list, put somewhere on the web along with the fundraising details, and we'd go from there. Cheers, -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Anyone using Linux LVM with cyrus?
On Tue, 2003-02-04 at 20:08, Ben Poliakoff wrote: Hi all, We're preparing to roll out a new cyrus mail system which will handle the bulk of our 1700 users' email. The server platform will be redhat linux 7.3 or 8.0. We'd like to use the Linux LVM (at the very least for the mail store itself) so that we can back up the system off of read only snapshots (courtesy of LVM). Has anyone out there used LVM with cyrus imap in an environment as large or larger than 1700 users? If so we'd love to hear about any lessons learned (i.e. Don't do it!) or gotchas... We decided to use EVMS instead of LVM for one customer's system, because in our opinion, it is more flexible, easy to use for administrators (mainly due to its GUI) and it proved to be a very reliable piece of software (by which I do not imply that LVM isn't). The tools are well designed, consistent, and they do what you expect them to do. There's a GUI, an ncurses-based interface, and a command line tool that is very well suited to scripting. We have an automatic 7-day rotating snapshot system and have already saved some important mails that were accidentally deleted by careless users (would you believe that in Outlook Express you can irreversibly delete a folder with its contents without even seeing a confirmation dialog?). We also have virus scanning and spam filtering in the same box. The hardware is a 1GHz PIII, 512MB of RAM and two 40GB IDE disks in a RAID-1 mirror as data store. The mailstore and snapshots are on the same disks -- thus the snapshots are also RAIDed. We use ext3 as file system, although we are looking very closely at the other journaling filesystems available for Linux at the moment. The user base of this customer is not as large as yours, though, but given this experience we're definately going to move our other customers to this setup as well. I'd say with appropriate hardware to back it up, EVMS would definately by up to the task. Cheers, -- Fabian Fagerholm [EMAIL PROTECTED] paniq.net
Re: When users delete mail, I want it to be moved to Trash.
On Mon, 2002-10-21 at 23:08, Erik Enge wrote: Remove the appropriate flags from the appropriate mailboxes. I understand that I can do this, but it will only work by side-effect. Ie. it will only work because most of the clients move the mail to the Trash folder when you hit delete. Some don't, however, and I would like not to loose sleep over them. (Figuratively speaking, of course.) What about introducing an ACL flag that would control the ability to expunge? (e) Many email clients have a hide deleted messages option. Thus, deleted messages would disappear from view, but you would be able to bring them back easily. Not being able to expunge would ensure that they are never removed from disk. Cheers, Fabian
Re: When users delete mail, I want it to be moved to Trash.
On Mon, 2002-10-21 at 22:13, Erik Enge wrote: [...] With Cyrus, this does not seem to be the case. It's my data and it's my hardware and still I cannot tell the users how I want business to be conducted on my systems. I think this is a bug. Cyrus should let me hook into it in some way so that I can use it in ways the authors never expected me to. The source code is available, just go ahead and implement whatever you like. I cannot believe this (no-delete) is not the policy for most corporate users of Cyrus. For legal and other reasons, keeping mail around is vital. Are you kidding? Most legal concerns are with *keeping* deleted data *deleted*. A number of corporate clients have been asking for an expiring filesystem that would automatically and permanently erase files older than a certain time. You could be doing your users major harm by not keeping what they deleted, deleted. Not to mention that you could be violating a number of laws, depending on where you live. Configuring all the clients (Outlook, Outlook Express, Gnus, Mozilla, KMail and Evolution) to move stuff into Trash whenever it is deleted (which not all of them do by default - and some even EXPUNGE by default) turns into a major administration hassle. If you have to maintain workstations for a number of users, you should set a client policy - ie. you should choose a client that works for you. If you want to let the users choose, then the responsibility is theirs. I want to hinder the users in deleting the mail from the server. Is that such an unreasonable request? Remove the appropriate flags from the appropriate mailboxes. You can make a Perl script that logs in for each user and sets the flags as you like them. I suspect your users will soon complain loudly, however. Instead of trying to do strange things and redefining the Delete function in your users' clients, you should teach your users not to press Delete when they don't mean to. Then, have fresh backups available. Cheers, Fabian
