hi all,
had the chance to do some testing with sogo's activesync on several
different centos6-x64 virtual machines running:
*OS*
centos6-x64 6.5 all updates applied
*sogo install*
sogo-2.1.2.20140208-1.centos6.x86_64
sogo-activesync-2.1.2.20140208-1.centos6.x86_64
sope49-core-4.9-20131204_1664.el6.1.x86_64
sope49-gdl1-4.9-20131204_1664.el6.1.x86_64
sope49-ldap-4.9-20131204_1664.el6.1.x86_64
sope49-appserver-4.9-20131204_1664.el6.1.x86_64
sope49-gdl1-contentstore-2.1.2.20140208-1.centos6.x86_64
sope49-xml-4.9-20131204_1664.el6.1.x86_64
sope49-mime-4.9-20131204_1664.el6.1.x86_64
sope49-sbjson-2.3.1-20131204_1664.el6.1.x86_64
sope49-gdl1-mysql-4.9-20131204_1664.el6.1.x86_64
sope49-cards-2.1.2.20140208-1.centos6.x86_64
*devices*
Apple-iPad1C1/902.206 -- a 1st generation ipad with last possible IOS update
SAMSUNG-GT-I9300/101.403 -- Samsung S3 with Android 4.3
a) connect direct without proxy
tried to connect devices on a closed lan directly to sogo by setting the
activesync server to:
172.16.35.13:20000/SOGo
it takes patience with the apple to timeout and finally let you uncheck
ssl, whereas the droid phone is easy. both devices pretty much failed --
could not receive mail and contact and calendar syncing was problematic.
this is an interesting experiment which led me to conclude that the
libraries specified with a http/https proxy are required to make it work.
b) connect with nginx proxy
lots of errors coming from nginx about proxy timeouts -- i increased
timeouts, could get some mail through, but sogo was way too slow to sync
(compared to a z-push) -- calendar and contacts problematic. complaints
about no available child process to connect to.
<pre>
server {
listen 443;
server_name s.domain.net;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
location ^~ /Microsoft-Server-ActiveSync {
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffers 32 4k;
proxy_redirect off;
proxy_pass http://127.0.0.1:20000/SOGo/Microsoft-Server-ActiveSync;
}
location /.woa/WebServerResources/ {
alias /usr/lib64/GNUstep/SOGo/WebServerResources/;
}
location /SOGo.woa/WebServerResources/ {
alias /usr/lib64/GNUstep/SOGo/WebServerResources/;
}
location /SOGo/WebServerResources/ {
alias /usr/lib64/GNUstep/SOGo/WebServerResources/;
}
location ^/SOGo/so/ControlPanel/Products/([^/]*)/Resources/(.*)$ {
alias /usr/lib64/GNUstep/SOGo/$1.SOGo/Resources/$2;
}
}
</pre>
c)connect with apache proxy
apache with stock SOGo.conf, sogo web page is perfect. same issues with
nginx -- plenty of complaints about proxy timeouts waiting for a response.
d) what's up with the no available worker instances?
checked my sogo.conf and i have:
SxVMemLimit = 2000;
WOLogFile = "/var/log/sogo/sogo.log";
WOPidFile = "/var/log/sogo/sogo.pid";
WOPort = 20000;
WOWorkersCount = 32;
hmmmm how is this wrong? did `ps -eaf | grep sogod` and i see that the
worker count is 3. then i check /etc/init.d/sogod file and find:
PREFORK=3
<snip>
DAEMON_OPTS="-WOWorkersCount $PREFORK -WOPidFile $PIDFILE -WOLogFile
$LOGFILE"
ahhh -- so any configuration file directives are overwritten here in the
startup script -- so i changed daemon options to:
DAEMON_OPTS="-WOPidFile $PIDFILE"
and restarted sogod -- better now -- plenty of sogo worker instances, so
i retried the above tests. if effect, daemons get `locked` while waiting
for responses from the proxy or/device and if you do a `service sogod
stop`, you are left with many sogod processes which refuse to die. only
way to startup clean is to do a `killall -9 -u sogo`.
that takes em out, however, after clean restarts and hours of testing,
still no joy at all. i get some syncing to work, but mail notifications
are slow to happen (if at all) and syncing contacts and calendars is
also painful.
hope this helps.
thanks
mayak
--
users@sogo.nu
https://inverse.ca/sogo/lists
