Re: RPM Upgrade Nightmare
Chris Dos schrieb: > > I forgot to mention that I got the SASL rpm's from your site as well. I > installed them and everything seem to go okay. The Cyrus-SASL rpms from > RH 8.0 look to be the same as yours. > > Do you have any ideas on what would be a good way to move the mail > directories from /var/spool/imap/user to /var/spool/imap/a-z and then > have Cyrus pick them up and run with them. Or perhaps, there might be a >way to convert the data that is in /var/imap so it works correctly in > /var/lib/imap? A small script should do it. There are tools in the 2.1 distribution to do the upgrade. You should be able to just move the spool and config dirs, then you the rehash script and maybe other scripts to convert cyrus data. Check the usual upgrade docs of Cyrus IMAPd. HTH Simon > > I have about eight installations that use 2.0.16 and I'd like to be able > to come up with a smooth upgrade to I can get them to the 2.1.x series > and then just use your rpms instead of Ramiro's which haven't been > upgraded in some time. > > Chris > > Simon Matter wrote: > > Tarjei Huse schrieb: > > > >>>Boy, what a nightmare this turned out to be. > >> > >>Yep. It aint easy :) > >> > >>>I've been running the cyrus-imapd-2.0.16 rpms developed by Ramiro which > >>>can be found here: > >>>http://rmorales.modwest.com/rpms/cyrus-imapd/ > >>> > >>>and I figured it was time to upgrade to the 2.1.* series, so I got the > >>>source rpm cyrus-imapd-2.1.10-3.src.rpm developed by Simon Matter from here: > >>>http://home.teleport.ch/simix/ > >> > >>At this point, how much did you bother to read the docs and check that things were > > > > > > cyrus-sasl 2.x is needed. RPMs for RH 7.3 can be found on my webpage > > too. > > ready? I just did a similar upgrade, and I tried reading the docs, but > > still. There were a lot of hassles. Here's my tips: > > > >>a) Maybe use RH's postfix rpms to start with? I think they got sasl support, and >that seems to be your only requirement.b) Install and move your user db before you >start with Cyrus. > > > > > > Well, at least for SMTP AUTH, RedHat's rpms don't work with SASL2 > > because they didn't patch the right way. > > > > > >>c) Simon, would you mind pointing this out on your fine webpage? > >> > >>>The RPMS have a difference in where they store the config directories: > >>>2.0.16 keeps it's configs in /var/imap > >>>2.1.10-3 keeps it's configs in /var/lib/imap > > > > > > I changed some paths to comply with FHS. You're right, I may mention > > this on the webpage. > > > > > >>d) This as well: > >> > >>>And how directory structure the mails box are located: > >>>2.0.16 keeps the files under /var/spool/imap/user > >>>2.1.10-3 keeps files under /var/spool/imap/a-z > >> > >>I belive that what you need to do is to use the rehash script found in >/usr/libexec/cyrus I ran that a cuple of times (if someone might supply Chris with >the correct way to rehash that would be nice.) > >> > >> > >>>In the end, I couldn't get the new cyrus rpms to find my mail boxes. > >> > >>This is probably related to the /var/imap vs /var/lib/imap tingy. I also had a BIG >hassle with getting my different indexfiles in /var/lib/imap to work. > >> > >>I suggest you set of some time to work on that. Remember to set logging to full >when you start so you know where to look. Also read through the man pages for the >ctl_* commands found in /usr/libexec/cyrus. > >> > >>I solved my problems with the indexes by setting all to skiplist and recompiling, >but that was on RH8.0. I'm not sure, but I think you need to recompile Cyrus if you >change the db type, so be prepared for some simple .spec file hacking. > >> > >>e) > >>I do not think you need db4 for 2.1. when you use 7.3 - db3 is ok. > >> > >>I hope this might help you, > >>Tarjei > >> > >>>gave up and eventually got the old rpms working again and I needed to > >>>rebuild my database to get it to work again with db3. I'm sure I made a > >>>few mistakes along the way so I'd like to find out how to properly > >>>migrate to the new cyrus rpms. Any thoughts, hints, or ideas would be > >>>greatly appreciated. Thank you. > >>> > >>> Chris > > > >
Re: php and cyrus
I have an entire Cyrus Admin class written in PHP, as the imap functions in php do not support all that is needed on a cyrus server (quota and ACL). I am using this to admin my own cyrus server via the web.. I will post it on my sourceforge site tomorrow.. It has currently been only tested on a Cyrus 2.0.16 server, but that should make no difference as I have followed the RFCs while creating the class.. Check http://urklesphp.sourceforge.net/ tomorrow afternoon. (I'm in CST) On Mon, 2002-11-25 at 17:50, Gregory Chagnon wrote: > Hi- > Does anyone know if there is a way to create a cyrus user and mailboxes > through php? I've looked around at imap_createmailbox() but am unlcear on > how to use it. Thanks!! > -Greg > > > > > > _ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus -- Edward Rudd <[EMAIL PROTECTED]>
error making 2.1.10
After sucessfull installation I'm trying to compile 2.1.10 to avoid problems with sieve.. And with the same 'configure' I get now: (./configure --with-dbdir=/usr/local/BerkeleyDB --with-openssl=/usr ...) = make[1]: Entering directory `/usr/src/cyrus-imapd-2.1.10/perl' (cd imap; \ OPENSSL_LIB="-L/usr/lib" OPENSSL_INC="-I/usr/include" \ SASL_LIB="" SASL_INC="" CC="gcc" \ perl5 Makefile.PL PREFIX=/usr/local) /bin/sh: perl5: command not found make[1]: *** [imap/Makefile] Error 127 make[1]: Leaving directory `/usr/src/cyrus-imapd-2.1.10/perl' make: *** [all] Error 1 = When I try to point with '--with-perl=/usr/lib/perl5', it says - '..is a directory..' and so on.. What changed in configure-make since 2.1.9 ? Best regards, Andrei V. Loukinykh , Evpatoria Ukrtelecom ISP, +380 6569 29376 ~~~ "UNIX is like a vigvam - no Windows, no Gates and an Apache inside"
Re: php and cyrus
much2 easier if you use perl... then use php passthru the perl program.. ___ ORENDA Mail - http://www.orenda.com.my/
Re: php and cyrus
Here's a small attachment you can use as an include file. You can use it
as such from PHP:
$server = new IMAP_Server();
$server->createMailbox("user.whatever");
$server->deleteMailbox("user.whatever");
Both functions return true or false on success or failure (respectively).
You can edit the file and set the proper variables, or you can pass them
in when you create the object.
-peace
On Mon, 25 Nov 2002, Gregory Chagnon wrote:
> Hi-
> I tried something like that before, but I get this error:
>
> Warning: Couldn't open stream {192.168.1.200} in
> /var/www/html/user/mail2.php on line 7
>
> Any ideas? Thanks all.
> -Greg
>
>
>
>
>
>
> >From: Veigar Freyr Jökulsson <[EMAIL PROTECTED]>
> >To: "Gregory Chagnon"
> ><[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
> >Subject: Re: php and cyrus
> >Date: Tue, 26 Nov 2002 00:40:42 -
> >
> > > Hi-
> > > Does anyone know if there is a way to create a cyrus user and mailboxes
> > > through php? I've looked around at imap_createmailbox() but am unlcear
> >on
> > > how to use it. Thanks!!
> > > -Greg
> > >
> >
> >You could do something like this, $uid is the login name you want to
> >create:
> >
> > $IMAPhost = "123.123.123.123";
> > $IMAPquota = "10240",
> > $username = "cyrus";
> > $password = "password";
> > $imapconn = imap_open("{" . $IMAPhost . "}", "$username",
> >"$password",OP_HALFOPEN);
> > if ($imapconn) {
> > imap_createmailbox($imapconn, "{" . $IMAPhost .
> >"}user.".$uid ) or die("can't connect: ".imap_last_error());
> > imap_set_quota($imapconn, "user.$uid", $IMAPquota) or
> >die("can't connect: ".imap_last_error());
> > imap_close($imapconn);
> > }
> >
> >
> >--
> >Veigar Freyr Jökulsson
> >[EMAIL PROTECTED]
>
>
> _
> Tired of spam? Get advanced junk mail protection with MSN 8.
> http://join.msn.com/?page=features/junkmail
>
>
--
Let he who is without clue kiss my ass
"mail.hudat.com",
"port" => "143",
"user" => "cyrus",
"pass" => "cyradm");
var $Error = "";
function IMAP_Server ($imap_spec = "") {
if ( (! empty($imap_spec)) && is_array($imap_spec) ) {
$this->imap = $imap_spec;
}
# First thing we do is open up our stream...
$this->stream = imap_open("{" . $this->imap["host"] . ":" . $this->imap["port"]
. "}", $this->imap["user"], $this->imap["pass"], OP_HALFOPEN);
if ( $this->stream !== false ) {
return(true);
} else {
$this->Error = imap_last_error();
return(false);
}
}
function createMailbox ($mailbox) {
$existing_boxes = imap_listmailbox($this->stream, "{" . $this->imap["host"] .
":" . $this->imap["port"] . "}", imap_utf7_encode($mailbox));
if ( ! empty($existing_boxes) ) {
$this->Error = "createMailbox(): mailbox allready exists.";
return(false);
}
if ( imap_createmailbox($this->stream, imap_utf7_encode("{" .
$this->imap["host"] . ":" . $this->imap["port"] . "}" . $mailbox)) ) {
return(true);
} else {
$this->Error = imap_last_error();
return(false);
}
}
function deleteMailbox ($mailbox) {
$existing_boxes = imap_listmailbox($this->stream, "{" . $this->imap["host"] .
":" . $this->imap["port"] . "}", imap_utf7_encode($mailbox));
if ( empty($existing_boxes) ) {
$this->Error = "deleteMailbox(): mailbox does not exist.";
return(false);
}
# Now we add the delete ACL to cyrus feature...
if ( ! imap_setacl($this->stream, imap_utf7_encode($mailbox),
$this->imap["user"], "cd") ) {
$this->Error = imap_last_error();
return(false);
}
if ( imap_deletemailbox($this->stream, imap_utf7_encode("{" .
$this->imap["host"] . ":" . $this->imap["port"] . "}" . $mailbox)) ) {
return(true);
} else {
$this->Error = imap_last_error();
return(false);
}
}
}
?>
Re: php and cyrus
Hi-
I tried something like that before, but I get this error:
Warning: Couldn't open stream {192.168.1.200} in
/var/www/html/user/mail2.php on line 7
Any ideas? Thanks all.
-Greg
From: Veigar Freyr Jökulsson <[EMAIL PROTECTED]>
To: "Gregory Chagnon"
<[EMAIL PROTECTED]>,<[EMAIL PROTECTED]>
Subject: Re: php and cyrus
Date: Tue, 26 Nov 2002 00:40:42 -
> Hi-
> Does anyone know if there is a way to create a cyrus user and mailboxes
> through php? I've looked around at imap_createmailbox() but am unlcear
on
> how to use it. Thanks!!
> -Greg
>
You could do something like this, $uid is the login name you want to
create:
$IMAPhost = "123.123.123.123";
$IMAPquota = "10240",
$username = "cyrus";
$password = "password";
$imapconn = imap_open("{" . $IMAPhost . "}", "$username",
"$password",OP_HALFOPEN);
if ($imapconn) {
imap_createmailbox($imapconn, "{" . $IMAPhost .
"}user.".$uid ) or die("can't connect: ".imap_last_error());
imap_set_quota($imapconn, "user.$uid", $IMAPquota) or
die("can't connect: ".imap_last_error());
imap_close($imapconn);
}
--
Veigar Freyr Jökulsson
[EMAIL PROTECTED]
_
Tired of spam? Get advanced junk mail protection with MSN 8.
http://join.msn.com/?page=features/junkmail
Re: php and cyrus
> Hi-
> Does anyone know if there is a way to create a cyrus user and mailboxes
> through php? I've looked around at imap_createmailbox() but am unlcear on
> how to use it. Thanks!!
> -Greg
>
You could do something like this, $uid is the login name you want to create:
$IMAPhost = "123.123.123.123";
$IMAPquota = "10240",
$username = "cyrus";
$password = "password";
$imapconn = imap_open("{" . $IMAPhost . "}", "$username",
"$password",OP_HALFOPEN);
if ($imapconn) {
imap_createmailbox($imapconn, "{" . $IMAPhost .
"}user.".$uid ) or die("can't connect: ".imap_last_error());
imap_set_quota($imapconn, "user.$uid", $IMAPquota) or
die("can't connect: ".imap_last_error());
imap_close($imapconn);
}
--
Veigar Freyr Jökulsson
[EMAIL PROTECTED]
Re: RPM Upgrade Nightmare
On 25 Nov 2002 at 16:18, Chris Dos wrote about "Re: RPM Upgrade Nightmare": > Do you have any ideas on what would be a good way to move the mail > directories from /var/spool/imap/user to /var/spool/imap/a-z and then > have Cyrus pick them up and run with them. Or perhaps, there might be a > >way to convert the data that is in /var/imap so it works correctly in > > /var/lib/imap? The paths used on my packages were inherited from the packages by RH as they were based on them and meant to server as an upgrade path. > > I have about eight installations that use 2.0.16 and I'd like to be able > to come up with a smooth upgrade to I can get them to the 2.1.x series > and then just use your rpms instead of Ramiro's which haven't been > upgraded in some time. That's true, but I don't plan to update the package to the 2.[12].x series anytime soon. My IMAP server upgrade schedule is unclear yet :-/ Perhaps I will update the package to a newer release to get in some small fixes I had been taking note of, but always in the 2.0.16 upstream version. > > Chris > Regards, - Ramiro
Re: PAm authentication method no longer supported?
Stefan Suurmeijer wrote: > > Hi list, > > sorry if this was dealt with earlier, didn't see it in the archives. > > I just installed Cyrus 2.1.9 on a new box. However, when I wanted to > copy my old config (cyrus 2.0.16, running on another box), I ran into a > snag. > > I was using > > sasl_pwcheck_method: pam > > but when I try to authorize now, I get authentication errors > (imapd[3070]: unknown password verifier). When I checked the imapd.conf > manpages, I saw that the PAM method was no longer listed under the > supported mechanisms. I was able to get it working with the sasldb2, but > I'd like to keep working with PAM, as it's nicely flexible. Was support > for the PAM method removed (something to do with the new sasl version > perhaps)? If so, is there another way to get PAM working again? Check the fourth bullet on doc/upgrading.html in the SASL distro. sasl_pwcheck_method: saslauthd And run: saslauthd -a pam -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: file-system problems after update from 2.0.16 to 2.1.9
On Sun, Nov 24, 2002 at 04:52:11PM +0100, Alexander Czernay wrote: > I just upgraded my Cyrus-IMAP from 2.0.16 to 2.1.9. At ./configure I > added --enable-fulldirhash and also compiled Berkeley4.1.24 in. > > It all worked well, but now I get some strange errors in the logs: > > IOERROR: opening /var/imap/user/c/czernay.seen: No such file or directory > DBERROR: opening /var/imap/user/c/czernay.seen: cyrusdb error > Could not open seen state for czernay (System I/O error) That suggests that `--enable-fulldirhash' didn't work. Does it show up in config.status? Does `USE_DIR_FULL 1' show up in config.h? Or, perhaps some of the old commands are running? > Investigating the file-sytem I found that only directories with capital > letters exist under the /var/imap/user tree. But these are all empty! Those are correct for full directory hashing. The `rehash' script should have moved your existing mailboxes to the correct directories, if it was able to find them. Perhaps you changed the location? -- -Gary Mills--Unix Support--U of M Academic Computing and Networking-
php and cyrus
Hi- Does anyone know if there is a way to create a cyrus user and mailboxes through php? I've looked around at imap_createmailbox() but am unlcear on how to use it. Thanks!! -Greg _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
PAm authentication method no longer supported?
Hi list, sorry if this was dealt with earlier, didn't see it in the archives. I just installed Cyrus 2.1.9 on a new box. However, when I wanted to copy my old config (cyrus 2.0.16, running on another box), I ran into a snag. I was using sasl_pwcheck_method: pam but when I try to authorize now, I get authentication errors (imapd[3070]: unknown password verifier). When I checked the imapd.conf manpages, I saw that the PAM method was no longer listed under the supported mechanisms. I was able to get it working with the sasldb2, but I'd like to keep working with PAM, as it's nicely flexible. Was support for the PAM method removed (something to do with the new sasl version perhaps)? If so, is there another way to get PAM working again? Relevant data: old machine (linux, 2.4.19) cyrus-imapd-2.0.16 cyrus-sasl-1.5.27 sasl_pwcheck_method: pam (working) new machine (linux, 2.4.19) cyrus-imapd-2.1.9 cyrus-sasl2-2.1.7 sasl_pwcheck_method: pam (not working) sasl_pwcheck_method: auxprop (working with sasldb2) TIA Stefan
Re: RPM Upgrade Nightmare
I forgot to mention that I got the SASL rpm's from your site as well. I installed them and everything seem to go okay. The Cyrus-SASL rpms from RH 8.0 look to be the same as yours. Do you have any ideas on what would be a good way to move the mail directories from /var/spool/imap/user to /var/spool/imap/a-z and then have Cyrus pick them up and run with them. Or perhaps, there might be a way to convert the data that is in /var/imap so it works correctly in /var/lib/imap? I have about eight installations that use 2.0.16 and I'd like to be able to come up with a smooth upgrade to I can get them to the 2.1.x series and then just use your rpms instead of Ramiro's which haven't been upgraded in some time. Chris Simon Matter wrote: Tarjei Huse schrieb: Boy, what a nightmare this turned out to be. Yep. It aint easy :) I've been running the cyrus-imapd-2.0.16 rpms developed by Ramiro which can be found here: http://rmorales.modwest.com/rpms/cyrus-imapd/ and I figured it was time to upgrade to the 2.1.* series, so I got the source rpm cyrus-imapd-2.1.10-3.src.rpm developed by Simon Matter from here: http://home.teleport.ch/simix/ At this point, how much did you bother to read the docs and check that things were cyrus-sasl 2.x is needed. RPMs for RH 7.3 can be found on my webpage too. ready? I just did a similar upgrade, and I tried reading the docs, but still. There were a lot of hassles. Here's my tips: a) Maybe use RH's postfix rpms to start with? I think they got sasl support, and that seems to be your only requirement.b) Install and move your user db before you start with Cyrus. Well, at least for SMTP AUTH, RedHat's rpms don't work with SASL2 because they didn't patch the right way. c) Simon, would you mind pointing this out on your fine webpage? The RPMS have a difference in where they store the config directories: 2.0.16 keeps it's configs in /var/imap 2.1.10-3 keeps it's configs in /var/lib/imap I changed some paths to comply with FHS. You're right, I may mention this on the webpage. d) This as well: And how directory structure the mails box are located: 2.0.16 keeps the files under /var/spool/imap/user 2.1.10-3 keeps files under /var/spool/imap/a-z I belive that what you need to do is to use the rehash script found in /usr/libexec/cyrus I ran that a cuple of times (if someone might supply Chris with the correct way to rehash that would be nice.) In the end, I couldn't get the new cyrus rpms to find my mail boxes. This is probably related to the /var/imap vs /var/lib/imap tingy. I also had a BIG hassle with getting my different indexfiles in /var/lib/imap to work. I suggest you set of some time to work on that. Remember to set logging to full when you start so you know where to look. Also read through the man pages for the ctl_* commands found in /usr/libexec/cyrus. I solved my problems with the indexes by setting all to skiplist and recompiling, but that was on RH8.0. I'm not sure, but I think you need to recompile Cyrus if you change the db type, so be prepared for some simple .spec file hacking. e) I do not think you need db4 for 2.1. when you use 7.3 - db3 is ok. I hope this might help you, Tarjei gave up and eventually got the old rpms working again and I needed to rebuild my database to get it to work again with db3. I'm sure I made a few mistakes along the way so I'd like to find out how to properly migrate to the new cyrus rpms. Any thoughts, hints, or ideas would be greatly appreciated. Thank you. Chris
Re: Changing databases at runtime
On Mon, 25 Nov 2002, Jonathan Marsden wrote: > This probably isn't something of great utility to CMU, but for the I think you hit the nail on the head here. > average Linux sysadmin who just wants to grab an RPM or a .deb and > install it and have Cyrus "just work", upgrading as new RPMs/.debs are > released, it could be a big deal in the long run. It's in bugzilla as #1681. Like I said, I don't expect its that hard (implementation ideas in body of bug), but I don't see us jumping to finish it. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
RE: Timsieved valid commands -- Expected EOL -- sovled
I did:
PUTSCRIPT "s2" {127+}
require ["fileinto", "reject", "imapflags"]; if header :is "From"
"[EMAIL PROTECTED]" { addflag["\\Answered", "$MDSent"]; }
OK
Thanks,
Su
-Original Message-
From: Su Li
Sent: November 25, 2002 1:59 PM
To: Mark Keasling
Cc: [EMAIL PROTECTED]
Subject: RE: Timsieved valid commands -- Expected EOL
Hi Mark,
I am still working on Timsieved. I got error "Expected EOL".
GETSCRIPT "mysieve"
{127}
require ["fileinto", "reject", "imapflags"];
if header :is "From" "[EMAIL PROTECTED]"
{
addflag["\\Answered", "$MDSent"];
}
OK
PUTSCRIPT "S1" "require ["fileinto", "reject", "imapflags"]; if header :is "From"
"[EMAIL PROTECTED]" { addflag["\\Answered", "$MDSent"]; }" {127}
NO "Expected EOL"
PUTSCRIPT "S1" {127} require ["fileinto", "reject", "imapflags"]; if header :is "From"
"[EMAIL PROTECTED]" { addflag["\\Answered", "$MDSent"]; }
NO "Did not specify script data"
In my C++ program I did:
sprintf((char*) sendBuffer, "PUTSCRIPT \"%s\" \"%s\"\r\n", scriptName.c_str(),
script.c_str());
m_pConnection->Send(sendBuffer, strlen(sendBuffer));
The C++ program gave me the same result.
I wonder why other command didn't complain about "EOL", but PUTSCRIPT complains?
Thanks a lot
Su
-Original Message-
From: Mark Keasling [mailto:[EMAIL PROTECTED]]
Sent: November 19, 2002 8:54 PM
To: Su Li
Cc: [EMAIL PROTECTED]
Subject: Re: Timsieved valid commands
Hi,
On Tue, 19 Nov 2002 16:08:58 -0500, Su Li <[EMAIL PROTECTED]> wrote...
> Hi
>
> I am building a web admin server to manage the sieve filtering for Cyrus IMAP. I
>don't want to use Sieveshell. I telnet to Sieve port 2000 and did a 'AUTHENTICATE
>"PLAIN" ' command. I checked the man page of timsieved. There is not much information
>about valid commands. I am not sure how can I input my auth name and user name to be
>able to login.
>
> This is so far I got:
>
> >telnet web9 2000
>
> >Trying 10.101.85.213...
> >Connected to web9.swlab.rim.net.
> >Escape character is '^]'.
> >"IMPLEMENTATION" "Cyrus timsieved v1.1.0"
> >"SASL" "PLAIN OTP DIGEST-MD5 CRAM-MD5"
> >"SIEVE" "fileinto reject envelope vacation imapflags notify subaddress relational
>regex"
> >OK
>
> >AUTHENTICATE "PLAIN"
>
> >{0}
>
> >user "cyrus"
>
> >NO "Authentication Error"
>
> Can any body let me know the valid commands for Timsieved?
The PLAIN authentication method seems to be defined in rfc2595.txt.
The example given for ACAP in the rfc is:
C: a003 AUTHENTICATE "PLAIN" {21+}
C: timtanstaaftanstaaf
S: a003 OK CRAM-MD5 password initialized
>From this it appears that you can't use PLAIN via telnet because you can't
enter a character (at least I don't know how it would be done).
I've been able to telnet to the timsieved by enabling the LOGIN authentication
mechanism. However you'll have to be able to convert username and password to
base64 inorder to use it.
I do have C++ source for a b64echo which I can post if anyone wants it.
Sieve commands are defined in:
cyrus-imapd-x.y.z/doc/sieve-protocol.html
Regards,
Mark Keasling <[EMAIL PROTECTED]>
Changing databases at runtime
On 25 Nov 2002, Rob Siemborski writes: > On 25 Nov 2002, Erik Enge wrote: >> I wouldn't rate it as easy unless it was a config option at >> run-time, not an option to configure at compile-time. > This wouldn't be tremendously hard to do (probably just a matter of > replacing some macros with some code that is a bit more clever), but > there'd be a (small) performance penalty and there isn't really any > intrest in doing it, since converting databases shouldn't be a > common operation anyway. This is in part a packaging and upgrading issue, though. Especially when the recomended default choices for what databases within Cyrus are in what form seem to change over time, and that this may get 'worse' as new backends are implemented, the ability to build a compiled version of Cyrus that could find and use whatever database format it can see (or failing that, whatever database some separate utility can see and then edit into the config files), would probably help reduce the "I upgraded Cyrus to the latest package, and everything broke" type of posts -- which in some cases have reportedly led to users giving up on Cyrus altogether. I don't know for sure whether a simple and reliable package upgrade is worth "a (small) performance penalty" for the average user of a pre-packaged (RPM or .deb) Cyrus, but I suspect it might well be. And over time, such sites may become the majority of Cyrus installations. This probably isn't something of great utility to CMU, but for the average Linux sysadmin who just wants to grab an RPM or a .deb and install it and have Cyrus "just work", upgrading as new RPMs/.debs are released, it could be a big deal in the long run. Jonathan -- Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic 1252 Judson Street | Phone: +1 (909) 795-3877 | communications work Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian USA | http://www.xc.org/jonathan| missions worldwide
RE: Timsieved valid commands -- Expected EOL
Hi Mark,
I am still working on Timsieved. I got error "Expected EOL".
GETSCRIPT "mysieve"
{127}
require ["fileinto", "reject", "imapflags"];
if header :is "From" "[EMAIL PROTECTED]"
{
addflag["\\Answered", "$MDSent"];
}
OK
PUTSCRIPT "S1" "require ["fileinto", "reject", "imapflags"]; if header :is "From"
"[EMAIL PROTECTED]" { addflag["\\Answered", "$MDSent"]; }" {127}
NO "Expected EOL"
PUTSCRIPT "S1" {127} require ["fileinto", "reject", "imapflags"]; if header :is "From"
"[EMAIL PROTECTED]" { addflag["\\Answered", "$MDSent"]; }
NO "Did not specify script data"
In my C++ program I did:
sprintf((char*) sendBuffer, "PUTSCRIPT \"%s\" \"%s\"\r\n", scriptName.c_str(),
script.c_str());
m_pConnection->Send(sendBuffer, strlen(sendBuffer));
The C++ program gave me the same result.
I wonder why other command didn't complain about "EOL", but PUTSCRIPT complains?
Thanks a lot
Su
-Original Message-
From: Mark Keasling [mailto:[EMAIL PROTECTED]]
Sent: November 19, 2002 8:54 PM
To: Su Li
Cc: [EMAIL PROTECTED]
Subject: Re: Timsieved valid commands
Hi,
On Tue, 19 Nov 2002 16:08:58 -0500, Su Li <[EMAIL PROTECTED]> wrote...
> Hi
>
> I am building a web admin server to manage the sieve filtering for Cyrus IMAP. I
>don't want to use Sieveshell. I telnet to Sieve port 2000 and did a 'AUTHENTICATE
>"PLAIN" ' command. I checked the man page of timsieved. There is not much information
>about valid commands. I am not sure how can I input my auth name and user name to be
>able to login.
>
> This is so far I got:
>
> >telnet web9 2000
>
> >Trying 10.101.85.213...
> >Connected to web9.swlab.rim.net.
> >Escape character is '^]'.
> >"IMPLEMENTATION" "Cyrus timsieved v1.1.0"
> >"SASL" "PLAIN OTP DIGEST-MD5 CRAM-MD5"
> >"SIEVE" "fileinto reject envelope vacation imapflags notify subaddress relational
>regex"
> >OK
>
> >AUTHENTICATE "PLAIN"
>
> >{0}
>
> >user "cyrus"
>
> >NO "Authentication Error"
>
> Can any body let me know the valid commands for Timsieved?
The PLAIN authentication method seems to be defined in rfc2595.txt.
The example given for ACAP in the rfc is:
C: a003 AUTHENTICATE "PLAIN" {21+}
C: timtanstaaftanstaaf
S: a003 OK CRAM-MD5 password initialized
>From this it appears that you can't use PLAIN via telnet because you can't
enter a character (at least I don't know how it would be done).
I've been able to telnet to the timsieved by enabling the LOGIN authentication
mechanism. However you'll have to be able to convert username and password to
base64 inorder to use it.
I do have C++ source for a b64echo which I can post if anyone wants it.
Sieve commands are defined in:
cyrus-imapd-x.y.z/doc/sieve-protocol.html
Regards,
Mark Keasling <[EMAIL PROTECTED]>
Re: Problem rebuilding Simons new source RPM
On 25 Nov 2002 at 16:53, Simon Matter wrote about "Re: Problem rebuilding Simons new
source RPM":
> Harris Landgarten schrieb:
> >
> > I tracked down the cause of the problem but am still looking for the
> > source.
> >
> > For some reason perl man pages are being installed to /usr/man instead
> > of /usr/shared/man
> >
> > This causes the find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man
> > -type f -name "Cyrus*" to find nothing and the following string of
> > commands to fail with an error.
> >
> > Do you have any idea what could be causing this?
>
> Sorry, no. Maybe there is something wrong with you man path?
I'm the original author if that piece of shell code for my
packages of Cyrus 2.0.x. When I had reports of these kind
it was because the installed copy of Perl was not installed
via RPM (and hence the Perl man pages location as reported
by perl -V weren't under the path described by the %{_mandir}
RPM macro (/usr/share/man)).
HTH,
-
Ramiro
>
> Simon
>
> >
> > Harris
> >
> > On Mon, 2002-11-25 at 04:01, Simon Matter wrote:
> > > Hi,
> > >
> > > The only thing I can say is that the source RPM build fine on a
> > > untouched RedHat 8.0 installation. I can't make sure it will build
> > > on a system where many packages have been installed from other
> > > places than the distribution RPMs.
> > >
> > > It's as easy as this:
> > > - Install RedHat 8.0.
> > > - Rebuild the source RPM.
> > >
> > > Simon
> > >
> > > >
> > > > I am currently running Cyrus 2.1.9 under Redhat 8 using Simons
> > > > source RPM. I had no problem recompiling and installing from the
> > > > source RPM per documentation. Subsequently I have updated many
> > > > Perl Modules. When I try to rebuild the 2.1.10-3 rpm from source I
> > > > get an error during the rebuild process. The error is from this
> > > > section of shell script:
> > > >
> > > >
> > > >
> > > > # Create filelist for perl package, compress manpages before
> > > >
> > > > [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress
> > > >
> > > > find
> > > > /var/tmp/cyrus-imapd-2.1.10-root/usr/lib/perl5/site_perl/5.8.0/i38
> > > > 6-linux-thread-multi/Cyrus
> > > > /var/tmp/cyrus-imapd-2.1.10-root/usr/lib/perl5/site_perl/5.8.0/i38
> > > > 6-linux-thread-multi/auto/Cyrus -type f -print |
> > > >
> > > > sed "s@^/var/tmp/cyrus-imapd-2.1.10-root@@g" |
> > > >
> > > > grep -v perllocal.pod |
> > > >
> > > > grep -v "\.packlist" > perl-Cyrus-2.1.10-filelist
> > > >
> > > > find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man -type f -name
> > > > "Cyrus*" -print |
> > > >
> > > > sed "s@^/var/tmp/cyrus-imapd-2.1.10-root@@g" |
> > > >
> > > > grep -v perllocal.pod |
> > > >
> > > > grep -v "\.packlist" >> perl-Cyrus-2.1.10-filelist
> > > >
> > > > if [ "$(cat perl-Cyrus-2.1.10-filelist)X" = "X" ] ; then
> > > >
> > > > echo "ERROR: EMPTY FILE LIST"
> > > >
> > > > exit -1
> > > >
> > > > fi
> > > >
> > > >
> > > >
> > > > It appears that perl-Cyrus-2.1.10-filelist is never being written
> > > > at all. If I manually run these commands after erroring out,
> > > > perl-Cyrus-2.1.10-filelist is properly written. I am not sure how
> > > > to debug an rpmbuild -rebuild so I can see what is going on. BTW,
> > > > when I try rpmbuild -rebuild on the original 2.1.9 source RPM that
> > > > I originally installed from, it errors out in the same place. When
> > > > I tried rebuilding on another Redhat 8.0 box on which the perl
> > > > modules are relatively untouched, the rpmbuild ran to conclusion.
> > > >
> > > >
> > > >
> > > > Any ideas on what is going on or how to debug an rpmbuild -rebuild
> > > > would be appreciated.
> > > >
> > > >
> > > >
> > > > Harris
> > --
> > Harris Landgarten <[EMAIL PROTECTED]>
>
> --
> Simon Matter Tel: +41 61 695 57 35
> Fr.Sauter AG / CITFax: +41 61 695 53 30
> Im Surinam 55
> CH-4016 Basel [mailto:[EMAIL PROTECTED]]
>
Re: Problem rebuilding Simons new source RPM
I found the problem. I had updated ExtUtils::MakeMaker via CPAN to the
latest version. That is turn replaced MM_Unix.pm with a version that
defaulted site and vendor to /usr/man. Redhat had supplied a patched
version of this file which defaults to /usr/share/man. I copied the file
from another machine and the problem went away. Unfortunately it took
1/2 a day to track down the problem. The Cyrus/Perl interface could
certainly be improved and Simons excellent RPMs could be more robust but
not necessarily worth the effort. Thanks for the help
Harris
On Mon, 2002-11-25 at 13:14, Jonathan Marsden wrote:
> On 25 Nov 2002, Simon Matter writes:
>
> > Harris Landgarten schrieb:
>
> >> For some reason perl man pages are being installed to /usr/man
> >> instead of /usr/shared/man
>
> In older (5.x and 6.x) Red Hat distributions, /usr/man was the default
> man page location. I strongly suspect that the %{_mandir} RPM macro
> is being set to /usr/man on those machines, and to /usr/share/man
> (note: not /usr/shared/man, presumably the extra 'd' was a typo?) on
> newer distributions.
>
> On my RH 7.3 machines %_mandir is set in /usr/lib/rpm/macros to
> /usr/man (somewhat surprisingly), but this is overridden by setting it
> to /usr/share/man in the architecture-specific files:
>
> /usr/lib/rpm/athlon-linux/macros
> /usr/lib/rpm/athlon-redhat-linux/macros
> /usr/lib/rpm/i386-linux/macros
> /usr/lib/rpm/i386-redhat-linux/macros
> /usr/lib/rpm/i486-linux/macros
> /usr/lib/rpm/i486-redhat-linux/macros
> /usr/lib/rpm/i586-linux/macros
> /usr/lib/rpm/i586-redhat-linux/macros
> /usr/lib/rpm/i686-linux/macros
> /usr/lib/rpm/i686-redhat-linux/macros
> /usr/lib/rpm/noarch-linux/macros
> /usr/lib/rpm/noarch-redhat-linux/macros
>
> >> This causes the find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man
> >> -type f -name "Cyrus*" to find nothing and the following string of
> >> commands to fail with an error.
>
> If I am correct, then it might be wise to use the %{_mandir} macro
> within that find command, and anywhere else in the .spec file that the
> man directory is referenced. Then man pages should be searched for in
> the correct place on all distributions, based on that configurable
> setting.
>
> >> Do you have any idea what could be causing this?
>
> I don't know what would change it in Red Hat 8.0 -- unless a user
> copied some .rpmmacros files or /usr/lib/rpm/* or /etc/rpm/* from an
> older machine, maybe?? Either that, or the machine in use does not
> think of itself as being an x86 machine at all, so none of the
> architecture-specific macro files are being used??
>
> As a quick check, for Harris it could be worth trying
>
> echo "%_mandir /usr/share/man" >>~/.rpmmacros
>
> and then rebuilding Simon's SRPM. If that "fixes" the problem, then
> the issue is indeed the %mandir setting, and the cause of the /usr/man
> value should be tracked back through the various places in RPM config
> files where it might be being set.
>
> Jonathan
> --
> Jonathan Marsden | Internet: [EMAIL PROTECTED] | Making electronic
> 1252 Judson Street| Phone: +1 (909) 795-3877 | communications work
> Redlands, CA 92374| Fax: +1 (909) 795-0327 | reliably for
>Christian
> USA | http://www.xc.org/jonathan| missions worldwide
--
Harris Landgarten <[EMAIL PROTECTED]>
Re: Problem rebuilding Simons new source RPM
On 25 Nov 2002, Simon Matter writes:
> Harris Landgarten schrieb:
>> For some reason perl man pages are being installed to /usr/man
>> instead of /usr/shared/man
In older (5.x and 6.x) Red Hat distributions, /usr/man was the default
man page location. I strongly suspect that the %{_mandir} RPM macro
is being set to /usr/man on those machines, and to /usr/share/man
(note: not /usr/shared/man, presumably the extra 'd' was a typo?) on
newer distributions.
On my RH 7.3 machines %_mandir is set in /usr/lib/rpm/macros to
/usr/man (somewhat surprisingly), but this is overridden by setting it
to /usr/share/man in the architecture-specific files:
/usr/lib/rpm/athlon-linux/macros
/usr/lib/rpm/athlon-redhat-linux/macros
/usr/lib/rpm/i386-linux/macros
/usr/lib/rpm/i386-redhat-linux/macros
/usr/lib/rpm/i486-linux/macros
/usr/lib/rpm/i486-redhat-linux/macros
/usr/lib/rpm/i586-linux/macros
/usr/lib/rpm/i586-redhat-linux/macros
/usr/lib/rpm/i686-linux/macros
/usr/lib/rpm/i686-redhat-linux/macros
/usr/lib/rpm/noarch-linux/macros
/usr/lib/rpm/noarch-redhat-linux/macros
>> This causes the find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man
>> -type f -name "Cyrus*" to find nothing and the following string of
>> commands to fail with an error.
If I am correct, then it might be wise to use the %{_mandir} macro
within that find command, and anywhere else in the .spec file that the
man directory is referenced. Then man pages should be searched for in
the correct place on all distributions, based on that configurable
setting.
>> Do you have any idea what could be causing this?
I don't know what would change it in Red Hat 8.0 -- unless a user
copied some .rpmmacros files or /usr/lib/rpm/* or /etc/rpm/* from an
older machine, maybe?? Either that, or the machine in use does not
think of itself as being an x86 machine at all, so none of the
architecture-specific macro files are being used??
As a quick check, for Harris it could be worth trying
echo "%_mandir /usr/share/man" >>~/.rpmmacros
and then rebuilding Simon's SRPM. If that "fixes" the problem, then
the issue is indeed the %mandir setting, and the cause of the /usr/man
value should be tracked back through the various places in RPM config
files where it might be being set.
Jonathan
--
Jonathan Marsden| Internet: [EMAIL PROTECTED] | Making electronic
1252 Judson Street | Phone: +1 (909) 795-3877 | communications work
Redlands, CA 92374 | Fax: +1 (909) 795-0327 | reliably for Christian
USA | http://www.xc.org/jonathan| missions worldwide
Re: PostgreSQL backend: a waste of time?
On 25 Nov 2002, Erik Enge wrote: > I wouldn't rate it as easy unless it was a config option at run-time, > not an option to configure at compile-time. This wouldn't be tremendously hard to do (probably just a matter of replacing some macros with some code that is a bit more clever), but there'd be a (small) performance penalty and there isn't really any intrest in doing it, since converting databases shouldn't be a common operation anyway. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: PostgreSQL backend: a waste of time?
Ken Murchison <[EMAIL PROTECTED]> writes: > All of the db stuff _is_ isolated in the cyrusdb layer. That's why it > is so easy to switch between flat/skiplist/berkeley. I wouldn't rate it as easy unless it was a config option at run-time, not an option to configure at compile-time. Erik.
Re: PostgreSQL backend: a waste of time?
On Mon, 25 Nov 2002 10:04:03 -0600 [EMAIL PROTECTED] wrote: > Seems kinda ironic in a way---doesn't MySQL use BerkeleyDB? I guess > it's all in the indexing/caching yes, it is one of the choices for table type. others are MyISAM and InnoDB, the latter supports transactions and is as fast as oracle if not a bit faster. -- Jure Pecar
Re: lmtpproxy (Was: Re: SpamAssassin & Sieve?)
On Mon, 25 Nov 2002, Marc G. Fournier wrote: > How are you dealing with the per-user settings, or aren't you? We're We're not. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: PostgreSQL backend: a waste of time?
> Alessandro Oliveira wrote: > > I think that all the code that is dependent on a particular database > should be completely isolated, making it simpler to port to new All of the db stuff _is_ isolated in the cyrusdb layer. That's why it is so easy to switch between flat/skiplist/berkeley. > databases, for instance: Nicola likes postgres, you like mysql, and I > love oracle (besides it is very expensive), somebody else would like > an interbase or a sapdb backend. > > 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. > > > > > > On 25-Nov-2002 Nicola Ranaldo wrote: > > > > > >> Due to our historical problems using BerkeleyDB4 over True64Unix > >> I'm > >> coding a PostgreSQL backend. > >> It's in alpha stage and seems to work fine over an our production > >> server > >> with about 7500 mailboxes. > >> Cyrus.log is DBERROR free, and users do not report any problem. > >> Access to mboxlist is about 5 time faster then with BerkeleyDB4. > >> If the cyrus community is interested in this little piece of code > >> (i > >> don't > >> know due to presence of skiplist backend) we can start a thread > >> now! > >> > >> > > > > | Noll Janos <[EMAIL PROTECTED]> | http://www.johnzero.hu | > > | "Expect the unexpected!"| ICQ# 4547866 | Be free! | > > > > > > > > -- > Best Regards, > > Alessandro Oliveira > Nuno Ferreira Cargas Internacionais Ltda. > Phone: +55-11-3241-2000 > Fax : +55-11-3242-9891 > --- > > It's trivial to make fun of Microsoft products, but it takes a real > man to make them work, and a god to make them do anything useful. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
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: Pros and cons using IDLED?
Simon Matter wrote: > > Ken Murchison schrieb: > > > > Simon Matter wrote: > > > > > > I have enabled compilation of idled in my newest RPM but am wondering > > > whether that was a good idea. I have two questions: > > > > > > 1) I was searching the archives and docs but still can't find a > > > description of the advantages and drawbacks when using idled instead of > > > poll. What are the drawback of possible problems I may face when using > > > idled? > > > > Being the guy that wrote idled, I guess I have to answer ;) > > > > The main advantage of idled versus polling is that you get event-driven > > instant notification of message changes (new, delete, flag changes, etc) > > in your client when IDLEing (light load on the server, because it only > > checks the mailbox when told to). With polling, you can can updates as > > fast as 1 sec, but you can beat the crap out of the server if you have a > > lot of users polling that much. > > > > The downside of using idled is that it might not scale well. I haven't > > received any input from a large site using idled. > > > > Keep in mind that idled (or polling) is only used when the client issues > > the IDLE command. The only mainstream client that I'm aware of that > > uses IDLE is Outlook. > > Thanks. So it means it's only interesting in an Outlook environment for > now. Like I said, Outlook is the only client that I'm aware of that supports IDLE. There may be others which support it that would take advantage of idled. For the most part, I think clients do their own polling via NOOP. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Problem rebuilding Simons new source RPM
Harris Landgarten schrieb: > > I tracked down the cause of the problem but am still looking for the > source. > > For some reason perl man pages are being installed to /usr/man instead > of /usr/shared/man > > This causes the find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man > -type f -name "Cyrus*" to find nothing and the following string of > commands to fail with an error. > > Do you have any idea what could be causing this? Sorry, no. Maybe there is something wrong with you man path? Simon > > Harris > > On Mon, 2002-11-25 at 04:01, Simon Matter wrote: > > Hi, > > > > The only thing I can say is that the source RPM build fine on a > > untouched RedHat 8.0 installation. I can't make sure it will build on a > > system where many packages have been installed from other places than > > the distribution RPMs. > > > > It's as easy as this: > > - Install RedHat 8.0. > > - Rebuild the source RPM. > > > > Simon > > > > > > > > I am currently running Cyrus 2.1.9 under Redhat 8 using Simons source RPM. I had >no problem recompiling and > > > installing from the source RPM per documentation. Subsequently I have updated >many Perl Modules. When I try to > > > rebuild the 2.1.10-3 rpm from source I get an error during the rebuild process. >The error is from this section of > > > shell script: > > > > > > > > > > > > # Create filelist for perl package, compress manpages before > > > > > > [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress > > > > > > find >/var/tmp/cyrus-imapd-2.1.10-root/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Cyrus > > > >/var/tmp/cyrus-imapd-2.1.10-root/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Cyrus > -type f -print | > > > > > > sed "s@^/var/tmp/cyrus-imapd-2.1.10-root@@g" | > > > > > > grep -v perllocal.pod | > > > > > > grep -v "\.packlist" > perl-Cyrus-2.1.10-filelist > > > > > > find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man -type f -name "Cyrus*" >-print | > > > > > > sed "s@^/var/tmp/cyrus-imapd-2.1.10-root@@g" | > > > > > > grep -v perllocal.pod | > > > > > > grep -v "\.packlist" >> perl-Cyrus-2.1.10-filelist > > > > > > if [ "$(cat perl-Cyrus-2.1.10-filelist)X" = "X" ] ; then > > > > > > echo "ERROR: EMPTY FILE LIST" > > > > > > exit -1 > > > > > > fi > > > > > > > > > > > > It appears that perl-Cyrus-2.1.10-filelist is never being written at all. If I >manually run these commands after > > > erroring out, perl-Cyrus-2.1.10-filelist is properly written. I am not sure how >to debug an rpmbuild -rebuild so I > > > can see what is going on. BTW, when I try rpmbuild -rebuild on the original >2.1.9 source RPM that I originally > > > installed from, it errors out in the same place. When I tried rebuilding on >another Redhat 8.0 box on which the perl > > > modules are relatively untouched, the rpmbuild ran to conclusion. > > > > > > > > > > > > Any ideas on what is going on or how to debug an rpmbuild -rebuild would be >appreciated. > > > > > > > > > > > > Harris > -- > Harris Landgarten <[EMAIL PROTECTED]> -- Simon Matter Tel: +41 61 695 57 35 Fr.Sauter AG / CITFax: +41 61 695 53 30 Im Surinam 55 CH-4016 Basel [mailto:[EMAIL PROTECTED]]
Re: PostgreSQL backend: a waste of time?
I think that all the code that is dependent on a particular database should be completely isolated, making it simpler to port to new databases, for instance: Nicola likes postgres, you like mysql, and I love oracle (besides it is very expensive), somebody else would like an interbase or a sapdb backend. 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. On 25-Nov-2002 Nicola Ranaldo wrote: Due to our historical problems using BerkeleyDB4 over True64Unix I'm coding a PostgreSQL backend. It's in alpha stage and seems to work fine over an our production server with about 7500 mailboxes. Cyrus.log is DBERROR free, and users do not report any problem. Access to mboxlist is about 5 time faster then with BerkeleyDB4. If the cyrus community is interested in this little piece of code (i don't know due to presence of skiplist backend) we can start a thread now! | Noll Janos <[EMAIL PROTECTED]> | http://www.johnzero.hu | | "Expect the unexpected!"| ICQ# 4547866 | Be free! | -- Best Regards, Alessandro Oliveira Nuno Ferreira Cargas Internacionais Ltda. Phone: +55-11-3241-2000 Fax : +55-11-3242-9891 --- It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a god to make them do anything useful.
RE: PostgreSQL backend: a waste of time?
--On Monday, November 25, 2002 4:36 PM +0100 Noll Janos <[EMAIL PROTECTED]> wrote: | 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. Seems kinda ironic in a way---doesn't MySQL use BerkeleyDB? I guess it's all in the indexing/caching Amos
Re: Problem rebuilding Simons new source RPM
I tracked down the cause of the problem but am still looking for the source. For some reason perl man pages are being installed to /usr/man instead of /usr/shared/man This causes the find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man -type f -name "Cyrus*" to find nothing and the following string of commands to fail with an error. Do you have any idea what could be causing this? Harris On Mon, 2002-11-25 at 04:01, Simon Matter wrote: > Hi, > > The only thing I can say is that the source RPM build fine on a > untouched RedHat 8.0 installation. I can't make sure it will build on a > system where many packages have been installed from other places than > the distribution RPMs. > > It's as easy as this: > - Install RedHat 8.0. > - Rebuild the source RPM. > > Simon > > > > > I am currently running Cyrus 2.1.9 under Redhat 8 using Simons source RPM. I had >no problem recompiling and > > installing from the source RPM per documentation. Subsequently I have updated many >Perl Modules. When I try to > > rebuild the 2.1.10-3 rpm from source I get an error during the rebuild process. >The error is from this section of > > shell script: > > > > > > > > # Create filelist for perl package, compress manpages before > > > > [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress > > > > find >/var/tmp/cyrus-imapd-2.1.10-root/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Cyrus > > >/var/tmp/cyrus-imapd-2.1.10-root/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Cyrus > -type f -print | > > > > sed "s@^/var/tmp/cyrus-imapd-2.1.10-root@@g" | > > > > grep -v perllocal.pod | > > > > grep -v "\.packlist" > perl-Cyrus-2.1.10-filelist > > > > find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man -type f -name "Cyrus*" -print | > > > > sed "s@^/var/tmp/cyrus-imapd-2.1.10-root@@g" | > > > > grep -v perllocal.pod | > > > > grep -v "\.packlist" >> perl-Cyrus-2.1.10-filelist > > > > if [ "$(cat perl-Cyrus-2.1.10-filelist)X" = "X" ] ; then > > > > echo "ERROR: EMPTY FILE LIST" > > > > exit -1 > > > > fi > > > > > > > > It appears that perl-Cyrus-2.1.10-filelist is never being written at all. If I >manually run these commands after > > erroring out, perl-Cyrus-2.1.10-filelist is properly written. I am not sure how to >debug an rpmbuild -rebuild so I > > can see what is going on. BTW, when I try rpmbuild -rebuild on the original 2.1.9 >source RPM that I originally > > installed from, it errors out in the same place. When I tried rebuilding on >another Redhat 8.0 box on which the perl > > modules are relatively untouched, the rpmbuild ran to conclusion. > > > > > > > > Any ideas on what is going on or how to debug an rpmbuild -rebuild would be >appreciated. > > > > > > > > Harris -- Harris Landgarten <[EMAIL PROTECTED]>
RE: PostgreSQL backend: a waste of time?
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. On 25-Nov-2002 Nicola Ranaldo wrote: > Due to our historical problems using BerkeleyDB4 over True64Unix I'm > coding a PostgreSQL backend. > It's in alpha stage and seems to work fine over an our production > server > with about 7500 mailboxes. > Cyrus.log is DBERROR free, and users do not report any problem. > Access to mboxlist is about 5 time faster then with BerkeleyDB4. > If the cyrus community is interested in this little piece of code (i > don't > know due to presence of skiplist backend) we can start a thread now! | Noll Janos <[EMAIL PROTECTED]> | http://www.johnzero.hu | | "Expect the unexpected!"| ICQ# 4547866 | Be free! |
lmtpproxy (Was: Re: SpamAssassin & Sieve?)
On Sat, 23 Nov 2002, Rob Siemborski wrote: > On Sat, 23 Nov 2002, Ken Murchison wrote: > > > CMU is using SpamAssassin, and I believe Rob successfully tested the > > Sieve relational extension with it when I first implemented it. I don't > > know if they are using it in production yet. > > "In Production" where it's on our production servers but it's not a > "supported service". How are you dealing with the per-user settings, or aren't you? We're using the spamproxy.py (we've re-written it in perl, since none of us really know python) and it works okay for 99.9% of the cases, but we've got one case where dataend() is returning 354 and is causing a failure ...
Re: Pros and cons using IDLED?
Ken Murchison schrieb: > > Simon Matter wrote: > > > > I have enabled compilation of idled in my newest RPM but am wondering > > whether that was a good idea. I have two questions: > > > > 1) I was searching the archives and docs but still can't find a > > description of the advantages and drawbacks when using idled instead of > > poll. What are the drawback of possible problems I may face when using > > idled? > > Being the guy that wrote idled, I guess I have to answer ;) > > The main advantage of idled versus polling is that you get event-driven > instant notification of message changes (new, delete, flag changes, etc) > in your client when IDLEing (light load on the server, because it only > checks the mailbox when told to). With polling, you can can updates as > fast as 1 sec, but you can beat the crap out of the server if you have a > lot of users polling that much. > > The downside of using idled is that it might not scale well. I haven't > received any input from a large site using idled. > > Keep in mind that idled (or polling) is only used when the client issues > the IDLE command. The only mainstream client that I'm aware of that > uses IDLE is Outlook. Thanks. So it means it's only interesting in an Outlook environment for now. > > > > > 2) I have read the man pages but still don't fully understand how things > > work. > > From the man page: > > = > > imapidlepoll: 60 > > The interval (in seconds) for polling the mailbox for changes while > > running the IDLE command. This option is > > used when idled can not be contacted or when polling is used > > exclusively. The minimum value is 1. A value of 0 > > will disable polling (and disable IDLE if polling is the only method > > available). > > = > > > > 60 is the default value for imapidlepoll. It means that unless specified > > otherwise, IDLE is always enabled, using polling or idled. Only setting > > it to 0 does in fact disable IDLE. The man pages also say that if idled > > can not be contacted, poll is used instead. > > My problem is now that I have compiled with idled but not enabled it in > > cyrus.conf. I then get following messages: > > /var/log/messages:Nov 22 22:26:56 xxl imapd[2594]: error sending to > > idled: 2 > > Is this message only a warning message or does it mean I really have to > > start idled if it's compiled in? > > If you compile with idled enabled, it expects it to be running. IIRC, > it will try talking to idled a handful of times, and then give up (using > polling exclusively). Okay, that explains it. Thanks! Simon > > Ken > -- > Kenneth Murchison Oceana Matrix Ltd. > Software Engineer 21 Princeton Place > 716-662-8973 x26 Orchard Park, NY 14127 > --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Timsieved versions differ
Andrei Loukinykh wrote: > > One does on his cyrus host: > > $ telnet imaphost 2000 > > And get: > > "IMPLEMENTATION" "Cyrus timsieved v2.1.10" > "SASL" "PLAIN LOGIN" > "SIEVE" "fileinto reject envelope vacation imapflags notify subaddress > relational regex" > .. > > And when I do the same with my brand-new Imapd 2.1.9 installed, I get: > > "IMPLEMENTATION" "Cyrus timsieved v1.1.0" > "SASL" "PLAIN" > "SIEVE" "fileinto reject envelope vacation imapflags notify subaddress > relational regex" > ... In Cyrus 2.1.10, we changed the version reported in the timsieved capabilities (banner) to be the same as the Cyrus release. > And I get sieve's parse error in logs when trying to save scripts through > avelsieve plugin. Can it happen because of this difference ? 2.1.10 also updated timsieved to be compliant with the latest managesieve draft http://www.ietf.org/internet-drafts/draft-martin-managesieve-04.txt which removes the auto-capability response after a successful STARTTLS. My guess is that your sieve client is expecting this response. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Pros and cons using IDLED?
Simon Matter wrote: > > I have enabled compilation of idled in my newest RPM but am wondering > whether that was a good idea. I have two questions: > > 1) I was searching the archives and docs but still can't find a > description of the advantages and drawbacks when using idled instead of > poll. What are the drawback of possible problems I may face when using > idled? Being the guy that wrote idled, I guess I have to answer ;) The main advantage of idled versus polling is that you get event-driven instant notification of message changes (new, delete, flag changes, etc) in your client when IDLEing (light load on the server, because it only checks the mailbox when told to). With polling, you can can updates as fast as 1 sec, but you can beat the crap out of the server if you have a lot of users polling that much. The downside of using idled is that it might not scale well. I haven't received any input from a large site using idled. Keep in mind that idled (or polling) is only used when the client issues the IDLE command. The only mainstream client that I'm aware of that uses IDLE is Outlook. > > 2) I have read the man pages but still don't fully understand how things > work. > From the man page: > = > imapidlepoll: 60 > The interval (in seconds) for polling the mailbox for changes while > running the IDLE command. This option is > used when idled can not be contacted or when polling is used > exclusively. The minimum value is 1. A value of 0 > will disable polling (and disable IDLE if polling is the only method > available). > = > > 60 is the default value for imapidlepoll. It means that unless specified > otherwise, IDLE is always enabled, using polling or idled. Only setting > it to 0 does in fact disable IDLE. The man pages also say that if idled > can not be contacted, poll is used instead. > My problem is now that I have compiled with idled but not enabled it in > cyrus.conf. I then get following messages: > /var/log/messages:Nov 22 22:26:56 xxl imapd[2594]: error sending to > idled: 2 > Is this message only a warning message or does it mean I really have to > start idled if it's compiled in? If you compile with idled enabled, it expects it to be running. IIRC, it will try talking to idled a handful of times, and then give up (using polling exclusively). Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: PostgreSQL backend: a waste of time?
I have the same point of view, could you please share with me your experiences with cyrus, and a more detailed information about your project ? Nicola Ranaldo wrote: Due to our historical problems using BerkeleyDB4 over True64Unix I'm coding a PostgreSQL backend. It's in alpha stage and seems to work fine over an our production server with about 7500 mailboxes. Cyrus.log is DBERROR free, and users do not report any problem. Access to mboxlist is about 5 time faster then with BerkeleyDB4. If the cyrus community is interested in this little piece of code (i don't know due to presence of skiplist backend) we can start a thread now! Best Regards Nicola Ranaldo System Manager C.D.S. Federico II University Neaples - Italy -- Best Regards, Alessandro Oliveira Nuno Ferreira Cargas Internacionais Ltda. Phone: +55-11-3241-2000 Fax : +55-11-3242-9891 --- It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a god to make them do anything useful.
Re: BAD ACL Behavior
On Mon, 25 Nov 2002, Alessandro Oliveira wrote: > When user X that has right to delete shared folders and delete a shared > folder, ordinary users that used to access that folder (lrs rights) > start to see the user X in the "Other Users" namespace, because they > still can access that folder even though it is in the user.X.Trash.FOLDER. I'd argue that this is totally bogus behavior that doesn't fit well withing the IMAP paradigm, and that the client should be responsible for ensuring that its implementation doesn't provide undesired effects anyway (the proper way to delete a folder is to issue a DELETE command, not a RENAME as I expect is the case here). > I think that the correct behavior would be to a copied FOLDER inherit > permissons from the new parent. Is this a bug ? Well, another perfectly valid argument is to say that the copied (well, renamed) folder keeps its ACL, since RFC2086 doesn't say one way or the other. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
PostgreSQL backend: a waste of time?
Due to our historical problems using BerkeleyDB4 over True64Unix I'm coding a PostgreSQL backend. It's in alpha stage and seems to work fine over an our production server with about 7500 mailboxes. Cyrus.log is DBERROR free, and users do not report any problem. Access to mboxlist is about 5 time faster then with BerkeleyDB4. If the cyrus community is interested in this little piece of code (i don't know due to presence of skiplist backend) we can start a thread now! Best Regards Nicola Ranaldo System Manager C.D.S. Federico II University Neaples - Italy
BAD ACL Behavior
Hi, When user X that has right to delete shared folders and delete a shared folder, ordinary users that used to access that folder (lrs rights) start to see the user X in the "Other Users" namespace, because they still can access that folder even though it is in the user.X.Trash.FOLDER. I think that the correct behavior would be to a copied FOLDER inherit permissons from the new parent. Is this a bug ? -- Thanks, Alessandro Oliveira Nuno Ferreira Cargas Internacionais Ltda. Phone: +55-11-3241-2000 Fax : +55-11-3242-9891 --- It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a god to make them do anything useful.
Pros and cons using IDLED?
I have enabled compilation of idled in my newest RPM but am wondering whether that was a good idea. I have two questions: 1) I was searching the archives and docs but still can't find a description of the advantages and drawbacks when using idled instead of poll. What are the drawback of possible problems I may face when using idled? 2) I have read the man pages but still don't fully understand how things work. >From the man page: = imapidlepoll: 60 The interval (in seconds) for polling the mailbox for changes while running the IDLE command. This option is used when idled can not be contacted or when polling is used exclusively. The minimum value is 1. A value of 0 will disable polling (and disable IDLE if polling is the only method available). = 60 is the default value for imapidlepoll. It means that unless specified otherwise, IDLE is always enabled, using polling or idled. Only setting it to 0 does in fact disable IDLE. The man pages also say that if idled can not be contacted, poll is used instead. My problem is now that I have compiled with idled but not enabled it in cyrus.conf. I then get following messages: /var/log/messages:Nov 22 22:26:56 xxl imapd[2594]: error sending to idled: 2 Is this message only a warning message or does it mean I really have to start idled if it's compiled in? Simon
Re: Problem rebuilding Simons new source RPM
Hi, The only thing I can say is that the source RPM build fine on a untouched RedHat 8.0 installation. I can't make sure it will build on a system where many packages have been installed from other places than the distribution RPMs. It's as easy as this: - Install RedHat 8.0. - Rebuild the source RPM. Simon > > I am currently running Cyrus 2.1.9 under Redhat 8 using Simons source RPM. I had no >problem recompiling and > installing from the source RPM per documentation. Subsequently I have updated many >Perl Modules. When I try to > rebuild the 2.1.10-3 rpm from source I get an error during the rebuild process. The >error is from this section of > shell script: > > > > # Create filelist for perl package, compress manpages before > > [ -x /usr/lib/rpm/brp-compress ] && /usr/lib/rpm/brp-compress > > find >/var/tmp/cyrus-imapd-2.1.10-root/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Cyrus > >/var/tmp/cyrus-imapd-2.1.10-root/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/auto/Cyrus > -type f -print | > > sed "s@^/var/tmp/cyrus-imapd-2.1.10-root@@g" | > > grep -v perllocal.pod | > > grep -v "\.packlist" > perl-Cyrus-2.1.10-filelist > > find /var/tmp/cyrus-imapd-2.1.10-root/usr/share/man -type f -name "Cyrus*" -print | > > sed "s@^/var/tmp/cyrus-imapd-2.1.10-root@@g" | > > grep -v perllocal.pod | > > grep -v "\.packlist" >> perl-Cyrus-2.1.10-filelist > > if [ "$(cat perl-Cyrus-2.1.10-filelist)X" = "X" ] ; then > > echo "ERROR: EMPTY FILE LIST" > > exit -1 > > fi > > > > It appears that perl-Cyrus-2.1.10-filelist is never being written at all. If I >manually run these commands after > erroring out, perl-Cyrus-2.1.10-filelist is properly written. I am not sure how to >debug an rpmbuild -rebuild so I > can see what is going on. BTW, when I try rpmbuild -rebuild on the original 2.1.9 >source RPM that I originally > installed from, it errors out in the same place. When I tried rebuilding on another >Redhat 8.0 box on which the perl > modules are relatively untouched, the rpmbuild ran to conclusion. > > > > Any ideas on what is going on or how to debug an rpmbuild -rebuild would be >appreciated. > > > > Harris
Re: RPM Upgrade Nightmare
Tarjei Huse schrieb: > > > Boy, what a nightmare this turned out to be. > Yep. It aint easy :) > > > > I've been running the cyrus-imapd-2.0.16 rpms developed by Ramiro which > > can be found here: > > http://rmorales.modwest.com/rpms/cyrus-imapd/ > > > > and I figured it was time to upgrade to the 2.1.* series, so I got the > > source rpm cyrus-imapd-2.1.10-3.src.rpm developed by Simon Matter from here: > > http://home.teleport.ch/simix/ > > At this point, how much did you bother to read the docs and check that things were cyrus-sasl 2.x is needed. RPMs for RH 7.3 can be found on my webpage too. ready? I just did a similar upgrade, and I tried reading the docs, but still. There were a lot of hassles. Here's my tips: > a) Maybe use RH's postfix rpms to start with? I think they got sasl support, and >that seems to be your only requirement.b) Install and move your user db before you >start with Cyrus. Well, at least for SMTP AUTH, RedHat's rpms don't work with SASL2 because they didn't patch the right way. > c) Simon, would you mind pointing this out on your fine webpage? > > The RPMS have a difference in where they store the config directories: > > 2.0.16 keeps it's configs in /var/imap > > 2.1.10-3 keeps it's configs in /var/lib/imap I changed some paths to comply with FHS. You're right, I may mention this on the webpage. > d) This as well: > > And how directory structure the mails box are located: > > 2.0.16 keeps the files under /var/spool/imap/user > > 2.1.10-3 keeps files under /var/spool/imap/a-z > I belive that what you need to do is to use the rehash script found in >/usr/libexec/cyrus I ran that a cuple of times (if someone might supply Chris with >the correct way to rehash that would be nice.) > > > In the end, I couldn't get the new cyrus rpms to find my mail boxes. > This is probably related to the /var/imap vs /var/lib/imap tingy. I also had a BIG >hassle with getting my different indexfiles in /var/lib/imap to work. > > I suggest you set of some time to work on that. Remember to set logging to full when >you start so you know where to look. Also read through the man pages for the ctl_* >commands found in /usr/libexec/cyrus. > > I solved my problems with the indexes by setting all to skiplist and recompiling, >but that was on RH8.0. I'm not sure, but I think you need to recompile Cyrus if you >change the db type, so be prepared for some simple .spec file hacking. > > e) > I do not think you need db4 for 2.1. when you use 7.3 - db3 is ok. > > I hope this might help you, > Tarjei > > gave up and eventually got the old rpms working again and I needed to > > rebuild my database to get it to work again with db3. I'm sure I made a > > few mistakes along the way so I'd like to find out how to properly > > migrate to the new cyrus rpms. Any thoughts, hints, or ideas would be > > greatly appreciated. Thank you. > > > > Chris
