Re: Error registering service with SLP
Am Saturday 09 September 2006 11:56 schrieb Achim Lammerts: after restarting cyrus I saw in the log these error messages: Sep 9 10:57:43 salamucha master[6160]: SLPRegister [service:imap://salamucha.:143] Sep 9 10:57:43 salamucha master[6160]: Error registering service with slp -20 Sep 9 10:57:43 salamucha master[6160]: SLPRegister [service:imaps://salamucha.:993] Sep 9 10:57:43 salamucha master[6160]: Error registering service with slp -20 Sep 9 10:57:43 salamucha master[6160]: SLPRegister [service:pop3://salamucha.:110] Sep 9 10:57:43 salamucha master[6160]: Error registering service with slp -20 Sep 9 10:57:43 salamucha master[6160]: SLPRegister [service:pop3s://salamucha.:995] Sep 9 10:57:43 salamucha master[6160]: Error registering service with slp -20 Sep 9 10:57:43 salamucha master[6160]: SLPRegister [service:sieve://salamucha.:2000] Sep 9 10:57:43 salamucha master[6160]: Error registering service with slp -20 Everything seems working well, I just like to know if there is a need to fix it and where is it to fix. Any suggestions? http://www.openslp.org/ The SLP-Stuff is not in a vanilla Cyrus-Imapd. It is a (Open)SuSE Patch. Best to ask the SuSE-Folks, why this is not configurable/disable at runtime. You can ignore these Errors. a.) You can install an OpenSLP-Service, so Cyrus-Imapd can register. b.) Maybe a Job for syslog-ng. -- Andreas Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sieveshell -a -u doesn't work as it should (bug?)
Am Saturday 09 September 2006 11:37 schrieb Rudy Gevaert: Andreas Winkelmann wrote: Am Friday 08 September 2006 14:51 schrieb Rudy Gevaert: I have this strange problem with sieveshell. (I'm using virtual domains, and unix seperator.) I can authenticate as an admin user and authorize as a normal user with cyradm. However with sieveshell this doesnt work the way it should: Here I log in and first give the wrong pass, and then the right one. When I then do a list I get to see the scripts. himalaya:/mail/mail1/etc# sieveshell -u [EMAIL PROTECTED] \ -a cyrus mail1.ugent.be connecting to mail1.ugent.be Please enter your password: wrong Please enter your password: right list default - active script ingo quit Here I give my right pass straight away and then do a list. As you can see it doesn't list any lists. himalaya:/mail/mail1/etc# sieveshell -u [EMAIL PROTECTED] \ -a cyrus mail1.ugent.be connecting to mail1.ugent.be Please enter your password: right list quit So, I first have to give a wrong password and then the password of the cyrus user to let me in. Could somebody verify this? Or tell me what I'm doing wrong? Show your configuration. At least imapd.conf. It's attached... Ok, please remove the LOGIN Mechanism from sasl_mech_list. # Authentication configuration sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN LOGIN LOGIN is not able to do authorization (-a cyrus -u user). Only PLAIN and DIGEST-MD5 can do that. Because you use saslauthd, you are bound to PLAIN. I would guess, the first time you type the Password LOGIN is used, the second time PLAIN. Maybe a special imapd.conf for sieve to use both for the other services where authorization is not needed. -- Andreas Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Sieve authentication problem
Am Saturday 09 September 2006 12:38 schrieb Achim Lammerts: do I get some help about Sieve here too? Some days ago I've added authentication by sasldb and today I saw that Sieve doesn't work anymore. I can't login to sieveshell from root like sieveshell --user mailuser --authname mailuser localhost, the correct password is not accepted. There are these entries in the log file: Sep 9 12:25:44 salamucha master[7088]: about to exec /usr/lib/cyrus/bin/timsieved Sep 9 12:25:44 salamucha sieve[7088]: executed Sep 9 12:25:44 salamucha sieve[7088]: accepted connection Sep 9 12:25:49 salamucha PAM-warn[1066]: function=[pam_sm_authenticate] service=[sieve] terminal=[unknown] user=[mailuser] ruser=[unknown] rhost=[unknown] But this is saslauthd/pam, which is queried, not sasldb. Check your saslauthd/pam Configuration. Sep 9 12:25:49 salamucha PAM-warn[1066]: function=[pam_sm_acct_mgmt] service=[sieve] terminal=[unknown] user=[mailuser] ruser=[unknown] rhost=[unknown] Sep 9 12:25:49 salamucha sieve[7088]: transitioning user mailuser to auxprop database Sep 9 12:25:49 salamucha sieve[7088]: setpass succeeded for mailuser Sep 9 12:25:49 salamucha sieve[7088]: mkdir /var/lib/sieve/m/mailuser: File exists Sep 9 12:25:49 salamucha sieve[7088]: error in actions_setuser() Sep 9 12:25:49 salamucha perl: No worthy mechs found Sep 9 12:25:49 salamucha master[6160]: process 7088 exited, status 0 The actual imapd.conf looks like this: ... sasl_pwcheck_method: saslauthd auxprop sasl_auxprop_plugin: sasldb sasl_auto_transition: yes sasl_mech_list: plain login ... Also avelsieve doesn't work correctly before I got this problem above, in the meantime I can't use avelsieve too of course (with a similar error message). That might be another question and not here, but I like to ask about the rights for the Sieve directory. It's set to 600 and the owner is cyrus:mail, is that right? -- Andreas Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Sieve authentication problem
Am Sunday 10 September 2006 08:00 schrieb Andreas Winkelmann: do I get some help about Sieve here too? Some days ago I've added authentication by sasldb and today I saw that Sieve doesn't work anymore. I can't login to sieveshell from root like sieveshell --user mailuser --authname mailuser localhost, the correct password is not accepted. There are these entries in the log file: Sep 9 12:25:44 salamucha master[7088]: about to exec /usr/lib/cyrus/bin/timsieved Sep 9 12:25:44 salamucha sieve[7088]: executed Sep 9 12:25:44 salamucha sieve[7088]: accepted connection Sep 9 12:25:49 salamucha PAM-warn[1066]: function=[pam_sm_authenticate] service=[sieve] terminal=[unknown] user=[mailuser] ruser=[unknown] rhost=[unknown] But this is saslauthd/pam, which is queried, not sasldb. Check your saslauthd/pam Configuration. Ok forget it, sometimes it is better to read further. Sep 9 12:25:49 salamucha PAM-warn[1066]: function=[pam_sm_acct_mgmt] service=[sieve] terminal=[unknown] user=[mailuser] ruser=[unknown] rhost=[unknown] Sep 9 12:25:49 salamucha sieve[7088]: transitioning user mailuser to auxprop database Sep 9 12:25:49 salamucha sieve[7088]: setpass succeeded for mailuser Sep 9 12:25:49 salamucha sieve[7088]: mkdir /var/lib/sieve/m/mailuser: File exists Check this Directory. Maybe it is a File, or the Permissions are incorrect. Sep 9 12:25:49 salamucha sieve[7088]: error in actions_setuser() Sep 9 12:25:49 salamucha perl: No worthy mechs found Sep 9 12:25:49 salamucha master[6160]: process 7088 exited, status 0 The actual imapd.conf looks like this: ... sasl_pwcheck_method: saslauthd auxprop sasl_auxprop_plugin: sasldb sasl_auto_transition: yes sasl_mech_list: plain login ... Also avelsieve doesn't work correctly before I got this problem above, in the meantime I can't use avelsieve too of course (with a similar error message). That might be another question and not here, but I like to ask about the rights for the Sieve directory. It's set to 600 and the owner is cyrus:mail, is that right? -- Andreas Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
sync_server memory leak with giant new mailbox first sync
Ok, so this isn't a memory leak as such, but...
When sync_client has a large folder to send (for
the sake of far too many hours of me trying to
make this work let's just say it's 180,000
messages), then it just sends a single
UPLOAD [lastuid] [lastappenddate] followed by
every single message on after the other.
There's logic on the server end to send a [RESTART]
back after 1000 new files arrive, but it doesn't
get to be called until all 180,000 messages have
arrived... or at least it would be if the sync_server
process didn't receive a SIGABRT somewhere around
102,000 messages in. I tried all sorts of things
to find the underlying cause, then finally just
watched 'top' on the sync_server machine as it ran.
This machine has 8Gb of memory, and was seeing over
30% being used by this one sync_server before it
died!
Well, the attached isn't the most elegant patch in
the world, and may not be the best way to solve the
problem, but at least it got that user replicated
and happy. The first time we had to deal with it
was moving the user off a corrupted filesystem that
I could only mount read-only, and it took about 3
hours for each run to fail thanks to the insanely
high IO load on that drive unit, so debugging was
more of a pain than you'd hope.
I hope something inspired by this can be merged
upstream to solve the spam sync_server until it
falls over failure mode.
Bron.
--
Bron Gondwana
[EMAIL PROTECTED]
diff -ur --new-file cyrus-imapd-cvs/imap/sync_client.c
cyrus-imapd-cvs.new/imap/sync_client.c
--- cyrus-imapd-cvs/imap/sync_client.c 2006-08-26 10:48:27.0 -0400
+++ cyrus-imapd-cvs.new/imap/sync_client.c 2006-09-10 10:51:06.0
-0400
@@ -1198,7 +1198,7 @@
static int upload_messages_list(struct mailbox *mailbox,
struct sync_msg_list *list)
{
-unsigned long msgno;
+unsigned long msgno = 1;
int r = 0;
struct index_record record;
struct sync_msg *msg;
@@ -1212,8 +1212,11 @@
return(IMAP_IOERROR);
}
+repeatupload:
+
msg = list-head;
-for (msgno = 1 ; msgno = mailbox-exists ; msgno++) {
+count = 0;
+for (; count 1000 msgno = mailbox-exists ; msgno++) {
r = mailbox_read_index_record(mailbox, msgno, record);
if (r) {
@@ -1272,6 +1275,12 @@
syslog(LOG_INFO, UPLOAD: received RESTART);
}
+/* don't overload the server with too many uploads at once! */
+if (count = 1000) {
+ syslog(LOG_INFO, UPLOAD: hit %d uploads at msgno %d, count, msgno);
+ goto repeatupload;
+}
+
return(0);
}
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sieveshell -a -u doesn't work as it should (bug?)
Andreas Winkelmann wrote: Ok, please remove the LOGIN Mechanism from sasl_mech_list. # Authentication configuration sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN LOGIN LOGIN is not able to do authorization (-a cyrus -u user). Only PLAIN and DIGEST-MD5 can do that. Because you use saslauthd, you are bound to PLAIN. I would guess, the first time you type the Password LOGIN is used, the second time PLAIN. Thanks your advice provided the solution! Rudy -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Rudy Gevaert [EMAIL PROTECTED] tel:+32 9 264 4734 Directie ICT, afd. Infrastructuur Direction ICT, Infrastructure dept. Groep Systemen Systems group Universiteit Gent Ghent University Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: sync_server memory leak with giant new mailbox first sync
I saw this problem the first time I enabled replication on a machine hosting all the IT support staff the University of Michigan. Plenty of large mailboxes there! My solution (such as it is) was to reduce the wasteful amount of space sync_server was allocating per message: --- cyrus-imapd-2.3.7/imap/sync_support.c 2006-06-14 14:03:24.0 -0400 +++ cyrus-imapd-2.3.7p3/imap/sync_support.c 2006-07-29 12:34:59.0 -0400 @@ -912,9 +912,9 @@ result = xzmalloc(sizeof(struct sync_message)); message_uuid_set_null(result-uuid); -result-msg_path = xzmalloc(5 * (MAX_MAILBOX_PATH+1) * sizeof (char)); +result-msg_path = xzmalloc((MAX_MAILBOX_PATH+1) * sizeof(char)); result-msg_path_end = result-msg_path + - 5 * (MAX_MAILBOX_PATH+1) * sizeof(char); + (MAX_MAILBOX_PATH+1) * sizeof(char); snprintf(result-stagename, sizeof(result-stagename), %lu., l-count); The times-5 is completely gratuitous. In fact the pre-allocation of any memory for paths is wasteful, but I was not up for reengineering the memory scheme in sync_server at the time. To solve the 1000- messages-RESTART transition, I wonder if the client couldn't just initiate the transition. After all, how smart is it to transmit 1000 messages before deciding that a more efficient approach might be needed? Especially since sync_client has an idea of how many messages it's going to attempt to send. :wes On 10 Sep 2006, at 11:15, Bron Gondwana wrote: When sync_client has a large folder to send (for the sake of far too many hours of me trying to make this work let's just say it's 180,000 messages), then it just sends a single UPLOAD [lastuid] [lastappenddate] followed by every single message on after the other. There's logic on the server end to send a [RESTART] back after 1000 new files arrive, but it doesn't get to be called until all 180,000 messages have arrived... or at least it would be if the sync_server process didn't receive a SIGABRT somewhere around 102,000 messages in. I tried all sorts of things to find the underlying cause, then finally just watched 'top' on the sync_server machine as it ran. This machine has 8Gb of memory, and was seeing over 30% being used by this one sync_server before it died! Well, the attached isn't the most elegant patch in the world, and may not be the best way to solve the problem, but at least it got that user replicated and happy. The first time we had to deal with it was moving the user off a corrupted filesystem that I could only mount read-only, and it took about 3 hours for each run to fail thanks to the insanely high IO load on that drive unit, so debugging was more of a pain than you'd hope. I hope something inspired by this can be merged upstream to solve the spam sync_server until it falls over failure mode. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Integrted tool for adminstering Cyrus IMAP and LDAP.
I have to deploy an Email Server based on Cyrus IMAP, Postfix and LDAP. This is no problem, I have done it before.However our customer requests for a web based tool for administering user accounts and quotas. We found tools capable of administering accounts in the LDAP Server (ie LDAPmyADMIN) or cyrus accounts, but not an integrated tool.We want a tool where you can create a Cyrus account with LDAP autentication filling one web based form, Same with modifications and deletions. Does someone has something to recomend? Thanks in advance. A/P Andres Tarallo WDB Consultores Montevideo - Uruguay Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
