Re: ACLs and such
On Wed, Feb 05, 2003 at 07:47:45PM -0500, Rob Siemborski wrote: So, Offhand, I think the rest of your mail is to special purpose for general use, but I'll address this part of it, since its been brought up before. At least the ability to automatically spread folders across several partitions depending on their names can contribute to performance. Part of the design of cyrus includes the assumption that it's a bigger helpdesk headache when users blow away their own acls (and lose access) than it is if they are actually held bound to them. Therefore, within a user's mailbox hierarchy, you cannot remove full rights for that user. This is a very good point, though it took me some time to understand it. I didn't realize that I cannot remove the 'a' flag from ACLs of user.* mailboxes for their owners. But I can still achieve what I want by creating an 'archives' hierarchy outside the 'user' hierarchy. With permissions set correctly, it's at least even more clear to the users what the archives-stuff is about. BTW, which IMAP clients or other programs are out there that allow users to easily edit their ACLs? A webclient to just set ACLs would also be ok. It would be *very* nice if I could tell our users to set the permissions they want on their mailfolders all on their own :) There are various arguments against this, and I think the final decision was that we look at an implicit rights patch, whereby admins could specify what rights their users had on their mailboxes implicitly (and I seem to remember Ken even made one), but I can't locate it right now. Ken? So this provides control over what rights are inherited? Sounds good :) GH
Re: Anyone using Linux LVM with cyrus?
On Thu, Feb 06, 2003 at 08:42:00AM +0100, Simon Matter wrote: - Hardware IDE Raid: Most so called hardware RAID are simply software RAID, because the driver from the vendor does software RAID. Those driver are often binary only and they do RAID worse than the Linux MD driver does it. Until you want to go with true hardware RAID like 3ware, stay away from it. Ja, I will. For one thing, it's not an option to rely on drivers supplied by the vendor, as you might suddenly get stuck without any driver at all as soon as a kernel update or something like that is neccessary. Well, 3ware seems to be what most ppl recommend. For another thing, I'm very reluctant with trusting any IDE hardware RAID. Before building on it, I definitely want to see that it actually works. - I've been using LVM on top of software RAID0,1,5. I've been told that the RAID function built in in LVM is not as good as Linux MD, YMMV. hm This sounds a bit overdone to me, but if it's better to use both tools, why not :) - XFS on top of LVM/MD is very cool because you can grow volumes and filesystems on the fully operating server. In fact, growing XFS can only be done online. XFS is a nice FS, but once I tried it and managed to damage some data. It was probably my own fault, but I'm still a bit, hm, afraid of using it. Otoh, I'd prefer XFS over reiserfs --- I don't like reiserfs for no relevant reason, just a personal dislike. Unfortunately there were some issues with snapshotting with XFS. Snapshotting? What's that? - ext3 on top of LVM/MD works well too. Snapshotting works well. Growing filesystems have to be done offline. There are tools to grow online, but this is dangerous. Growing could be done offline, but I doubt that it'll ever be needed. The server may end up with about 15 million files on a 100 or 120 GB partition at the time it is running out of disk space. My intention was to use ext3 on that partition, but considering the large number of files, I begin to doubt that ext3 is a good choice. What do you guys think? GH
informing users about quotas
Hi, how can users securely be informed about their quota usage? It seems to be left to the clients to ignore or to not ignore the warnings from cyrus. Unfortunately, the mozilla client ignores the warnings, and incoming mail would be silently rejected once the user is over quota. Is there a tool (for cyrus 1.5.x as comes with Debian Woody) that could be run by cron to send the users who are about to reach their quota limit a warning message? GH
ACLs and such
Hi, can I set quotas and ACLs for a user named 'test' like the following ... cm user.test cm user.test.archives otherpartition sq user.test 100 sq user.test.archives 1000 sam user.test.archives test lrswipca ... and nevertheless allow user 'test' to delete mails and folders residing under user.test.archives by default? The point is that the user must not be able to delete his 'archives' folder, but he must be able to freely operate on anything that resides within that folder. The purpose of this is to force users to automatically and transparently move old mail to another partition that physically resides on cheap IDE disks, but to have all mail that's accessed more frequently stored on fast SCSI disks. This would allow to run the server without relevant storage limitations while keeping up excellent performance at relatively low costs. Another approach would be an option to specify by regular expressions that folders with certain names (like 'archive.*') are always created on certain partitions. A more sophisticated implementation of that would additionally allow to specify certain levels of how deeply folders are nested in the hierarchy to decide on what partition the folder is physically stored. Just like that in /etc/imapd.conf: defaultpartition: default partition-default: /var/spool/cyrus/mail partition-newpart: /data-1/newpart foldername-newpart: *archive.* partition-nesting: /data-2/nesting nestlevel-nesting: 5 Thereby, user.test would reside on /var/spool/cyrus/mail, user.test.archive would go to /data-1/newpart, and anything nested deeper than five folders is put to /data-2/nesting. Maybe even a combination of nameing and nesting would be nice, though I currently can't see its practical use. Hm, this could be especially interesting in environments that handle larger numbers of users: partition-usera: /data/usera foldername-usera: user.a* partition-userb: /data/userb foldername-userb: user.b* # ... and so on Further extend this to use some other storage method than direct file-system access, like networked access to another server ... At least, allow to store mails redundantly on a number of partitions for backup purposes or for keeping a cluster of servers in sync :) GH
Re: creating user-mailboxes without cyradm
On Mon, Jan 27, 2003 at 12:28:56PM -0500, Ken Murchison wrote: is there a way to create INBOXes for users by IMAP-commands Sure, read RFC 2060. You'd do tag CREATE user/username How is this dealt with in respect to security and reliability? Just write a script that logs in and automatically creates mailboxes from randomly generated (user-) names until the storage is full. That's sort of making DOS attacks utterly easy. GH
Re: creating user-mailboxes without cyradm
On Wed, Feb 05, 2003 at 02:13:55PM -0500, Rob Siemborski wrote: How is this dealt with in respect to security and reliability? Only admins can do this for any username, there is a config option that allows authenticated users to do this for their own mailbox, but no others. Ah! THX, I've tried it now and found it working as it should :) full. That's sort of making DOS attacks utterly easy. If your admins are trying to DOS you, you've got bigger problems. Well, I'm always using the latest lart from cvs, in a prophylactic manner ;) GH
Re: Anyone using Linux LVM with cyrus?
On Wed, Feb 05, 2003 at 04:36:03PM -0400, Patrick Boutilier wrote: We are using LVM to give the ability to add disk space and expand our reiserfs when necessary. Is it possible to add disc space with ext3fs and LVM, too? We are using LVM on top of hardware RAID 5 so as long as 2 disks don't fail at once we should be OK. Hm, sounds nice :) To be more specific, what I've in mind is a setup like that, for 60--100 users: + 18 or 36 GB SCSI: system itselfe and about 20--25 GB /var for incoming/outgoing mail (incl. virus scanning) and the more actively used part of the cyrus mail store, quota of about 100 MB/user or 10 GB shared by the user.* hierarchy on it + 120 GB IDE to keep another cyrus mail store partition (archive) Users should move older mail from the default partition to the archive. Some shared folders will probably reside on the IDE discs, too. The archives will provide a quota of 1 GB/user. Two identical 120 GB IDE discs should be used to keep and mirror the archive. The SCSI disc should be mirrored also (at least the /var partition), though I'm not sure yet whether it's better to use a second SCSI disc for that or if it's a good idea to divide the IDEs into partitions of 100 GB and 20 GB each, so that the SCSI disc can be mirrored to the 20 GB partitions on the IDEs. Daily backups will probably be done to another 120 GB IDE disc. I'll use ext3fs for all partitions --- reiserfs or even xfs may have advantages, but I like ext3 more, and the expected number of files that have to be handled should be still ok for ext3. Is this a reasonable setup, and can it reliably be done with LVM? Or is it better to use raidtools2 for it? Or would you suggest to use hardware IDE RAID instead, maybe by forgoing SCSI? Any suggestions are appreciated --- I don't know how flexible LVM can make things, so a totally different setup might be even better. GH
