[SOGo] BTS activities for Thursday, August 07 2014
Title: BTS activities for Thursday, August 07 2014 BTS Activities Home page: http://www.sogo.nu/bugs Project: SOGo For the period covering: Thursday, August 07 2014 idlast updatestatus (resolution)categorysummary 2887 2014-08-07 17:26:45 updated (open) ActiveSync Workerthreads hanging on sync with mobile devices (Android, Blackberry) 2708 2014-08-07 02:23:20 updated (open) OpenChange backend Samba4 - INTERNAL ERROR: Signal 11 2886 2014-08-07 07:55:11 updated (open) Packaging (Debian) /usr/sbin/sogod: Uncaught exception NSInvalidArgumentException, reason: Tried to add nil to array
Re: [SOGo] 2.2.7 - [{"owner"
We re=applied the patch and it's working now. Our tech thinks he may have made a typo the first time. :-) Thanks!! Romeyn On Aug 6, 2014, at 12:33 PM, Romeyn Prescott wrote: > Christian, > > We'll check on the server. > > Thanks, > Romeyn > > On Aug 6, 2014, at 7:33 AM, Christian Mack > wrote: > >> Hello Romeyn Prescott >> >> >> Are you sure, you did apply these changes correctly on a stock 2.2.7 >> SOGo Version? >> >> I happen to have done that yesterday on one system and it worked after >> reloading all JavaScript files in my browser. >> >> >> Kind regards, >> Christian Mack >> >> Am 2014-08-05 17:19, schrieb Romeyn Prescott: >>> Thanks. We did, but now NO calendar shows up under any user. >>> >>> Ideas? >>> Romeyn >>> >>> On Jul 31, 2014, at 7:34 PM, Ludovic Marcotte wrote: >>> On 2014-07-31, 3:35 PM, Romeyn Prescott wrote: > > Thoughts? Apply this: https://github.com/inverse-inc/sogo/commit/f43341c1005d3d5813c23133071c253c753bb3e9 -- Ludovic Marcotte lmarco...@inverse.ca :: +1.514.755.3630 :: http://inverse.ca Inverse inc. :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists >>> >>> -- >>> signat-url: http://www2.potsdam.edu/prescor/signat-url.htm >>> >>> >>> >> >> >> -- >> Christian Mack >> Universität Konstanz >> Kommunikations-, Informations-, Medienzentrum (KIM) >> Abteilung Basisdienste >> 78457 Konstanz >> +49 7531 88-4416 >> > > -- > signat-url: http://www2.potsdam.edu/prescor/signat-url.htm > > > > -- > users@sogo.nu > https://inverse.ca/sogo/lists -- signat-url: http://www2.potsdam.edu/prescor/signat-url.htm -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo Docker Container
https://github.com/openchange/docker/ Cheers, Julien. On 07/08/14 15:55, Martin Karrer wrote: > Hey, > > I’m Computer Science Student from Austria and tried to install SOGo on > a CentOS Server where many other Applications where running. With the > huge list of dependencies an all the shared Libs I had Problem to get > it running without destroying other Applications. > > So my Question is: > > SOGo in a Docker Container? > > > It should be possible and will we have a Container in the Future or do > we have to build a Community Container an Maintain it ourselves? > > Greetings from Austria > > Martin -- Julien Kerihuel j.kerih...@openchange.org OpenChange Project Founder Twitter: http://twitter.com/jkerihuel GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79 signature.asc Description: OpenPGP digital signature
Re: [SOGo] SOGo Docker Container
Hi, I’m already running in a Docker container for my own (not provided by Inverse), but have to resolve some minor issues first before I’ll release it. If everything runs well, I should get round to do it within the next two weeks. I’m already running the container for about two months now without major issues (for a single user) and probably sorted out the major problems already, but still got to think about some things like how to handle upgrades, and change the underlying system to a baseimage already providing the cron daemon and similar things. If you’re really interested in having a look at it I can send you a preliminary version, but it’s still missing documentation (and some nitpicks should be considered in there). Regards from Lake Constance, Germany, Jens -- Jens Erat [phone]: tel:+49-151-56961126 [mail]: mailto:em...@jenserat.de [jabber]: xmpp:jab...@jenserat.de [web]: http://www.jenserat.de PGP: 350E D9B6 9ADC 2DED F5F2 8549 CBC2 613C D745 722B Am 07.08.2014 um 15:55 schrieb Martin Karrer : > Hey, > > I’m Computer Science Student from Austria and tried to install SOGo on a > CentOS Server where many other Applications where running. With the huge list > of dependencies an all the shared Libs I had Problem to get it running > without destroying other Applications. > > So my Question is: > SOGo in a Docker Container? > > It should be possible and will we have a Container in the Future or do we > have to build a Community Container an Maintain it ourselves? > > Greetings from Austria > > Martin smime.p7s Description: S/MIME cryptographic signature
[SOGo] SOGo Docker Container
Hey, I’m Computer Science Student from Austria and tried to install SOGo on a CentOS Server where many other Applications where running. With the huge list of dependencies an all the shared Libs I had Problem to get it running without destroying other Applications. So my Question is: SOGo in a Docker Container? It should be possible and will we have a Container in the Future or do we have to build a Community Container an Maintain it ourselves? Greetings from Austria Martin signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [SOGo] Best practice to force https in SOGo.conf
Just make sure that you have adapted following lines in _default_:443> i.e. to refer only to https and 443 RequestHeader set "x-webobjects-server-port" "*443*" RequestHeader set "x-webobjects-server-name" "sogo.example.com" RequestHeader set "x-webobjects-server-url" "*https*://sogo.example.com" Regards, Igor sr wrote on 07/08/2014 14:35: Hello Sven, hello all, Thanks for the answer, finaly I just put this on httpd.conf and it's work : ServerName yourdomain.yourdomain/SOGo Redirect permanent /SOGo https://yourdomain.yourdomain/SOGo the section is on a separe file named ssl.conf thanks! Le 06/08/2014 17:43, Sven Arnold a écrit : Hello Samuel, What is the best way to force people using HTTPS when they come in sogo site? ( virtual hosts? .htaccess file? ) That depends (of course) on your webserver and setup. If you are using apache you can perform a simple redirect on requests on port 80 similar to: RedirectMatch ^/$ https://yourdomain.yourdomain/SOGo and of course put your SOGo configuration inside of: ... Is there a way to enable https just for authentification? Maybe that is possible, but is this useful? I suppose you do not only want to secure authentication but also email content? Thanks all! Samuel Regards, Sven -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Best practice to force https in SOGo.conf
Hello Sven, hello all, Thanks for the answer, finaly I just put this on httpd.conf and it's work : ServerName yourdomain.yourdomain/SOGo Redirect permanent /SOGo https://yourdomain.yourdomain/SOGo the section is on a separe file named ssl.conf thanks! Le 06/08/2014 17:43, Sven Arnold a écrit : Hello Samuel, What is the best way to force people using HTTPS when they come in sogo site? ( virtual hosts? .htaccess file? ) That depends (of course) on your webserver and setup. If you are using apache you can perform a simple redirect on requests on port 80 similar to: RedirectMatch ^/$ https://yourdomain.yourdomain/SOGo and of course put your SOGo configuration inside of: ... Is there a way to enable https just for authentification? Maybe that is possible, but is this useful? I suppose you do not only want to secure authentication but also email content? Thanks all! Samuel Regards, Sven -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Can not delete mail when over quota bug 2812
And in Dovecot is allowed 10% more for Trash Folder in my configuration, so the deleting mail can be moved to Trash folder first. Kind Regards, Martin Dne 7.8.2014 07:38, Martin Šinský napsal(a): Hi, i did test it by myself, but wrote it not exactly right, sorry. You have absolutely right, permanently deletion is not working, as you have reported in bug 2812. Kind Regards, Martin Dne 6.8.2014 14:02, Christian Mack napsal(a): Hi Martin Šinský You obviously didn't test this problem yourself. SOGo does the right thing already. When it cannot move the email to the trash folder, it asks the user, if she wants to delete it permanently. But the bug is, that even if the user accepts to permanently erase the email this doesn't work. So this is really a bug and not en enhancement request. Just wanted to make this clear. Kind regards, Christian Mack Am 2014-08-06 09:21, schrieb Martin Šinský: Hi, so is the only way to migrate to dovecot, which is not affected by that? I red on cyrus pages: *Q:* Why can't I delete any messages from my over-quota mailbox? I'm using a client with a 'trash folder'. *A:* Trash folders, as they are commonly implemented (as an actual IMAP mailbox), do not fit the IMAP delete/expunge model very well. In fact, naive client implementations will get stuck in a situation where they cannot delete a message from a mailbox because they try to COPY it to the trash folder before deleting the message. This operation will fail due to the mailbox being over quota. This is separate from the fact that a specific mailbox name is not interoperable between clients (one might call it 'trash', another 'Trash', another 'Recycle Bin', etc) Given the lack of protocol support for a trash folder, this is mostly a quality-of-implementation issue on the client side. There are a few options here: * Contact your client vendor to have the broken client fixed (one possibility is to have the client ask the user if they wish to permanantly delete the message if the COPY operation fails). * Stop using the 'trash mailbox' feature of your client (if possible). Is implementing of "the client have to ask the user if they wish to permanantly delete the message if the COPY operation fails" problematic? Regards, Martin Dne 29.7.2014 14:44, Martin Šinský napsal(a): Hi, I have exactly the same problem like here: http://sogo.nu/bugs/view.php?id=2812 on one server with Cyrus. On the seccond server with dovecot is everything ok. This bug is very annoying for the web users, migration to dovecot is now impossible for me. And it is not so good that this solution (Cyrus with this bug) is used in your virtual appliance. I can help with logs or testing or whatever to solve this problem. Please, can someone focus on this? Regards, Martin -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Can not delete mail when over quota bug 2812
Hi, i did test it by myself, but wrote it not exactly right, sorry. You have absolutely right, permanently deletion is not working, as you have reported in bug 2812. Kind Regards, Martin Dne 6.8.2014 14:02, Christian Mack napsal(a): Hi Martin Šinský You obviously didn't test this problem yourself. SOGo does the right thing already. When it cannot move the email to the trash folder, it asks the user, if she wants to delete it permanently. But the bug is, that even if the user accepts to permanently erase the email this doesn't work. So this is really a bug and not en enhancement request. Just wanted to make this clear. Kind regards, Christian Mack Am 2014-08-06 09:21, schrieb Martin Šinský: Hi, so is the only way to migrate to dovecot, which is not affected by that? I red on cyrus pages: *Q:* Why can't I delete any messages from my over-quota mailbox? I'm using a client with a 'trash folder'. *A:* Trash folders, as they are commonly implemented (as an actual IMAP mailbox), do not fit the IMAP delete/expunge model very well. In fact, naive client implementations will get stuck in a situation where they cannot delete a message from a mailbox because they try to COPY it to the trash folder before deleting the message. This operation will fail due to the mailbox being over quota. This is separate from the fact that a specific mailbox name is not interoperable between clients (one might call it 'trash', another 'Trash', another 'Recycle Bin', etc) Given the lack of protocol support for a trash folder, this is mostly a quality-of-implementation issue on the client side. There are a few options here: * Contact your client vendor to have the broken client fixed (one possibility is to have the client ask the user if they wish to permanantly delete the message if the COPY operation fails). * Stop using the 'trash mailbox' feature of your client (if possible). Is implementing of "the client have to ask the user if they wish to permanantly delete the message if the COPY operation fails" problematic? Regards, Martin Dne 29.7.2014 14:44, Martin Šinský napsal(a): Hi, I have exactly the same problem like here: http://sogo.nu/bugs/view.php?id=2812 on one server with Cyrus. On the seccond server with dovecot is everything ok. This bug is very annoying for the web users, migration to dovecot is now impossible for me. And it is not so good that this solution (Cyrus with this bug) is used in your virtual appliance. I can help with logs or testing or whatever to solve this problem. Please, can someone focus on this? Regards, Martin -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Cannot Login to Web Interface after Upgrade to 2.2.5-3 (Debian Package)
Fair enough! I’ll dig through the logs. I appreciate your looking into it.
On Aug 5, 2014, at 8:19 AM, Christian Mack
wrote:
> Hello Ron Scott-Adams
>
> There is no 404 error in your sogo logs.
> Therefore I assume your request never reaches SOGo.
> Then your sogo.conf is irrelevant.
>
> So please check your nginx logs and config.
> (Sorry cannot help you there, as I am not using nginx)
>
>
> Kind regards,
> Christian Mack
>
> Am 2014-08-01 03:15, schrieb Ron Scott-Adams:
>> I don’t wish to be a pest, but if someone could give me a hand with this,
>> that’d be super swell; I’m stumped...
>>
>>
>> Begin forwarded message:
>>
>>> From: Ron Scott-Adams
>>> Subject: [SOGo] Cannot Login to Web Interface after Upgrade to 2.2.5-3
>>> (Debian Package)
>>> Date: July 17, 2014 at 4:13:04 AM EDT
>>> To: users@sogo.nu
>>> Reply-To: users@sogo.nu
>>>
>>> As near as I can tell, nothing else has changed except upgrading from the
>>> previous version in the Debian testing repos, whichh I believe was also a
>>> variant of 2.2.5.
>>>
>>> I get a 404 now for e.g. https://tohuw.net/SOGo/so/tohuw/Mail/view
>>>
>>> Nothing in syslog or so regarding LDAP failures, and my other LDAP
>>> authenticated softwares are working fine.
>>>
>>> In sogo.log, I see cycles like this:
>>> 2014-07-17 04:03:09.980 sogod[24672] WOCompoundElement: pool embedding is
>>> on.
>>> 2014-07-17 04:03:09.980 sogod[24672] WOCompoundElement: id logging is on.
>>> 127.0.0.1 - - [17/Jul/2014:04:03:09 GMT] "GET /SOGo/ HTTP/1.0" 302 0/0
>>> 0.021 - - 984K
>>> 127.0.0.1 - - [17/Jul/2014:04:03:10 GMT] "GET /SOGo/ HTTP/1.0" 302 0/0
>>> 0.003 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:10 GMT] "GET /SOGo/tohuw HTTP/1.0" 302 0/0
>>> 0.003 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:10 GMT] "GET /SOGo/tohuw/view HTTP/1.0"
>>> 302 0/0 0.003 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:10 GMT] "GET /SOGo/so/tohuw/Mail HTTP/1.0"
>>> 302 0/0 0.002 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:10 GMT] "GET /SOGo/so/tohuw/Mail/view
>>> HTTP/1.0" 404 208/0 0.003 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:13 GMT] "PROPFIND
>>> /SOGo/dav/tohuw/Calendar/ HTTP/1.0" 401 0/2097 0.001 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:14 GMT] "PROPFIND
>>> /SOGo/dav/tohuw/Calendar/ HTTP/1.0" 207 1236/2097 0.007 6057 79% 60K
>>> 127.0.0.1 - - [17/Jul/2014:04:03:14 GMT] "PROPPATCH
>>> /SOGo/dav/tohuw/Calendar/ HTTP/1.0" 403 250/425 0.002 - - -4K
>>> 127.0.0.1 - - [17/Jul/2014:04:03:14 GMT] "PROPPATCH
>>> /SOGo/dav/tohuw/Calendar/ HTTP/1.0" 403 254/430 0.004 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:14 GMT] "PROPFIND
>>> /SOGo/dav/tohuw/Calendar/inbox/ HTTP/1.0" 207 301/181 0.003 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:19 GMT] "OPTIONS /SOGo/dav//tohuw/
>>> HTTP/1.0" 401 0/0 0.001 - - 4K
>>> 127.0.0.1 - - [17/Jul/2014:04:03:19 GMT] "OPTIONS /SOGo/dav//tohuw/
>>> HTTP/1.0" 200 0/0 0.002 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:19 GMT] "PROPFIND /SOGo/dav//tohuw/
>>> HTTP/1.0" 207 522/439 0.003 1630 67% 8K
>>> 127.0.0.1 - - [17/Jul/2014:04:03:20 GMT] "OPTIONS /SOGo/dav//tohuw/
>>> HTTP/1.0" 200 0/0 0.002 - - 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:20 GMT] "PROPFIND
>>> /SOGo/dav//tohuw/Contacts/ HTTP/1.0" 207 609/717 0.005 2753 77% 4K
>>> 127.0.0.1 - - [17/Jul/2014:04:03:20 GMT] "PROPFIND
>>> /SOGo/dav//tohuw/Contacts/public/ HTTP/1.0" 207 506/717 0.003 1366 62% 0
>>> 127.0.0.1 - - [17/Jul/2014:04:03:20 GMT] "PROPFIND
>>> /SOGo/dav//tohuw/Contacts/personal/ HTTP/1.0" 207 312/181 0.003 - - 0
>>>
>>> sogo.conf:
>>> {
>>> SOGoProfileURL = "mysql://sogo:sogo@localhost:3306/sogo/sogo_user_profile";
>>> OCSFolderInfoURL = "mysql://sogo:sogo@localhost:3306/sogo/sogo_folder_info";
>>> OCSSessionsFolderURL =
>>> "mysql://sogo:sogo@localhost:3306/sogo/sogo_sessions_folder";
>>> OCSEMailAlarmsFolderURL =
>>> "mysql://sogo:sogo@localhost:3306/sogo/sogo_alarms_folder";
>>>
>>> SOGoSMTPServer = 127.0.0.1;
>>> SOGoMailDomain = tohuw.net;
>>> SOGoMailingMechanism = smtp;
>>> SOGoForceExternalLoginWithEmail = NO;
>>> SOGoMailSpoolPath = /var/spool/sogo;
>>>
>>> SOGoIMAPServer = localhost;
>>> NGImap4ConnectionStringSeparator = "/";
>>> SOGoDraftsFolderName = Drafts;
>>> SOGoSentFolderName = Sent;
>>> SOGoTrashFolderName = Trash;
>>>
>>> SOGoIMAPAclConformsToIMAPExt = YES;
>>> SOGoMailAuxiliaryUserAccountsEnabled = YES;
>>> SOGoDefaultCalendar = "personal";
>>>
>>> SOGoHideSystemEmail = YES;
>>>
>>> SOGoSieveServer = sieve://127.0.0.1:4190;
>>> SOGoSieveScriptsEnabled = YES;
>>> SOGoVacationEnabled = YES;
>>> SOGoForwardEnabled = YES;
>>> SOGoSieveServer = sieve://127.0.0.1:4190;
>>>
>>> SOGoAppointmentSendEMailNotifications = YES;
>>> SOGoACLsSendEMailNotifications = YES;
>>> SOGoEnableEmailAlarms = YES;
>>>
>>> SOGoUserSources = (
>>> {
>>> type = ldap;
>>> CNFieldName = cn;
>>> IDFieldName = uid;
>>> UIDFieldName = uid;
>>> baseDN = "ou=Users,dc=tohuw,dc=net";
>>> bindDN = "uid=sogo,ou=Services,dc=tohuw,dc=net";
>>>
