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
<Directory /usr/lib/GNUstep/SOGo/>
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.
<IfModule expires_module>
ExpiresActive On
ExpiresDefault "access plus 1 year"
</IfModule>
</Directory>
<LocationMatch
"^/SOGo/so/ControlPanel/Products/.*UI/Resources/.*\.(jpg|png|gif|css|js)">
SetHandler default-handler
</LocationMatch>
## 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.
#<Location /SOGo>
# AuthType XXX
# Require valid-user
# SetEnv proxy-nokeepalive 1
# Allow from all
#</Location>
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
# <Proxy http://localhost/app/cas-proxy-validate.py>
# Order deny,allow
# Allow from your-cas-host-addr
# </Proxy>
ProxyPass /SOGo http://127.0.0.1:20000/SOGo retry=0
<Proxy http://127.0.0.1:20000/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
</Proxy>
# 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
<VirtualHost 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:20000/SOGo/dav/ interpolate
ProxyPass /SOGo/dav/ http://127.0.0.1:20000/SOGo/dav/ interpolate
ProxyPass / http://127.0.0.1:20000/SOGo/dav/ interpolate
<Proxy http://127.0.0.1:20000>
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
</Proxy>
</VirtualHost>
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=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 <christian.m...@uni-konstanz.de>
> 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 <r...@tohuw.net
>>> <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
