Re: Testing
Pong
Re: compiling error - cannot find -lssl
On Tuesday 18 February 2003 17:39 pm, Mike O'Rourke wrote: Hi Mark, Sorry to be jumping in so late, but I have been busy with LDAP, et.al. Did you compile SASL2 on your machine? If not, did you install it from the RPM's? RedHat (even as late as 8.0) only installs SASLv1 by default. You are trying to use SASLv1 to compile Cyrus-IMAPd 2.1.11! Try installing SASLv2 from the RPM's, if you do not care to download and compile it as well. Not so with 8.0: [root@director1 root]# cat /etc/redhat-release Red Hat Linux release 8.0 (Psyche) [root@director1 root]# [root@director1 root]# rpm -qa|grep sasl cyrus-sasl-2.1.7-2 cyrus-sasl-devel-2.1.7-2 cyrus-sasl-md5-2.1.7-2 cyrus-sasl-plain-2.1.7-2 To my knowledge the v1 RPMS aren't included with the 8.0 distro anymore. As to your original problem, again you need to tip your hat to the kind folks at RedHat. The default install does not install the static libraries for OpenSSL. So, unless you have explicitely installed the static libraries (I am not even sure they are available on the disks), if you look in /usr/lib, you will find only libssl.so, libssl.so.0.9.6b and the libcrypto.so.0.9.6b files. Hence, -lssl finds no static libraries to link to, and chokes. Mike. Same machine: [root@director1 root]# ls -l /usr/lib/*ssl* -rw-r--r-- 1 root root 281772 Aug 6 2002 /usr/lib/libssl.a lrwxrwxrwx 1 root root 26 Nov 8 07:16 /usr/lib/libssl.so - ../../lib/libssl.so.0.9.6b This is a rather default Server install, I can't say what a Workstation install is like. Dunno what Mark's root problem is, just wanted to share the above tidbits... Jeremy
Re: imapd's hang when maxchild count is reached
On Thursday 06 February 2003 12:10 pm, Henrique de Moraes Holschuh wrote: On Thu, 06 Feb 2003, Dave McMurtrie wrote: Would this actually work anyway? If the parent were to pass a file You can send descriptors over sockets if your unix kernel supports it. Linux does, and apparently so does Solaris. Anyway, I dislike the idea of losing preforks heavily, it is bound to be a major pain when the system is overloaded. The send descriptors idea would also allow a prefork. I would also agree that the one connection per child idea is out the door. One other idea, could it be portable enought to say, initialize a semaphore and set the resource count on it to the maximum number of connections. If a child accepts a connection, it will first have to gain the semaphore resource first. If it fails (all the semaphore resources are taken), then the child would know that the maximum number of connections has been exceeded and return an error to the connecting party. I did read an old Bugzilla entry that said fully threading imapd and friends was an idea... Don't know if that has any affect on any future direction. I haven't worked with semaphores for a long while so I could be talking outta my arse :). Jeremy
Re: imapd's hang when maxchild count is reached
Hmmm... what does Sendmail do? It's got lots of children, but still manages to refuse connections when it gets busy (RefuseLA)... I kinda like that behavior. I definitely like it better than keeping more and more sockets open. -- Stephen L. Ulmer [EMAIL PROTECTED] Senior Systems Programmer http://www.ulmer.org/ Northeast Regional Data Center VOX: (352) 392-2061 University of Florida FAX: (352) 392-9440 It may not prefork it's processes. The master process could accept the connection, fork, closes the socket (the child is now servicing it), and go back into a listen state. Therefore the master process can choose to reject connections without any coordination from the children. Children then have a service life of one connection and that's it. They could also use a technique where a master process can pass file (socket) descriptors down to a child via a unix domain socket using sendmsg() or recvmsg(). In this case the master accepts the connection, passes the descriptor to a child via sendmsg(), closes the socket (the child should now be servicing it), and goes back to listening. Either way, in the above, the master process is the only process that actually accepts the connections. I'm not sure how sendmail actually does it though, the above is purely speculation... Jeremy
Re: Problem with cyrus and deleting a message with a virus.
On Tuesday 21 January 2003 16:58 pm, Will Day wrote: A short time ago, at a computer terminal not so far away, Mark London wrote: If you're messing around with the internal data stores of a program, and then you get upset when the program doesn't work, I'd say that you've created your own problem. I'm not messing with it, uvscan is doing it. Is there a better software alternative that will delete viruses on the server? Are we the only people using cyrus that are running virus scanning software on the server? We're using Cyrus and doing virus scanning (with uvscan in fact), but we do it from the MTA, before it reaches cyrus (using Anomy as content-filter in postfix). Yes, amavis-new also will do this and is uvscan compatible. http://www.ijs.si/software/amavisd/ Cheers, Jeremy
Re: Latest on Cyrus and GFS?
On Friday 17 January 2003 16:59 pm, [EMAIL PROTECTED] wrote: A Murder allows segmentation (for most purposes) of the mailboxes.db, which is the single-most-contended-for resource in Cyrus (as far as I can tell). The problem that *isn't* addresses is availability of each IMAP back-end. We're hoping to use IBM's HACMP for this, I think that there is a Linux-ish, scriptable-takeover-on-hearbeat-failure hooya, though I don't know what it is called. Hi there, I think what you are talking about with that scriptable-takeover-on-heartbeat-failre is actually heartbeat itself available at linux-ha.org :) Regards A more HACMPish solution would be Kimberlite: http://oss.missioncriticallinux.com/projects/kimberlite/
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
On Tuesday 14 January 2003 23:36 pm, Igor Brezac wrote: Jeremy, This stuff looks great and with a limited user sample (10) the performance improvement was almost 100 fold. Keep in mind, this is my first crack at it. I am using Solaris 9. I am getting the following error # ./saslcache -s could not attach shared memory segment: 1200 shmat: Invalid argument It is likely I need to adjust shared memory params. I'll let you know what I find. One more note, can you make the changes against the cvs version? -Igor Ok, I've set things up on a Solaris 8 machine for testing. After a few tweaks, things appear to be working ok. One thing though, it seems that the maximum shared memory segment size on Solaris is 1M by default. Solaris users will have to tweak their system settings if a larger cache is desired. Due to this, I've set the default cache size to under 1M (down from ~4M). This way saslauthd will always start with the cache enabled under default circumstances. Changes at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-2.patch Or fully patched source at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-2.tar.gz I'll work on getting a diff against current cvs as well Thanks, Jeremy
Re: [PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
Thanks, excellent feedback. I've been busy coding away all day. I'm not quite ready for another realease, but I thought I'd drop a line with some of the mods I'm making (they're pretty major). The biggie: cache_lookup() writes the user-provided password hash into the hash table BEFORE it is verfied. There's now a race where an attacker can submit an arbitrary string as a password, (if there's currently an entry in the cache, it will be evicted), then while the real lookup is happening he'll try a second authentication, which will succeed if cache_purge has not yet been called. I think I have a general problem with cache_lookup writing to the hash table, I'd expect lookup to be a read-only operation. If it fails, we do a lookup to the backend anyway, and then only if we SUCCEED in that lookup do we write the good password to the table. Round 3 now has: cache_lookup() cache_commit() cache_discard() Another important one: No locking of any kind is used on the shared memory segment. I'm not sure this is directly exploitable, but it could give odd behavior. Let's assume that we've fixed the above problem. Now we have a cache_write() (that looks similar to the writing portion of the current cache_lookup()) instead of a cache_purge(). If two processes are in cache_write at the same time, there's a race where they could both pick the same block to evict, and the result could be some mangled combination of both (or one or the other, but not both). Take this for instance (we assume that we had two cache misses, and that we only have one processor): . ... There clearly needs to be some sort of semaphore on the table (or on entries, or something). I've put in a first attempt at per bucket level locking via fcntl(). The only thing left to consider is if we should acquire a lock when the stats counters are updated. I'm not sure if the perf difference would be worth some inaccuracies in the hits/misses/attempts counters. Wasn't this originally going to use libmm? My knowledge on libmm is brief (quick reading today), Saslauthd already depends on fcntl() being there natively. If I understand correctly, libmm only does shm segment level locking. I'm not sure what the perf differences would be between per bucket level locking via fcntl() and table level locking via fcntl(). Since fcntl() is required by saslauthd, I went with per bucket level locking. libmm introduces another dependency (including autconf checks), unless libmm would be distributed with the saslauthd package. I originally thought it beneficial to keep any additional dependencies down if a good alternative could be presented. Plus, all in all, it sounded pretty challenging. Haven't done any hard core coding in awhile :). Finally: I think shared memory is way overkill for the doors version, since it all takes place within one process. Though, we'd still need to use some sort of councurrancy control. -Rob Yes, I've started to addresses this to. I've broken out the memory allocation so that the unix IPC method will use a shared memory segment, while the doors IPC method would stick with a malloc'd segment. The doors IPC method will retain the fcntl() based locking for the malloc'd segment. I have some reading up to do on doors IPC (is it thread based?). -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper Thanks, Jeremy
[PATCH][saslauthd] cyrus-sasl-2.1.10/saslauthd credential caching
All, I've been working on combining some of the ideas for a credential caching layer into saslauthd. This is the first release for review/comments/testing. Changes: Three files have been added to the saslauthd package: cache.c cache.h README.cache saslcache.c Four files have been modified Makefile.am Makefile.in saslauthd-doors.c saslauthd-unix.c The saslauthd executable now accepts three new command line switches. -c Enables the credential cache -s Sets the size of the credential cache in kilobytes -t Sets the timeout of items in the credential cache in seconds A show_usage() function has been added that dumps all possible options out when an invalid command line switch is found: ./saslauthd: invalid option -- - usage: saslauthd [options] option information: -a authmech Selects the authentication mechanism to use. -c Enable credential caching. -d Enables debugging, run in the foreground. -O optionOptional argument to pass to the authentication mechanism. -m path Alternate path for the mux socket, must be absolute. -n threads Number of worker threads to create -s kilobytes Size of the credential cache (in kilobytes) -t seconds Timeout for items in the credential cache (in seconds) -T Honor time-of-day login restrictions. -v Display version information and available authentication mechanisms and exit. The caching layer caches the username, realm, service, and an md5 hash of the passwords for all authentication mechanisms (LDAP, rimap, PAM, etc). It's been tested it on RedHat 7.2 Alpha and RedHat 7.3 Intel. I've also only been able to compile the modifications using the unix IPC option (saslauthd-unix.c). The same modifications have been made to the doors IPC option (saslauthd-doors.c), but have not been compiled or tested. More detailed information about the cache is in the README.cache file. In addition to testsaslauthd, a second utility is included, saslcache. The saslcache utility can be used to attach to the shared memory segment and perform various tasks. The saslcache utility can be built by: cd saslauthd make saslcache Usage examples: ./saslcache -s dumps out some information about the cache Saslauthd Cache Detail: timeout (seconds) : 28800 total slots allocated : 3643 slots in use: 3 total buckets : 21858 buckets per slot: 6 buckets in use : 3 hash table size (bytes) : 2098536 bucket size (bytes) : 96 minimum slot allocation : 0 maximum slot allocation : 1 slots at maximum allocation : 3 slots at minimum allocation : 3640 overall hash table load : 0.00 hits* : 19 misses* : 3 total lookup attempts* : 22 hit ratio* : 86.36 * May not be completely accurate ./saslcache -d dumps the contents of the cache in a csv format user,realm,service,created,created_localtime m3,,imap,1042513583,Mon Jan 13 22:06:23 2003 m2,,imap,1042513256,Mon Jan 13 22:00:56 2003 m1,,imap,1042513355,Mon Jan 13 22:02:35 2003 ./saslcache -f purges/deletes all entries in the cache 21858 entries purged Todo: Test the doors IPC stuff. Test on alternate OSs (only linux so far) Have someone help with the autoconf stuff. I'm not very familiar with autoconf and modeled the modifications after those for testsaslauthd. I'm not sure if they're entirely correct. For testing one should probably run saslauthd with the -d switch. The cache will log information to syslog (LOG_INFO|LOG_AUTH). Optionally, one could use the saslcache utility. Log Example: saslauthd[27772]: cache_lookup: user=m2 realm= service=imap: not found, entry created saslauthd[27772]: OK: user=m2 service=imap realm= saslauthd[27772]: cache_lookup: user=m2 realm= service=imap: found with valid passwd saslauthd[27772]: OK: user=m2 service=imap realm= saslauthd[20673]: cache_lookup: user=m2 realm= service=imap: found with invalid passwd, passwd synced saslauthd[20673]: cache_purge : prior lookup purged saslauthd[20673]: AUTHFAIL: user=m2 service=imap realm= Anyhow, if anyone wants to give it a whirl. Here's a first patch attempt against cyrus-sasl-2.1.10: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-1.patch Or, a fully patched tar of cyrus-sasl-2.1.10 at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-sasl/cyrus-sasl-2.1.10-cache-1.tar.gz Feedback welcome... Cheers, Jeremy
Re: saslauthd performance anxiety
This whole idea sounds great, especially as I'd expect a lot of the authentication load to come from a small number of users with their clients set to check mail every few minutes. For debugging it would help if there was a way to force a flush of the entire cache, and one to dump its contents. I'm not sure how you'd get saslauthd to recognise maintenance commands like this - maybe some method of out-of-band signalling, which seems better than tinkering with the socket protocol. -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand How about SIGUSR1 and SIGUSR2? Cheers, Jeremy
Re: saslauthd performance anxiety
I always hashed the password as soon as they entered the cache. So the checkpoint dump would contain binary MD5, SHA hashes etc. They're not clear text per say, but I can see why some would not find even that ideal. Cheers, Jeremy On Friday 10 January 2003 11:07 am, Paul M Fleming wrote: Personally I have issues with dumping the contents of a password cache to a file. Especially in this case, they WILL be stored in cleartext. I had planned on keeping somes stats (hits,misses,etc) Jeremy Rumpf wrote: This whole idea sounds great, especially as I'd expect a lot of the authentication load to come from a small number of users with their clients set to check mail every few minutes. For debugging it would help if there was a way to force a flush of the entire cache, and one to dump its contents. I'm not sure how you'd get saslauthd to recognise maintenance commands like this - maybe some method of out-of-band signalling, which seems better than tinkering with the socket protocol. -- Simon Brady mailto:[EMAIL PROTECTED] ITS Technical Services University of Otago, Dunedin, New Zealand How about SIGUSR1 and SIGUSR2? Cheers, Jeremy
Re: saslauthd performance anxiety
On Thursday 09 January 2003 03:55 pm, Paul M Fleming wrote: Timing out the passwords is simple ( I think ) I would store the time when the entry is added and force a reauth if the password has been cached longer than a timeout (for example one hour ). That forces a reauth at least every timeout period of time. If an entry isn't in the cache (or if it is different the entry would be removed and ) a reauth would be forced. Every successfull auth would be added to the cache. Some time ago I wrote a plugin for the Netscape/iPlanet Directory server that intercepted bind authentications and passed them off to a kerberos backend. It allowed us to integrate LDAP services with our Kerberos environment. Anyhow, it implemented just this, with the timeouts and all. I also implemented a checkpoint feature where the hash table was periodically dumped to a file. That way if you restarted the LDAP server you wouldn't lose you're cached entries. You can grab a copy of the plugin at: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/krbdirp-1.2.0.tar.gz Look in the file krbdirp.c, specifically at the function validate_with_cache(). The text file CACHE also has some thoughts and ideas. The LDAP directory was used for an iPlanet mail setup to store user information. The idea of the credential cache has worked quite well. Implementing it for saslauthd would be a nice feature. I'd be more than willing to help/contribute to the effort. Cheers, Jeremy
[PATCH] master -C command line option
All,
I've come across a need to be able to specify the configuration file (default
of /etc/cyrus.conf) to the master process when starting it.
As of cyrus 2.1.11 it appears that imapd and friends all accept the command
line option of -C for specifying an alternate configuration file. Master
though, only uses the hardcoded configuration file in masterconf.c.
Attached is a patch that implements the -C command line option for the master
process.
master -C /path/to/cyrus.conf
Questions, comments, flames welcome...
Cheers,
Jeremy
diff -ur cyrus-imapd-2.1.11.orig/master/master.c cyrus-imapd-2.1.11/master/master.c
--- cyrus-imapd-2.1.11.orig/master/master.c 2002-11-01 11:44:33.0 -0500
+++ cyrus-imapd-2.1.11/master/master.c 2003-01-07 22:10:24.0 -0500
@@ -1205,7 +1205,7 @@
p = getenv(CYRUS_VERBOSE);
if (p) verbose = atoi(p) + 1;
-while ((opt = getopt(argc, argv, l:D)) != EOF) {
+while ((opt = getopt(argc, argv, l:DC:)) != EOF) {
switch (opt) {
case 'l': /* user defined listen queue backlog */
listen_queue_backlog = atoi(optarg);
@@ -1213,6 +1213,9 @@
case 'D':
close_std = 0;
break;
+ case 'C':
+ masterconf_set_filename(optarg);
+ break;
default:
break;
}
diff -ur cyrus-imapd-2.1.11.orig/master/masterconf.c cyrus-imapd-2.1.11/master/masterconf.c
--- cyrus-imapd-2.1.11.orig/master/masterconf.c 2002-11-06 15:43:31.0 -0500
+++ cyrus-imapd-2.1.11/master/masterconf.c 2003-01-07 22:19:21.0 -0500
@@ -60,6 +60,8 @@
#define CONFIG_FILENAME /etc/cyrus.conf
+static char *config_filename = NULL;
+
struct configlist {
char *key;
char *value;
@@ -71,6 +73,11 @@
{
openlog(ident, LOG_PID, LOG_LOCAL6);
+if (config_filename == NULL) {
+if ((config_filename = strdup(CONFIG_FILENAME)) == NULL)
+fatal(masterconf_init: memory allocation failed for: config_filename, EX_CONFIG);
+}
+
return 0;
}
@@ -79,6 +86,17 @@
int lineno;
};
+void masterconf_set_filename(const char *filename)
+{
+if (config_filename != NULL) {
+free(config_filename);
+config_filename = NULL;
+}
+
+if ((config_filename = strdup(filename)) == NULL)
+fatal(masterconf_set_filename: memory allocation failed for: config_filename, EX_CONFIG);
+}
+
const char *masterconf_getstring(struct entry *e, const char *key,
const char *def)
{
@@ -101,7 +119,7 @@
}
if (*p != '') {
sprintf(k, configuration file %s: missing \ on line %d,
- CONFIG_FILENAME, e-lineno);
+ config_filename, e-lineno);
fatal(k, EX_CONFIG);
}
} else {
@@ -197,10 +215,10 @@
int lineno = 0;
char buf[4096];
-infile = fopen(CONFIG_FILENAME, r);
+infile = fopen(config_filename, r);
if (!infile) {
snprintf(buf, sizeof(buf), can't open configuration file %s: %s,
- CONFIG_FILENAME, strerror(errno));
+ config_filename, strerror(errno));
fatal(buf, EX_CONFIG);
}
diff -ur cyrus-imapd-2.1.11.orig/master/masterconf.h cyrus-imapd-2.1.11/master/masterconf.h
--- cyrus-imapd-2.1.11.orig/master/masterconf.h 2000-05-23 16:56:30.0 -0400
+++ cyrus-imapd-2.1.11/master/masterconf.h 2003-01-07 21:32:53.0 -0500
@@ -46,6 +46,8 @@
extern int masterconf_init(const char *ident);
+extern void masterconf_set_filename(const char *filename);
+
struct entry;
extern const char *masterconf_getstring(struct entry *e,
Re: cyradm headache
On Wednesday 18 December 2002 11:20 am, Jorge Merlino wrote: I installed Cyrus IMAP to use it with Postfix. My problem is that the authentication with the sasldb database doesn't seems to work. When I run cyradm localhost y can type any string as the password and I get the prompt, but if I try to execute cm I get a Permission denied error. I'm including here a copy of my imapd.conf file where I set sasldb as the password checking method. The sasldb file itselfs seems to be correct (according to sasldblistusers) and the cyrus user is able to read and write it. I'll appreciate any help about this issue. TIA, Jorge This is making a few assumptions (such as your using cyrus 2.1.x), but above you listed sasldblistusers. Are you using /etc/sasldb instead of /etc/sasldb2 or sasldblistusers instead of sasldblistusers2. Also run cyradm like this: cyradm --user cyrus --server localhost --auth CRAM-MD5 imapd.conf: configdirectory: /var/imap partition-default: /var/spool/imap admins: cyrus allowanonymouslogin: no autocreatequota: 1 reject8bit: no quotawarn: 90 timeout: 30 poptimeout: 10 dracinterval: 0 drachost: localhost sasl_pwcheck_method: sasldb
Re: Slow LIST command
Cyrus doesn't do anything to increase the BDB cache size, and the default (256 kB) is way too small for any reasonably large site. With some 5 mailboxes and random operations, I found the hit rate for default BDB cache to be 70-80%. After growing the cache size to 2M, hit rate approached 99% and disk traffic was greatly reduced since most of the operations are reads anyway. Therefore processes could complete their work and release their locks much more quickly, and the dreaded DBERROR: xxx lockers messages stayed at a comfortable level. Out of sheer curiosity. I'm assuming the skiplist backend also uses an in core cache as well? If so, is it also tuneable or does it dynamically extend itself? Cheers, Jeremy
Re: using Murder for migration from UW IMAP
On Monday 09 December 2002 23:10 pm, John A. Tamplin wrote: Quoting Jeremy Rumpf [EMAIL PROTECTED]: You might also want to consider using the perdition IMAP/Pop3 proxy. It's well suited for something like this since it can use LDAP, MySQL, PostreSQL, and local GDBM databases to lookup the real server for users. http://www.vergenet.net/linux/perdition/ Thanks for the pointer. Do you have a suggestion for an LMTP proxy that might use the same back-end database? Not off hand, you can use Postfix's transport maps to kind of fake being an LMTP proxy. That would require you to put another MTA hop in the mix, or replace your boarder MTAs with postfix. I'm not sure how your layout is, but postfix + LDAP can do some pretty nifty things when it comes to mail routing (I'm sure other MTAs can as well, but I'm mostly fluent with postfix). From postfix's perspective, one address could be delivered via LMTP to a Cyrus mail backend, while another address can be SMTP delievered to another MTA running on a UW IMAP backend. Routing can be switched on the fly by updating the LDAP entry. I kind of describe what I'm talking about in this post: http://asg.web.cmu.edu/archive/message.php?mailbox=archive.info-cyrussearchterm=perditionmsg=17997 I have plans to wrap this up into a more formal howto, but haven't found the time yet. If you have any other questions/ideas, feel free to ask. Cheers, Jeremy
Re: using Murder for migration from UW IMAP
On Monday 09 December 2002 06:37 pm, John Alton Tamplin wrote: Would it be possible to use Murder to migrate from UW IMAP? I have Cyrus setup and running on a new machine, but the problem is that taking everything down and converting all the mailboxes would be too much downtime (2-3 days). What I was thinking of is setting up a frontend server with UW IMAP and Cyrus as the backend servers, with the initial mupdated database showing all the mailboxes were on the old IMAP server. UW IMAP isn't going to talk to mupdated, but if no mailboxes are being created there it seems like that won't matter. As each mailbox is moved to the new server, the master list of mailboxes is reflected to update the new location. From my inspection of the documentation and some of the code, it looks like this should work with a couple of caveats (during the transition, users have to be prevented from creating new mailboxes -- this can be hacked in the code, and connections that have been referred to the old server have to be broken when the mailbox is transferred). Does anyone see a reason why this won't work or any other gotchas to watch for? Thanks. You might also want to consider using the perdition IMAP/Pop3 proxy. It's well suited for something like this since it can use LDAP, MySQL, PostreSQL, and local GDBM databases to lookup the real server for users. http://www.vergenet.net/linux/perdition/ Cheers, Jeremy
Re: Newbie help: Domain names as part of user names/mailboxes/etc?
But imapd, by default, uses dots as separators. So I can't just do: createmailbox [EMAIL PROTECTED] because that ends up looking like mailbox jay@jay with sub-mailbox fm. And I can't just: createmailbox jay because I must authenticate as [EMAIL PROTECTED] and not just jay. I realize that I could use unixhierarchysep, and I probably will end up doing so anyway, but I suspect that there is a simpler answer I'm not seeing. I've tried setting unixhierarchysep is your answer for the mailbox question. Enable that and then do: createmailbox [EMAIL PROTECTED] As far as sasl, it usually sets the default realm to the hostname of the machine it's running on. So [EMAIL PROTECTED] probably get's authenticated as [EMAIL PROTECTED]@linux.home.jay.fm So when you create the user in sasldb: saslpasswd2 -c [EMAIL PROTECTED] and it will fill in the realm with @linux.home.jay.fm. If cyrus is running on the same machine, it should default the realm to be @linux.home.jay.fm as well. sasldblistusers2 should give you something like: [EMAIL PROTECTED]@linux.home.jay.fm: userPassword [EMAIL PROTECTED]: cmusaslsecretOTP HTH, Jeremy
Re: Cyrus IMAPd 2.1.10 Released
On Thursday 14 November 2002 14:43 pm, Scott Russell wrote: On Thu, Nov 14, 2002 at 02:35:02PM -0500, Lawrence Greenfield wrote: Date: Thu, 14 Nov 2002 10:56:07 -0500 From: Scott Russell [EMAIL PROTECTED] [...] Sooo... any reason why the docs aren't sgml and then built for text, html, ps, etc? Think of this as less of a request and more of 'would CMU be interested' type question. :) No objections, but it's one of those things of is it worth creating more dependencies versus the current very simple htmlstrip and html files. At one point I converted some of the files to XHTML and that process will probably continue slowly. If someone has a good idea of how to make the documentation easier to deal with, we're all for it. I'm not sure it would be easier. It's question of maintaining sgml docbook sources vs xhtml/html sources. The theoretical advantage is that the sgml/docbook tools are plentiful and easily exported to other formats. It might also be a good motivation for me to get learning docbook/sgml :) Last night I had some spare time, so I docbookafied a chapter in the CMU doc directory. Admittedly, I didn't spend much time on it and didn't use some of the more intricate features of docbook, but I thought it would be something as an example. The content is taken verbatim from the install-compile text file. A pdf generated output (from the docbook2pdf tool in RH 7.3) can be viewed here: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-docs/cyrus-imapd-manual.pdf The docbook source can be grabbed from here: ftp://ftp.net.ohio-state.edu/pub/users/jrumpf/cyrus-docs/cyrus-docs.tar.gz Cheers, Jeremy
Re: cyrus-sasl-2.1.x compile under redehat8.0
On Sunday 10 November 2002 07:08 pm, aa wrote: hello, I have to install cyrus-sasl-2.1.7/9 on my redhat 8.0 But default is installed cyrus-sasl-2.1.7 with rpm's i can not removed the rpm's to much dependence. if i compile cyrus-sasl-2.1.9 on that system the makefile installed all under /usr/local/lib/sasl2 (normal) but i need sometimes a symlink to /usr/lib/sasl2 on /usr/lib/sasl2 is installed my cyrus-sasl-rpm's Please, could any say what i have to do ? I need cyrus-sasl and cyrus-imapd-2.1.x with authmethod pam (plain) I would use cyrus with lookup-tables in Mysql-db over pam thank's a lot for any Informations and help's Best wishes Achim You should be able to compile cyrus-sasl-2.1.9 over the redhat RPM and have it work. Or you could try removing the RPM compile/install 2.1.9 and if it doesn't work, reinstall the 2.1.7 RPM. I believe the redhat RPM is compiled with something equivalent to --prefix=/usr (you can verify with the SRPM). The other option, would be to leave 2.1.9 installed into /usr/local/lib and modify your startup scripts in init.d to do this before you launch any of the applications: export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH That will cause the linker to look in /usr/local/lib _before_ /usr/lib and should find the 2.1.9 libraries before the 2.1.7 libraries. When you symlink /usr/lib/sasl2 to /usr/local/lib/sasl2 above, what you're actually doing is using the sasl 2.1.7 library with the sasl 2.1.9 modules. Your 2.1.7 library is /usr/lib/libsasl2.so and its modules are in /usr/lib/sasl2. As well, your 2.1.9 library is /usr/local/lib/libsasl2.so and its modules are in /usr/local/lib/sasl2. There will also be further issues with saslauthd. I wouldn't really keep two copies around, especially since you'll be using a common auth method (ie pam), but the choice is yours. You can experiement with each, but make a backup first :). Something like this should compile you a package like redhat's with what you want, but I can't guarantee it since I haven't personally done it. ./configure --enable-static --with-pic --enable-shared --disable-java --with-plugindir=/usr/lib/sasl2 --disable-krb4 --enable-gssapi=/usr/kerberos --with-rc4 --with-dblib=berkeley --with-saslauthd=/var/run/saslauthd --without-pwcheck --enable-anon --enable-cram --enable-digest --enable-plain --enable-login --prefix=/usr --sysconfdir=/etc --with-pam Cheers, Jeremy
Re: posting troubles
Any suggestions on the second part of my question - is there a utility to take the qpopper mail file and feed it to cyrus so the mail ends up in the cyrus mailbox system ? Jens YMMV, http://dannyman.toldme.com/warez/mbox2cyrus
Re: how many users can Cyrus server support? -- is 5.5 msg/sec sl ow?
Do you really think that you run into performance problems with 25 msg/sec ? Do you _really_ think that 25 msg/sec is so bad ? 25 msg/sec times 60 are 1500 msg/min times 60 are 9 msg/hour times 24 are 216 msg/day ! Do you really think that your machine will have to handle over 2 million messages _every_ day ? Isn't that 2 million message think more a peak value on high load situations than the approximately everyday situation ? At peak loads, not really. The MTA front ends on the system I work on route about 1.5 million messages a day. More specific, one backend server (Sun E4000), with 70k users, accepts approx 10-20 messages per second with 30 or so POP attempts per second (Qpopper, no IMAP yet). This all at peak times between 10AM and 2 or 3PM. I agree that Su isn't seeing the performance he should be getting, but I also see where he would _need_ this performance. Other alternatives for Su are out there, such as clustering IMAP back ends using either Perdition http://www.vergenet.net/linux/perdition/ or the Murder system. His use of Linux should not be a major issue.
Re: how many users can Cyrus server support? -- is 5.5 msg/sec sl ow?
On Thursday 26 September 2002 23:37 pm, Su Li wrote: Oh man! you really did a lot to improve the the performance. I will for sure need to look into lmtpd temp file. So far I don't think Sendmail is a bottle neck, may be later it will be. RAID 5 is the slowest one, if I didn't remember wrong. I am using RAID 0, with no protection at all. I think your idea of mount a temp file system is good. But I not sure how to do that on Linux. Thank you so much for your help. If I can come up with some thing new, I 'll share with every body in the mailing list too. Su RAID 0 will be faster than RAID 5. No parity, equal sriping across the drives. Best perfomance with protection would be RAID 0+1. As for tmpfs on Linux, good tutorial/article: http://www-106.ibm.com/developerworks/library/l-fs3.html Jeremy
Re: relaying with cyrus-imap
On Friday 27 September 2002 15:05 pm, Jens wrote: I am still working on my first install of cyrus on my Debian box and I am trying to get all the little wrinkles sorted out. I was under the impression that once I set up a valid login authorization (I am using auxprop/sasldb), a user could log in and both send and receive email. The receiving part works great but when trying to send, postfix denies relaying. Could somebody point into the right direction as to what I have to do to allow a user that has authenticated to relay ? I realize that this is probably a postfix question but I am trying to use it with cyrus :) Another curious thing - I keep getting kerberos4 error messages in my auth.log file. It complains about no /etc/srvtab file and that sasl_plugin_load failed for kerberos4. Since I am running debian, I use the package as provided and don't do any compilation or what not - is there any way of telling the system that I do not use kerberos4 ? Everything seems to run fine so this isn't a show stopper but it's a loose end I would like to fix. Jens Add/update these lines in /etc/postfix/mail.cf (or whereever it's stashed) smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, permit_sasl_authenticated, reject Those last two are one line. No idea about the krb4 messages. Jeremy
