from:"Ron Scott\-Adams"

[SOGo] Nginx Configuration for CardDav?

2017-04-30 Thread Ron Scott-Adams

I’ve had great success getting everything working in SOGo 3.2.6 except for 
CardDav with macOS and iOS clients. Does anyone have an Nginx equivalent to 
this Apache example in the docs: 
https://sogo.nu/files/docs/SOGoInstallationGuide.html#_apple_addressbook 


Thanks in advance!
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Database Tables Not Populated After Install (3.2.6, Ubuntu 17.04, MariaDB 10.1)

2017-04-24 Thread Ron Scott-Adams

I found the issue... MariaDB sets the character sets to utf8mb4, thus it is 
necessary to complete this by doing as is suggested in the SOGo docs for 
complete unicode compliance for MySQL. This is covered in section 5.9.1 
"Complete Unicode Compliance". Until the sogo.conf and mariadb configurations 
are properly changed, the database tables will not be created. All is 
(actually) well now.

> On Apr 23, 2017, at 21:31, Ron Scott-Adams  wrote:
> 
> I tried spinning up a completely fresh instance on Ubuntu 16.04.2 using the 
> official nightly repo and notice that there, the problem is similar: only one 
> table is created, sogo_acl.
> 
> Any ideas?
> 
>> On Apr 23, 2017, at 05:16, Ron Scott-Adams > <mailto:r...@tohuw.net>> wrote:
>> 
>> After a very confusing session of troubleshooting settings not being 
>> available, I’ve realized it isn’t solved after all: there’s still no tables. 
>> Can someone take a look at this and assist? Thank you!
>> 
>> 
>>> On Apr 23, 2017, at 03:28, Ron Scott0Adams >> <mailto:r...@tohuw.net>> wrote:
>>> 
>>> Thanks to a little digging through the archives, I found the issue is that 
>>> memcached and rpl weren’t installed. Seems there’s some missing 
>>> dependencies in the Ubuntu repo version of this package. All is well now.
>>> 
>>> 
>>>> On Apr 23, 2017, at 03:16, Ron Scott0Adams >>> <mailto:r...@tohuw.net>> wrote:
>>>> 
>>>> I see the following in sogo.log after logging in to the web interface 
>>>> (which succeeds):
>>>>> sogod [11471]: [WARN] <0x0x7fbac999c4c0[WOxElemBuilder]> could not locate 
>>>>> builders: WOxExtElemBuilder,WOxExtElemBuilder
>>>>> sogod [11471]: <0x0x5614b1d9b1b0[SOGoCache]> an error occurred when 
>>>>> caching value for key ‘myuser+dn': "SERVER HAS FAILED AND IS DISABLED 
>>>>> UNTIL TIMED RETRY”
>>>> 
>>>> As near as I can tell, connection to the database is successful. It 
>>>> certainly fails if I throw a bogus password. Additionally, I verified the 
>>>> mysql user ‘sogo’ has all privileges on the database ‘sogo’.
>>>> 
>>>> My sogo.conf:
>>>> {
>>>>   SOGoLanguage = English;
>>>>   SOGoTimeZone = America/Chicago;
>>>>   SOGoAppointmentSendEMailNotifications = YES;
>>>>   SOGoFirstDayOfWeek = 0;
>>>>   SOGoMailMessageCheck = every_minute;
>>>>   SOGoMailAuxiliaryUserAccountsEnabled = YES;
>>>>   SOGoMemcachedHost = 127.0.0.1;
>>>>   SOGoMailDomain = tohuw.net <http://tohuw.net/>;
>>>>   SOGoPasswordChangeEnabled = YES;
>>>>   SOGoMaximumFailedLoginCount = 5;
>>>>   SOGoMaximumFailedLoginInterval = 60;
>>>>   SOGoFailedLoginBlockInterval = 300;
>>>> 
>>>>   SOGoPageTitle = "TohuwNet";
>>>>   SOGoLoginModule = Mail;
>>>> 
>>>> 
>>>>   MySQL4Encoding = "utf8mb4";
>>>>   SOGoProfileURL = 
>>>> "mysql://sogo:my_password@localhost/sogo/sogo_user_profile 
>>>> ";
>>>>   OCSFolderInfoURL = 
>>>> "mysql://sogo:my_password@localhost/sogo/sogo_folder_info 
>>>> ";
>>>>   OCSSessionsFolderURL = 
>>>> "mysql://sogo:my_password@localhost/sogo/sogo_sessions_folder 
>>>> ";
>>>>   OCSEMailAlarmsFolderURL = 
>>>> "mysql://sogo:my_password@localhost/sogo/sogo_alarms_folder 
>>>> ";
>>>>   OCSStoreURL = "mysql://sogo:my_password@localhost/sogo/sogo_store 
>>>> ";
>>>>   OCSAclURL = "mysql://sogo:my_password@localhost/sogo/sogo_acl 
>>>> ";
>>>>   OCSCacheFolderURL = 
>>>> "mysql://sogo:my_password@localhost/sogo/sogo_cache_folder 
>>>> ";
>>>> 
>>>>   SOGoMailingMechanism = smtp;
>>>>   SOGoSMTPServer = 127.0.0.1;
>>>> 
>>>>   SOGoIMAPServer = "imaps://localhost:143/?tls=YES 
>>>> ";
>>>>   SOGoSieveServer = "sieve://localhost:4190/?tls=YES 
>>>> ";
>>>>   SOGoIMAPAclConformsToIMAPExt = YES;
>>>>   SOGoSentFolderName = Sent;
>>>>   SOGoTrashFolderName = Trash;
>>>>   SOGoDraftsFolderName = Drafts;
>>>>   SOGoVacationEnabled = YES;
>>>>   SOGoForwardEnabled = YES;
>>>>   SOGoSieveScriptsEnabled = YES;
>>>> 
>>>>   SOGoLDAPContactInfoAttribute = displayName;
>>>> 
>>>>   SOGoUserSources = (
>>>> {
>>>> type = ldap;
>>>> CNFieldName = cn;
>>>> IDFieldName = cn;
>>>> UIDFieldName = uid;
>>>> baseDN = "ou=users,dc=tohuw,dc=net";
>>>> bindDN = "uid=sogo,ou=services,dc=tohuw,dc=net";
>>>> bindFields = (uid);
>>>> bindPassword = my_ldap_password;
>>>> canAuthenticate = YES;
>>>> displayName = "TohuwNet";
>>>> hostname = ldap://localhost <ldap://localhost>;
>>>> id = directory;
>>>> isAddressBook = YES;
>>>> }
>>>>   );
>>>> }
>>> 
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [SOGo] Database Tables Not Populated After Install (3.2.6, Ubuntu 17.04, MariaDB 10.1)

2017-04-24 Thread Ron Scott-Adams

I tried spinning up a completely fresh instance on Ubuntu 16.04.2 using the 
official nightly repo and notice that there, the problem is similar: only one 
table is created, sogo_acl.

Any ideas?

> On Apr 23, 2017, at 05:16, Ron Scott-Adams  wrote:
> 
> After a very confusing session of troubleshooting settings not being 
> available, I’ve realized it isn’t solved after all: there’s still no tables. 
> Can someone take a look at this and assist? Thank you!
> 
> 
>> On Apr 23, 2017, at 03:28, Ron Scott0Adams > <mailto:r...@tohuw.net>> wrote:
>> 
>> Thanks to a little digging through the archives, I found the issue is that 
>> memcached and rpl weren’t installed. Seems there’s some missing dependencies 
>> in the Ubuntu repo version of this package. All is well now.
>> 
>> 
>>> On Apr 23, 2017, at 03:16, Ron Scott0Adams >> <mailto:r...@tohuw.net>> wrote:
>>> 
>>> I see the following in sogo.log after logging in to the web interface 
>>> (which succeeds):
>>>> sogod [11471]: [WARN] <0x0x7fbac999c4c0[WOxElemBuilder]> could not locate 
>>>> builders: WOxExtElemBuilder,WOxExtElemBuilder
>>>> sogod [11471]: <0x0x5614b1d9b1b0[SOGoCache]> an error occurred when 
>>>> caching value for key ‘myuser+dn': "SERVER HAS FAILED AND IS DISABLED 
>>>> UNTIL TIMED RETRY”
>>> 
>>> As near as I can tell, connection to the database is successful. It 
>>> certainly fails if I throw a bogus password. Additionally, I verified the 
>>> mysql user ‘sogo’ has all privileges on the database ‘sogo’.
>>> 
>>> My sogo.conf:
>>> {
>>>   SOGoLanguage = English;
>>>   SOGoTimeZone = America/Chicago;
>>>   SOGoAppointmentSendEMailNotifications = YES;
>>>   SOGoFirstDayOfWeek = 0;
>>>   SOGoMailMessageCheck = every_minute;
>>>   SOGoMailAuxiliaryUserAccountsEnabled = YES;
>>>   SOGoMemcachedHost = 127.0.0.1;
>>>   SOGoMailDomain = tohuw.net <http://tohuw.net/>;
>>>   SOGoPasswordChangeEnabled = YES;
>>>   SOGoMaximumFailedLoginCount = 5;
>>>   SOGoMaximumFailedLoginInterval = 60;
>>>   SOGoFailedLoginBlockInterval = 300;
>>> 
>>>   SOGoPageTitle = "TohuwNet";
>>>   SOGoLoginModule = Mail;
>>> 
>>> 
>>>   MySQL4Encoding = "utf8mb4";
>>>   SOGoProfileURL = 
>>> "mysql://sogo:my_password@localhost/sogo/sogo_user_profile 
>>> ";
>>>   OCSFolderInfoURL = 
>>> "mysql://sogo:my_password@localhost/sogo/sogo_folder_info 
>>> ";
>>>   OCSSessionsFolderURL = 
>>> "mysql://sogo:my_password@localhost/sogo/sogo_sessions_folder 
>>> ";
>>>   OCSEMailAlarmsFolderURL = 
>>> "mysql://sogo:my_password@localhost/sogo/sogo_alarms_folder 
>>> ";
>>>   OCSStoreURL = "mysql://sogo:my_password@localhost/sogo/sogo_store 
>>> ";
>>>   OCSAclURL = "mysql://sogo:my_password@localhost/sogo/sogo_acl 
>>> ";
>>>   OCSCacheFolderURL = 
>>> "mysql://sogo:my_password@localhost/sogo/sogo_cache_folder 
>>> ";
>>> 
>>>   SOGoMailingMechanism = smtp;
>>>   SOGoSMTPServer = 127.0.0.1;
>>> 
>>>   SOGoIMAPServer = "imaps://localhost:143/?tls=YES 
>>> ";
>>>   SOGoSieveServer = "sieve://localhost:4190/?tls=YES 
>>> ";
>>>   SOGoIMAPAclConformsToIMAPExt = YES;
>>>   SOGoSentFolderName = Sent;
>>>   SOGoTrashFolderName = Trash;
>>>   SOGoDraftsFolderName = Drafts;
>>>   SOGoVacationEnabled = YES;
>>>   SOGoForwardEnabled = YES;
>>>   SOGoSieveScriptsEnabled = YES;
>>> 
>>>   SOGoLDAPContactInfoAttribute = displayName;
>>> 
>>>   SOGoUserSources = (
>>> {
>>> type = ldap;
>>> CNFieldName = cn;
>>> IDFieldName = cn;
>>> UIDFieldName = uid;
>>> baseDN = "ou=users,dc=tohuw,dc=net";
>>> bindDN = "uid=sogo,ou=services,dc=tohuw,dc=net";
>>> bindFields = (uid);
>>> bindPassword = my_ldap_password;
>>> canAuthenticate = YES;
>>> displayName = "TohuwNet";
>>> hostname = ldap://localhost <ldap://localhost>;
>>> id = directory;
>>> isAddressBook = YES;
>>> }
>>>   );
>>> }
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: [SOGo] Database Tables Not Populated After Install (3.2.6, Ubuntu 17.04, MariaDB 10.1)

2017-04-23 Thread Ron Scott-Adams

After a very confusing session of troubleshooting settings not being available, 
I’ve realized it isn’t solved after all: there’s still no tables. Can someone 
take a look at this and assist? Thank you!


> On Apr 23, 2017, at 03:28, Ron Scott0Adams  wrote:
> 
> Thanks to a little digging through the archives, I found the issue is that 
> memcached and rpl weren’t installed. Seems there’s some missing dependencies 
> in the Ubuntu repo version of this package. All is well now.
> 
> 
>> On Apr 23, 2017, at 03:16, Ron Scott0Adams > > wrote:
>> 
>> I see the following in sogo.log after logging in to the web interface (which 
>> succeeds):
>>> sogod [11471]: [WARN] <0x0x7fbac999c4c0[WOxElemBuilder]> could not locate 
>>> builders: WOxExtElemBuilder,WOxExtElemBuilder
>>> sogod [11471]: <0x0x5614b1d9b1b0[SOGoCache]> an error occurred when caching 
>>> value for key ‘myuser+dn': "SERVER HAS FAILED AND IS DISABLED UNTIL TIMED 
>>> RETRY”
>> 
>> As near as I can tell, connection to the database is successful. It 
>> certainly fails if I throw a bogus password. Additionally, I verified the 
>> mysql user ‘sogo’ has all privileges on the database ‘sogo’.
>> 
>> My sogo.conf:
>> {
>>   SOGoLanguage = English;
>>   SOGoTimeZone = America/Chicago;
>>   SOGoAppointmentSendEMailNotifications = YES;
>>   SOGoFirstDayOfWeek = 0;
>>   SOGoMailMessageCheck = every_minute;
>>   SOGoMailAuxiliaryUserAccountsEnabled = YES;
>>   SOGoMemcachedHost = 127.0.0.1;
>>   SOGoMailDomain = tohuw.net ;
>>   SOGoPasswordChangeEnabled = YES;
>>   SOGoMaximumFailedLoginCount = 5;
>>   SOGoMaximumFailedLoginInterval = 60;
>>   SOGoFailedLoginBlockInterval = 300;
>> 
>>   SOGoPageTitle = "TohuwNet";
>>   SOGoLoginModule = Mail;
>> 
>> 
>>   MySQL4Encoding = "utf8mb4";
>>   SOGoProfileURL = 
>> "mysql://sogo:my_password@localhost/sogo/sogo_user_profile 
>> ";
>>   OCSFolderInfoURL = 
>> "mysql://sogo:my_password@localhost/sogo/sogo_folder_info 
>> ";
>>   OCSSessionsFolderURL = 
>> "mysql://sogo:my_password@localhost/sogo/sogo_sessions_folder 
>> ";
>>   OCSEMailAlarmsFolderURL = 
>> "mysql://sogo:my_password@localhost/sogo/sogo_alarms_folder 
>> ";
>>   OCSStoreURL = "mysql://sogo:my_password@localhost/sogo/sogo_store 
>> ";
>>   OCSAclURL = "mysql://sogo:my_password@localhost/sogo/sogo_acl 
>> ";
>>   OCSCacheFolderURL = 
>> "mysql://sogo:my_password@localhost/sogo/sogo_cache_folder 
>> ";
>> 
>>   SOGoMailingMechanism = smtp;
>>   SOGoSMTPServer = 127.0.0.1;
>> 
>>   SOGoIMAPServer = "imaps://localhost:143/?tls=YES 
>> ";
>>   SOGoSieveServer = "sieve://localhost:4190/?tls=YES 
>> ";
>>   SOGoIMAPAclConformsToIMAPExt = YES;
>>   SOGoSentFolderName = Sent;
>>   SOGoTrashFolderName = Trash;
>>   SOGoDraftsFolderName = Drafts;
>>   SOGoVacationEnabled = YES;
>>   SOGoForwardEnabled = YES;
>>   SOGoSieveScriptsEnabled = YES;
>> 
>>   SOGoLDAPContactInfoAttribute = displayName;
>> 
>>   SOGoUserSources = (
>> {
>> type = ldap;
>> CNFieldName = cn;
>> IDFieldName = cn;
>> UIDFieldName = uid;
>> baseDN = "ou=users,dc=tohuw,dc=net";
>> bindDN = "uid=sogo,ou=services,dc=tohuw,dc=net";
>> bindFields = (uid);
>> bindPassword = my_ldap_password;
>> canAuthenticate = YES;
>> displayName = "TohuwNet";
>> hostname = ldap://localhost ;
>> id = directory;
>> isAddressBook = YES;
>> }
>>   );
>> }
> 



smime.p7s
Description: S/MIME cryptographic signature

[SOGo] View Event Confirmations

2014-10-03 Thread Ron Scott-Adams

If I invite someone not in my SOGo instance (e.g., someone using Exchange or 
iCloud as their backend) to a calendar event, is there a way to see their 
acceptance of the event? Because right now, if they accept the event, I am not 
ever notified.

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Cannot Login to Web Interface after Upgrade to 2.2.5-3 (Debian Package)

2014-08-07 Thread Ron Scott-Adams

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 =

[SOGo] Cannot Login to Web Interface after Upgrade to 2.2.5-3 (Debian Package)

2014-07-31 Thread 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...


Ron Scott-Adams
r...@tohuw.net
“We are stuck with technology when what we really want is just stuff that 
works.” (Douglas Adams)




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";
>

[SOGo] Cannot Login to Web Interface after Upgrade to 2.2.5-3 (Debian Package)

2014-07-17 Thread Ron Scott-Adams

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";
bindPassword = [redacted];
canAuthenticate = YES;
displayName = "Shared Addresses";
hostname = ldap://127.0.0.1:389;
id = public;
isAddressBook = YES;
}
);

SOGoPasswordChangeEnabled = YES;

SOGoPageTitle = Webmail;
SOGoLanguage = English;
SOGoTimeZone = America/New_York;
}

Nginx Config:
server {
  server_name tohuw.net;
  return https://$http_host$request_uri?;
}
server {
  listen 443;
  server_name tohuw.net;
  ssl on;
  include global/certs/tohuw_net.conf;
  include global/defaults/defaults.conf;
  location / {
root /srv/www/tohuwnet;
  }
  location = /search {
return 301 /search.html$is_args$args;
  }
  location /stats {
alias /usr/share/piwik;
  }
  location /stats/index.php {
alias /usr/share/piwik/index.php;
fastcgi_pass unix:/var/run/php5-fpm.sock;
include global/php.conf;
include global/geoip.conf;
  }
  location /stats/piwik.php {
alias /usr/share/piwik/piwik.php;
fastcgi_pass unix:/var/run/php5-fpm.sock;
include global/php.conf;
  }
  location = /webmail {
rewrite ^ https://$server_name/SOGo; 
allow all; 
  }
  location ^~/SOGo {
proxy_pass http://127.0.0.1:2; 
proxy_redirect http://127.0.0.1:2 de

[SOGo] Nginx with SOGo 2.2.5 "Upstream prematurely closed connection" when Checking Contacts

2014-07-13 Thread Ron Scott-Adams

In my Nginx error.log, I frequently see:
[error] 24793#0: *23012 upstream prematurely closed connection while reading 
response header from upstream, client: 1.2.3.4, server: example.org, request: 
"PROPFIND /SOGo/dav/username/Contacts/ HTTP/1.1", upstream: 
"http://127.0.0.1:2/SOGo/dav//username/Contacts/";, host: “example.org:8843”

Why?-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Search entire mailstore from the GUI?

2014-03-13 Thread Ron Scott-Adams

Why not configure your MTA to blind-copy to a central mailbox and search from 
there?

If the desire is to access existing mail, why not access all of the boxes via 
IMAP and copy messages to a central mailbox?

On Mar 12, 2014, at 4:30 PM, Charles Marcus  wrote:

> On 3/12/2014 11:23 AM, Christian Mack  wrote:
>> Am 2014-03-12 12:37, schrieb Charles Marcus:
>>> >On 3/11/2014 9:29 PM, Nigel Pegram  wrote:
 >>Is the web GUI a must? Thunderbird has this capability.
>>> >
>>> >You misunderstand.
>>> >
>>> >I'm talking about an Administrative function.
>>> >
>>> >Something that can search all mailboxes for all user accounts across an
>>> >entire domain (or even multiple domains, if SOGo is set up for it).
>>> >
>> No, this "feature" is not available in SOGo.
>> It has nothing to do with a mail client, so SOGo is not the way to go.
>> And to use such a feature would be highly illegal at least in Europe
> 
> In the US, employees of companies have no expectation of privacy regarding 
> email, under the following conditions:
> 
> 1. The employee is using a company email address and system owned and 
> operated by the company, and
> 
> 2. The Company has a formal policy that the employee is made fully aware of 
> the fact that their employer may monitor their email usage at any time.
> 
> Alas, I've been tasked with finding some kind of system that will allow the 
> boss, and potentially one or two other people the ability to do this when 
> necessary.
> 
> Thanks anyway,
> 
> -- 
> 
> Best regards,
> 
> Charles
> 
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] SOGo as second DC

2014-03-13 Thread Ron Scott-Adams

Seizing any roles from an SBS server is not supported. Ever. Under no 
circumstances should you ever transfer any domain services away from an SBS 
box. Regardless of what samba documentation, et al may claim, this is always an 
incorrect action to take.

You cannot treat SBS as a typical domain controller, nor can you treat an SBS 
forest as a typical forest. There are elements within SBS that completely 
depend upon and expect all roles to be present at all times. And of all roles 
to transfer, the schema role invites possibly the most disaster, as SBS does 
not expect non-resident schema modifications.

When you’re playing on Microsoft’s infrastructure, there are some MS rules you 
have to follow. Not everything they mandate is merely a “best practice” or 
without reason, and this is a prime example.

Now that I’m done ranting/scolding, what is the detailed message you receive 
from ntdsutil? It may be helpful to up the logging level of LDAP Interface 
Events and DS Schema in 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics (start 
with a value of 2).

Also, you may consider a system state restore (you do back up your system state 
frequently, I hope): 
http://blogs.technet.com/b/sbs/archive/2011/03/31/how-to-perform-an-authoritative-system-state-restore-in-sbs-2008-2011-standard.aspx.
 Note this will likely hose your samba instance and require some sort of 
cleaning to realign it to reality, but SOGo should remain unscathed.

Good luck and such.

On Mar 12, 2014, at 5:14 PM, Patric Becker  wrote:

> OK, monologue ;-),
>  
> I give it up! How should I transfer the Schema role from the sogo box to my 
> sbs?
>  
> I´ve tried it in Win with ntdsutil and on my linux with
>  
> samba-tool fsmo seize --role=schema
>  
> Where is my failure?? ;(
>  
> Thanks
>  
> Paddie
>  
>> Patric Becker  hat am 12. März 2014 um 20:43 
>> geschrieben: 
>> 
>> OK, forget the last mail ;-). After I read a bit more I find out, that the 
>> command worked. BUT if I test with
>>  
>> samba-tool fsmo show
>>  
>> it tells me, that schemamasterrole still is on the sogo box ;-(.
>>  
>> I will test a little more this evening. If i get it OK, if not i give up on 
>> it.
>>  
>> Thanks
>>  
>> Paddie
>>> Patric Becker  hat am 12. März 2014 um 19:51 
>>> geschrieben: 
>>> 
>>> Many Thanks for your extensive answer. I´ve tried it this way a few minutes 
>>> ago. but when I want to seize it back to the SBS i get this error
>>>  
>>> FSMO transfer of 'schema' role successful 
>>> ERROR: Failed to initiate role seize of 'schema' role: objectclass: modify 
>>> message must have elements/attributes!
>>> I´ve googled a little and found this bugreport
>>>  
>>> https://bugzilla.samba.org/show_bug.cgi?id=9461
>>>  
>>> As I understand it correctly. I have to rebuild samba with this Patch 
>>> applied to get this working.
>>>  
>>> Thanks
>>>  
>>> Paddie
>>>  
 Steve Boley  hat am 12. März 2014 um 17:08 geschrieben: 

 You only need to move the global catalog the schema over to setup 
 openchange and then you can seize it back from the sbs system and all 
 would be well in active directory land. To simply join as 2nd dc you do 
 not have to seize any roles and the seizing is for extending the exchange 
 schema onto the active directory which actually should be in place in sbs 
 so you might have to just seize the role so the global catalog is copied 
 over and take it right back and openchange might be happy just get ready 
 for a lot of google and debugging probably as this is not a simple task to 
 get it all working. I've put in a feature request for openchange to check 
 for the schema on a remote dc not the local one but that might take a 
 while to be added. 
 Steve 
 On 3/9/2014 8:37 AM, Patric Becker wrote:
> Hi,
>  
> I want to join a SOGo-Box to an existing Domain with a Windows SBS 2011 
> Essentials(!!!) Box.
>  
> I´ve asked this Question a few weeks before and get the hint to copy/move 
> the fsmo roles from the Windows to the SOGo Box BUT after a few tries and 
> a little more searching in the Web I found out, that I CAN´T copy/move 
> all fsmo Roles from an SBS Essential Server to an other box.
>  
> My next Idea was to Use the SOGo Box as FIRST DC but the SBS Essential 
> Box couldn´t join a Network as second DC ;(.
>  
> Is there an other solution to use SOGo in this network??
>  
> Thanks
>  
> Paddie
>  
> PS: Sorry for starting an new Thread but I´m at home now and write this 
> with our Provider-webfronend. ;-).
>  
> PPS: The SBS Essential Box was there as I joined the Company ;). I would 
> never buy such crap...
>>> 
>>>  
>> 
>>  
> 
>  

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] How to connect such as Outlook Anywhere

2014-03-09 Thread Ron Scott-Adams

Oh, wow, I missed that. Thanks for the heads up… I’m surprised SOGo supports 
that. Sorry for my misinformation, then...

On Mar 5, 2014, at 10:17 AM, Szládovics Péter  wrote:

> 2014-03-05 16:04 keltezéssel, Ron Scott-Adams írta:
>> Outlook Anywhere uses MAPI-RPC, a protocol not available in SOGo.
> 
> Outlook Anywhere is working through rpc proxy ;)
> http://www.sogo.nu/files/docs/SOGo%20Native%20Microsoft%20Outlook%20Configuration.pdf
> Chapter 8: Microsoft Outlook Confguration
> 
>> On Mar 5, 2014, at 6:38 AM, info Zarafa  wrote:
>>> Hello
>>> On connecting via a dedicated server as Outlook Anywhere, what I should add 
>>> as url, the domain or domaine.com / rpc / ...
>>> Lament my English
>>> thank you
>>> Michel--
>>> users@sogo.nu
>>> https://inverse.ca/sogo/lists
> 
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Deploying Thunderbird including Lightning & sogo-integrator

2014-03-05 Thread Ron Scott-Adams

This question is best directed to 
https://lists.mozilla.org/listinfo/support-thunderbird, and perhaps reaching 
out to http://www.opsi.org/en/support/support-for-opsi#community as well. In my 
mind, there's nothing particularly weird about the SOGo extensions that a 
general packaging person can’t answer.

On Mar 5, 2014, at 1:47 PM, J. Echter  
wrote:

> Hi,
> 
> i'd like to deploy thunderbird to more than one pc's.
> 
> My question is what is the best way to add sogo extensions + lightning
> to it?
> 
> My favourite solution would be to unzip the .exe file, copy xpi's into
> extensions folder, pack it up again, and install :)
> 
> I'm using opsi (www.opsi.org) as deployment system. Opsi scripts are
> also welcome :P
> 
> 
> Thanks for all your input.
> 
> Juergen
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] SOGo 2.2/Apple Calendar 7.0 - CalDAVAccountRefreshQueueableOperation

2014-03-05 Thread Ron Scott-Adams

Ah, I had 8443 missing from the SSL conditional block (it was only in the TLS 
block). Oops. It’s working now… that’s two silly mistakes in a row, time to 
take a vacation, yeah? Thanks Christian!

On Mar 5, 2014, at 10:07 AM, Christian Mack  
wrote:

> Am 2014-03-05 05:25, schrieb Ron Scott-Adams:
>> Terribly sorry, it’s been a long day. I bet this would help:
>> 
>> Using tohuw.net for domain
>> Using /SOGo/dav/tohuw/ for path
>> Using 8443 for port with SSL
>> 
>> Web UI Calendar works fine.
>> 
>> Contacts (CardDAV) exhibits similar problems, using same settings as above
>> 
>> Apache SOGo Conf:
>> 
>> Alias /SOGo.woa/WebServerResources/ \
>>  /usr/lib/GNUstep/SOGo/WebServerResources/
>> Alias /SOGo/WebServerResources/ \
>>  /usr/lib/GNUstep/SOGo/WebServerResources/
>> AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
>>   /usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2
>> 
>> 
>>AllowOverride None
>>Order deny,allow
>>Allow from all
>> 
>># Explicitly allow caching of static content to avoid browser specific 
>> behavior.
>># A resource's URL MUST change in order to have the client load the new 
>> version.
>>
>>  ExpiresActive On
>>  ExpiresDefault "access plus 1 year"
>>
>> 
>> 
>> > "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*\.(jpg|png|gif|css|js)">
>>  SetHandler default-handler
>> 
>> 
>> ## Uncomment the following to enable proxy-side authentication, you will then
>> ## need to set the "SOGoTrustProxyAuthentication" SOGo user default to YES 
>> and
>> ## adjust the "x-webobjects-remote-user" proxy header in the "Proxy" section
>> ## below.
>> #
>> #  AuthType XXX
>> #  Require valid-user
>> #  SetEnv proxy-nokeepalive 1
>> #  Allow from all
>> #
>> 
>> ProxyRequests Off
>> SetEnv proxy-nokeepalive 1
>> ProxyPreserveHost On
>> 
>> # When using CAS, you should uncomment this and install cas-proxy-validate.py
>> # in /usr/lib/cgi-bin to reduce server overloading
>> #
>> # ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
>> # http://localhost/app/cas-proxy-validate.py>
>> #   Order deny,allow
>> #   Allow from your-cas-host-addr
>> # 
>> 
>> ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0
>> 
>> http://127.0.0.1:2/SOGo>
>> ## adjust the following to your configuration
>>  RequestHeader set "x-webobjects-server-port" "443"
>>  RequestHeader set "x-webobjects-server-name" "tohuw.net"
>>  RequestHeader set "x-webobjects-server-url" "https://tohuw.net";
>> 
>> ## When using proxy-side autentication, you need to uncomment and
>> ## adjust the following line:
>> #  RequestHeader set "x-webobjects-remote-user" "%{REMOTE_USER}e"
>> 
>>  RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
>> 
>>  AddDefaultCharset UTF-8
>> 
>>  Order allow,deny
>>  Allow from all
>> 
>> 
>> # Create a rule to allow the url to be all lower-case
>> RewriteEngine On
>> RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
>> Redirect permanent /webmail https://tohuw.net/SOGo
>> 
>> # CardDav (Mac) Support
>> NameVirtualHost 0.0.0.0:8843
>> 
>>ServerName tohuw.net
>>SSLEngine On
>>SSLCertificateFile [redacted]
>>SSLCertificateKeyFile [redacted]
>>SSLCertificateChainFile [redacted]
>> 
>>ProxyRequests Off
>>SetEnv proxy-nokeepalive 1
>>ProxyPreserveHost On
>> 
>>ProxyPassInterpolateEnv On
>>ProxyPass /principals http://127.0.0.1:2/SOGo/dav/ interpolate
>>ProxyPass /SOGo/dav/ http://127.0.0.1:2/SOGo/dav/ interpolate
>>ProxyPass / http://127.0.0.1:2/SOGo/dav/ interpolate
>> 
>>http://127.0.0.1:2>
>>RequestHeader set "x-webobjects-server-port" "8843"
>>RequestHeader set "x-webobjects-server-name" "tohuw.net:8843"
>>RequestHeader set "x-webobjects-server-url" "https://tohuw.net:8843";
>>RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
>>RequestHeader set "x-webobjects-remote-host" "127.0.0.1"
>>AddDefaultCharset UTF-8
>>Order allow,deny
>>Allow from all
>>
>> 
>> 
>> On Mar 4, 2014, at 11:19 PM, Ron Scott-Adams  wrote:
>> 
>>> Evening. I’ve had a long standing issue with the CalDAV support in Apple 
>>> Calendar (formerly iCal) since upgrading to Apple OS 10.9. I consistently 
>>> cannot load the calendar and receive the following message:
>>> 
>>> Your calendar couldn’t be refreshed.
>>> The request for account “Personal” failed.
>>> Operation: CalDAVAccountRefreshQueueableOperation.
>>> 
>>> I’ve searched around but not found a reliable fix. Where’s a good place to 
>>> start with this?
>> 
> 
> And where is your 8443 Apache configuration?
> 
> 
> Kind regards,
> Christian Mack
> 
> -- 
> Christian Mack
> Abteilung Basisdienste
> KIM IT-Services
> Universität Konstanz

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] v2.2 Password modify problem?

2014-03-05 Thread Ron Scott-Adams

The constraint violation is almost certainly emanating from LDAP. Can you 
enable more detailed logging on that side and search for this event from those 
logs?

On Mar 5, 2014, at 8:22 AM, Szládovics Péter  wrote:

> Dear Gents,
> 
> The password modify feature doesn't working anymore while I upgrade to v2.2 :(
> The Samba4 LDAP and SOGo are there in some server, and this feature is 
> working fine in 2.1.x
> Relevant logs:
> Mar 05 09:48:26 sogod [28952]: [ERROR] <0x0xb986dd70[NGLdapConnection]> 
> Couldn't change password for cn=USER,cn=users,dc=CORP,dc=local
> Mar 05 09:48:26 sogod [28952]: <0x0xb9322080[LDAPSource]>  0xb9738df0> NAME:LDAPException REASON:operation modify failed: Constraint 
> violation (0x13) INFO:{dn = "cn=USER,cn=users,dc=CORP,dc=local"; }
> 78.131.57.83 - - [05/Mar/2014:09:48:26 GMT] "POST /SOGo/so/changePassword 
> HTTP/1.1" 403 40/294 0.705 - - 604K
> With samba-tool the password can be modify as well.
> Does anyone know the truth?

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] How to connect such as Outlook Anywhere

2014-03-05 Thread Ron Scott-Adams

Outlook Anywhere uses MAPI-RPC, a protocol not available in SOGo.

On Mar 5, 2014, at 6:38 AM, info Zarafa  wrote:

> Hello 
> On connecting via a dedicated server as Outlook Anywhere, what I should add 
> as url, the domain or domaine.com / rpc / ... 
> Lament my English 
> thank you 
> Michel-- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] SOGo 2.2/Apple Calendar 7.0 - CalDAVAccountRefreshQueueableOperation

2014-03-05 Thread Ron Scott-Adams

Terribly sorry, it’s been a long day. I bet this would help:

Using tohuw.net for domain
Using /SOGo/dav/tohuw/ for path
Using 8443 for port with SSL

Web UI Calendar works fine.

Contacts (CardDAV) exhibits similar problems, using same settings as above

Apache SOGo Conf:

Alias /SOGo.woa/WebServerResources/ \
  /usr/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo/WebServerResources/ \
  /usr/lib/GNUstep/SOGo/WebServerResources/
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
   /usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2


AllowOverride None
Order deny,allow
Allow from all

# Explicitly allow caching of static content to avoid browser specific 
behavior.
# A resource's URL MUST change in order to have the client load the new 
version.

  ExpiresActive On
  ExpiresDefault "access plus 1 year"




  SetHandler default-handler


## Uncomment the following to enable proxy-side authentication, you will then
## need to set the "SOGoTrustProxyAuthentication" SOGo user default to YES and
## adjust the "x-webobjects-remote-user" proxy header in the "Proxy" section
## below.
#
#  AuthType XXX
#  Require valid-user
#  SetEnv proxy-nokeepalive 1
#  Allow from all
#

ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On

# When using CAS, you should uncomment this and install cas-proxy-validate.py
# in /usr/lib/cgi-bin to reduce server overloading
#
# ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
# http://localhost/app/cas-proxy-validate.py>
#   Order deny,allow
#   Allow from your-cas-host-addr
# 

ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0

http://127.0.0.1:2/SOGo>
## adjust the following to your configuration
  RequestHeader set "x-webobjects-server-port" "443"
  RequestHeader set "x-webobjects-server-name" "tohuw.net"
  RequestHeader set "x-webobjects-server-url" "https://tohuw.net";

## When using proxy-side autentication, you need to uncomment and
## adjust the following line:
#  RequestHeader set "x-webobjects-remote-user" "%{REMOTE_USER}e"

  RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"

  AddDefaultCharset UTF-8

  Order allow,deny
  Allow from all


# Create a rule to allow the url to be all lower-case
RewriteEngine On
RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
Redirect permanent /webmail https://tohuw.net/SOGo

# CardDav (Mac) Support
NameVirtualHost 0.0.0.0:8843

ServerName tohuw.net
SSLEngine On
SSLCertificateFile [redacted]
SSLCertificateKeyFile [redacted]
SSLCertificateChainFile [redacted]

ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On

ProxyPassInterpolateEnv On
ProxyPass /principals http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass /SOGo/dav/ http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass / http://127.0.0.1:2/SOGo/dav/ interpolate

http://127.0.0.1:2>
RequestHeader set "x-webobjects-server-port" "8843"
RequestHeader set "x-webobjects-server-name" "tohuw.net:8843"
RequestHeader set "x-webobjects-server-url" "https://tohuw.net:8843";
RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
RequestHeader set "x-webobjects-remote-host" "127.0.0.1"
AddDefaultCharset UTF-8
Order allow,deny
Allow from all



On Mar 4, 2014, at 11:19 PM, Ron Scott-Adams  wrote:

> Evening. I’ve had a long standing issue with the CalDAV support in Apple 
> Calendar (formerly iCal) since upgrading to Apple OS 10.9. I consistently 
> cannot load the calendar and receive the following message:
> 
> Your calendar couldn’t be refreshed.
> The request for account “Personal” failed.
> Operation: CalDAVAccountRefreshQueueableOperation.
> 
> I’ve searched around but not found a reliable fix. Where’s a good place to 
> start with this?

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] SOGo 2.2/Apple Calendar 7.0 - CalDAVAccountRefreshQueueableOperation

2014-03-05 Thread Ron Scott-Adams

Evening. I’ve had a long standing issue with the CalDAV support in Apple 
Calendar (formerly iCal) since upgrading to Apple OS 10.9. I consistently 
cannot load the calendar and receive the following message:

Your calendar couldn’t be refreshed.
The request for account “Personal” failed.
Operation: CalDAVAccountRefreshQueueableOperation.

I’ve searched around but not found a reliable fix. Where’s a good place to 
start with this?-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Cannot Bind to LDAP, but No Attempt Appears to be Made

2014-03-05 Thread Ron Scott-Adams

Good call here Steve. I did double check them, (different uids), and tried 
using the dovecot, but it was a no-go: same results.

HOWEVER, I discovered I’m a dolt and didn’t pay attention to a critical 
difference between the servers: the new server had an older version of SOGo. 
Upgraded, tweaked a few minor details, and all is well. Sigh… details. Thanks 
all!

On Mar 4, 2014, at 9:43 AM, Steve Boley  wrote:

> What user id is dovecot binding with? If it's not binding with the sogo try a 
> different UID to bind with or just check the ldap structure of both of them.
> Steve
> On 3/4/2014 8:18 AM, Ron Scott-Adams wrote:
>> Hi Sven, I could give that a go, but LDAP operations for dovecot seem to 
>> succeed just fine. Likewise, postfix has no problem looking up mail domains.
>> 
>>> On Mar 4, 2014, at 2:09, Sven Schwedas  wrote:
>>> 
>>> Hi,
>>> 
>>>> On 2014-03-04 02:06, Ron Scott-Adams wrote:
>>>> I'm seeing the following in sogo.log, but nothing in OpenLDAP logs to 
>>>> indicate a why, even with logging set to -1. More to the point, I don't 
>>>> even see login attempts, or any reference to that user. Meanwhile logs of 
>>>> Dovecot's LDAP user binding and searching abound.
>>> Have you considered running tcpdump and see whether the problem is
>>> somewhere down the stack?
>>> 
>>>> The log message is:
>>>> [ERROR] <0x0xb8c8a460[LDAPSource]> Could not bind to the LDAP server 
>>>> ldap://127.0.0.1:389 (389) using the bind DN: 
>>>> uid=sogo,ou=Services,dc=tohuw,dc=net--
>>>> users@sogo.nu
>>>> https://inverse.ca/sogo/lists
>>> -- 
>>> Mit freundlichen Grüßen, / Best Regards,
>>> Sven Schwedas
>>> Systemadministrator
>>> TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
>>> Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167
>>> http://software.tao.at
>>> 
> 
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Cannot Bind to LDAP, but No Attempt Appears to be Made

2014-03-04 Thread Ron Scott-Adams

Hi Sven, I could give that a go, but LDAP operations for dovecot seem to 
succeed just fine. Likewise, postfix has no problem looking up mail domains. 

> On Mar 4, 2014, at 2:09, Sven Schwedas  wrote:
> 
> Hi,
> 
>> On 2014-03-04 02:06, Ron Scott-Adams wrote:
>> I'm seeing the following in sogo.log, but nothing in OpenLDAP logs to 
>> indicate a why, even with logging set to -1. More to the point, I don't even 
>> see login attempts, or any reference to that user. Meanwhile logs of 
>> Dovecot's LDAP user binding and searching abound.
> 
> Have you considered running tcpdump and see whether the problem is
> somewhere down the stack?
> 
>> 
>> The log message is:
>> [ERROR] <0x0xb8c8a460[LDAPSource]> Could not bind to the LDAP server 
>> ldap://127.0.0.1:389 (389) using the bind DN: 
>> uid=sogo,ou=Services,dc=tohuw,dc=net-- 
>> users@sogo.nu
>> https://inverse.ca/sogo/lists
> 
> -- 
> Mit freundlichen Grüßen, / Best Regards,
> Sven Schwedas
> Systemadministrator
> TAO Beratungs- und Management GmbH | Lendplatz 45 | A - 8020 Graz
> Mail/XMPP: sven.schwe...@tao.at | +43 (0)680 301 7167
> http://software.tao.at
> 
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Cannot Bind to LDAP, but No Attempt Appears to be Made

2014-03-03 Thread Ron Scott-Adams

I'm seeing the following in sogo.log, but nothing in OpenLDAP logs to indicate 
a why, even with logging set to -1. More to the point, I don't even see login 
attempts, or any reference to that user. Meanwhile logs of Dovecot's LDAP user 
binding and searching abound.

The log message is:
[ERROR] <0x0xb8c8a460[LDAPSource]> Could not bind to the LDAP server 
ldap://127.0.0.1:389 (389) using the bind DN: 
uid=sogo,ou=Services,dc=tohuw,dc=net-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Can't Login after Install/Configuration of New Instance

2014-03-03 Thread Ron Scott-Adams

If someone can take a look at this, that would be great. I lost a bit of this 
thread inadvertently, but for anyone interested in the backlog, it’s at 
https://lists.inverse.ca/sogo/arc/users/2014-02/msg00378.html. I’m pasting the 
most relevant trail below, **with a relevant revision based on my very latest 
conf**. I have at this point moved DNS and services to this server. Everything 
in Postfix/Dovecot works fine. Anything SOGo seems to not work, including 
logging in to the web interface, and any of the DAV services.

I have noticed if I visit the URL https://tohuw.net/SOGo/dav/tohuw/, I get 
"object not found: tohuw”, but I can’t remember if that’s expected behavior or 
not.

Let me know what else I can provide. Thanks in advance.


—
Ah, now I’ve gotten somewhere. I added an MX entry and flipped the domain so I 
can test logging in via IMAP. That worked fine, as did SMTP. So my only auth 
problem is with the SOGo web interface and any DAV logins. So, we’re dealing 
with my SOGo Apache conf now, yeah?

tohuw@joab:~$ sudo cat /etc/apache2/conf.d/SOGo.conf 
Alias /SOGo.woa/WebServerResources/ \
  /usr/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo/WebServerResources/ \
  /usr/lib/GNUstep/SOGo/WebServerResources/
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
   /usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2


AllowOverride None
Order deny,allow
Allow from all

# Explicitly allow caching of static content to avoid browser specific 
behavior.
# A resource's URL MUST change in order to have the client load the new 
version.

  ExpiresActive On
  ExpiresDefault "access plus 1 year"




  SetHandler default-handler


## Uncomment the following to enable proxy-side authentication, you will then
## need to set the "SOGoTrustProxyAuthentication" SOGo user default to YES and
## adjust the "x-webobjects-remote-user" proxy header in the "Proxy" section
## below.
#
#  AuthType XXX
#  Require valid-user
#  SetEnv proxy-nokeepalive 1
#  Allow from all
#

ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On

# When using CAS, you should uncomment this and install cas-proxy-validate.py
# in /usr/lib/cgi-bin to reduce server overloading
#
# ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
# http://localhost/app/cas-proxy-validate.py>
#   Order deny,allow
#   Allow from your-cas-host-addr
# 

ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0

http://127.0.0.1:2/SOGo>
## adjust the following to your configuration
  RequestHeader set "x-webobjects-server-port" "443"
  RequestHeader set "x-webobjects-server-name" "tohuw.net"
  RequestHeader set "x-webobjects-server-url" "https://tohuw.net";

## When using proxy-side autentication, you need to uncomment and
## adjust the following line:
#  RequestHeader set "x-webobjects-remote-user" "%{REMOTE_USER}e"

  RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"

  AddDefaultCharset UTF-8

  Order allow,deny
  Allow from all


# Create a rule to allow the url to be all lower-case
RewriteEngine On
RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
Redirect permanent /webmail https://tohuw.net/SOGo

# CardDav (Mac) Support
NameVirtualHost 0.0.0.0:8843

ServerName tohuw.net
SSLEngine On
SSLCertificateFile /etc/ssl/certs/tohuw_net.crt
SSLCertificateKeyFile /etc/ssl/private/tohuw_net.key
SSLCertificateChainFile /etc/ssl/certs/tohuw_net.ca-bundle

ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On

ProxyPassInterpolateEnv On
ProxyPass /principals http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass /SOGo/dav/ http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass / http://127.0.0.1:2/SOGo/dav/ interpolate

http://127.0.0.1:2>
RequestHeader set "x-webobjects-server-port" "8843"
RequestHeader set "x-webobjects-server-name" "tohuw.net:8843"
RequestHeader set "x-webobjects-server-url" "https://tohuw.net:8843";
RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
RequestHeader set "x-webobjects-remote-host" "127.0.0.1"
AddDefaultCharset UTF-8
Order allow,deny
Allow from all




On Feb 28, 2014, at 12:11 AM, Ron Scott-Adams < r...@tohuw.net> wrote:

Hi Christian. Thanks again for your assistance. What you say about the database 
makes sense, and is rather what I expected. 

The LDAP search returns results fine. The difference in our ACLs is nominal, to 
my understanding.

tohuw@joab:~$ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b 
uid=tohuw,ou=users,dc=tohuw,dc=net -D uid=sogo,ou=Services,dc=tohuw,dc=net
dn: uid=tohuw,ou=Users,dc=t

Re: [SOGo] Can't Login after Install/Configuration of New Instance

2014-03-02 Thread Ron Scott-Adams

Any ideas? I’m running out of ideas here. Let me know if I can provide any 
other details.

On Feb 28, 2014, at 1:20 AM, Ron Scott-Adams  wrote:

> Ah, now I’ve gotten somewhere. I added an MX entry and flipped the domain so 
> I can test logging in via IMAP. That worked fine, as did SMTP. So my only 
> auth problem is with the SOGo web interface and any DAV logins. So, we’re 
> dealing with my SOGo Apache conf now, yeah?
> 
> tohuw@joab:~$ sudo cat /etc/apache2/conf.d/SOGo.conf 
> Alias /SOGo.woa/WebServerResources/ \
>   /usr/lib/GNUstep/SOGo/WebServerResources/
> Alias /SOGo/WebServerResources/ \
>   /usr/lib/GNUstep/SOGo/WebServerResources/
> AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
>/usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2
> 
> 
> AllowOverride None
> Order deny,allow
> Allow from all
> 
> # Explicitly allow caching of static content to avoid browser specific 
> behavior.
> # A resource's URL MUST change in order to have the client load the new 
> version.
> 
>   ExpiresActive On
>   ExpiresDefault "access plus 1 year"
> 
> 
> 
>  "^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*\.(jpg|png|gif|css|js)">
>   SetHandler default-handler
> 
> 
> ## Uncomment the following to enable proxy-side authentication, you will then
> ## need to set the "SOGoTrustProxyAuthentication" SOGo user default to YES and
> ## adjust the "x-webobjects-remote-user" proxy header in the "Proxy" section
> ## below.
> #
> #  AuthType XXX
> #  Require valid-user
> #  SetEnv proxy-nokeepalive 1
> #  Allow from all
> #
> 
> ProxyRequests Off
> SetEnv proxy-nokeepalive 1
> ProxyPreserveHost On
> 
> # When using CAS, you should uncomment this and install cas-proxy-validate.py
> # in /usr/lib/cgi-bin to reduce server overloading
> #
> # ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
> # http://localhost/app/cas-proxy-validate.py>
> #   Order deny,allow
> #   Allow from your-cas-host-addr
> # 
> 
> ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0
> 
> http://127.0.0.1:2/SOGo>
> ## adjust the following to your configuration
>   RequestHeader set "x-webobjects-server-port" "443"
>   RequestHeader set "x-webobjects-server-name" "joab.tohuw.net"
>   RequestHeader set "x-webobjects-server-url" "https://joab.tohuw.net";
> 
> ## When using proxy-side autentication, you need to uncomment and
> ## adjust the following line:
> #  RequestHeader set "x-webobjects-remote-user" "%{REMOTE_USER}e"
> 
>   RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
> 
>   AddDefaultCharset UTF-8
> 
>   Order allow,deny
>   Allow from all
> 
> 
> # Create a rule to allow the url to be all lower-case
> RewriteEngine On
> RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
> Redirect permanent /webmail https://tohuw.net/SOGo
> 
> # CardDav (Mac) Support
> NameVirtualHost 0.0.0.0:8843
> 
> ServerName tohuw.net
> SSLEngine On
> SSLCertificateFile /etc/ssl/certs/tohuw_net.crt
> SSLCertificateKeyFile /etc/ssl/private/tohuw_net.key
> SSLCertificateChainFile /etc/ssl/certs/tohuw_net.ca-bundle
> 
> ProxyRequests Off
> SetEnv proxy-nokeepalive 1
> ProxyPreserveHost On
> 
> ProxyPassInterpolateEnv On
> ProxyPass /principals http://127.0.0.1:2/SOGo/dav/ interpolate
> ProxyPass /SOGo/dav/ http://127.0.0.1:2/SOGo/dav/ interpolate
> ProxyPass / http://127.0.0.1:2/SOGo/dav/ interpolate
> 
> http://127.0.0.1:2>
> RequestHeader set "x-webobjects-server-port" "8843"
> RequestHeader set "x-webobjects-server-name" "joab.tohuw.net:8843"
> RequestHeader set "x-webobjects-server-url" 
> "https://joab.tohuw.net:8843";
> RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
> RequestHeader set "x-webobjects-remote-host" "127.0.0.1"
> AddDefaultCharset UTF-8
> Order allow,deny
> Allow from all
> 
> 
> 
> 
> On Feb 28, 2014, at 12:11 AM, Ron Scott-Adams  wrote:
> 
>> Hi Christian. Thanks again for your assistance. What you say about the 
>> database makes sense, and is rather what I expected. 
>> 
>> The LDAP search returns results fine. The difference in our ACLs is nominal, 
>> to my understanding.
>> 
>> tohuw@joab:~$ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -

Re: [SOGo] Can't Login after Install/Configuration of New Instance

2014-02-28 Thread Ron Scott-Adams

Hi Christian. Thanks again for your assistance. What you say about the database 
makes sense, and is rather what I expected. 

The LDAP search returns results fine. The difference in our ACLs is nominal, to 
my understanding.

tohuw@joab:~$ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b 
uid=tohuw,ou=users,dc=tohuw,dc=net -D uid=sogo,ou=Services,dc=tohuw,dc=net
dn: uid=tohuw,ou=Users,dc=tohuw,dc=net
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: tohuw
sn: Scott-Adams
givenName: Ron
cn: Ron Scott-Adams
gecos: Ron Scott-Adams
loginShell: /bin/bash
homeDirectory: /home/tohuw
uidNumber: 1000
gidNumber: 1000
mail: r...@joab.tohuw.net 

On Feb 27, 2014, at 4:17 AM, Christian Mack  
wrote:

> Hello Ron Scott-Adams
> 
> 
> Am 2014-02-26 03:11, schrieb Ron Scott-Adams:
>> It’s also worth mentioning that my postgres database is empty, though
>> the base schema seems to be present:
>> sogo=# \d
>>  List of relations
>> Schema |   Name   |   Type   | Owner 
>> +--+--+---
>> public | sogo_folder_info | table| sogo
>> public | sogo_folder_info_c_folder_id_seq | sequence | sogo
>> public | sogo_sessions_folder | table| sogo
>> public | sogo_user_profile| table| sogo
>> (4 rows)
>> 
>> Is that normal due to no user having ever successfully logged in, or is
>> something else wrong that may be contributing to my login issue?
>> 
> 
> Yes, that is normal.
> All other information and tables are created on the fly, when logging in
> the first time.
> 
> 
>> Also, I should mention I also tested logging in as the SOGo ldap user
>> via ldapwhoami, and it succeeded.
>> 
> 
> ldapwhoami only shows, that your account exists, and the password is
> correct.
> It doesn't show which privileges you have in the LDAP tree.
> 
> 
>> Lastly, everything else in the stack seems to work:
>> Postfix/Dovecot/Sieve channel a message correctly when testing via
>> Telnet. It’s non-trivial to test too far beyond that, though, and
>> obviously, this is a login issue specific to SOGo. I’m sure there’s
>> something simple I’m not considering, but what?
>> 
>> 
>> On Feb 25, 2014, at 6:21 PM, Ron Scott-Adams > <mailto:r...@tohuw.net>> wrote:
>>> 
>>> After adding the LDAP clause to my conf and restarting SOGo, I get no
>>> further information in sogo.log. For the record, the ACL entry for the
>>> SOGo LDAP user follows. It’s identical to the permissions in my
>>> functional SOGo implementation, and the DIT is structured the same.
>>> 
>>> dn: olcDatabase={1}hdb,cn=config
>>> changetype: modify
>>> add: olcAccess
>>> olcAccess: to dn.subtree="ou=Users,dc=tohuw,dc=net" by
>>> dn="uid=sogo,ou=Services,dc=tohuw,dc=net" write
>>> *
> < cut >
> 
> In my openLDAP olcAccess is in
> dn: olcDatabase={-1}frontend,cn=config
> 
> But I am not sure, this is your problem.
> Could you try an ldapsearch with the
> dn="uid=sogo,ou=Services,dc=tohuw,dc=net" user?
> Please search for another users entrys.
> 
> 
> Kind regards,
> Christian Mack
> 
> -- 
> Christian Mack
> Abteilung Basisdienste
> KIM IT-Services
> Universität Konstanz
> 

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Can't Login after Install/Configuration of New Instance

2014-02-28 Thread Ron Scott-Adams

Ah, now I’ve gotten somewhere. I added an MX entry and flipped the domain so I 
can test logging in via IMAP. That worked fine, as did SMTP. So my only auth 
problem is with the SOGo web interface and any DAV logins. So, we’re dealing 
with my SOGo Apache conf now, yeah?

tohuw@joab:~$ sudo cat /etc/apache2/conf.d/SOGo.conf 
Alias /SOGo.woa/WebServerResources/ \
  /usr/lib/GNUstep/SOGo/WebServerResources/
Alias /SOGo/WebServerResources/ \
  /usr/lib/GNUstep/SOGo/WebServerResources/
AliasMatch /SOGo/so/ControlPanel/Products/(.*)/Resources/(.*) \
   /usr/lib/GNUstep/SOGo/$1.SOGo/Resources/$2


AllowOverride None
Order deny,allow
Allow from all

# Explicitly allow caching of static content to avoid browser specific 
behavior.
# A resource's URL MUST change in order to have the client load the new 
version.

  ExpiresActive On
  ExpiresDefault "access plus 1 year"




  SetHandler default-handler


## Uncomment the following to enable proxy-side authentication, you will then
## need to set the "SOGoTrustProxyAuthentication" SOGo user default to YES and
## adjust the "x-webobjects-remote-user" proxy header in the "Proxy" section
## below.
#
#  AuthType XXX
#  Require valid-user
#  SetEnv proxy-nokeepalive 1
#  Allow from all
#

ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On

# When using CAS, you should uncomment this and install cas-proxy-validate.py
# in /usr/lib/cgi-bin to reduce server overloading
#
# ProxyPass /SOGo/casProxy http://localhost/cgi-bin/cas-proxy-validate.py
# http://localhost/app/cas-proxy-validate.py>
#   Order deny,allow
#   Allow from your-cas-host-addr
# 

ProxyPass /SOGo http://127.0.0.1:2/SOGo retry=0

http://127.0.0.1:2/SOGo>
## adjust the following to your configuration
  RequestHeader set "x-webobjects-server-port" "443"
  RequestHeader set "x-webobjects-server-name" "joab.tohuw.net"
  RequestHeader set "x-webobjects-server-url" "https://joab.tohuw.net";

## When using proxy-side autentication, you need to uncomment and
## adjust the following line:
#  RequestHeader set "x-webobjects-remote-user" "%{REMOTE_USER}e"

  RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"

  AddDefaultCharset UTF-8

  Order allow,deny
  Allow from all


# Create a rule to allow the url to be all lower-case
RewriteEngine On
RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
Redirect permanent /webmail https://tohuw.net/SOGo

# CardDav (Mac) Support
NameVirtualHost 0.0.0.0:8843

ServerName tohuw.net
SSLEngine On
SSLCertificateFile /etc/ssl/certs/tohuw_net.crt
SSLCertificateKeyFile /etc/ssl/private/tohuw_net.key
SSLCertificateChainFile /etc/ssl/certs/tohuw_net.ca-bundle

ProxyRequests Off
SetEnv proxy-nokeepalive 1
ProxyPreserveHost On

ProxyPassInterpolateEnv On
ProxyPass /principals http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass /SOGo/dav/ http://127.0.0.1:2/SOGo/dav/ interpolate
ProxyPass / http://127.0.0.1:2/SOGo/dav/ interpolate

http://127.0.0.1:2>
RequestHeader set "x-webobjects-server-port" "8843"
RequestHeader set "x-webobjects-server-name" "joab.tohuw.net:8843"
RequestHeader set "x-webobjects-server-url" 
"https://joab.tohuw.net:8843";
RequestHeader set "x-webobjects-server-protocol" "HTTP/1.0"
RequestHeader set "x-webobjects-remote-host" "127.0.0.1"
AddDefaultCharset UTF-8
Order allow,deny
Allow from all




On Feb 28, 2014, at 12:11 AM, Ron Scott-Adams  wrote:

> Hi Christian. Thanks again for your assistance. What you say about the 
> database makes sense, and is rather what I expected. 
> 
> The LDAP search returns results fine. The difference in our ACLs is nominal, 
> to my understanding.
> 
> tohuw@joab:~$ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b 
> uid=tohuw,ou=users,dc=tohuw,dc=net -D uid=sogo,ou=Services,dc=tohuw,dc=net
> dn: uid=tohuw,ou=Users,dc=tohuw,dc=net
> objectClass: inetOrgPerson
> objectClass: posixAccount
> objectClass: shadowAccount
> uid: tohuw
> sn: Scott-Adams
> givenName: Ron
> cn: Ron Scott-Adams
> gecos: Ron Scott-Adams
> loginShell: /bin/bash
> homeDirectory: /home/tohuw
> uidNumber: 1000
> gidNumber: 1000
> mail: r...@joab.tohuw.net 
> 
> On Feb 27, 2014, at 4:17 AM, Christian Mack  
> wrote:
> 
>> Hello Ron Scott-Adams
>> 
>> 
>> Am 2014-02-26 03:11, schrieb Ron Scott-Adams:
>>> It’s also worth mentioning that my postgres database is empty, though
>>> the base schema seems to be present:
>>> sogo=# \d
>>>  List

Re: [SOGo] Upcoming v2.2 release

2014-02-26 Thread Ron Scott-Adams

If I’m understanding your question correctly, you are asking if a CardDAV 
account synchronized to a Thunderbird Address Book will be reconciled to an 
iCloud Address Book.

Not only is this beyond the scope of SOGo, it isn’t possible for a third party 
to force iCloud contacts to sync with anything. iCloud is a CardDAV provider, 
just like SOGo, but SOGo cannot force iCloud to accept data it presents. The 
connectors are meant to provide linkage between contacts and clients via 
WebDAV, it is not a magic bridge to allow every service to synchronize (though, 
it arguably could be, if enough services worked the same way and allowed for 
certain configurations).

If I’ve missed the mark on your question, I apologize.

On Feb 25, 2014, at 6:59 PM, J. Land  wrote:

> Ludovic
> Can you tell if the connectors will sync contacts between TB address book and 
> iCloud?
> 
> Thank you. 
> 
>  
> Regards,
> 
> J. Land
> 
> Sent from my iPhone
> 
> On Feb 7, 2014, at 7:27 AM, Ludovic Marcotte  wrote:
> 
>> Hi,
>> 
>> SOGo v2.2 is almost ready. We've done a good amount of changes in SOGo and 
>> the extensions.
>> 
>> Please test the nightly builds of SOGo: 
>> http://www.sogo.nu/downloads/backend_nightly.html
>> 
>> and the extensions: http://www.packetfence.org/downloads/extensions/nightly/
>> 
>> Also please test if possible our new Active Sync support. For the complete 
>> list of changes so far, please see:
>> 
>> http://sogo.nu/bugs/changelog_page.php?version_id=127
>> 
>> Thanks,
>> 
>> -- 
>> 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

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Can't Login after Install/Configuration of New Instance

2014-02-25 Thread Ron Scott-Adams

It’s also worth mentioning that my postgres database is empty, though the base 
schema seems to be present:
sogo=# \d
  List of relations
 Schema |   Name   |   Type   | Owner 
+--+--+---
 public | sogo_folder_info | table| sogo
 public | sogo_folder_info_c_folder_id_seq | sequence | sogo
 public | sogo_sessions_folder | table| sogo
 public | sogo_user_profile| table| sogo
(4 rows)

Is that normal due to no user having ever successfully logged in, or is 
something else wrong that may be contributing to my login issue?

Also, I should mention I also tested logging in as the SOGo ldap user via 
ldapwhoami, and it succeeded.

Lastly, everything else in the stack seems to work: Postfix/Dovecot/Sieve 
channel a message correctly when testing via Telnet. It’s non-trivial to test 
too far beyond that, though, and obviously, this is a login issue specific to 
SOGo. I’m sure there’s something simple I’m not considering, but what?


On Feb 25, 2014, at 6:21 PM, Ron Scott-Adams  wrote:

> Hello Christian, thanks for the reply.
> 
> After adding the LDAP clause to my conf and restarting SOGo, I get no further 
> information in sogo.log. For the record, the ACL entry for the SOGo LDAP user 
> follows. It’s identical to the permissions in my functional SOGo 
> implementation, and the DIT is structured the same.
> 
> dn: olcDatabase={1}hdb,cn=config
> changetype: modify
> add: olcAccess
> olcAccess: to dn.subtree="ou=Users,dc=tohuw,dc=net" by 
> dn="uid=sogo,ou=Services,dc=tohuw,dc=net" write
> 
> 
> Ron Scott-Adams
> r...@tohuw.net
> “We are stuck with technology when what we really want is just stuff that 
> works.” (Douglas Adams)
> 
> 
> 
> 
> On Feb 25, 2014, at 5:58 AM, Christian Mack  
> wrote:
> 
>> Hello Ron Scott-Adams
>> 
>> 
>> Am 2014-02-25 03:53, schrieb Ron Scott-Adams:
>>> I'm building a new SOGo install very similar to a current, working one.
>>> I'm experiencing an issue with logging in. There is a single auth source
>>> (ldap). The error is: "SOGoRootPage Login for user 'username' might not
>>> have worked - password policy: 65535  grace: -1  expire: -1  bound: 0"
>>> What can I do to elicit more information?
>>> 
>> < cut >
>> 
>> Your config looks OK.
>> I guess your user doesn't have the privileges needed on your LDAP.
>> 
>> In order to get more debugging information for your LDAP access, add the
>> following to your config:
>>LDAPDebugEnabled = YES;
>> 
>> 
>> Kind regards,
>> Christian Mack
>> 
>> -- 
>> Christian Mack
>> Abteilung Basisdienste
>> KIM
>> Universität Konstanz
>> -- 
>> users@sogo.nu
>> https://inverse.ca/sogo/lists
> 

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Can't Login after Install/Configuration of New Instance

2014-02-25 Thread Ron Scott-Adams

Hello Christian, thanks for the reply.

After adding the LDAP clause to my conf and restarting SOGo, I get no further 
information in sogo.log. For the record, the ACL entry for the SOGo LDAP user 
follows. It’s identical to the permissions in my functional SOGo 
implementation, and the DIT is structured the same.

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to dn.subtree="ou=Users,dc=tohuw,dc=net" by 
dn="uid=sogo,ou=Services,dc=tohuw,dc=net" write


Ron Scott-Adams
r...@tohuw.net
“We are stuck with technology when what we really want is just stuff that 
works.” (Douglas Adams)




On Feb 25, 2014, at 5:58 AM, Christian Mack  
wrote:

> Hello Ron Scott-Adams
> 
> 
> Am 2014-02-25 03:53, schrieb Ron Scott-Adams:
>> I'm building a new SOGo install very similar to a current, working one.
>> I'm experiencing an issue with logging in. There is a single auth source
>> (ldap). The error is: "SOGoRootPage Login for user 'username' might not
>> have worked - password policy: 65535  grace: -1  expire: -1  bound: 0"
>> What can I do to elicit more information?
>> 
> < cut >
> 
> Your config looks OK.
> I guess your user doesn't have the privileges needed on your LDAP.
> 
> In order to get more debugging information for your LDAP access, add the
> following to your config:
>LDAPDebugEnabled = YES;
> 
> 
> Kind regards,
> Christian Mack
> 
> -- 
> Christian Mack
> Abteilung Basisdienste
> KIM
> Universität Konstanz
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Can't Login after Install/Configuration of New Instance

2014-02-24 Thread Ron Scott-Adams

I'm building a new SOGo install very similar to a current, working one. I'm 
experiencing an issue with logging in. There is a single auth source (ldap). 
The error is: "SOGoRootPage Login for user 'username' might not have worked - 
password policy: 65535  grace: -1  expire: -1  bound: 0" What can I do to 
elicit more information?

The configuration is not different between the two servers that I can tell, 
except those parts necessary due to the server being different. I have ensured 
the necessary entries exist in LDAP, and everything else seems correct. 
ldapwhoami authenticates the user fine.

My sogo.conf follows. If I can provide anything else, please let me know.

{
SOGoProfileURL = "postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
OCSFolderInfoURL = 
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
OCSSessionsFolderURL = 
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
OCSEMailAlarmsFolderURL = 
"postgresql://sogo:sogo@localhost:5432/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";
   bindPassword = [redacted];
   canAuthenticate = YES;
   displayName = "Shared Addresses";
   hostname = ldap://127.0.0.1:389;
   id = public;
   isAddressBook = YES;
   }
);

SOGoPasswordChangeEnabled = YES;

SOGoPageTitle = Webmail;
SOGoLanguage = English;
SOGoTimeZone = America/New_York;
}


Ron Scott-Adams
r...@tohuw.net
“We are stuck with technology when what we really want is just stuff that 
works.” (Douglas Adams)




-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Responses to Events Sent to Wrong Address

2013-08-06 Thread Ron Scott-Adams

There is! In fact, it's my user. uid=tohuw, mail=r...@tohuw.net. So, where am I missing something?On Monday, August 5, 2013 11:06 EDT, Christian Mack  wrote: Am 2013-08-03 04:12, schrieb Ron Scott-Adams:> SOGo 2.0.7, Ubuntu 12.04.2 with OpenLDAP/Postfix/Dovecot>> My email address I use with SOGo is r...@tohuw.net. However, whenever> a calendar invite is sent, it emits from to...@tohuw.net. I cannot> see why. My config is at http://paste2.org/3BL2m8zB. No account in> the DIT has a mail of to...@tohuw.net. Let me know what other details> I can provide. Thanks!>Is there a user with uid=tohuw ?Kind regards,Christian Mack--Christian MackGruppe InformationsdiensteRechenzentrum Universität Konstanz--users@sogo.nuhttps://inverse.ca/sogo/lists

[SOGo] Responses to Events Sent to Wrong Address

2013-08-02 Thread Ron Scott-Adams

SOGo 2.0.7, Ubuntu 12.04.2 with OpenLDAP/Postfix/Dovecot

My email address I use with SOGo is r...@tohuw.net. However, whenever a 
calendar invite is sent, it emits from to...@tohuw.net. I cannot see why. My 
config is at http://paste2.org/3BL2m8zB. No account in the DIT has a mail of 
to...@tohuw.net. Let me know what other details I can provide. Thanks!


Ron Scott-Adams
r...@tohuw.net
"The truth is incontrovertible. Malice may attack it, ignorance may deride it, 
but in the end, there it is." (Winston Churchill)







-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Can't See or Send Calendar Invites (OS X Calendar/Mail)

2013-06-18 Thread Ron Scott-Adams

So, it seems the web interface does work, the emails were just delayed in being 
sent to the test accounts. They come through quickly enough now. So, iOS and 
Apple Calendar seem not to work, whereas the web interface does as it should.


Ron Scott-Adams
r...@tohuw.net
"We are stuck with technology when what we really want is just stuff that 
works." (Douglas Adams)







On Jun 18, 2013, at 19:34 , Ron Scott-Adams  wrote:

> I have found that while I can respond correctly to events sent to me on iOS, 
> I cannot create new ones and successfully invite attendees. They never 
> receive any invitations from the web interface or Apple Calendar.
> 
> Can someone please assist? Thank you.
> 
> 
> Ron Scott-Adams
> r...@tohuw.net
> Nothing in the world can take the place of persistence. Talent will not; 
> nothing is more common than unsuccessful men with talent. Genius will not; 
> unrewarded genius is almost a proverb. Education will not; the world is full 
> of educated derelicts. Persistence and determination alone are omnipotent. 
> The slogan "press on" has solved and always will solve the problems of the 
> human race." (Calvin Coolidge)
> 
> 
> 
> 
> 
> 
> On Jun 14, 2013, at 23:03 , Ron Scott-Adams  wrote:
> 
>> So, as an update to this issue, everything works just dandy on iOS, I found 
>> (didn't have an iOS device to test with until today).
>> 
>> From the iOS device, I can see invites and deal with them, it's just Apple 
>> Mail and Calendar where I get no joy. Any ideas?
>> 
>> 
>> Ron Scott-Adams
>> r...@tohuw.net
>> "We are stuck with technology when what we really want is just stuff that 
>> works." (Douglas Adams)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jun 13, 2013, at 20:23 , Ron Scott-Adams  wrote:
>> 
>>> Can someone provide some insight on the below, please? I'm at a loss
>>> 
>>> 
>>> Ron Scott-Adams
>>> r...@tohuw.net
>>> "The God who gave us life, gave us liberty at the same time; the hand of 
>>> force may destroy, but cannot disjoin them." (Thomas Jefferson)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Jun 7, 2013, at 22:24 , Ron Scott-Adams  wrote:
>>> 
>>>> I can receive calendar invites as attachments to messages containing other 
>>>> stuff just fine, but if I send a calendar invite via Calendar or if 
>>>> someone sends me one, I never receive it in Calendar or Mail. Config is 
>>>> below. Thanks in advance.
>>>> 
>>>> {
>>>> SOGoProfileURL = 
>>>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
>>>> OCSFolderInfoURL = 
>>>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
>>>> OCSSessionsFolderURL = 
>>>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
>>>> OCSEMailAlarmsFolderURL = 
>>>> "postgresql://sogo:sogo@localhost:5432/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;
>>>> 
>>>> SOGoSieveServer = sieve://127.0.0.1:4190;
>>>> SOGoSieveScriptsEnabled = YES;
>>>> SOGoVacationEnabled = YES;
>>>> SOGoForwardEnabled = YES;
>>>> SOGoSieveServer = sieve://127.0.0.1:4190;
>>>> 
>>>> SOGoAppointmentSendEMailNotifications = YES;
>>>> SOGoACLsSendEMailNotifications = 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";
>>>> bindPassword = [redacted];
>>>> canAuthenticate = YES;
>>>> displayName = "Shared Addresses";
>>>> hostname = ldap://127.0.0.1:389;
>>>> id = public;
>>>> isAddressBook = YES;
>>>> }
>>>> );
>>>> 
>>>> SOGoPageTitle = Webmail;
>>>> SOGoLanguage = English;
>>>> SOGoTimeZone = America/New_York;
>>>> }
>>>> 
>>>> 
>>>> 
>>>> Ron Scott-Adams
>>>> r...@tohuw.net
>>>> "Soap and education are not as sudden as a massacre, but they are more 
>>>> deadly in the long run." (Mark Twain)
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Can't See or Send Calendar Invites (OS X Calendar/Mail)

2013-06-18 Thread Ron Scott-Adams

I have found that while I can respond correctly to events sent to me on iOS, I 
cannot create new ones and successfully invite attendees. They never receive 
any invitations from the web interface or Apple Calendar.

Can someone please assist? Thank you.


Ron Scott-Adams
r...@tohuw.net
Nothing in the world can take the place of persistence. Talent will not; 
nothing is more common than unsuccessful men with talent. Genius will not; 
unrewarded genius is almost a proverb. Education will not; the world is full of 
educated derelicts. Persistence and determination alone are omnipotent. The 
slogan "press on" has solved and always will solve the problems of the human 
race." (Calvin Coolidge)






On Jun 14, 2013, at 23:03 , Ron Scott-Adams  wrote:

> So, as an update to this issue, everything works just dandy on iOS, I found 
> (didn't have an iOS device to test with until today).
> 
> From the iOS device, I can see invites and deal with them, it's just Apple 
> Mail and Calendar where I get no joy. Any ideas?
> 
> 
> Ron Scott-Adams
> r...@tohuw.net
> "We are stuck with technology when what we really want is just stuff that 
> works." (Douglas Adams)
> 
> 
> 
> 
> 
> 
> 
> On Jun 13, 2013, at 20:23 , Ron Scott-Adams  wrote:
> 
>> Can someone provide some insight on the below, please? I'm at a loss
>> 
>> 
>> Ron Scott-Adams
>> r...@tohuw.net
>> "The God who gave us life, gave us liberty at the same time; the hand of 
>> force may destroy, but cannot disjoin them." (Thomas Jefferson)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Jun 7, 2013, at 22:24 , Ron Scott-Adams  wrote:
>> 
>>> I can receive calendar invites as attachments to messages containing other 
>>> stuff just fine, but if I send a calendar invite via Calendar or if someone 
>>> sends me one, I never receive it in Calendar or Mail. Config is below. 
>>> Thanks in advance.
>>> 
>>> {
>>> SOGoProfileURL = 
>>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
>>> OCSFolderInfoURL = 
>>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
>>> OCSSessionsFolderURL = 
>>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
>>> OCSEMailAlarmsFolderURL = 
>>> "postgresql://sogo:sogo@localhost:5432/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;
>>> 
>>> SOGoSieveServer = sieve://127.0.0.1:4190;
>>> SOGoSieveScriptsEnabled = YES;
>>> SOGoVacationEnabled = YES;
>>> SOGoForwardEnabled = YES;
>>> SOGoSieveServer = sieve://127.0.0.1:4190;
>>> 
>>> SOGoAppointmentSendEMailNotifications = YES;
>>> SOGoACLsSendEMailNotifications = 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";
>>> bindPassword = [redacted];
>>> canAuthenticate = YES;
>>> displayName = "Shared Addresses";
>>> hostname = ldap://127.0.0.1:389;
>>> id = public;
>>> isAddressBook = YES;
>>> }
>>> );
>>> 
>>> SOGoPageTitle = Webmail;
>>> SOGoLanguage = English;
>>> SOGoTimeZone = America/New_York;
>>> }
>>> 
>>> 
>>> 
>>> Ron Scott-Adams
>>> r...@tohuw.net
>>> "Soap and education are not as sudden as a massacre, but they are more 
>>> deadly in the long run." (Mark Twain)
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Can't See or Send Calendar Invites (OS X Calendar/Mail)

2013-06-14 Thread Ron Scott-Adams

So, as an update to this issue, everything works just dandy on iOS, I found 
(didn't have an iOS device to test with until today).

>From the iOS device, I can see invites and deal with them, it's just Apple 
>Mail and Calendar where I get no joy. Any ideas?


Ron Scott-Adams
r...@tohuw.net
"We are stuck with technology when what we really want is just stuff that 
works." (Douglas Adams)







On Jun 13, 2013, at 20:23 , Ron Scott-Adams  wrote:

> Can someone provide some insight on the below, please? I'm at a loss
> 
> 
> Ron Scott-Adams
> r...@tohuw.net
> "The God who gave us life, gave us liberty at the same time; the hand of 
> force may destroy, but cannot disjoin them." (Thomas Jefferson)
> 
> 
> 
> 
> 
> 
> 
> 
> On Jun 7, 2013, at 22:24 , Ron Scott-Adams  wrote:
> 
>> I can receive calendar invites as attachments to messages containing other 
>> stuff just fine, but if I send a calendar invite via Calendar or if someone 
>> sends me one, I never receive it in Calendar or Mail. Config is below. 
>> Thanks in advance.
>> 
>> {
>> SOGoProfileURL = 
>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
>> OCSFolderInfoURL = 
>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
>> OCSSessionsFolderURL = 
>> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
>> OCSEMailAlarmsFolderURL = 
>> "postgresql://sogo:sogo@localhost:5432/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;
>> 
>> SOGoSieveServer = sieve://127.0.0.1:4190;
>> SOGoSieveScriptsEnabled = YES;
>> SOGoVacationEnabled = YES;
>> SOGoForwardEnabled = YES;
>> SOGoSieveServer = sieve://127.0.0.1:4190;
>> 
>> SOGoAppointmentSendEMailNotifications = YES;
>> SOGoACLsSendEMailNotifications = 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";
>> bindPassword = [redacted];
>> canAuthenticate = YES;
>> displayName = "Shared Addresses";
>> hostname = ldap://127.0.0.1:389;
>> id = public;
>> isAddressBook = YES;
>> }
>> );
>> 
>> SOGoPageTitle = Webmail;
>> SOGoLanguage = English;
>> SOGoTimeZone = America/New_York;
>> }
>> 
>> 
>> 
>> Ron Scott-Adams
>> r...@tohuw.net
>> "Soap and education are not as sudden as a massacre, but they are more 
>> deadly in the long run." (Mark Twain)
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: Re: [SOGo] Resources Booking

2013-06-14 Thread Ron Scott-Adams

Hello, please reply to the list when replying. :) Thank you.Regarding your question, if your LDAP stack is configured to use ncsd, then it's likely SOGo may obey that when binding. I'd say if it happens again, try restarting ncsd and see what happens.I only suggested restarting slapd because it would likely force rebinds and reconnection of any current cache(s).For a tracing, try strace against slapd, or a more verbose debug level as per the options in slapd(8) (-1 or so).On Friday, June 14, 2013 07:56 EDT,  wrote: Hi,Thank you for your help. Do SOGo uses nscd to cache LDAP requests ? I'm notsure that restarting slapd would correct the situation.Concerning the second question, I can't see any useful trace. Should I add aspecifig debug log level ?Thank you
  !
 Best regards,Jean-Philippe.

Re: [SOGo] Can't See or Send Calendar Invites (OS X Calendar/Mail)

2013-06-13 Thread Ron Scott-Adams

Can someone provide some insight on the below, please? I'm at a loss


Ron Scott-Adams
r...@tohuw.net
"The God who gave us life, gave us liberty at the same time; the hand of force 
may destroy, but cannot disjoin them." (Thomas Jefferson)








On Jun 7, 2013, at 22:24 , Ron Scott-Adams  wrote:

> I can receive calendar invites as attachments to messages containing other 
> stuff just fine, but if I send a calendar invite via Calendar or if someone 
> sends me one, I never receive it in Calendar or Mail. Config is below. Thanks 
> in advance.
> 
> {
> SOGoProfileURL = 
> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
> OCSFolderInfoURL = 
> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
> OCSSessionsFolderURL = 
> "postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
> OCSEMailAlarmsFolderURL = 
> "postgresql://sogo:sogo@localhost:5432/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;
> 
> SOGoSieveServer = sieve://127.0.0.1:4190;
> SOGoSieveScriptsEnabled = YES;
> SOGoVacationEnabled = YES;
> SOGoForwardEnabled = YES;
> SOGoSieveServer = sieve://127.0.0.1:4190;
> 
> SOGoAppointmentSendEMailNotifications = YES;
> SOGoACLsSendEMailNotifications = 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";
> bindPassword = [redacted];
> canAuthenticate = YES;
> displayName = "Shared Addresses";
> hostname = ldap://127.0.0.1:389;
> id = public;
> isAddressBook = YES;
> }
> );
> 
> SOGoPageTitle = Webmail;
> SOGoLanguage = English;
> SOGoTimeZone = America/New_York;
> }
> 
> 
> 
> Ron Scott-Adams
> r...@tohuw.net
> "Soap and education are not as sudden as a massacre, but they are more deadly 
> in the long run." (Mark Twain)
> 
> 
> 
> 
> 
> 
> 

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Resources Booking

2013-06-13 Thread Ron Scott-Adams

If the value didn't appear to be different until you restarted the whole 
server, I'd guess restarting slapd would have done the trick.

Regarding the second question, can you post the complete content (including all 
headers) of a message emanating under the conditions you described?


Ron Scott-Adams
r...@tohuw.net
"The truth is incontrovertible. Malice may attack it, ignorance may deride it, 
but in the end, there it is." (Winston Churchill)







On Jun 13, 2013, at 14:27 , jean-philippe.ghiba...@oca.eu wrote:

> Hi,
> 
> It's just pure knowledge, but I've just configured the Resource Booking with
> SOGo successfully. The first time, I set Multiplebookings attribute on my
> OpenLDAP server to 0. I've spent quite a lot of time to figure out why, as I
> changed for 1, the resource didn't reject a second overlapping booking.
> 
> The value of Multiplebookings attribute seems to be cached, or store in
> database. I restarted a lot of time the SOGo service and it has never red 
> again
> the attribute.
> I don't usually do that with a Linux server, but I've rebooted it and... It 
> now
> works !
> 
> Could someone please explain to me what's the process ?
> 
> Plus, it does not concern the Inverse team, but I can't invite people (so a
> resource) by adding the email address in the guests field on my Android 4.2.2
> phone with Funambol and the standard Google app for calendars. Someone knows
> the trick ?
> 
> Thank you,
> Best regards,
> Jean-Philippe.
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Caldav support and SOGo

2013-06-13 Thread Ron Scott-Adams

Can you post your sogo.conf, please?

Ron Scott-Adams
r...@tohuw.net
Nothing in the world can take the place of persistence. Talent will not; 
nothing is more common than unsuccessful men with talent. Genius will not; 
unrewarded genius is almost a proverb. Education will not; the world is full of 
educated derelicts. Persistence and determination alone are omnipotent. The 
slogan "press on" has solved and always will solve the problems of the human 
race." (Calvin Coolidge)

On Jun 12, 2013, at 21:15 , Louis-Philippe Gauthier  
wrote:

> Hi,
> 
> Where can I find documentation for CalDav support for SOGo?
> 
> I looked in Apache's documentation. I enabled dav and dav_fs in Apache
> 
> and now ? 
> 
> I always have the message :
> 
> An error occurred during object publishing
> 
> no WebDAV GET support?!
> 
> 
> 
> -- 
> Louis-Philippe

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Sogo Web Address

2013-06-13 Thread Ron Scott-Adams

A reverse proxy would arguably harden your server.

If you don't mind that the fact that the URL will still translate "back" on the 
address bar, you could utilize a rewrite rule.

Examples abound in the documentation and list archive.

Ron Scott-Adams
r...@tohuw.net
"The God who gave us life, gave us liberty at the same time; the hand of force 
may destroy, but cannot disjoin them." (Thomas Jefferson)

On Jun 13, 2013, at 15:39 , Ian J.  wrote:

> Hi,
> 
> I'm not confident of setting up a proxy based change to my mail server due to
> potential issues with hacking. Is there no way to change the address within 
> the
> SOGo configuration?
> 
> Ian
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Auto-reply ? Possible

2013-06-08 Thread Ron Scott-Adams

It means it passed through SOGo, and that SOGo tacked on that header because it 
classified the message as a calendar invitation reply. Can you post your 
sogo.conf, please?


Ron Scott-Adams
r...@tohuw.net
"Soap and education are not as sudden as a massacre, but they are more deadly 
in the long run." (Mark Twain)







On Jun 8, 2013, at 03:42 , Albert Shih  wrote:

> Le 07/06/2013 ? 22:59:47-0400, Ron Scott-Adams a écrit
> Hi,
> 
>> I'm willing to bet this user has some setting in their client treating 
>> calendar
> 
> Wellbecause I don't like to loose ;-) ;-)
> 
>> invites in some fashion (either automatically rejecting or accepting them.)
> 
> PossibleHe using generally AppleMail, but if it's the situation why the
> mail « he » (or AppleMail) send have this header 
> 
> x-sogo-message-type: calendar:invitation-reply
> 
> Isn't that mean it's send by sogo ? 
> 
> Thanks for the help
> 
> Regards.
> 
> JAS
> -- 
> Albert SHIH
> DIO bâtiment 15
> Observatoire de Paris
> 5 Place Jules Janssen
> 92195 Meudon Cedex
> France
> Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
> xmpp: j...@obspm.fr
> Heure local/Local time:
> sam 8 jui 2013 09:40:08 CEST
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Auto-reply ? Possible

2013-06-07 Thread Ron Scott-Adams

I'm willing to bet this user has some setting in their client treating calendar 
invites in some fashion (either automatically rejecting or accepting them.)

What happens if you send this user a calendar invite and trace the emissions 
from that users account for awhile?


Ron Scott-Adams
r...@tohuw.net
"The God who gave us life, gave us liberty at the same time; the hand of force 
may destroy, but cannot disjoin them." (Thomas Jefferson)








On Jun 7, 2013, at 17:09 , Albert Shih  wrote:

> Le 07/06/2013 ? 10:55:59+0200, Christian Mack a écrit
> Hi,
> 
> Thanks for your answer.
> 
>> 
>> 
>> Am 2013-06-06 23:09, schrieb Albert Shih:
>>> 
>>> I've a strange report from one of my user. 
>>> 
>>> He claim he just receive some message from yahoo (not important can be any
>>> server) smtp server for unknown user. 
>>> 
>>> Meanning he send a email to this unknown user. Of course he never send this
>>> message (spam). 
>>> 
>>> First I suspect some basic spam. But when I check the header I see : 
>>> 
>>>x-sogo-message-type: calendar:invitation-reply
>>> 
>>> and indeed the message is really send from sogo.
>>> 
>>> My question is : Is it possible sogo reply AUTOMATICALLY to some message ?
>>> That's sound very strange to me but...well...I'm want to be sure. 
>>> 
>> 
>> If you use resource accounts, then yes.
>> They will automatically accept invitations, if the desired time frame is
>> not already used up by other events.
>> Accepting invitations from users outside SOGo means sending them an email.
>> 
>> That is by design, and the sole purpose of resource accounts.
>> 
> 
> Well the point is I don't use resource accounts. And more strange the first
> mail was a spam. 
> 
> What I can find in the log, 
> 
>someone on internet send a spam to my user.
> 
>sogo answer automaticaly to this spam
> 
>of course the spammer address don't exist
> 
>so the user received a return warning message say the spammer address
>don't exist.
> 
> I'm little worry about that because that's mean if it's really append, some
> spammer can use sogo as spam realy. 
> 
> Regards. 
> 
> -- 
> Albert SHIH
> DIO bâtiment 15
> Observatoire de Paris
> 5 Place Jules Janssen
> 92195 Meudon Cedex
> France
> Téléphone : +33 1 45 07 76 26/+33 6 86 69 95 71
> xmpp: j...@obspm.fr
> Heure local/Local time:
> ven 7 jui 2013 23:05:45 CEST
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Can't See or Send Calendar Invites (OS X Calendar/Mail)

2013-06-07 Thread Ron Scott-Adams

I can receive calendar invites as attachments to messages containing other 
stuff just fine, but if I send a calendar invite via Calendar or if someone 
sends me one, I never receive it in Calendar or Mail. Config is below. Thanks 
in advance.

{
SOGoProfileURL = "postgresql://sogo:sogo@localhost:5432/sogo/sogo_user_profile";
OCSFolderInfoURL = 
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_folder_info";
OCSSessionsFolderURL = 
"postgresql://sogo:sogo@localhost:5432/sogo/sogo_sessions_folder";
OCSEMailAlarmsFolderURL = 
"postgresql://sogo:sogo@localhost:5432/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;

SOGoSieveServer = sieve://127.0.0.1:4190;
SOGoSieveScriptsEnabled = YES;
SOGoVacationEnabled = YES;
SOGoForwardEnabled = YES;
SOGoSieveServer = sieve://127.0.0.1:4190;

SOGoAppointmentSendEMailNotifications = YES;
SOGoACLsSendEMailNotifications = 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";
bindPassword = [redacted];
canAuthenticate = YES;
displayName = "Shared Addresses";
hostname = ldap://127.0.0.1:389;
id = public;
isAddressBook = YES;
}
);

SOGoPageTitle = Webmail;
SOGoLanguage = English;
SOGoTimeZone = America/New_York;
}



Ron Scott-Adams
r...@tohuw.net
"Soap and education are not as sudden as a massacre, but they are more deadly 
in the long run." (Mark Twain)







-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] SOGo Sieve Scripts Path?

2013-06-07 Thread Ron Scott-Adams

Gah, sorry. Disregard again. Just realized that's set in the sieve options for 
dovecot.


Ron Scott-Adams
r...@tohuw.net
"The God who gave us life, gave us liberty at the same time; the hand of force 
may destroy, but cannot disjoin them." (Thomas Jefferson)








On Jun 7, 2013, at 10:46 , Ron Scott-Adams  wrote:

> Is there a config option to change the default path for where the sieve 
> scripts are created (from ~/sieve)? I didn't see one in the admin guide.
> 
> 
> Ron Scott-Adams
> r...@tohuw.net
> "Soap and education are not as sudden as a massacre, but they are more deadly 
> in the long run." (Mark Twain)
> 
> 
> 
> 
> 
> 
> 

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] SOGo Sieve Scripts Path?

2013-06-07 Thread Ron Scott-Adams

Is there a config option to change the default path for where the sieve scripts 
are created (from ~/sieve)? I didn't see one in the admin guide.


Ron Scott-Adams
r...@tohuw.net
"Soap and education are not as sudden as a massacre, but they are more deadly 
in the long run." (Mark Twain)







-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Mail Filters under Mail Options?

2013-06-07 Thread Ron Scott-Adams

Disregard, found option SOGoSieveScriptsEnabled right under my nose in the 
admin guide. I have dovecot-sieve installed, so this should work…


Ron Scott-Adams
r...@tohuw.net
"The God who gave us life, gave us liberty at the same time; the hand of force 
may destroy, but cannot disjoin them." (Thomas Jefferson)








On Jun 7, 2013, at 09:41 , Ron Scott-Adams  wrote:

> I noticed many SOGo providers/help guides talking about filtering options in 
> the "Mail options" tab. I don't have those on my SOGo 2.0.5 installation. 
> What must I do to get them?
> 
> 
> Ron Scott-Adams
> r...@tohuw.net
> Nothing in the world can take the place of persistence. Talent will not; 
> nothing is more common than unsuccessful men with talent. Genius will not; 
> unrewarded genius is almost a proverb. Education will not; the world is full 
> of educated derelicts. Persistence and determination alone are omnipotent. 
> The slogan "press on" has solved and always will solve the problems of the 
> human race." (Calvin Coolidge)
> 
> 
> 
> 
> 
> 

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Mail Filters under Mail Options?

2013-06-07 Thread Ron Scott-Adams

I noticed many SOGo providers/help guides talking about filtering options in 
the "Mail options" tab. I don't have those on my SOGo 2.0.5 installation. What 
must I do to get them?


Ron Scott-Adams
r...@tohuw.net
Nothing in the world can take the place of persistence. Talent will not; 
nothing is more common than unsuccessful men with talent. Genius will not; 
unrewarded genius is almost a proverb. Education will not; the world is full of 
educated derelicts. Persistence and determination alone are omnipotent. The 
slogan "press on" has solved and always will solve the problems of the human 
race." (Calvin Coolidge)






-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Samba 4 source install with Openchange

2013-06-06 Thread Ron Scott-Adams

Dominique,

I haven't built a .deb from a Git source before, but here's a discussion on 
that matter from a few years back on Debian list: 
http://lists.debian.org/debian-devel/2010/11/msg00118.html. While not really 
the same problem you're having, it may be worth reading through to get an idea 
as to how get-orig-source relates to SCMs. For further assistance, I suggest 
the Debian or Ubuntu Devel lists, as I don't wish to derail this list too much 
further with an essentially off-topic issue. Good luck!


Ron Scott-Adams
r...@tohuw.net
"The truth is incontrovertible. Malice may attack it, ignorance may deride it, 
but in the end, there it is." (Winston Churchill)





On Jun 6, 2013, at 07:18 , Dominique  wrote:

> Hi Ron,
> 
> Thanks for the detailed answer. Too make it simple and sweet I went with 
> option 3... I'll go for the build. I already successfully installed samba4 
> from source so, I figure I could go a bit further and try to package it.
> 
> I already went through some how-tos to reuse the git repository I cloned 
> earlier. Got the git package builder but I am stuck with a
> 
> ./debian/rules get-orig-source
> 
> That I cant seem to find. I'll keep looking for it. Any pointers ?
> 
> If not, I'll go back to the official Debian manual and start from scratch 
> again.
> 
> Cheers,
> 
> Dominique
> 
> 
> 
> On 06/06/2013 11:21, Ron Scott-Adams wrote:
>> Hi Dominique,
>> 
>> A few suggestions:
>> 
>> 1) Try calling apt-get install with --arch-only. Per the apt-get man page: 
>> "Only process architecture-dependent build-dependencies." This probably 
>> won't work, as Samba4 is likely to still be considered dependent in this 
>> case.
>> 
>> 
>> 2) You could try --force-yes: "Force yes; This is a dangerous option that 
>> will cause apt to continue without prompting if it is doing something 
>> potentially harmful. It should not be used except in very special 
>> situations. Using force-yes can potentially destroy your system!" Mind the 
>> warning; but if you think it through, this may work out fine.
>> 
>> 
>> 3) The cleanest option, most likely, is to build a package as Christian 
>> suggested. Depending on your time/willingness, you may consider one of these 
>> options:
>>  
>> a) There is a PPA (personal package archive) which claims to have a package 
>> already for the stable Samba4 targeted to Ubuntu 12.04: deb 
>> http://ppa.launchpad.net/kernevil/samba4/ubuntu precise main
>> 
>> Note the version string for the samba4 source provided is 
>> 4.0.1+dfsg1-1+zentyal2, so it may be worth asking someone who knows if this 
>> constitutes the build you are looking for. (I wouldn't get hung up on the 
>> +xyz strings, it's common to tack on things there to satisfy or clue in 
>> other packages when really the sources themselves have little to do with 
>> those strings.)
>> 
>> The latest Samba4 is 4.0.6 (May 21), so this does put you a bit behind the 
>> game. Another PPA (https://launchpad.net/~wagungs/+archive/samba4) seems to 
>> have 4.0.3 (4.0.3+dfsg1-0.1), and the provider may supply newer packages 
>> soon enough (it never hurts to contact them and ask).
>> 
>> There may be other PPAs still; those were just some I found following links.
>> 
>> b) If you wish to build the latest package yourself, take a look at the 
>> Debian New Maintainer's guide: 
>> http://www.debian.org/doc/manuals/maint-guide/. It's not so painful, and 
>> there are other, quicker guides out there if you're looking to just jump 
>> into it, but of course it's best to do things the "most right way" the first 
>> time. :)
>> 
>> If you'd like further assistance building the package, both the Ubuntu 
>> Developer's mailing list and the Debian Dev list are helpful.
>> 
>> c) I doubt you'd want to, but you could always just wait for an official 
>> package to come through the repos. Despite the grumbling and moaning on 
>> forums and lists out there, I doubt Canonical has turned a deaf ear to the 
>> masses' cry for Samba4, but they are slow to build packages, as they tend to 
>> be more conservative to ensure stability (hence the swell of PPAs out there).
>> 
>> However, I think it's more likely that any later build of Samba4 is going to 
>> appear in 13.04 first, and then be backported. As you can see, 4.0.0 is the 
>> most current they provide: 
>> http://packages.ubuntu.com/search?keywords=samba4&searchon=names&exact=1&suite=all§ion=all
>>

Re: [SOGo] Samba 4 source install with Openchange

2013-06-06 Thread Ron Scott-Adams

Hi Dominique,

A few suggestions:

1) Try calling apt-get install with --arch-only. Per the apt-get man page: 
"Only process architecture-dependent build-dependencies." This probably won't 
work, as Samba4 is likely to still be considered dependent in this case.

2) You could try --force-yes: "Force yes; This is a dangerous option that will 
cause apt to continue without prompting if it is doing something potentially 
harmful. It should not be used except in very special situations. Using 
force-yes can potentially destroy your system!" Mind the warning; but if you 
think it through, this may work out fine.

3) The cleanest option, most likely, is to build a package as Christian 
suggested. Depending on your time/willingness, you may consider one of these 
options:

a) There is a PPA (personal package archive) which claims to have a package 
already for the stable Samba4 targeted to Ubuntu 12.04: deb 
http://ppa.launchpad.net/kernevil/samba4/ubuntu precise main

Note the version string for the samba4 source provided is 
4.0.1+dfsg1-1+zentyal2, so it may be worth asking someone who knows if this 
constitutes the build you are looking for. (I wouldn't get hung up on the +xyz 
strings, it's common to tack on things there to satisfy or clue in other 
packages when really the sources themselves have little to do with those 
strings.)

The latest Samba4 is 4.0.6 (May 21), so this does put you a bit behind the 
game. Another PPA (https://launchpad.net/~wagungs/+archive/samba4) seems to 
have 4.0.3 (4.0.3+dfsg1-0.1), and the provider may supply newer packages soon 
enough (it never hurts to contact them and ask).

There may be other PPAs still; those were just some I found following links.

b) If you wish to build the latest package yourself, take a look at the Debian 
New Maintainer's guide: http://www.debian.org/doc/manuals/maint-guide/. It's 
not so painful, and there are other, quicker guides out there if you're looking 
to just jump into it, but of course it's best to do things the "most right way" 
the first time. :)

If you'd like further assistance building the package, both the Ubuntu 
Developer's mailing list and the Debian Dev list are helpful.

c) I doubt you'd want to, but you could always just wait for an official 
package to come through the repos. Despite the grumbling and moaning on forums 
and lists out there, I doubt Canonical has turned a deaf ear to the masses' cry 
for Samba4, but they are slow to build packages, as they tend to be more 
conservative to ensure stability (hence the swell of PPAs out there).

However, I think it's more likely that any later build of Samba4 is going to 
appear in 13.04 first, and then be backported. As you can see, 4.0.0 is the 
most current they provide: 
http://packages.ubuntu.com/search?keywords=samba4&searchon=names&exact=1&suite=all§ion=all

12.04 will be the current LTS until April 2014, so it seems very possible a 
backport could trickle down in that time (for at least 4.04 or so).

Hopefully some of this info helps. Good luck!

On Jun 6, 2013, at 02:06 , Christian Mack  
wrote:

> Hello Dominique
> 
> 
> Am 2013-06-05 18:40, schrieb Dominique:
>> 
>> I am trying to setup a new Ubuntu 12.04 LTS server with samba4 and sogo.
>> 
>> I tried to install samba4 from repositories - ubuntu and sogo with no
>> results. It just does not want to work.
>> 
>> I finally installed samba4 from source. It allows to install the last
>> stable version of samba instead of an alpha or beta. That went well.
>> 
>> I am now trying to resume installing sogo with openchange through
>> repositories but it want to reinstall samba4...
>> 
>> Any idea if what I do is feasible - mixing sources and repository
>> install ? How do I tell openchange/sogo that I already have samba
>> installed ? Do I have to keep installing from source ?
>> 
>> Any hint is welcome.
>> 
> 
> I assume you "installed" samba4 via make install.
> This does not work.
> 
> You have to make a deb-package out of your self compiled samba4.
> Then install it via dpkg.
> With that Ubuntu knows, that you installed samba4 already.
> 
> 
> Kind regards,
> Christian Mack
> 
> -- 
> Christian Mack
> Gruppe Informationsdienste
> Rechenzentrum Universität Konstanz
> -- 
> users@sogo.nu
> https://inverse.ca/sogo/lists

Ron Scott-Adams
r...@tohuw.net
"The God who gave us life, gave us liberty at the same time; the hand of force 
may destroy, but cannot disjoin them." (Thomas Jefferson)

-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] 404 on login

2013-06-05 Thread Ron Scott-Adams

The last line in the log (10.0.40.34 - - [05/Jun/2013:20:46:25 +0200] "GET 
/(null):…) looks to be the issue. Can you post your SOGo Apache conf please?

On Jun 5, 2013, at 14:54 , spamv...@googlemail.com wrote:

> hi..
> 
> ive just setup 2.0.5a on centos.
> When i login I got a "404 Not Found"
> 
> Not Found
> 
> The requested URL /(null):/SOGo/so/hpeter/Calendar was not found on this 
> server.
> 
> 
> 
> the sogo.log shows:
> 
> 
> Jun 05 20:46:25 sogod [3370]: SOGoRootPage successful login from '10.0.40.34' 
> for user 'hpeter' - expire = -1  grace = -1
> 
> 10.0.40.34 - - [05/Jun/2013:20:46:25 GMT] "POST /SOGo/connect HTTP/1.1" 200 
> 27/46 0.167 - - 0
> 
> 10.0.40.34 - - [05/Jun/2013:20:46:25 GMT] "GET /SOGo/hpeter HTTP/1.1" 302 0/0 
> 0.002 - - 0
> 
> 10.0.40.34 - - [05/Jun/2013:20:46:25 GMT] "GET /SOGo/hpeter/view HTTP/1.1" 
> 302 0/0 0.004 - - 0
> 
> access.log
> 10.0.40.34 - - [05/Jun/2013:20:46:25 +0200] "GET 
> /SOGo.woa/WebServerResources/busy.gif HTTP/1.1" 200 825 "http://so
>  go2.mydom.net/SOGo/" "Mozilla/5.0 (Windows NT 6.2; WOW64; 
> rv:21.0) Gecko/20100101 Firefox/21.0"
> 10.0.40.34 - - [05/Jun/2013:20:46:25 +0200] "POST /SOGo/connect HTTP/1.1" 200 
> 27 "http://sogo2.mydom.net/SOGo/"; "Mo zilla/5.0 
> (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0"
> 10.0.40.34 - - [05/Jun/2013:20:46:25 +0200] "GET /SOGo/hpeter HTTP/1.1" 302 - 
> "http://sogo2.mydom.net/SOGo/"; "Moz illa/5.0 
> (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0"
> 10.0.40.34 - - [05/Jun/2013:20:46:25 +0200] "GET /SOGo/hpeter/view HTTP/1.1" 
> 302 - "http://sogo2.mydom.net/SOGo/";  
> "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0"
> 10.0.40.34 - - [05/Jun/2013:20:46:25 +0200] "GET 
> /(null):/SOGo/so/hpeter/Calendar HTTP/1.1" 404 312 "http://sogo2  
>.mydom.net/SOGo/" "Mozilla/5.0 (Windows NT 6.2; WOW64; 
> rv:21.0) Gecko/20100101 Firefox/21.0"
> 
> Any ideas ?
> 
> Hans
> 



Ron Scott-Adams
r...@tohuw.net
"The truth is incontrovertible. Malice may attack it, ignorance may deride it, 
but in the end, there it is." (Winston Churchill)





-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Can't Get Dovecot 2.0.19 to work with my SOGo installation

2013-06-04 Thread Ron Scott-Adams

I'm using LDAP authentication and can login via the web interface, but I
can't seem to get Dovecot connected.

Using netcat, a login tohuw [myPassword] returns "NO [AUTHENTICATIONFAILED]
Authentication failed." I believe I'm missing a configuration detail, but
what?


info.log: http://pastebin.ca/2388873

debug.log: http://pastebin.ca/2388872

error.log: http://pastebin.ca/2388871

dovecot -n: http://pastebin.ca/2388870

dovecot-ldap.conf.ext summary: http://pastebin.ca/2388867
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

Re: [SOGo] Cannot Bring Up Web Interface

2013-06-03 Thread Ron Scott-Adams

Ah, thanks Joro. You were quite right. Incidentally, Safari seems to not
handle case-sensitive URLs well if you previously typed them differently...

At any rate, inserting the following (inspired by the Debian Wiki entry for
SOGo) did the trick:

RewriteEngine On
RewriteRule ^/SOGo/(.*)$ /SOGo/$1 [env=REMOTE_HOST:%{REMOTE_ADDR},PT]
Redirect permanent /sogo https://mydomain.tld/SOGo


On Mon, Jun 3, 2013 at 3:33 AM, Joro Mindlab  wrote:

>
> Am 03.06.2013 09:20 schrieb "Ron Scott-Adams" :
>
> >
> > Try as I may, I cannot get the web interface of Sogo working. I can see
> the incompatible browser warning page from links on the server at
> 127.0.0.1:2 (therefore everything local seems to work).
> >
> > I have configured the SOGo.conf file: http://paste.ubuntu.com/5728492/
> >
> > I have ensured the modules proxy, proxy http, headers and rewrite are
> enabled.
> >
> > I have tried disabling the parent site (the one that causes the 404 page
> you see currently if you try http://sogo.com/sogo).
> >
> > I see nothing relevant in the sogo or Apache logs, except Apache
> complaining it was not able to find /var/www/sogo, which tells me the proxy
> settings are not working.
> >
> > What can I try?
>
> Hi,
> The URL you are looking for is http://yourbox.com/SOGo with capital
> letters, not /sogo. Either change your apache conf or, if don't want to
> remember the 'right' spelling just rewrite anything that matches the string
> sogo in any case to your configured url.
> Hth,
> Joro
>
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Re: Cannot Receive Mail

2013-06-03 Thread Ron Scott-Adams

I should also mention that I did attempt to test mail acceptance by telnet
for this address and received a 550 5.1.1: Recipient address rejected: User
unknown in local recipient table.

Do I need to configure Postfix to look to LDAP or something?

On Mon, Jun 3, 2013 at 4:50 AM, Ron Scott-Adams  wrote:

> I have SOGo up and running with one user. This user can send mail, but not
> receive it. I am using Postfix and Dovecot. I am unsure what configuration
> I need to do to get this working.
>
> I do not see any mail folders in the web interface, just a parent node
> with the user's email address. The domain is valid and this server has
> received mail before for this address, just not using SOGo.
>
> Please advise as to what useful configuration information I can provide.
> Thanks!
>
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Cannot Receive Mail

2013-06-03 Thread Ron Scott-Adams

I have SOGo up and running with one user. This user can send mail, but not
receive it. I am using Postfix and Dovecot. I am unsure what configuration
I need to do to get this working.

I do not see any mail folders in the web interface, just a parent node with
the user's email address. The domain is valid and this server has received
mail before for this address, just not using SOGo.

Please advise as to what useful configuration information I can provide.
Thanks!
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Cannot Bring Up Web Interface

2013-06-03 Thread Ron Scott-Adams

Try as I may, I cannot get the web interface of Sogo working. I can see the
incompatible browser warning page from links on the server at
127.0.0.1:2 (therefore everything local seems to work).

I have configured the SOGo.conf file: http://paste.ubuntu.com/5728492/

I have ensured the modules proxy, proxy http, headers and rewrite are
enabled.

I have tried disabling the parent site (the one that causes the 404 page
you see currently if you try http://sogo.com/sogo).

I see nothing relevant in the sogo or Apache logs, except Apache
complaining it was not able to find /var/www/sogo, which tells me the proxy
settings are not working.

What can I try?
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

[SOGo] Do I Need LDAP Entries for Existing Local Users?

2013-05-28 Thread Ron Scott-Adams

I noticed that OpenLDAP (or another LDAP provider) is required. Does this
imply I need to create an inetorgperson for my existing local users who will
have email addresses at various domains?Forgive my lack of experience
with LDAP in a POSIX environment, but what are the ramifications of having an
LDAP user and a local user for the same person? Or, is there some way to
import local users? I have asked a more complete version of this question at
serverfault.com: http://j.mp/131USMZThanks in advance.
-- 
users@sogo.nu
https://inverse.ca/sogo/lists

55 matches

Mail list logo