GNOME Bugzilla – Bug 750427
Preserve EWS autodiscovered hosts in GOA accounts
Last modified: 2015-06-10 08:45:12 UTC
This is a follow-up from gnome-online-accounts bug https://bugzilla.gnome.org/show_bug.cgi?id=750392 In our Exchange environment the EWS server is running at mail.foo.com (real name masked). When I try to add the account using gnome-control-center/gnome-online-accounts I have to use the servername 'foo.com' instead of 'mail.foo.com' to make the autodiscovery work correctly and allow the account to be configured correctly. When I start evolution after the account is added then evolution sees the new account (as expected) but it fails to connect to it. This appears due to evolution trying to connect to the server 'foo.com' instead of 'mail.foo.com'. The AutoDiscover response from the EWS server (the request for this was done by GOA internally) contains this data: <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"> <<snip>> <Account> <<snip>> <Protocol> <<snip>> <ASUrl>https://mail.foo.com/EWS/Exchange.asmx</ASUrl> <EwsUrl>https://mail.foo.com/EWS/Exchange.asmx</EwsUrl> <EcpUrl>https://owa.foo.com/ecp/</EcpUrl> <<snip>> </Protocol> </Account> </Response> </Autodiscover> The AutoDiscover server for this Exchange environment is running at autodiscover.foo.com I would expect evolution to also try to look up the exact server name based on a AutoDiscover request instead of using the exact same servername as configured in gnome-control-center/GOA.
(In reply to Erik van Pienbroek from comment #0) > I would expect evolution to also try to look up the exact server name based > on a AutoDiscover request instead of using the exact same servername as > configured in gnome-control-center/GOA. The org.gnome.OnlineAccounts.Exchange:Host property is something that should be used to do the autodiscovery. It is not the outcome of autodiscovery. See https://developer.gnome.org/goa/stable/gdbus-org.gnome.OnlineAccounts.Exchange.html#gdbus-property-org-gnome-OnlineAccounts-Exchange.Host
The evolution-data-server does the autodiscovery on the evolution-source-registry side, as can be seen here [1]. There will be hidden something more behind this. I tried with my server and the autodiscovery works fine here, even I do not have the special host name change. Could you run evolution-source-registry as follows and check its output for any clues, please? $ G_MESSAGES_DEBUG=module-gnome-online-accounts \ /usr/libexec/evolution-source-registry It will print debugging information from the autodiscovery, like what was sent and what was received, though not on which address/host. There are done two tries, as described at the above link at the comment #1. [1] https://git.gnome.org/browse/evolution-data-server/tree/modules/gnome-online-accounts/module-gnome-online-accounts.c#n312
Hi Milan, With the evolution-source-registry debug command I indeed see AutoDiscover requests being performed by evolution. The AutoDiscover responses all contain the correct server names (like mentioned in comment 0). When running evolution itself with EWS_DEBUG=2 and opening the mailbox in question I see the following failure showing up once a connect timeout occurs: < HTTP/1.1 7 Could not connect: Socket I/O timed out < Soup-Debug-Timestamp: 1433786155 < Soup-Debug: ESoapMessage 0 (0x41fef50) Netstat shows that evolution (and its related processes) are connecting to foo.com (1.2.3.4) instead of to mail.foo.com (different IP): $ netstat -anp | grep SYN (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 1 192.168.10.219:54738 1.2.3.4:443 SYN_SENT 5266/evolution tcp 0 1 192.168.10.219:54748 1.2.3.4:443 SYN_SENT 5412/evolution-addr tcp 0 1 192.168.10.219:54737 1.2.3.4:443 SYN_SENT 5154/evolution-sour Gdb shows this suspicious thread in evolution itself:
+ Trace 235133
(sorry, don't have debuginfo packages installed atm.., but hopefully the stack traces are usable enough)
Aah, I see it now, there was a code which intentionally changed the host of the autodiscovered URLs to those provided by the GOA itself, thus to the wrong in your case. I dropped that faulty code for the next versions. Created commit 119c48e in eds master (3.17.3+) Created commit bf888b0 in eds gnome-3-16 (3.16.4+)
Thanks for the patch. I just did some quick testing with it, but it doesn't seem to have resolved the issue for me. The gdb stacktraces looks the same as mentioned earlier and netstat still reports several connections hanging in SYN_SENT. Of course I did a 'evolution --force-shutdown' before restarting evolution again. I'll do more testing tomorrow and get back to this.
The trick is to re-add the account in GOA. evolution-source-registry doesn't overwrite those settings each start. I forgot to mention it above, I'm sorry.
I just tried to re-added the account in GOA and as expected your patch resolved the issue now. Thanks again!
Good. I guess it doesn't worth it to update the patch to always re-set the autodiscovered URLs, or do you think it does? Your setup is rare, but another use case might be that the autodiscover changes HostURL due to having exchange servers in a cluster or a similar setup, thus providing different servers "for each week", where it might make sense to update the settings.
I think that in practice it is reasonable safe to assume that the server names never change. IP adresses might get changed, but clients are expected to use DNS names to connect to Exchange servers (which the AutoDiscover request also returns) so that shouldn't cause any problems. I can't think of any situation where server names do change other than a switch to a complete new domain (foo.com -> bar.com) but in that case it likely would be recommended for users to reconfigure their clients anyway.