View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001100SOGoBackend Generalpublic2011-01-27 06:292011-01-27 18:21
Reporterjthibeault Assigned Tofrancis  
PrioritynormalSeveritycrashReproducibilityalways
Status resolvedResolutionfixed 
Fixed in Version1.3.5a 
Summary0001100: [1.3.5] "Unhandled error occurred" on login after upgrade
Description

Prior to upgrading to 1.3.5 on Ubuntu 10.04 using the http://inverse.ca/ubuntu lucid repository, my SOGo installation (1.3.4) was functioning perfectly. After performing a dist-upgrade, SOGo is completely inaccessible. Attempting to log in gives "Unhandled error occurred".

I've added OCSSessionsFolderURL to .GNUstepDefaults, and the new table is
created with the following structure:

mysql> describe sogo_sessions_folder
-> ;
+----------------+--------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+----------------+--------------+------+-----+---------+-------+
| c_id | varchar(255) | NO | | NULL | |
| c_value | varchar(255) | NO | | NULL | |
| c_creationdate | int(11) | NO | | NULL | |
| c_lastseen | int(11) | NO | | NULL | |
+----------------+--------------+------+-----+---------+-------+

The table is not populated.

I have restarted memcached, sogo, and have even rebooted the server in question. Logs in Additional Information.

Thanks for your assistance! Hope to get this working soon.

Additional Information

The packages I have installed for sope and sogo:

admin@host:~$
dpkg -l | grep sope
ii libsope-appserver4.9 4.9.r1664.20110126
SOPE application server libraries
ii libsope-appserver4.9-dev 4.9.r1664.20110126
Development files for the SOPE libraries
ii libsope-core4.9 4.9.r1664.20110126
Core libraries of the SOPE application serve
ii libsope-core4.9-dev 4.9.r1664.20110126
Development files for the SOPE core librarie
ii libsope-gdl1-4.9 4.9.r1664.20110126
GNUstep database libraries for SOPE
ii libsope-gdl1-4.9-dev 4.9.r1664.20110126
Development files for the GNUstep database l
ii libsope-ldap4.9 4.9.r1664.20110126
SOPE libraries for LDAP access
ii libsope-ldap4.9-dev 4.9.r1664.20110126
Development files for the SOPE LDAP librarie
ii libsope-mime4.9 4.9.r1664.20110126
SOPE libraries for MIME processing
ii libsope-mime4.9-dev 4.9.r1664.20110126
Development files for the SOPE MIME librarie
ii libsope-xml4.9 4.9.r1664.20110126
SOPE libraries for XML processing
ii libsope-xml4.9-dev 4.9.r1664.20110126
Development files for the SOPE XML libraries
ii libsope4.9-dev 4.9.r1664.20110126
Development files for all SOPE libraries
ii sope4.9-appserver 4.9.r1664.20110126
SOPE application server
ii sope4.9-dbg 4.9.r1664.20110126
Debugging files
ii sope4.9-gdl1-mysql 4.9.r1664.20110126
MySQL connector for SOPE's fork of the GNUst
ii sope4.9-gdl1-postgresql 4.9.r1664.20110126
PostgreSQL connector for SOPE's fork of the
ii sope4.9-libxmlsaxdriver 4.9.r1664.20110126
XML Parser for SOPE's SAX engine
ii sope4.9-stxsaxdriver 4.9.r1664.20110126
Structured Text Parser for SOPE's SAX engine

admin@host:~$
dpkg -l | grep sogo
ii sogo 1.3.5
a modern and scalable groupware

I'm probably overkill on sope, having done "apt-get
install sope*" to make sure all packages were upgraded.

My log file when attempting to log in via LDAP to an ActiveDirectory user
source (I tried a few times):

2011-01-27 01:18:43.584 sogod[7578] WOCompoundElement: pool embedding is on.
2011-01-27 01:18:43.584 sogod[7578] WOCompoundElement: id logging is on.
Jan 27 01:18:43 sogod [7596]: <0x0x8e8a240[SOGoProductLoader]> SOGo products
loaded from '/usr/lib/GNUstep/SOGo':
Jan 27 01:18:43 sogod [7596]: <0x0x8e8a240[SOGoProductLoader]> Mailer.SOGo,
PreferencesUI.SOGo, AdministrationUI.SOGo, Appointments.SOGo, MainUI.SOGo,
Contacts.SOGo, CommonUI.SOGo, MailPartViewers.SOGo, MailerUI.SOGo,
ContactsUI.SOGo, SchedulerUI.SOGo
Jan 27 01:18:43 sogod [7596]: |SOGo| version 1.3.5 (build @vizzini.inverse.ca
201101261802) -- starting
Jan 27 01:18:43 sogod [7596]: |SOGo| vmem size check enabled: shutting down
app
when vmem > 384 MB
EXCEPTION: <NSException: 0x8c55d20> NAME:NSInvalidArgumentException
REASON:Tried to add nil value for key 'jason.thibeault' to dictionary INFO:{}
Jan 27 01:18:43 sogod [7575]: <0x0x8d3d6e8[WOWatchDogChild]> child 7578 exited
Jan 27 01:18:43 sogod [7575]: <0x0x8d3d6e8[WOWatchDogChild]> (terminated due
to signal 6)
Jan 27 01:18:43 sogod [7575]: <0x0x8d21340[WOWatchDog]> child spawned with pid
7597
Jan 27 01:18:43 sogod [7596]: <0x0x8e7cf08[SOGoCache]> Cache cleanup interval
set every 300.000000 seconds
Jan 27 01:18:43 sogod [7596]: <0x0x8e7cf08[SOGoCache]> Using host(s)
'localhost' as server(s)
2011-01-27 01:18:43.731 sogod[7596] Note(SoObject): SoDebugKeyLookup is
enabled!
2011-01-27 01:18:43.731 sogod[7596] Note(SoObject): SoDebugBaseURL is enabled!
2011-01-27 01:18:43.731 sogod[7596] Note(SoObject): relative base URLs are
enabled.
2011-01-27 01:18:43.738 sogod[7596] ERROR(-[NGBundleManager bundleWithPath:]):
could not create bundle for path:
'/usr/share/GNUstep/Libraries/gnustep-base/Versions/1.19/Resources/SSL.bundle'
2011-01-27 01:18:43.758 sogod[7596] WOCompoundElement: pool embedding is on.
2011-01-27 01:18:43.759 sogod[7596] WOCompoundElement: id logging is on.
Jan 27 01:18:43 sogod [7597]: <0x0x8e8a270[SOGoProductLoader]> SOGo products
loaded from '/usr/lib/GNUstep/SOGo':
Jan 27 01:18:43 sogod [7597]: <0x0x8e8a270[SOGoProductLoader]> Mailer.SOGo,
PreferencesUI.SOGo, AdministrationUI.SOGo, Appointments.SOGo, MainUI.SOGo,
Contacts.SOGo, CommonUI.SOGo, MailPartViewers.SOGo, MailerUI.SOGo,
ContactsUI.SOGo, SchedulerUI.SOGo
Jan 27 01:18:43 sogod [7597]: |SOGo| version 1.3.5 (build @vizzini.inverse.ca
201101261802) -- starting
Jan 27 01:18:43 sogod [7597]: |SOGo| vmem size check enabled: shutting down
app
when vmem > 384 MB
EXCEPTION: <NSException: 0x8c4ad50> NAME:NSInvalidArgumentException
REASON:Tried to add nil value for key 'jason.thibeault' to dictionary INFO:{}
Jan 27 01:18:43 sogod [7575]: <0x0x8d3d5f8[WOWatchDogChild]> child 7596 exited
Jan 27 01:18:43 sogod [7575]: <0x0x8d3d5f8[WOWatchDogChild]> (terminated due
to signal 6)
Jan 27 01:18:43 sogod [7575]: <0x0x8d3d5f8[WOWatchDogChild]> avoiding to
respawn child before 2011-01-27 01:18:48 -0400
Jan 27 01:18:43 sogod [7597]: <0x0x8c36f68[SOGoCache]> Cache cleanup interval
set every 300.000000 seconds
Jan 27 01:18:43 sogod [7597]: <0x0x8c36f68[SOGoCache]> Using host(s)
'localhost' as server(s)
2011-01-27 01:18:43.922 sogod[7597] Note(SoObject): SoDebugKeyLookup is
enabled!
2011-01-27 01:18:43.922 sogod[7597] Note(SoObject): SoDebugBaseURL is enabled!
2011-01-27 01:18:43.922 sogod[7597] Note(SoObject): relative base URLs are
enabled.
2011-01-27 01:18:43.929 sogod[7597] ERROR(-[NGBundleManager bundleWithPath:]):
could not create bundle for path:
'/usr/share/GNUstep/Libraries/gnustep-base/Versions/1.19/Resources/SSL.bundle'
2011-01-27 01:18:43.948 sogod[7597] WOCompoundElement: pool embedding is on.
2011-01-27 01:18:43.948 sogod[7597] WOCompoundElement: id logging is on.
EXCEPTION: <NSException: 0x8c5f198> NAME:NSInvalidArgumentException
REASON:Tried to add nil value for key 'jason.thibeault' to dictionary INFO:{}

TagsNo tags attached.

Activities

jthibeault

jthibeault

2011-01-27 13:54

reporter   ~0002058

It appears that when I delete the two authentication sources I have configured, which point to two different Apple LDAP servers, the issue disappears, but my users on those auth sources can no longer log in (obviously). I've tried adding SearchFieldNames per the changelog in case that was necessary, but it didn't help. Only removing those auth sources allows me to log in.

From .GNUstepDefaults:

        &lt;dict>
            &lt;key>CNFieldName&lt;/key>
            &lt;string>cn&lt;/string>
            &lt;key>IDFieldName&lt;/key>
            &lt;string>cn&lt;/string>
            &lt;key>UIDFieldName&lt;/key>
            &lt;string>uid&lt;/string>
            &lt;key>baseDN&lt;/key>
            &lt;string>cn=users,dc=xxxxxx,dc=local&lt;/string>
            &lt;key>bindDN&lt;/key>
            &lt;string>uid=ldapbinduser,cn=users,dc=xxxxxx,dc=local&lt;/string>
            &lt;key>bindFields&lt;/key>
            &lt;array>
                &lt;string>uid&lt;/string>
            &lt;/array>
            &lt;key>MailFieldNames&lt;/key>
            &lt;array>
                &lt;string>mail&lt;/string>
            &lt;/array>
            &lt;key>SearchFieldNames&lt;/key>
            &lt;array>
                &lt;string>mail&lt;/string>
                &lt;string>cn&lt;/string>
                &lt;string>uid&lt;/string>
            &lt;/array>
            &lt;key>bindPassword&lt;/key>
            &lt;string>xxxxxxxxx&lt;/string>
            &lt;key>canAuthenticate&lt;/key>
            &lt;string>YES&lt;/string>
            &lt;key>displayName&lt;/key>
            &lt;string>xxxxxx Apple LDAP&lt;/string>
            &lt;key>hostname&lt;/key>
            &lt;string>xxx.xx.xxx.xx&lt;/string>
            &lt;key>id&lt;/key>
            &lt;string>auth_xxxldap&lt;/string>
            &lt;key>isAddressBook&lt;/key>
            &lt;string>YES&lt;/string>
            &lt;key>port&lt;/key>
            &lt;string>389&lt;/string>
            &lt;key>type&lt;/key>
            &lt;string>ldap&lt;/string>
        &lt;/dict>
        &lt;dict>
            &lt;key>CNFieldName&lt;/key>
            &lt;string>cn&lt;/string>
            &lt;key>IDFieldName&lt;/key>
            &lt;string>cn&lt;/string>
            &lt;key>UIDFieldName&lt;/key>
            &lt;string>uid&lt;/string>
            &lt;key>baseDN&lt;/key>
            &lt;string>cn=users,dc=yyyyyy,dc=local&lt;/string>
            &lt;key>bindDN&lt;/key>
            &lt;string>uid=ldapbinduser,cn=users,dc=yyyyyy,dc=local&lt;/string>
            &lt;key>bindFields&lt;/key>
            &lt;array>
                &lt;string>uid&lt;/string>
            &lt;/array>
            &lt;key>MailFieldNames&lt;/key>
            &lt;array>
                &lt;string>mail&lt;/string>
            &lt;/array>
            &lt;key>SearchFieldNames&lt;/key>
            &lt;array>
                &lt;string>mail&lt;/string>
                &lt;string>cn&lt;/string>
            &lt;/array>
            &lt;key>bindPassword&lt;/key>
            &lt;string>xxxxxxxxxx&lt;/string>
            &lt;key>canAuthenticate&lt;/key>
            &lt;string>YES&lt;/string>
            &lt;key>displayName&lt;/key>
            &lt;string>yyyyyyyy Apple LDAP&lt;/string>
            &lt;key>hostname&lt;/key>
            &lt;string>xx.xx.xx.xx&lt;/string>
            &lt;key>id&lt;/key>
            &lt;string>auth_yyyldap&lt;/string>
            &lt;key>isAddressBook&lt;/key>
            &lt;string>YES&lt;/string>
            &lt;key>port&lt;/key>
            &lt;string>389&lt;/string>
            &lt;key>type&lt;/key>
            &lt;string>ldap&lt;/string>
        &lt;/dict>

Am I missing anything that's necessary in this new version?
jthibeault

jthibeault

2011-01-27 13:59

reporter   ~0002059

For the record, I have four authentication sources -- I know, I know. Less than ideal management-wise too, but it's necessary until I can move people off the Apple LDAPs. When I say "I can now log in successfully after removing those two sources", I mean my logins on the ActiveDirectory domain or MySQL database both work. I've also disabled my MySQL login for testing purposes, though it's probably not entirely necessary right now. Adding the auth source for the Apple LDAP, either one, is all it takes to break my server.
francis

francis

2011-01-27 17:54

administrator   ~0002061

Fixed with revision 67ceb1cbca26597fa55e31fb97e198f72e72f1df.

Issue History

Date Modified Username Field Change
2011-01-27 06:29 jthibeault New Issue
2011-01-27 13:54 jthibeault Note Added: 0002058
2011-01-27 13:59 jthibeault Note Added: 0002059
2011-01-27 17:54 francis Note Added: 0002061
2011-01-27 17:54 francis Status new => resolved
2011-01-27 17:54 francis Resolution open => fixed
2011-01-27 17:54 francis Assigned To => francis
2011-01-27 18:21 francis Fixed in Version => 1.3.5a