(Illustration by Gaich Muramatsu)
Greetings! I'm presently evaluating Coda for production use in an ISP-like environment. I know the, erm, slightly elderly Coda website does not recommend this. I also get the impression from the list I wouldn't be the first to disregard that warning. I've spent some time getting up to speed with Coda and deploying it on my home network, but it's clear I'm not going to be able to develop a comprehensive understanding very quickly. Time is precious though, and I'm still uncertain whether I should commit to this solution or cut my losses and try something else. I'm prepared for a few headaches, what I'm worried about are the potential show-stoppers that I might not be seeing. I'd sure appreciate any input the list can offer. We would like to replicate the mailboxes and web folders for up to roughly 33,000 users. (The initial requirements would be 1/10 - 1/100 of that.) There will be two hosts acting as mail servers, and two acting as web servers. The "secondary host" of each pair will serve as coda servers. It's my understanding that the maildir mailbox format is generally recommended for delivering to network filesystems, though there are gotchas on Coda because of the lack of inter-directory hard links. So, there's a sort of de facto standard for maildir on Coda that just assumes coda will make rename instead of link-and-unlink safe. Is maildir still the state of the art? I think there are other one-file-per-message formats. Are they more likely to generate collisions and conflicts on Coda? What maildir delivery and mailbox software is known to follow the de facto standard? If I have to test a new package, what actions use cross folder links, according to the spec? Does the server ever do this, even, or is it strictly a mailreader issue? Also, has anyone hacked gnu's nnmaildir module to work with coda yet? (That's just for me. I moved all my email onto a coda volume. It took many hours, and now it's darn well staying there. ;-) ) We will have two servers accepting mail from the Internet. We would like to have complete redundancy, so rather than having the secondary server just hang onto mail until the primary server comes back up, we'd like it to deliver any mail it gets right to the shared maildirs. That way users can still get to email that comes in during an outage of the primary server. Is this a completely stupid idea? Will it "just work" or am I going to have to do some hacking? Lastly (for now), we pretty much have to avoid exposing coda conflicts to the end user. I'm still shaky on manual conflict resolution, so it's really unclear to me whether or not it will be possible to take care of conflicts via policies, or some other mechanism. The manual suggests conflict resolution can be automated for some cases, but it seems rather vague about it. It seems to me that, so long as I can make sure there cannot be multiple mailreaders active on the same volume but on different hosts, there is no possibility of a conflict, no matter what the (assumedly sane) mail delivery agents may do. Is this so? The other conflict scenario I see is when the user attempts to update their web folder from both hosts at the same time, or (more likely) wants to run a .cgi which modifies files in their volume. I'm a bit concerned about this one. My initial idea to work around this possibility is a simple priority policy. The conflicting change owned by the greatest userid is automatically selected to resolve the conflict. This would allow a user to easily manually refresh a file that a .cgi is also meanwhile updating, so long as all the server processes clog in to a low userid. I could possibly also give the secondary servers higher uids than the primaries. However, it seems to cause as many problems as it solves, and beside that, I haven't got the first idea yet how to add an automated resolution policy. Am I misguided to try to hide conflicts from the users? There's no way I could expose them to 'cfs' and 'repair', are there any more friendly (preferably web interface-providing) packages for examining and manually resolving conflicts? I guess that's all I can burden the list with so far. I hope I haven't used up my grace. I realize a lot of these topics have probably already been covered more than once. Responses need not cover every detail, I just want a little reassurance that what I'm attempting isn't begging for problems. Thanks a lot! Mike.Received on 2004-04-27 13:35:12