Re: [SOGo] SOGo 1.3.8a: loggin problems with multi domains
Hi Dominique On 2011-07-23, at 12:55 PM, Dominique BERTHET wrote: Upgrading to the 1.3.8a resolves all my ACL problems for shared calendars and contacts but now i have a new problem. I'm obliged to connect 2 times to the web interface. The fist time I try to log, i just come back to the login page and i have this message in the sogo.log: localhost - - [23/Jul/2011:18:07:04 GMT] POST /SOGo/connect HTTP/1.1 200 27/47 0.088 - - 664K Jul 23 18:07:04 sogod [1096]: 0x0x161aef0[SOGoWebAuthenticator] tried wrong password for user 'EAzDUDpXhKdFxxZulPFTbVmpjlSwDjt2LiqFOdv0MSxcUaxl8IQ1BRpREBpXXvxpUr8LWXizJ7b/M9MLkqajuw=='! The second time i log with any problem in the domain and everything is working Fixed in revision fb2d19f2d09037cb11414b10bc8c3bb8beb37bd9. Next nighly packages will include the fix. I have also notice that when i try to use sogo-tool, i have the following message: ERROR(+[GCSFolderManager defaultFolderManager]): default 'OCSFolderInfoURL' is not configured. but OCSFolderInfoURL id defined in my configuration... Run sogo-tool as your sogo user. Francis -- flachape...@inverse.ca :: +1.514.755.3640 :: http://www.inverse.ca Inverse :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] CardDAV iPhone address book sync issue
Hi All, Have just installed SOGo 1.3.8 under UBUNTU and having problems connecting to address book from iPhone. Can someone share a SOGo.conf file for Apache2 where address book works with iPhone over SSL? (I have set up sogo over SSL). From reading the web I got a feeling that there are some problems with Address Book sync and it's not working??? Thank you, Sergei. *** -- users@sogo.nu https://inverse.ca/sogo/lists
RE: [SOGo] Calendar items not getting saved
I assume I want to use the following when running postgresql: ./usr/share/doc/sogo-1.3.7a/sql-update-1.3.3_to_1.3.4.sh Regards, John John Marsetta Senior Support Engineer New England Organ Bank 60 First Avenue Waltham, MA 02451 (w)617-558-6623 (c)617-595-6754 (f)617-244-8755 [cid:image001.jpg@01CC4ACA.401F63F0] Sign up to be an organ donor @: https://secure.rmv.state.ma.us/OrganDonor/intro.aspx From: Ludovic Marcotte [mailto:lmarco...@inverse.ca] Sent: Thursday, July 21, 2011 4:31 PM To: users@sogo.nu Subject: Re: [SOGo] Calendar items not getting saved On 21/07/11 16:02, John Marsetta wrote: Jul 21 15:59:10 sogod [5677]: [ERROR] 0x0xb054cd0[GCSFolder] -[GCSFolder fetchFields:fetchSpecification:ignoreDeleted:]: cannot execute quick-fetch SQL 'SELECT b.c_name,b.c_content,b.c_creationdate,b.c_lastmodified,b.c_version,a.c_component,a.c_title,a.c_location,a.c_orgmail,a.c_status,a.c_category,a.c_classification,a.c_isallday,a.c_isopaque,a.c_participants,a.c_partmails,a.c_partstates,a.c_sequence,a.c_priority,a.c_cycleinfo,a.c_iscycle,a.c_nextalarm,a.c_uid,a.c_startdate,a.c_enddate FROM sogojmarsett00110d38fdd_quick a, sogojmarsett00110d38fdd b WHERE ((c_component = 'vevent') AND ((c_startdate IS NULL) OR (c_startdate = 1311825599)) AND ((c_enddate IS NULL) OR (c_enddate = 1311220800)) AND (c_iscycle = 0)) AND a.c_name = b.c_name AND (c_deleted != 1 OR c_deleted IS NULL)': PostgreSQL72Exception: 0xbb8ad28 NAME:PostgreSQL72FatalError REASON:fatal pgsql error (channel=0x0xbf93798[PostgreSQL72Channel]: connection=0x0xbbc6228[PGConnection]: connection=0x0xb00a708): ERROR: column a.c_category does not exist Run the update scripts. -- Ludovic Marcotte lmarco...@inverse.camailto:lmarco...@inverse.ca :: +1.514.755.3630 :: www.inverse.cahttp://www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nuhttp://www.sogo.nu) and PacketFence (www.packetfence.orghttp://www.packetfence.org) This email message and any files transmitted with it contain confidential information intended only for the person(s) to whom this email message is addressed. If you have received this email message in error, please notify the sender immediately by telephone or email and destroy the original message without printing or making a copy. inline: image001.jpg
Re: [SOGo] Parent process consumes 100% cpu
Hi,
I tried different numbers of sogod workers. Nothing worked. Since this
happens in our production server i can't investigate the problem if it
happens through the day.
Fortunately is right now happening an everyone already left the office.
This means 2 things:
1. There is not really any load on the server.
2. I can wait and do some debugging without being forced to restart SOGo.
Here what i found so far.
Parent process consuming full cpu.
6 child processes doing nothing with almost identical backtrace:
#0 0x7f42540ce02e in __lll_lock_wait_private () from /lib/libc.so.6
#1 0x7f425406bb43 in _L_lock_4488 () from /lib/libc.so.6
#2 0x7f4254068aab in free () from /lib/libc.so.6
#3 0x7f4254ec73c0 in default_free (zone=0x7f42552eae00,
ptr=0x8cb540) at NSZone.m:501
#4 0x7f4254d48a57 in NSZoneFree (zone=0x7f42552eae00, ptr=0x8cb540)
at ../Headers/Foundation/NSZone.h:373
#5 0x7f4254d492f3 in GSIMapMoreNodes (map=0xb2fb18, required=0) at
../Headers/Additions/GNUstepBase/GSIMap.h:442
#6 0x7f4254d4950f in GSIMapNewNode (map=0xb2fb18, key={addr =
139922873388096, obj = 0x7f42552a0c40, nso = 0x7f42552a0c40},
value={addr = 139922652533808, obj = 0x7f4248001430, nso =
0x7f4248001430}) at ../Headers/Additions/GNUstepBase/GSIMap.h:484
#7 0x7f4254d49962 in GSIMapAddPair (map=0xb2fb18, key={addr =
139922873388096, obj = 0x7f42552a0c40, nso = 0x7f42552a0c40},
value={addr = 139922652533808, obj = 0x7f4248001430, nso =
0x7f4248001430}) at ../Headers/Additions/GNUstepBase/GSIMap.h:774
#8 0x7f4254d4a3ae in -[GSMutableDictionary setObject:forKey:]
(self=0xb2fb10, _cmd=0x7f42552a11c0, anObject=0x7f4248001430,
aKey=0x7f42552a0c40) at GSDictionary.m:419
#9 0x7f4254e2b3f5 in +[NSNotificationQueue defaultQueue]
(self=0x7f42552a0f60, _cmd=0x7f4256b2b6d0) at NSNotificationQueue.m:314
#10 0x7f425681051b in signalHandlerFunction (signum=value optimized
out) at UnixSignalHandler.m:186
#11 signal handler called
#12 0x7f42540690a1 in _int_malloc () from /lib/libc.so.6
#13 0x7f425406aad8 in malloc () from /lib/libc.so.6
#14 0x7f42547ee91a in objc_malloc () from /usr/lib/libobjc.so.2
#15 0x7f4254ec7243 in default_malloc (zone=0x7f42552eae00, size=3)
at NSZone.m:466
#16 0x7f4254d67957 in NSZoneMalloc (zone=0x7f42552eae00, size=3) at
../Headers/Foundation/NSZone.h:316
#17 0x7f4254d7eb52 in -[GSMutableString initWithCapacity:]
(self=0x9344600, _cmd=0x7f42552ca050, capacity=2) at GSString.m:3890
#18 0x7f4254e92392 in +[NSMutableString string]
(self=0x7f42552c8a80, _cmd=0x7f4256e30100) at NSString.m:4769
#19 0x7f4256c0b7c6 in -[CardVersitRenderer renderElement:]
(self=0x9335290, _cmd=0x7f4256e300e0, anElement=0x9334ec0) at
CardVersitRenderer.m:64
#20 0x7f4256c0b749 in -[CardVersitRenderer render:] (self=0x9335290,
_cmd=0x7f4256e30290, anElement=0x9334ec0) at CardVersitRenderer.m:49
#21 0x7f4256c0bf55 in -[CardVersitRenderer renderGroup:]
(self=0x9335290, _cmd=0x7f4256e300d0, aGroup=0x9334e70) at
CardVersitRenderer.m:146
#22 0x7f4256c0b720 in -[CardVersitRenderer render:] (self=0x9335290,
_cmd=0x7f4256e2e590, anElement=0x9334e70) at CardVersitRenderer.m:49
#23 0x7f4256c09726 in -[CardElement versitString] (self=0x9334e70,
_cmd=0x7f4256e33580) at CardElement.m:491
#24 0x7f4256c0f557 in -[iCalCalendar versitString] (self=0x9334e70,
_cmd=0x7f424fbcdd20) at iCalCalendar.m:210
#25 0x7f424f99d832 in -[SOGoCalendarComponent secureContentAsString]
(self=0x930e750, _cmd=0x7f424fbcdf40) at SOGoCalendarComponent.m:261
#26 0x7f424f99e30b in -[SOGoCalendarComponent contentAsString]
(self=0x930e750, _cmd=0x7f424fbcdf70) at SOGoCalendarComponent.m:444
#27 0x7f424f99e3a5 in -[SOGoCalendarComponent davCalendarData]
(self=0x930e750, _cmd=0x6931d0) at SOGoCalendarComponent.m:456
#28 0x7f4254e3845a in -[NSObject performSelector:] (self=0x930e750,
_cmd=0x7f4257afe270, aSelector=0x6931d0) at NSObject.m:1954
#29 0x7f42578ac162 in ?? () from /usr/lib/libSOGo.so.1
#30 0x7f42578ac654 in ?? () from /usr/lib/libSOGo.so.1
#31 0x7f42578ac9c6 in ?? () from /usr/lib/libSOGo.so.1
#32 0x7f42578ad01a in ?? () from /usr/lib/libSOGo.so.1
#33 0x7f4254e3857a in -[NSObject performSelector:withObject:]
(self=0xcd63a0, _cmd=0x7f4256bc7600, aSelector=0x68ed80,
anObject=0x74c040) at NSObject.m:1980
#34 0x7f42568a55fe in -[SoSelectorInvocation
primaryCallSelector:withArguments:] (self=0xa0b8f0, _cmd=value
optimized out, _sel=0x68ed80, _args=0x90) at SoSelectorInvocation.m:226
#35 0x7f42568b8d66 in -[SoObjectWebDAVDispatcher doREPORT:]
(self=0x1149c60, _cmd=value optimized out, _ctx=0x74c040) at
SoObjectWebDAVDispatcher.m:1596
#36 0x7f4254e3857a in -[NSObject performSelector:withObject:]
(self=0x1149c60, _cmd=0x7f4256bda420, aSelector=0x6aa0c0,
anObject=0x74c040) at NSObject.m:1980
#37 0x7f42568b941c in -[SoObjectWebDAVDispatcher dispatchInContext:]
(self=0x1149c60, _cmd=value optimized
Re: [SOGo] CardDAV iPhone address book sync issue
On Jul 25, 2011, at 11:32 AM, sbaz...@gmail.com wrote: Hi All, Have just installed SOGo 1.3.8 under UBUNTU and having problems connecting to address book from iPhone. Can someone share a SOGo.conf file for Apache2 where address book works with iPhone over SSL? (I have set up sogo over SSL). From reading the web I got a feeling that there are some problems with Address Book sync and it's not working??? Thank you, Sergei. *** Here's mine... Works with both iPhones and desktop Macs using Address Book. Notice that CardDAV is over port 8843: VirtualHost 0.0.0.0:8843 ServerName sme.qzoneinc.com SSLEngine On 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 Proxy http://127.0.0.1:2 RequestHeader set x-webobjects-server-port 8843 RequestHeader set x-webobjects-server-name sme.qzoneinc.com:8843 RequestHeader set x-webobjects-server-url https://sme.qzoneinc.com: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 /Proxy /VirtualHost-- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] Parent process consumes 100% cpu
I need to correct myself. The backtraces are only identical up to line 16.
It seems that this is not code from SOGo. So it may be a bug in gnustep
or libc.
Since this server is still running debian lenny, it may be fixed in
squeeze.
Upgrade is planned anyway. I'll write again if the problem still exists
after the upgrade.
Cheers
Raffael
On 07/25/2011 07:03 PM, Raffael Bachmann wrote:
Hi,
I tried different numbers of sogod workers. Nothing worked. Since this
happens in our production server i can't investigate the problem if it
happens through the day.
Fortunately is right now happening an everyone already left the
office. This means 2 things:
1. There is not really any load on the server.
2. I can wait and do some debugging without being forced to restart SOGo.
Here what i found so far.
Parent process consuming full cpu.
6 child processes doing nothing with almost identical backtrace:
#0 0x7f42540ce02e in __lll_lock_wait_private () from /lib/libc.so.6
#1 0x7f425406bb43 in _L_lock_4488 () from /lib/libc.so.6
#2 0x7f4254068aab in free () from /lib/libc.so.6
#3 0x7f4254ec73c0 in default_free (zone=0x7f42552eae00,
ptr=0x8cb540) at NSZone.m:501
#4 0x7f4254d48a57 in NSZoneFree (zone=0x7f42552eae00,
ptr=0x8cb540) at ../Headers/Foundation/NSZone.h:373
#5 0x7f4254d492f3 in GSIMapMoreNodes (map=0xb2fb18, required=0)
at ../Headers/Additions/GNUstepBase/GSIMap.h:442
#6 0x7f4254d4950f in GSIMapNewNode (map=0xb2fb18, key={addr =
139922873388096, obj = 0x7f42552a0c40, nso = 0x7f42552a0c40},
value={addr = 139922652533808, obj = 0x7f4248001430, nso =
0x7f4248001430}) at ../Headers/Additions/GNUstepBase/GSIMap.h:484
#7 0x7f4254d49962 in GSIMapAddPair (map=0xb2fb18, key={addr =
139922873388096, obj = 0x7f42552a0c40, nso = 0x7f42552a0c40},
value={addr = 139922652533808, obj = 0x7f4248001430, nso =
0x7f4248001430}) at ../Headers/Additions/GNUstepBase/GSIMap.h:774
#8 0x7f4254d4a3ae in -[GSMutableDictionary setObject:forKey:]
(self=0xb2fb10, _cmd=0x7f42552a11c0, anObject=0x7f4248001430,
aKey=0x7f42552a0c40) at GSDictionary.m:419
#9 0x7f4254e2b3f5 in +[NSNotificationQueue defaultQueue]
(self=0x7f42552a0f60, _cmd=0x7f4256b2b6d0) at NSNotificationQueue.m:314
#10 0x7f425681051b in signalHandlerFunction (signum=value
optimized out) at UnixSignalHandler.m:186
#11 signal handler called
#12 0x7f42540690a1 in _int_malloc () from /lib/libc.so.6
#13 0x7f425406aad8 in malloc () from /lib/libc.so.6
#14 0x7f42547ee91a in objc_malloc () from /usr/lib/libobjc.so.2
#15 0x7f4254ec7243 in default_malloc (zone=0x7f42552eae00, size=3)
at NSZone.m:466
#16 0x7f4254d67957 in NSZoneMalloc (zone=0x7f42552eae00, size=3)
at ../Headers/Foundation/NSZone.h:316
#17 0x7f4254d7eb52 in -[GSMutableString initWithCapacity:]
(self=0x9344600, _cmd=0x7f42552ca050, capacity=2) at GSString.m:3890
#18 0x7f4254e92392 in +[NSMutableString string]
(self=0x7f42552c8a80, _cmd=0x7f4256e30100) at NSString.m:4769
#19 0x7f4256c0b7c6 in -[CardVersitRenderer renderElement:]
(self=0x9335290, _cmd=0x7f4256e300e0, anElement=0x9334ec0) at
CardVersitRenderer.m:64
#20 0x7f4256c0b749 in -[CardVersitRenderer render:]
(self=0x9335290, _cmd=0x7f4256e30290, anElement=0x9334ec0) at
CardVersitRenderer.m:49
#21 0x7f4256c0bf55 in -[CardVersitRenderer renderGroup:]
(self=0x9335290, _cmd=0x7f4256e300d0, aGroup=0x9334e70) at
CardVersitRenderer.m:146
#22 0x7f4256c0b720 in -[CardVersitRenderer render:]
(self=0x9335290, _cmd=0x7f4256e2e590, anElement=0x9334e70) at
CardVersitRenderer.m:49
#23 0x7f4256c09726 in -[CardElement versitString] (self=0x9334e70,
_cmd=0x7f4256e33580) at CardElement.m:491
#24 0x7f4256c0f557 in -[iCalCalendar versitString]
(self=0x9334e70, _cmd=0x7f424fbcdd20) at iCalCalendar.m:210
#25 0x7f424f99d832 in -[SOGoCalendarComponent
secureContentAsString] (self=0x930e750, _cmd=0x7f424fbcdf40) at
SOGoCalendarComponent.m:261
#26 0x7f424f99e30b in -[SOGoCalendarComponent contentAsString]
(self=0x930e750, _cmd=0x7f424fbcdf70) at SOGoCalendarComponent.m:444
#27 0x7f424f99e3a5 in -[SOGoCalendarComponent davCalendarData]
(self=0x930e750, _cmd=0x6931d0) at SOGoCalendarComponent.m:456
#28 0x7f4254e3845a in -[NSObject performSelector:]
(self=0x930e750, _cmd=0x7f4257afe270, aSelector=0x6931d0) at
NSObject.m:1954
#29 0x7f42578ac162 in ?? () from /usr/lib/libSOGo.so.1
#30 0x7f42578ac654 in ?? () from /usr/lib/libSOGo.so.1
#31 0x7f42578ac9c6 in ?? () from /usr/lib/libSOGo.so.1
#32 0x7f42578ad01a in ?? () from /usr/lib/libSOGo.so.1
#33 0x7f4254e3857a in -[NSObject performSelector:withObject:]
(self=0xcd63a0, _cmd=0x7f4256bc7600, aSelector=0x68ed80,
anObject=0x74c040) at NSObject.m:1980
#34 0x7f42568a55fe in -[SoSelectorInvocation
primaryCallSelector:withArguments:] (self=0xa0b8f0, _cmd=value
optimized out, _sel=0x68ed80, _args=0x90) at
SoSelectorInvocation.m:226
#35 0x7f42568b8d66 in
[SOGo] Authentication Error
Fellow SOGo users,
I'm having trouble with authentication. Help would greatly be appreciated.
When I login with a new user, this error displays in the web interface:
Login failed due to unhandled error case: -1
The logs show this error:
Jul 25 12:08:10 sogod [24233]: 0x0x2bd8010[NGLdapConnection] bind -
ldap_result call result: 97
Jul 25 12:08:10 sogod [24233]: 0x0x2bd8010[NGLdapConnection] bind -
ldap_parse_result - ctrls is NULL
Jul 25 12:08:10 sogod [24233]: SOGoRootPage Login for user 'j...@wohlford.org'
might not have worked - password policy: -1 grace: -1 expire: -1 bound: 1
166.248.70.150 - - [25/Jul/2011:12:08:10 GMT] POST /SOGo/connect HTTP/1.1
403 31/53 0.006 - - 0
An immediate second try using the exact same username and password, will then
let me in. As also can be seen in the logs:
Jul 25 12:08:51 sogod [24233]: SOGoRootPage successful login for user
'j...@wohlford.org' - expire = -1 grace = -1
166.248.70.150 - - [25/Jul/2011:12:08:51 GMT] POST /SOGo/connect HTTP/1.1
200 27/53 0.049 - - 4K
166.248.70.150 - - [25/Jul/2011:12:08:51 GMT] GET /SOGo/so/; @wohlford.org
HTTP/1.1 302 0/0 0.003 - - 0
166.248.70.150 - - [25/Jul/2011:12:08:51 GMT] GET /SOGo/so/;
@wohlford.org/view HTTP/1.1 302 0/0 0.004 - - 0
2011-07-25 12:08:51.753 sogod[24233] 0x0x256c0e0[PostgreSQL72Channel]:
connection=0x0x258ee20[PGConnection]: connection=0x0x26f1560: message:
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
sogojbwohlfo00141b94556_pkey for table sogojbwohlfo00141b94556
I'm guessing there is some issue between SOGo and ldap on my server. It's as if
SOGo does an ldap query, but doesn't actually wait for the ldap response. Once
the second login attempt comes, the ldap query is cached with SOGo and then
authentication is sucessful. This error occurs again if the user hasn't logged
in for a time. How much time I have been unable to determine.
On what I believe is a related note, Mac OS X iCal (10.6 10.7) will fail
authentication on CalDAV periodically. It will behave fine, but after a time
iCal with complain about an invalid password. The password is valid and was
valid before, but all of the sudden it isn't. I believe this is related because
if SOGo does cache ldap queries, then once the cache expires it would produce a
similar issue in the iCal as in the web interface. However, I could be
completely wrong on this.
localhost - - [25/Jul/2011:11:43:32 GMT] PROPFIND
/SOGo/dav/j...@wohlford.org/Calendar/ HTTP/1.1 401 0/1868 0.008 - - 0
Jul 25 11:43:33 sogod [12444]: 0x0x106f660[NGLdapConnection] bind -
ldap_result call result: 97
Jul 25 11:43:33 sogod [12444]: 0x0x106f660[NGLdapConnection] bind -
ldap_parse_result - ctrls is NULL
Jul 25 11:43:33 sogod [12444]: 0x0x9ae850[SOGoDAVAuthenticator] tried wrong
password for user 'j...@wohlford.org'!
localhost - - [25/Jul/2011:11:43:33 GMT] PROPFIND
/SOGo/dav/j...@wohlford.org/Calendar/ HTTP/1.1 401 12/1868 0.004 - - 0
Also, does anyone know what this 'bind - ldap_parse_result - ctrls is NULL'
message is all about? It looks disconcerting. It could also be related.
Any help is greatly appreciated.
Best Regards,
Jason
SOGoUserSources:
(
{ type = ldap;
id = directory;
CNFieldName = cn;
IDFieldName = uid;
UIDFieldName = mail;
bindFields = ( mail );
IMAPLoginFieldName = mail;
bindAsCurrentUser = YES;
hostname = localhost;
port = 389;
canAuthenticate = YES;
passwordPolicy = YES;
isAddressBook = NO;
}
)
--
Jason Wohlford
ja...@wohlfordcompany.com
http://www.wohlfordcompany.com/
334.322.1491
smime.p7s
Description: S/MIME cryptographic signature
[SOGo] LDAP issue
I'm new to SoGo and to using ldap as well so any help would be greatly appreciated. I have a working SoGo server and allowing password changes with it as well. Running Centos 5.6 with the updated versions of everything. Dovecot,ldap,mysql,etc. The problem Im having is that when a user changes there password via the SoGo web interface it stores as plaintext which in turns makes all of there mail not readable. Users are able to login however the cannot get to there mailbox. What am I missing. Bo Lynch -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] LDAP issue
Bo- I believe that you have to use a more recent version of openldap that supports this feature (2.4+). Your directory also has to then have the appropriate attributes from the Password Policy schema. I don't think that CentOS 5.6 provides these. You might want to have a look at CentOS 6 to see if they have updated openldap and start there. Steve On Mon, Jul 25, 2011 at 1:24 PM, Bo Lynch bly...@ameliaschools.com wrote: I'm new to SoGo and to using ldap as well so any help would be greatly appreciated. I have a working SoGo server and allowing password changes with it as well. Running Centos 5.6 with the updated versions of everything. Dovecot,ldap,mysql,etc. The problem Im having is that when a user changes there password via the SoGo web interface it stores as plaintext which in turns makes all of there mail not readable. Users are able to login however the cannot get to there mailbox. What am I missing. Bo Lynch -- users@sogo.nu https://inverse.ca/sogo/lists -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo 1.3.8a: loggin problems with multi domains
On 07/25/11 11:56, Francis Lachapelle wrote: Hi Dominique On 2011-07-23, at 12:55 PM, Dominique BERTHET wrote: Upgrading to the 1.3.8a resolves all my ACL problems for shared calendars and contacts but now i have a new problem. I'm obliged to connect 2 times to the web interface. The fist time I try to log, i just come back to the login page and i have this message in the sogo.log: localhost - - [23/Jul/2011:18:07:04 GMT] POST /SOGo/connect HTTP/1.1 200 27/47 0.088 - - 664K Jul 23 18:07:04 sogod [1096]:0x0x161aef0[SOGoWebAuthenticator] tried wrong password for user 'EAzDUDpXhKdFxxZulPFTbVmpjlSwDjt2LiqFOdv0MSxcUaxl8IQ1BRpREBpXXvxpUr8LWXizJ7b/M9MLkqajuw=='! The second time i log with any problem in the domain and everything is working Fixed in revision fb2d19f2d09037cb11414b10bc8c3bb8beb37bd9. Next nighly packages will include the fix. Does this problem affect systems using CAS authentication? (I ask because our (multi-domain) system does use CAS, and I don't want to upgrade to 1.3.8a if it's just going to break immediately.) -mm I have also notice that when i try to use sogo-tool, i have the following message: ERROR(+[GCSFolderManager defaultFolderManager]): default 'OCSFolderInfoURL' is not configured. but OCSFolderInfoURL id defined in my configuration... Run sogo-tool as your sogo user. Francis -- flachape...@inverse.ca :: +1.514.755.3640 :: http://www.inverse.ca Inverse :: Leaders behind SOGo (http://sogo.nu) and PacketFence (http://packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] BTS activities for Monday, July 25 2011
Title: BTS activities for Monday, July 25 2011 BTS Activities Home page: http://www.sogo.nu/bugs Project: SOGo For the period covering: Monday, July 25 2011 idlast updatestatus (resolution)categorysummary 1395 2011-07-25 11:57:47 updated (open) Backend Mail Enabling threaded view crashes SOGo
