Discussion:
Cyrus tweaks (slow on roundcube)
Paul Bronson
2015-09-06 02:22:00 UTC
Permalink
Okay guys, I have put a lot of research into this so bear with me.

Here's what I am up against. I have been working with RC (roundcube) for a
long time and I know some awesome mySQL tweaks that work wonders, etc. My
tweaks haven't done a single thing for the kolab install. This the first
time I've worked with memcache. So here's my config before I proceed:

// IMAP Server Settings
$config['default_host'] = 'localhost';
$config['default_port'] = 143;
$config['imap_delimiter'] = '/';
$config['imap_force_lsub'] = true;

// Caching and storage settings
$config['imap_cache'] = 'memcache';
$config['imap_cache_ttl'] = '10d';
$config['messages_cache'] = 'db';
$config['message_cache_ttl'] = '10d';
$config['session_storage'] = 'db';

// SMTP Server Settings
$config['smtp_server'] = 'tls://localhost';
$config['smtp_port'] = 587;
$config['smtp_user'] = '%u';
$config['smtp_pass'] = '%p';
$config['smtp_helo_host'] = $_SERVER["HTTP_HOST"];


I did notice that when I turn off tls on:

$config['smtp_server'] = 'tls://localhost';

that I can't log into RC, it seems to want to force me to use TLS, which I
read somewhere else. Not sure if this is the culprit here.

CHATTRSYNC is off on cyrus already (by default I guess?)

I've installed imapproxy which seems to be working as far as the logs are
concerned, but I STILL get about 3-4-5 second delay when opening through
email. I have since uninstalled the imapproxy... Memcache is working
properly according to the simply ps aux command or memcache-tool command
but it still seems slow on RC, doesn't seem to have made a difference. I
get these constant logs:

Sep 5 20:54:51 es1 imap[2281]: login: localhost [::1]
***@domain.com PLAIN+TLS
User logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
Sep 5 20:54:51 es1 imap[2281]: USAGE ***@domain.com user: 0.009998
sys: 0.006999

It logs everytime the user makes a click or opens an email. Again,
imapproxy didn't work much.. I tried disabling TLS, tried changing the
cache methods.. Have been doing research pretty much all day trying to
tweak this. Some have said comment out the kolab files plugin, that didn't
make any difference at all. Cyrus just seems to take forever for some
reason.. I am talking 4-5 seconds waiting before the email even shows on
the screen.

memcache conf:

PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="1024"
OPTIONS="-l 127.0.0.1"
OPTIONS="-vv >> /var/log/memcached 2>&1"

I tried increasing cache size, didn't help (not that I thought it would
either)... I am getting a little desperate here.

I changed php.ini to memory_limit = 4096M... Already kicked up my innodb
performance settings tuned like my fast non-kolab servers.. I don't think
its a mysql problem either.. The problem is with the

Any ideas as to why this is so slow compared to my non-kolab RC install I
have going right now (dovecot based)?

By the way, this server has two active email accounts on it.. No load what
so ever.

Kolab 3.4, centos 6

I am not sure what else to try to make cyrus faster!!! Can someone suggest
something?
Paul Bronson
2015-09-06 16:26:55 UTC
Permalink
Anyone have any ideas on this?
Post by Paul Bronson
Okay guys, I have put a lot of research into this so bear with me.
Here's what I am up against. I have been working with RC (roundcube) for a
long time and I know some awesome mySQL tweaks that work wonders, etc. My
tweaks haven't done a single thing for the kolab install. This the first
// IMAP Server Settings
$config['default_host'] = 'localhost';
$config['default_port'] = 143;
$config['imap_delimiter'] = '/';
$config['imap_force_lsub'] = true;
// Caching and storage settings
$config['imap_cache'] = 'memcache';
$config['imap_cache_ttl'] = '10d';
$config['messages_cache'] = 'db';
$config['message_cache_ttl'] = '10d';
$config['session_storage'] = 'db';
// SMTP Server Settings
$config['smtp_server'] = 'tls://localhost';
$config['smtp_port'] = 587;
$config['smtp_user'] = '%u';
$config['smtp_pass'] = '%p';
$config['smtp_helo_host'] = $_SERVER["HTTP_HOST"];
$config['smtp_server'] = 'tls://localhost';
that I can't log into RC, it seems to want to force me to use TLS, which I
read somewhere else. Not sure if this is the culprit here.
CHATTRSYNC is off on cyrus already (by default I guess?)
I've installed imapproxy which seems to be working as far as the logs are
concerned, but I STILL get about 3-4-5 second delay when opening through
email. I have since uninstalled the imapproxy... Memcache is working
properly according to the simply ps aux command or memcache-tool command
but it still seems slow on RC, doesn't seem to have made a difference. I
User logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
sys: 0.006999
It logs everytime the user makes a click or opens an email. Again,
imapproxy didn't work much.. I tried disabling TLS, tried changing the
cache methods.. Have been doing research pretty much all day trying to
tweak this. Some have said comment out the kolab files plugin, that didn't
make any difference at all. Cyrus just seems to take forever for some
reason.. I am talking 4-5 seconds waiting before the email even shows on
the screen.
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="1024"
OPTIONS="-l 127.0.0.1"
OPTIONS="-vv >> /var/log/memcached 2>&1"
I tried increasing cache size, didn't help (not that I thought it would
either)... I am getting a little desperate here.
I changed php.ini to memory_limit = 4096M... Already kicked up my innodb
performance settings tuned like my fast non-kolab servers.. I don't think
its a mysql problem either.. The problem is with the
Any ideas as to why this is so slow compared to my non-kolab RC install I
have going right now (dovecot based)?
By the way, this server has two active email accounts on it.. No load what
so ever.
Kolab 3.4, centos 6
I am not sure what else to try to make cyrus faster!!! Can someone suggest
something?
Bron Gondwana
2015-09-06 23:57:19 UTC
Permalink
On a Sunday night?  Not really.

So Cyrus itself isn't this slow unless you have a horrible IO system
under it or so little RAM that you can't fit the entire index into
memory and it goes swapping.

A possible issue would be failed DNS resolution on every connect, so you
could check your hosts file to make sure localhost is mentioned (or
change the default_host to 127.0.0.1 to avoid the name lookup at all).

I don't know WTF Kolab are doing with chattrsync.  Cyrus uses fdatasync
correctly to avoid losing data already - if it doesn't that's a really
serious bug, but I'm pretty sure I've audited everything.

So basically - check your IO speeds, and check your DNS.  Anything more
than that, I'd need to see the system or know more about how Kolab
itself is set up.

Bron.
Post by Paul Bronson
Anyone have any ideas on this?
On Sat, Sep 5, 2015 at 10:22 PM, Paul Bronson
Post by Paul Bronson
Okay guys, I have put a lot of research into this so bear with me.
Here's what I am up against. I have been working with RC (roundcube)
for a long time and I know some awesome mySQL tweaks that work
wonders, etc. My tweaks haven't done a single thing for the kolab
install. This the first time I've worked with memcache. So here's my
// IMAP Server Settings    $config['default_host'] = 'localhost';
$config['default_port'] = 143;    $config['imap_delimiter'] = '/';
$config['imap_force_lsub'] = true;
// Caching and storage settings    $config['imap_cache'] =
'memcache';    $config['imap_cache_ttl'] = '10d';
$config['messages_cache'] = 'db';    $config['message_cache_ttl'] =
'10d';    $config['session_storage'] = 'db';
// SMTP Server Settings    $config['smtp_server'] =
'tls://localhost';    $config['smtp_port'] = 587;
$config['smtp_user'] = '%u';    $config['smtp_pass'] = '%p';
$config['smtp_helo_host'] = $_SERVER["HTTP_HOST"];
$config['smtp_server'] = 'tls://localhost';
that I can't log into RC, it seems to want to force me to use TLS,
which I read somewhere else. Not sure if this is the culprit here.
CHATTRSYNC is off on cyrus already (by default I guess?)
I've installed imapproxy which seems to be working as far as the logs
are concerned, but I STILL get about 3-4-5 second delay when opening
through email. I have since uninstalled the imapproxy... Memcache is
working properly according to the simply ps aux command or memcache-
tool command but it still seems slow on RC, doesn't seem to have made
Sep  5 20:54:51 es1 imap[2281]: login: localhost [::1]
15740725055571902363> Sep  5 20:54:51 es1 imap[2281]: USAGE
It logs everytime the user makes a click or opens an email. Again,
imapproxy didn't work much.. I tried disabling TLS, tried changing
the cache methods.. Have been doing research pretty much all day
trying to tweak this. Some have said comment out the kolab files
plugin, that didn't make any difference at all. Cyrus just seems to
take forever for some reason.. I am talking 4-5 seconds waiting
before the email even shows on the screen.
PORT="11211" USER="memcached" MAXCONN="1024" CACHESIZE="1024" OPTIONS="-
l 127.0.0.1" OPTIONS="-vv >> /var/log/memcached 2>&1"
I tried increasing cache size, didn't help (not that I thought it
would either)... I am getting a little desperate here.
I changed php.ini to memory_limit = 4096M... Already kicked up my
innodb performance settings tuned like my fast non-kolab servers.. I
don't think its a mysql problem either.. The problem is with the
Any ideas as to why this is so slow compared to my non-kolab RC
install I have going right now (dovecot based)?
By the way, this server has two active email accounts on it.. No load
what so ever.
Kolab 3.4, centos 6
I am not sure what else to try to make cyrus faster!!! Can someone
suggest something?
----
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
  Bron Gondwana
  ***@fastmail.fm
s***@gmail.com
2015-09-07 01:15:38 UTC
Permalink
Haha hey bron. Sorry, I'm a 24/7 workaholic. :)

I don't think it's IO. It's a VM on a HA cluster. The node its on is 64GB of RAM, I have 1 user and assigned everything to it for now. Everything else runs beautifully on it the identical nodes. I have similar setups (non kolab) that run off of dovecot and runs fantastic. Other file intensive apps also work well.

Some of the cyrus.conf

configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus-admin
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
sasl_pwcheck_method: auxprop saslauthd
sasl_mech_list: PLAIN LOGIN
allowplaintext: no
tls_server_cert: /etc/pki/cyrus-imapd/cyrus-imapd.pem
tls_server_key: /etc/pki/cyrus-imapd/cyrus-imapd.pem
# uncomment this if you're operating in a DSCP environment (RFC-4594)
# qosmarking: af13
auth_mech: pts
pts_module: ldap
ldap_servers: ldap://localhost:389
ldap_sasl: 0


Hosts file is fine I checked that, thanks. Kolab uses 389 to authenticate for everything, so Cyrus is using LDAP as you can see above. I think the problem lies in the constant TLS logins into Cyrus for every click:

imap[2281]: login: localhost [::1] ***@domain.com PLAIN+TLS User logged in SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
Sep 5 20:54:51 es1 imap[2281]: USAGE ***@domain.com user: 0.009998 sys: 0.006999


Again its only one user, on roundcube... I am afraid to put any more users on it. There doesn't seem to be much of performance tweaks with Cyrus around the web either...
On a Sunday night? Not really.
So Cyrus itself isn't this slow unless you have a horrible IO system under it or so little RAM that you can't fit the entire index into memory and it goes swapping.
A possible issue would be failed DNS resolution on every connect, so you could check your hosts file to make sure localhost is mentioned (or change the default_host to 127.0.0.1 to avoid the name lookup at all).
I don't know WTF Kolab are doing with chattrsync. Cyrus uses fdatasync correctly to avoid losing data already - if it doesn't that's a really serious bug, but I'm pretty sure I've audited everything.
So basically - check your IO speeds, and check your DNS. Anything more than that, I'd need to see the system or know more about how Kolab itself is set up.
Bron.
Post by Paul Bronson
Anyone have any ideas on this?
Okay guys, I have put a lot of research into this so bear with me.
// IMAP Server Settings
$config['default_host'] = 'localhost';
$config['default_port'] = 143;
$config['imap_delimiter'] = '/';
$config['imap_force_lsub'] = true;
// Caching and storage settings
$config['imap_cache'] = 'memcache';
$config['imap_cache_ttl'] = '10d';
$config['messages_cache'] = 'db';
$config['message_cache_ttl'] = '10d';
$config['session_storage'] = 'db';
// SMTP Server Settings
$config['smtp_server'] = 'tls://localhost';
$config['smtp_port'] = 587;
$config['smtp_user'] = '%u';
$config['smtp_pass'] = '%p';
$config['smtp_helo_host'] = $_SERVER["HTTP_HOST"];
$config['smtp_server'] = 'tls://localhost';
that I can't log into RC, it seems to want to force me to use TLS, which I read somewhere else. Not sure if this is the culprit here.
CHATTRSYNC is off on cyrus already (by default I guess?)
It logs everytime the user makes a click or opens an email. Again, imapproxy didn't work much.. I tried disabling TLS, tried changing the cache methods.. Have been doing research pretty much all day trying to tweak this. Some have said comment out the kolab files plugin, that didn't make any difference at all. Cyrus just seems to take forever for some reason.. I am talking 4-5 seconds waiting before the email even shows on the screen.
PORT="11211"
USER="memcached"
MAXCONN="1024"
CACHESIZE="1024"
OPTIONS="-l 127.0.0.1"
OPTIONS="-vv >> /var/log/memcached 2>&1"
I tried increasing cache size, didn't help (not that I thought it would either)... I am getting a little desperate here.
I changed php.ini to memory_limit = 4096M... Already kicked up my innodb performance settings tuned like my fast non-kolab servers.. I don't think its a mysql problem either.. The problem is with the
Any ideas as to why this is so slow compared to my non-kolab RC install I have going right now (dovecot based)?
By the way, this server has two active email accounts on it.. No load what so ever.
Kolab 3.4, centos 6
I am not sure what else to try to make cyrus faster!!! Can someone suggest something?
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Bron Gondwana
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Rudy Gevaert
2015-09-07 01:50:26 UTC
Permalink
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?

Is saslauthd compiled against /dev/urandom?

Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Rudy Gevaert e-mail: ***@UGent.be
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
s***@gmail.com
2015-09-07 02:15:15 UTC
Permalink
Hey Rudy!

As far as entropy: Probably not, it's brand new. One user (me.. Testing) is playing on it. This is something I've never touched and know very little about, can you explain?

And can you explain: Is saslauthd compiled against /dev/urandom?

Thanks again guys..

- Paul




Sent from my iPhone
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Bron Gondwana
2015-09-07 04:26:36 UTC
Permalink
Yeah, so tls to localhost is dumb. That's security theatre at its silliest. Best to turn that off.

Here's some possibilities to make it not required:

imapd.conf:
allowplaintext: yes
sasl_mech_list: PLAIN LOGIN

There used to be a sasl layer thing we did too... "-p 1" in cyrus.conf for the imapd line that listens on localhost will tell sasl that you already have a protection layer.

Bron.
Post by s***@gmail.com
Hey Rudy!
As far as entropy: Probably not, it's brand new. One user (me.. Testing) is playing on it. This is something I've never touched and know very little about, can you explain?
And can you explain: Is saslauthd compiled against /dev/urandom?
Thanks again guys..
- Paul
Sent from my iPhone
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Bron Gondwana
***@fastmail.fm
Paul Bronson
2015-09-07 18:25:00 UTC
Permalink
Bron,

I found the issue. I've logged this with Kolab. Their plugins are
initiating unneeded imap logins every time the user simply select a
message. If you are interested, here's the bug report.

https://issues.kolab.org/show_bug.cgi?id=5219

Thanks for all your help!!!
Post by Bron Gondwana
Yeah, so tls to localhost is dumb. That's security theatre at its
silliest. Best to turn that off.
allowplaintext: yes
sasl_mech_list: PLAIN LOGIN
There used to be a sasl layer thing we did too... "-p 1" in cyrus.conf for
the imapd line that listens on localhost will tell sasl that you already
have a protection layer.
Bron.
Post by s***@gmail.com
Hey Rudy!
As far as entropy: Probably not, it's brand new. One user (me.. Testing)
is playing on it. This is something I've never touched and know very little
about, can you explain?
Post by s***@gmail.com
And can you explain: Is saslauthd compiled against /dev/urandom?
Thanks again guys..
- Paul
Sent from my iPhone
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
Post by s***@gmail.com
Post by Rudy Gevaert
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264
4750
Post by s***@gmail.com
Post by Rudy Gevaert
Universiteit Gent fax: +32 9 264
4994
Post by s***@gmail.com
Post by Rudy Gevaert
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie
www.UGent.be
Post by s***@gmail.com
Post by Rudy Gevaert
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
Post by s***@gmail.com
Post by Rudy Gevaert
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Bron Gondwana
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
s***@gmail.com
2015-09-08 22:04:52 UTC
Permalink
Bron,

So the kolab guys got back to me and said this is done purposely to check against cache. I am CCing the kolab user list and fwith many active users who are watching over this scenario and well as a few friends too.

Can you think of any other reasons that this auth process would be slow? Again it's not horribly slow just it's noticeable for those that use roundcube with less of this "check ins" from multiple roundcube plugins during each message select. I suspect that the four plugins mentioned in the bug I reported are checking in with IMAP with each and EVERY message view (just viewing messages without changing folders)

They're wondering why my installation is so slow. Again, don't think it's the IO, it's running on a pretty high tech environment.

Any logs or anything I can provide for further analysis on the Cyrus end of things?

Thanks again man!

- Paul
Post by Bron Gondwana
Yeah, so tls to localhost is dumb. That's security theatre at its silliest. Best to turn that off.
allowplaintext: yes
sasl_mech_list: PLAIN LOGIN
There used to be a sasl layer thing we did too... "-p 1" in cyrus.conf for the imapd line that listens on localhost will tell sasl that you already have a protection layer.
Bron.
Post by s***@gmail.com
Hey Rudy!
As far as entropy: Probably not, it's brand new. One user (me.. Testing) is playing on it. This is something I've never touched and know very little about, can you explain?
And can you explain: Is saslauthd compiled against /dev/urandom?
Thanks again guys..
- Paul
Sent from my iPhone
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Bron Gondwana
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Bron Gondwana
2015-09-09 04:26:55 UTC
Permalink
Slow auth would be down to your authentication config or authentication daemon. We run a custom saslauthd at FastMail and it's plenty fast, so that's purely down to how Kolab is set up.

I don't know how Kolab works well enough to help here sorry.

Bron.
Post by s***@gmail.com
Bron,
So the kolab guys got back to me and said this is done purposely to check against cache. I am CCing the kolab user list and fwith many active users who are watching over this scenario and well as a few friends too.
Can you think of any other reasons that this auth process would be slow? Again it's not horribly slow just it's noticeable for those that use roundcube with less of this "check ins" from multiple roundcube plugins during each message select. I suspect that the four plugins mentioned in the bug I reported are checking in with IMAP with each and EVERY message view (just viewing messages without changing folders)
They're wondering why my installation is so slow. Again, don't think it's the IO, it's running on a pretty high tech environment.
Any logs or anything I can provide for further analysis on the Cyrus end of things?
Thanks again man!
- Paul
Post by Bron Gondwana
Yeah, so tls to localhost is dumb. That's security theatre at its silliest. Best to turn that off.
allowplaintext: yes
sasl_mech_list: PLAIN LOGIN
There used to be a sasl layer thing we did too... "-p 1" in cyrus.conf for the imapd line that listens on localhost will tell sasl that you already have a protection layer.
Bron.
Post by s***@gmail.com
Hey Rudy!
As far as entropy: Probably not, it's brand new. One user (me.. Testing) is playing on it. This is something I've never touched and know very little about, can you explain?
And can you explain: Is saslauthd compiled against /dev/urandom?
Thanks again guys..
- Paul
Sent from my iPhone
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Bron Gondwana
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
--
Bron Gondwana
***@fastmail.fm
s***@gmail.com
2015-09-07 03:08:09 UTC
Permalink
Rudy,

Entropy is 158 I just looked. And as far as compiling against urandom, to be honest I'm
not sure.

- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Andre Felipe Machado
2015-09-10 21:00:48 UTC
Permalink
Hello,
Entropy of 158 is way too low for production servers. And this *MAY* cause weird
slowness without logging any errors.
You could install "haveged" and configure for max threshold levels on production
servers.
https://packages.debian.org/search?keywords=haveged

Regards.

Andre Felipe
http://www.techforce.com.br
Post by s***@gmail.com
Rudy,
Entropy is 158 I just looked. And as far as compiling against urandom, to be
honest
Post by s***@gmail.com
I'm
not sure.
- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
s***@gmail.com
2015-09-10 21:24:58 UTC
Permalink
Andre,

Really? What should it be? I was curious and checked.. Entropy on some of my other big time production servers for email is only about 200) and its lightning fast?

- Paul
Post by Andre Felipe Machado
Hello,
Entropy of 158 is way too low for production servers. And this *MAY* cause weird
slowness without logging any errors.
You could install "haveged" and configure for max threshold levels on production
servers.
https://packages.debian.org/search?keywords=haveged
Regards.
Andre Felipe
http://www.techforce.com.br
Post by s***@gmail.com
Rudy,
Entropy is 158 I just looked. And as far as compiling against urandom, to be
honest
Post by s***@gmail.com
I'm
not sure.
- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Paul Bronson
2015-09-11 00:14:30 UTC
Permalink
Guys,

I ran cat /dev/urandom | rngtest -c 1000

and got:

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=22.980; avg=501.129;
max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=98.317; avg=121.603; max=131.541)Mibits/s
rngtest: Program run time: 198018 microseconds


Does this look bad to you considering all of my slow SASL auths? (no
haveged is on at this point.. available entropy is between 131 - 160...
pool size is default 4096.

I also tried installing haveged, which worked fine, but as soon as I
started the service it said something like process dead, sub sys locked...
? Sorry, entropy is fairly new to me.
Post by s***@gmail.com
Andre,
Really? What should it be? I was curious and checked.. Entropy on some of
my other big time production servers for email is only about 200) and its
lightning fast?
- Paul
On Sep 10, 2015, at 5:00 PM, Andre Felipe Machado <
Hello,
Entropy of 158 is way too low for production servers. And this *MAY*
cause weird
slowness without logging any errors.
You could install "haveged" and configure for max threshold levels on
production
servers.
https://packages.debian.org/search?keywords=haveged
Regards.
Andre Felipe
http://www.techforce.com.br
Post by s***@gmail.com
Rudy,
Entropy is 158 I just looked. And as far as compiling against urandom,
to be
honest
Post by s***@gmail.com
I'm
not sure.
- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264
4750
Post by s***@gmail.com
Post by Rudy Gevaert
Universiteit Gent fax: +32 9 264
4994
Post by s***@gmail.com
Post by Rudy Gevaert
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie
www.UGent.be
Post by s***@gmail.com
Post by Rudy Gevaert
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
s***@gmail.com
2015-09-11 02:33:17 UTC
Permalink
Is there some type of log I can provide from Cyrus / sasl to help diagnose this better to the kolab guys? Other kolab guys I know say their entropy is right where I'm at and they aren't experiencing these slowness issues.

Are their sasl or Cyrus logs I can provide?

- Paul
Post by Andre Felipe Machado
Hello,
Entropy of 158 is way too low for production servers. And this *MAY* cause weird
slowness without logging any errors.
You could install "haveged" and configure for max threshold levels on production
servers.
https://packages.debian.org/search?keywords=haveged
Regards.
Andre Felipe
http://www.techforce.com.br
Post by s***@gmail.com
Rudy,
Entropy is 158 I just looked. And as far as compiling against urandom, to be
honest
Post by s***@gmail.com
I'm
not sure.
- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Andrew Morgan
2015-09-11 18:47:09 UTC
Permalink
Post by s***@gmail.com
Is there some type of log I can provide from Cyrus / sasl to help
diagnose this better to the kolab guys? Other kolab guys I know say
their entropy is right where I'm at and they aren't experiencing these
slowness issues.
Are their sasl or Cyrus logs I can provide?
Maybe I missed this detail earlier in the thread, but why not run an IMAP
proxy to reduce the rate of new connections to Cyrus? Making a new IMAP
connection with every click seems abusive! :)

Andy
s***@gmail.com
2015-09-11 18:55:57 UTC
Permalink
I tried imapproxy. It is the same speed. And again, definitely not hardware related.

I see in the logs in queries the proxy and that works fine but not sure why it's still the same speed.


- Paul
Post by s***@gmail.com
Is there some type of log I can provide from Cyrus / sasl to help diagnose this better to the kolab guys? Other kolab guys I know say their entropy is right where I'm at and they aren't experiencing these slowness issues.
Are their sasl or Cyrus logs I can provide?
Maybe I missed this detail earlier in the thread, but why not run an IMAP proxy to reduce the rate of new connections to Cyrus? Making a new IMAP connection with every click seems abusive! :)
Andy
Andrew Morgan
2015-09-11 20:03:04 UTC
Permalink
I use imapproxy with Horde Webmail here. Assuming the proxy is using
cached connections instead of making a new connection each click, then I
would look into performance problems within Cyrus itself. It would be
interesting to see what IMAP commands Roundcube is issuing to Cyrus.
Perhaps it is doing something "stupid" like retrieving all the message
bodies on each click?

If you haven't already, try enabling telemetry logging for a single user
and check the telemetry log files. If you can post some of those logs
here, we may be able to identify the problem.

Thanks,
Andy
Post by s***@gmail.com
I tried imapproxy. It is the same speed. And again, definitely not hardware related.
I see in the logs in queries the proxy and that works fine but not sure why it's still the same speed.
- Paul
Post by s***@gmail.com
Is there some type of log I can provide from Cyrus / sasl to help diagnose this better to the kolab guys? Other kolab guys I know say their entropy is right where I'm at and they aren't experiencing these slowness issues.
Are their sasl or Cyrus logs I can provide?
Maybe I missed this detail earlier in the thread, but why not run an IMAP proxy to reduce the rate of new connections to Cyrus? Making a new IMAP connection with every click seems abusive! :)
Andy
Andre Felipe Machado
2015-09-11 17:54:31 UTC
Permalink
Hello,
We setup haveged threshold at 2048 (its max pool size is 4096 , afaik) for our
high load cyrus imap servers.
At our cyrus imap servers the depletion bursts are amazing.....
Watch the entropy available during your peak ours and you will get an overview
of your needs.
Regards.
Andre Felipe
Post by s***@gmail.com
Andre,
Really? What should it be? I was curious and checked.. Entropy on some of my other
big time production servers for email is only about 200) and its lightning fast?
- Paul
On Sep 10, 2015, at 5:00 PM, Andre Felipe Machado
Hello,
Entropy of 158 is way too low for production servers. And this *MAY* cause weird
slowness without logging any errors.
You could install "haveged" and configure for max threshold levels on production
servers.
https://packages.debian.org/search?keywords=haveged
Regards.
Andre Felipe
http://www.techforce.com.br
Post by s***@gmail.com
Rudy,
Entropy is 158 I just looked. And as far as compiling against urandom, to be
honest
Post by s***@gmail.com
I'm
not sure.
- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
s***@gmail.com
2015-09-11 18:17:36 UTC
Permalink
When I installed havaged the process died instantly and gives me a locked sub system. If I restart it again, instantly dies again. Im on centos. Any ideas why this is happening?
Anyone else experienced this?

- Paul
Post by Andre Felipe Machado
Hello,
We setup haveged threshold at 2048 (its max pool size is 4096 , afaik) for our
high load cyrus imap servers.
At our cyrus imap servers the depletion bursts are amazing.....
Watch the entropy available during your peak ours and you will get an overview
of your needs.
Regards.
Andre Felipe
Post by s***@gmail.com
Andre,
Really? What should it be? I was curious and checked.. Entropy on some of my other
big time production servers for email is only about 200) and its lightning fast?
- Paul
On Sep 10, 2015, at 5:00 PM, Andre Felipe Machado
Hello,
Entropy of 158 is way too low for production servers. And this *MAY* cause weird
slowness without logging any errors.
You could install "haveged" and configure for max threshold levels on production
servers.
https://packages.debian.org/search?keywords=haveged
Regards.
Andre Felipe
http://www.techforce.com.br
Post by s***@gmail.com
Rudy,
Entropy is 158 I just looked. And as far as compiling against urandom, to be
honest
Post by s***@gmail.com
I'm
not sure.
- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Andre Felipe Machado
2015-09-11 18:30:26 UTC
Permalink
Hello
This is difficult to diagnose, if not looking at the pool size.
No error is logged, it is only "slow" or even suffering hiccups on extreme loads
and or under specified cpu.

"Every time a process is started, or allocates memory, it will reduce the
entropy pool because entropy is used to randomize the placement of that memory."
https://www.reddit.com/r/linux/comments/2hu9za/watch_the_amount_of_entropy_your_system_has/ckwi415

https://www.reddit.com/r/linux/comments/2hu9za/watch_the_amount_of_entropy_your_system_has/

Maybe others have better suggestions.
Regards.
Andre Felipe
Post by s***@gmail.com
Is there some type of log I can provide from Cyrus / sasl to help diagnose this
better to the kolab guys? Other kolab guys I know say their entropy is right where
I'm at and they aren't experiencing these slowness issues.
Are their sasl or Cyrus logs I can provide?
- Paul
On Sep 10, 2015, at 5:00 PM, Andre Felipe Machado
Hello,
Entropy of 158 is way too low for production servers. And this *MAY* cause weird
slowness without logging any errors.
You could install "haveged" and configure for max threshold levels on production
servers.
https://packages.debian.org/search?keywords=haveged
Regards.
Andre Felipe
http://www.techforce.com.br
Post by s***@gmail.com
Rudy,
Entropy is 158 I just looked. And as far as compiling against urandom, to be
honest
Post by s***@gmail.com
I'm
not sure.
- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Andre Felipe Machado
2015-09-11 18:59:40 UTC
Permalink
Hello,

By your numbers it seems that your machine is able to generate random numbers at good speed. But the problem is WHEN and HOW OFTEN.

Afaik, the linux kernel waits too long to trigger the process to generate random numbers and fast paced process spawning or ssl connections could deplete pool before the process is triggered again.

This is the problem that haveged could solve. Triggering a random numbers generation at a higher threshold and at higher frequency.

http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/

Well, it is only ONE of possible causes of your problem. Unfortunately one obscure and difficult to identify because it does not generate errors, crashes or logs. Simply slowness.

Had you checked disk latency? Does your servers have enough sasl processes?

We use Debian and did not find haveged installation issues, so you will have to search a bit more about your running errors.

Regards.

Andre Felipe

http://www.techforce.com.br



Paul Bronson <***@gmail.com> wrote .. Guys, I ran cat /dev/urandom | rngtest -c 1000 and got: rngtest: starting FIPS tests... rngtest: bits received from input: 20000032 rngtest: FIPS 140-2 successes: 998 rngtest: FIPS 140-2 failures: 2 rngtest: FIPS 140-2(2001-10-10) Monobit: 0 rngtest: FIPS 140-2(2001-10-10) Poker: 0 rngtest: FIPS 140-2(2001-10-10) Runs: 1 rngtest: FIPS 140-2(2001-10-10) Long run: 1 rngtest: FIPS 140-2(2001-10-10) Continuous run: 0 rngtest: input channel speed: (min=22.980; avg=501.129; max=19073.486)Mibits/s rngtest: FIPS tests speed: (min=98.317; avg=121.603; max=131.541)Mibits/s rngtest: Program run time: 198018 microseconds Does this look bad to you considering all of my slow SASL auths? (no haveged is on at this point.. available entropy is between 131 - 160... pool size is default 4096. I also tried installing haveged, which worked fine, but as soon as I started the service it said something like process dead, sub sys locke!
d... ? So
e-
mail: ***@UGent.be >>> Directie ICT, Afdeling Infrastructuur >>> Groep Systemen tel: +32 9 264 4750 >>> Universiteit Gent fax: +32 9 264 4994 >>> Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be >>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- >>> >>> >>> ---- >>> Cyrus Home Page: http://www.cyrusimap.org/ >>> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ >>> To Unsubscribe: >>> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus >> ---- >> Cyrus Home Page: http://www.cyrusimap.org/ >> List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ >> To Unsubscribe: >> https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > ---- > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo!
/info-cyr
us
s***@gmail.com
2015-09-11 19:12:55 UTC
Permalink
Andre,

Thanks for the info!! Two questions since sasl is still new to me:

1) How many processes should I have running? Is there an option somewhere to adjust this or see it?

2) I installed havaged, but the process instantly crashes and tells me a sub system is locked when I try to restart it. Any ideas on that? (On centos 6)


Thanks again!

- Paul
Post by Andre Felipe Machado
Hello,
By your numbers it seems that your machine is able to generate random numbers at good speed. But the problem is WHEN and HOW OFTEN.
Afaik, the linux kernel waits too long to trigger the process to generate random numbers and fast paced process spawning or ssl connections could deplete pool before the process is triggered again.
This is the problem that haveged could solve. Triggering a random numbers generation at a higher threshold and at higher frequency.
http://blog-ftweedal.rhcloud.com/2014/05/more-entropy-with-haveged/
Well, it is only ONE of possible causes of your problem. Unfortunately one obscure and difficult to identify because it does not generate errors, crashes or logs. Simply slowness.
Had you checked disk latency? Does your servers have enough sasl processes?
We use Debian and did not find haveged installation issues, so you will have to search a bit more about your running errors.
Regards.
Andre Felipe
http://www.techforce.com.br
Guys,
I ran cat /dev/urandom | rngtest -c 1000
rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 998
rngtest: FIPS 140-2 failures: 2
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 1
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=22.980; avg=501.129; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=98.317; avg=121.603; max=131.541)Mibits/s
rngtest: Program run time: 198018 microseconds
Does this look bad to you considering all of my slow SASL auths? (no haveged is on at this point.. available entropy is between 131 - 160... pool size is default 4096.
I also tried installing haveged, which worked fine, but as soon as I started the service it said something like process dead, sub sys locked... ? Sorry, entropy is fairly new to me.
Post by s***@gmail.com
Andre,
Really? What should it be? I was curious and checked.. Entropy on some of my other big time production servers for email is only about 200) and its lightning fast?
- Paul
Post by Andre Felipe Machado
Hello,
Entropy of 158 is way too low for production servers. And this *MAY* cause weird
slowness without logging any errors.
You could install "haveged" and configure for max threshold levels on production
servers.
https://packages.debian.org/search?keywords=haveged
Regards.
Andre Felipe
http://www.techforce.com.br
&g! t;> Ru dy,
Post by Andre Felipe Machado
Post by s***@gmail.com
Entropy is 158 I just looked. And as far as compiling against urandom, to be
honest
Post by s***@gmail.com
I'm
not sure.
- Paul
Post by Rudy Gevaert
Post by s***@gmail.com
Hosts file is fine I checked that, thanks. Kolab uses 389 to
authenticate for everything, so Cyrus is using LDAP as you can see
above. I think the problem lies in the constant TLS logins into
logged in
SESSIONID=<es1.domain.com-2281-1441500890-1-15740725055571902363>
0.009998 sys: 0.006999
Again its only one user, on roundcube... I am afraid to put any more
users on it. There doesn't seem to be much of performance tweaks
with Cyrus around the web either...
does your system have enough entropy?
Is saslauthd compiled against /dev/urandom?
Rudy
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ! -- -- -- -- -- --
Directie ICT, Afdeling Infrastructuur
Groep Systemen tel: +32 9 264 4750
Universiteit Gent fax: +32 9 264 4994
Krijgslaan 281, gebouw S9, 9000 Gent, Belgie www.UGent.be
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Post by s***@gmail.com
;>>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Patrick Boutilier
2015-09-11 19:53:20 UTC
Permalink
Post by s***@gmail.com
Andre,
1) How many processes should I have running? Is there an option
somewhere to adjust this or see it?
2) I installed havaged, but the process instantly crashes and tells me a
sub system is locked when I try to restart it. Any ideas on that? (On
centos 6)
For the lock part look in /var/lock/subsys/ for a file called havaged or
similar.
Post by s***@gmail.com
Thanks again!
- Paul
<snip>
s***@gmail.com
2015-09-11 23:30:36 UTC
Permalink
Hi Patrick,

Then do what with it?

- Paul
Post by s***@gmail.com
Andre,
1) How many processes should I have running? Is there an option
somewhere to adjust this or see it?
2) I installed havaged, but the process instantly crashes and tells me a
sub system is locked when I try to restart it. Any ideas on that? (On
centos 6)
For the lock part look in /var/lock/subsys/ for a file called havaged or similar.
Post by s***@gmail.com
Thanks again!
- Paul
<snip>
<boutilpj.vcf>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Patrick Boutilier
2015-09-12 00:03:12 UTC
Permalink
Delete it. Then you can try to start havaged and see if it crashes again.
Post by s***@gmail.com
Hi Patrick,
Then do what with it?
- Paul
Post by s***@gmail.com
Andre,
1) How many processes should I have running? Is there an option
somewhere to adjust this or see it?
2) I installed havaged, but the process instantly crashes and tells me a
sub system is locked when I try to restart it. Any ideas on that? (On
centos 6)
For the lock part look in /var/lock/subsys/ for a file called havaged or similar.
Post by s***@gmail.com
Thanks again!
- Paul
<snip>
<boutilpj.vcf>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
s***@gmail.com
2015-09-12 01:04:29 UTC
Permalink
Nope, dies instantly and locks it again. "Haveged dead but subsys locked"


- Paul
Post by Patrick Boutilier
Delete it. Then you can try to start havaged and see if it crashes again.
Post by s***@gmail.com
Hi Patrick,
Then do what with it?
- Paul
Post by s***@gmail.com
Andre,
1) How many processes should I have running? Is there an option
somewhere to adjust this or see it?
2) I installed havaged, but the process instantly crashes and tells me a
sub system is locked when I try to restart it. Any ideas on that? (On
centos 6)
For the lock part look in /var/lock/subsys/ for a file called havaged or similar.
Post by s***@gmail.com
Thanks again!
- Paul
<snip>
<boutilpj.vcf>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
<boutilpj.vcf>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
s***@gmail.com
2015-09-12 01:23:53 UTC
Permalink
So I tried:

haveged -r 0

and the service now works but entropy is still 129

- Paul
Post by Patrick Boutilier
Delete it. Then you can try to start havaged and see if it crashes again.
Post by s***@gmail.com
Hi Patrick,
Then do what with it?
- Paul
Post by s***@gmail.com
Andre,
1) How many processes should I have running? Is there an option
somewhere to adjust this or see it?
2) I installed havaged, but the process instantly crashes and tells me a
sub system is locked when I try to restart it. Any ideas on that? (On
centos 6)
For the lock part look in /var/lock/subsys/ for a file called havaged or similar.
Post by s***@gmail.com
Thanks again!
- Paul
<snip>
<boutilpj.vcf>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
<boutilpj.vcf>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
s***@gmail.com
2015-09-12 04:19:26 UTC
Permalink
Okay so I figured out since this is a container and not a VM I can't install haveged on it. Awesome I learned something. Okay now... Next question to solve this insanity.

Can I point everything Cyrus/SASL and TLS Related to use urandom instead of random?

I found this:

http://security.stackexchange.com/a/14399/86596

But I don't want to do something to jeapordize my whole system.

I think this is the last piece of the puzzle.

Thanks again guys.

- Paul
Post by Patrick Boutilier
Delete it. Then you can try to start havaged and see if it crashes again.
Post by s***@gmail.com
Hi Patrick,
Then do what with it?
- Paul
Post by s***@gmail.com
Andre,
1) How many processes should I have running? Is there an option
somewhere to adjust this or see it?
2) I installed havaged, but the process instantly crashes and tells me a
sub system is locked when I try to restart it. Any ideas on that? (On
centos 6)
For the lock part look in /var/lock/subsys/ for a file called havaged or similar.
Post by s***@gmail.com
Thanks again!
- Paul
<snip>
<boutilpj.vcf>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
<boutilpj.vcf>
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Loading...