Hi,
i have to confess, that the imap pooling isn't the problem.
After having (imap pooling disabled) the "object not found" failure
again, i checked the sogo config for ldap auth, which Ludovic and other
recommended.
For testing purpose do a ldapsearch with the exact (copy & paste)
paramteres from the sogo-config.
For me the problem seems a additional ldap-filter that was wrongly
interpreted by a update-script or else:
businessCategory= "pro" to "'pro'"
Testing with ldapsearch gives no result with the old filter.
(CentOS5)
ldapsearch -x -D "uid=UID,BASEDN from sogo-config" -b "BASEDN from
sogo-config" -w - "(&(objectClass=*)(businessCategory='pro'))"
Now it does.
ldapsearch -x -D "uid=UID,BASEDN from sogo-config" -b "BASEDN from
sogo-config" -w - "(&(objectClass=*)(businessCategory=pro))"
Or do you have aonther solution found for this ?
Also check the bindAsCurrentUser and canAuthenticate Parameter (look
also at the lists for [SOGo] "object not found" after login)
Best regards to Potsdam from Stuttgart ;-)
Philipp
Philipp v. Strobl.-Albeg
- PILAKRTO.NET -
Am 24.01.2013 17:11, schrieb Ronald J. Yacketta:
Donny,
Thanks for the reply!
Wish this was the case, but we have been running SOGo in production for 2+
weeks without any configuration changes. Everything has been fine until this
week when SOGo usage increased due to students and faculty returning from break.
A restored of SOGo and memcached seems to have resolved the issue for the time
being, a bit worried that this issue will creep up over the next few days of
usage.
-Ron
On Thursday, 24 January, 2013 11:06 EST, "Donny
Brooks"<dbro...@mdah.state.ms.us> wrote:
On 01/24/2013 07:57 AM, Ronald J. Yacketta wrote:
We have been running SOGo in production mode for 2 without any configuration
changes to SOGo, Mail or LDAP. This week have been receiving reports of user
getting error 'object not found: SOGo => username' when accessing the
calendar tab.
Log shows the following:
Jan 24 08:46:55 sogod [9353]: SOGoRootPage successful login for user 'UID' -
expire = -1 grace = -1
137.143.160.6 - - [24/Jan/2013:08:46:55 GMT] "POST /SOGo/connect HTTP/1.1" 200
27/43 0.076 - - 688K
2013-01-24 08:46:55.636 sogod[9310] ERROR(-[NSNull(misc) forwardInvocation:]):
called selector objectForKey: on NSNull !
2013-01-24 08:46:55.662 sogod[9310] ERROR(-[NSNull(misc) forwardInvocation:]):
called selector setObject:forKey: on NSNull !
2013-01-24 08:46:55.662 sogod[9310] didn't set return value for type 'v'
137.143.160.6 - - [24/Jan/2013:08:46:55 GMT] "GET /SOGo/UIDHTTP/1.1" 404 36/0
0.028 - - 1M
Searching list archives returns results indicating that the user does not
exist, but in this case the user is one of the first to use SOGo in production
and has been doing all of our campus training.
I had a similar issue yesterday but it was on our new machine. Ludovic
sent this in reply to my message:
That means your SOGoUserSources is wrong. Correctly set IDFieldName and
UIDFieldName.
--
Ludovic Marcotte
+1.514.755.3630 ::www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
--
users@sogo.nu
https://inverse.ca/sogo/lists
--
users@sogo.nu
https://inverse.ca/sogo/lists
