Mailing List Archive: DAViCal: General

iCal account duplication problem

Index | Next | Previous | View Threaded

benjamin.hagemann at servicereisen

Oct 16, 2012, 5:53 AM

Post #1 of 5 (309 views)
Permalink

iCal account duplication problem

Hello,

we have a little problem with auch davical setup. Every day some of our
colleagues have auto misconfigured iCals.

Your setup:
DaviCal 1.0.1 on one virtual machine with other web instances as fcgi on Ubuntu
12.04.
postgresql 8.4 on one virtual machine with other databases (wikis...) on Ubuntu
12.04.

Both runs on the same host system, Xeon E5649, 32 GB RAM, 10 GB Ethernet.

DaviCal: 356 princials, 948 collections, 83963 resources => 142 MB pg database

The clients are Mac OS X 10.7.5, iCal 5.0.3 and iPhones/iPads.

Every employee has his own calendar account and some company collection as
subscription.
Manager has rights for the calendar accounts of their team-members.
So they have e.g. 10 configured accounts with their own username, password, but
others url. For example

http://webcal/davical.php/user1
http://webcal/davical.php/team1
http://webcal/davical.php/user2
http://webcal/davical.php/user3
...
http://webcal/davical.php/company/events (subscription)
http://webcal/davical.php/compnay/cars (subscription)

Since some weeks/ few month every day some colleagues alert us, that their iCal
config changed:
Where the user2 and user3 path should be, iCal switched to the primary user1 path.

First we had fcgi in suspiction, but we have no errors there today.
So I checked the access logs and found some suspicious lines.
Before the colleageues iCals switched to wrong path these iCals starts a bulk of
requests in few seconds.

Have a look at some lines of our access.log file attached.

Have anybody similar problems?
Have anybody a hint to solve this problem?

Thank you.

--
Kind regards,

Benjamin Hagemann
Systemadministrator

Telefon: +49-(0)641-4006-159
Fax: +49-(0)641-4006-6-159
benjamin.hagemann [at] servicereisen
http://www.servicereisen.de

SERVICE-REISEN Heyne GmbH & Co. KG
Rödgener Str. 12, 35394 Giessen

eingetragen beim AG Giessen HRA 1333
persönlich haftende Gesellschafterin:
Heyne GmbH, eingetragen beim AG Giessen HRB 2163
Geschäftsführer: Kristiane Heyne-Strauch, Karl Heyne

Attachments:

user1-ical.log (3.94 KB)

jan.mate at inf-it

Oct 16, 2012, 6:11 AM

Post #2 of 5 (314 views)
Permalink

Re: iCal account duplication problem [In reply to]

As usually this is Apple bug,

it is fixed in iOS6 but still present in OS X 10.8 ... for iCal in OS X you can use "delegation" tab in account settings. It works OK.

JM

On Oct 16, 2012, at 2:53 PM, Benjamin Hagemann <benjamin.hagemann [at] servicereisen> wrote:

> Hello,
>
> we have a little problem with auch davical setup. Every day some of our
> colleagues have auto misconfigured iCals.
>
> Your setup:
> DaviCal 1.0.1 on one virtual machine with other web instances as fcgi on Ubuntu
> 12.04.
> postgresql 8.4 on one virtual machine with other databases (wikis...) on Ubuntu
> 12.04.
>
> Both runs on the same host system, Xeon E5649, 32 GB RAM, 10 GB Ethernet.
>
> DaviCal: 356 princials, 948 collections, 83963 resources => 142 MB pg database
>
> The clients are Mac OS X 10.7.5, iCal 5.0.3 and iPhones/iPads.
>
> Every employee has his own calendar account and some company collection as
> subscription.
> Manager has rights for the calendar accounts of their team-members.
> So they have e.g. 10 configured accounts with their own username, password, but
> others url. For example
>
> http://webcal/davical.php/user1
> http://webcal/davical.php/team1
> http://webcal/davical.php/user2
> http://webcal/davical.php/user3
> ...
> http://webcal/davical.php/company/events (subscription)
> http://webcal/davical.php/compnay/cars (subscription)
>
> Since some weeks/ few month every day some colleagues alert us, that their iCal
> config changed:
> Where the user2 and user3 path should be, iCal switched to the primary user1 path.
>
> First we had fcgi in suspiction, but we have no errors there today.
> So I checked the access logs and found some suspicious lines.
> Before the colleageues iCals switched to wrong path these iCals starts a bulk of
> requests in few seconds.
>
> Have a look at some lines of our access.log file attached.
>
> Have anybody similar problems?
> Have anybody a hint to solve this problem?
>
> Thank you.
>
> --
> Kind regards,
>
>
> Benjamin Hagemann
> Systemadministrator
>
> Telefon: +49-(0)641-4006-159
> Fax: +49-(0)641-4006-6-159
> benjamin.hagemann [at] servicereisen
> http://www.servicereisen.de
>
>
> SERVICE-REISEN Heyne GmbH & Co. KG
> Rödgener Str. 12, 35394 Giessen
>
> eingetragen beim AG Giessen HRA 1333
> persönlich haftende Gesellschafterin:
> Heyne GmbH, eingetragen beim AG Giessen HRB 2163
> Geschäftsführer: Kristiane Heyne-Strauch, Karl Heyne
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 401 418 "-" "CalendarStore/5.0.3 (1204.2); iCal/5.0.3 (1605.4); Mac OS X/10.7.5 (11G63)"
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user2/ HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user3/ HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user4/ HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/team1/ HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "GET /caldav.php/company/conference-rooms HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "GET /caldav.php/user9/home HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "GET /caldav.php/company/events-intern HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "GET /caldav.php/company/cars HTTP/1.1" 401 418
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 207 1891
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user2/ HTTP/1.1" 207 1852
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user4/ HTTP/1.1" 207 1852
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 207 1891
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/user3/ HTTP/1.1" 207 1850
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user5/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:14 +0200] "GET /caldav.php/user9/home HTTP/1.1" 200 75924
> [16/Oct/2012:11:04:13 +0200] "PROPFIND /caldav.php/team1/ HTTP/1.1" 207 2071
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/team2/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:14 +0200] "GET /caldav.php/company/events-intern HTTP/1.1" 200 139132
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 207 1891
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user6/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 207 1891
> [16/Oct/2012:11:04:13 +0200] "GET /caldav.php/company/events-extern HTTP/1.1" 401 418
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 207 1891
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 207 1891
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/user5/ HTTP/1.1" 207 1940
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user7/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/team3/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user8/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:14 +0200] "PROPFIND /caldav.php/team2/ HTTP/1.1" 207 1885
> [16/Oct/2012:11:04:14 +0200] "GET /caldav.php/company/events-intern HTTP/1.1" 200 360094
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 401 417
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user6/ HTTP/1.1" 207 1906
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 207 1891
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user8/ HTTP/1.1" 207 1853
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user7/ HTTP/1.1" 207 1853
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/team3/ HTTP/1.1" 207 1882
> [16/Oct/2012:11:04:15 +0200] "GET /caldav.php/company/events-extern HTTP/1.1" 200 172784
> [16/Oct/2012:11:04:15 +0200] "PROPFIND /caldav.php/user1/ HTTP/1.1" 207 1891
> [16/Oct/2012:11:04:13 +0200] "GET /caldav.php/company/converence-rooms HTTP/1.1" 200 709219
>
> 46 requests in 3 seconds:
>
> user1: 16x
> user 2-8: 2x
> subscription user9: 2x
> subscriptions conference-rooms, cars, events-extern: 2x
> subscription events-intern 3x
> team 1: 1x
> team 2-3: 2x
>
> every line ends with
> "-" "CalendarStore/5.0.3 (1204.2); iCal/5.0.3 (1605.4); Mac OS X/10.7.5 (11G63)"
> like line 1------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________
> Davical-general mailing list
> Davical-general [at] lists
> https://lists.sourceforge.net/lists/listinfo/davical-general

Attachments:

smime.p7s (4.71 KB)

benjamin.hagemann at servicereisen

Oct 17, 2012, 12:52 AM

Post #3 of 5 (305 views)
Permalink

Re: iCal account duplication problem [In reply to]

Hello Ján,

Ján Máté schrieb:

> As usually this is Apple bug,
>
> it is fixed in iOS6 but still present in OS X 10.8 ... for iCal in OS X you can use "delegation" tab in account settings. It works OK.

oh okay. All I found when I ask google about "ical account duplication" were
problems related to a second data source like iCloud or mobileme and so on.
Our clients use only davical accounts - no iCloud or somthing else.

Are there other reports in forums or in the apple support area about my problem?
Are there any information about, when Apple solves this problem?

Thank you.

--
Kind regards,

Benjamin Hagemann
Systemadministrator

Telefon: +49-(0)641-4006-159
Fax: +49-(0)641-4006-6-159
benjamin.hagemann [at] servicereisen
http://www.servicereisen.de

SERVICE-REISEN Heyne GmbH & Co. KG
Rödgener Str. 12, 35394 Giessen

eingetragen beim AG Giessen HRA 1333
persönlich haftende Gesellschafterin:
Heyne GmbH, eingetragen beim AG Giessen HRB 2163
Geschäftsführer: Kristiane Heyne-Strauch, Karl Heyne

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

benjamin.hagemann at servicereisen

Jul 16, 2013, 7:15 AM

Post #4 of 5 (69 views)
Permalink

Re: iCal account duplication problem [In reply to]

Hello Ján,
Hello all,

Am 17.10.2012 um 11:24 schrieb Ján Máté <jan.mate [at] inf-it>:

> On Oct 17, 2012, at 9:52 AM, Benjamin Hagemann <benjamin.hagemann [at] servicereisen> wrote:
>> Ján Máté schrieb:
>>
>>> As usually this is Apple bug,
>>>
>>> it is fixed in iOS6 but still present in OS X 10.8 ... for iCal in OS X you can use "delegation" tab in account settings. It works OK.
>>
>> oh okay. All I found when I ask google about "ical account duplication" were
>> problems related to a second data source like iCloud or mobileme and so on.
>> Our clients use only davical accounts - no iCloud or somthing else.
>
> this bug is not "account duplication", it is rather automatic (or mysterious?) principal URL change.
>
>> Are there other reports in forums or in the apple support area about my problem?
>
> for example: http://www.gossamer-threads.com/lists/davical/general/2231
>
>> Are there any information about, when Apple solves this problem?
>
> Apple is usually silent and never confirm any existing bugs (the only exception is iOS maps :-))).

Today we have round 60x users with 10.8.4 calendar and 70x with 10.7.5 iCal but your account duplication bug pops up at some users all few days.

Last time I set a 10.7 iCal in debug mode and your davical 1.0.1 in full debug mode and I could provocate this duplicate bug with toggling between ethernet and (parallel) wireless connection. But so I got more than 200 MB debug log ;)

For the first review I found a suspicious point:

iCal send some "PROPFIND /caldav.php/" (without user-part) and get the correct answer

response:--> <current-user-principal>
response:--> <href>/caldav.php/MYUSER/</href>
response:--> </current-user-principal>
response:--> <principal-collection-set>
response:--> <href>/caldav.php/</href>
response:--> </principal-collection-set>

So I ask me, could it be iCal ask our davical, which user / user path is the right one for this login-data and get MYUSER back -
and next iCal changed the correct paths of the other accounts to MYUSER and so we have your problem?
After the bug the second, third and fourth account toggled to my private account / path.

Background is some employee have not only their own/private calendar account, there are some more department and company calendar accounts.
In my test, I have 4 accounts (read/write, with my login data) and 4 subscriptions (read only, with my login data). Some user have 20+ accounts configured...

Any tips/ hints? :)

--
Kind regards,

Benjamin Hagemann
Profi für IT-Administration

Telefon-Durchwahl: +49-641-4006-159
E-Mail: benjamin.hagemann [at] servicereisen
www.servicereisen.de

SERVICE-REISEN HEYNE GmbH & Co. KG
Rödgener Straße 12; 35394 Giessen

eingetragen beim AG Giessen HRA 1333
persönlich haftende Gesellschafterin:
Heyne GmbH, eingetragen beim AG Giessen HRB 2163
Geschäftsführer: Kristiane Heyne-Strauch, Karl Heyne

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Davical-general mailing list
Davical-general [at] lists
https://lists.sourceforge.net/lists/listinfo/davical-general

jan.mate at inf-it

Jul 16, 2013, 7:43 AM

Post #5 of 5 (69 views)
Permalink

Re: iCal account duplication problem [In reply to]

Hi,

On Jul 16, 2013, at 4:15 PM, Benjamin Hagemann <benjamin.hagemann [at] servicereisen> wrote:

> Today we have round 60x users with 10.8.4 calendar and 70x with 10.7.5 iCal but your account duplication bug pops up at some users all few days.
>
> Last time I set a 10.7 iCal in debug mode and your davical 1.0.1 in full debug mode and I could provocate this duplicate bug with toggling between ethernet and (parallel) wireless connection. But so I got more than 200 MB debug log ;)
>
> For the first review I found a suspicious point:
>
> iCal send some "PROPFIND /caldav.php/" (without user-part) and get the correct answer
>
> response:--> <current-user-principal>
> response:--> <href>/caldav.php/MYUSER/</href>
> response:--> </current-user-principal>
> response:--> <principal-collection-set>
> response:--> <href>/caldav.php/</href>
> response:--> </principal-collection-set>
>
> So I ask me, could it be iCal ask our davical, which user / user path is the right one for this login-data and get MYUSER back -
> and next iCal changed the correct paths of the other accounts to MYUSER and so we have your problem?
> After the bug the second, third and fourth account toggled to my private account / path.

Yes I can confirm this ... it looks like Apple logic is something like:

1.) sync the calendar
2.) if sync is successful schedule 1.)
3.) if sync is unsuccessful for ANY reason then get the user home URL
4.) replace the principal URL with user home URL
5.) goto 1.)

I also noticed that after replacing my server (new server=32 cores instead of 2) this error occurs less frequently => so maybe simple timeout (server is too busy) can trigger the 3.)

The solution is:

1.) check the server error log (maybe there is some error which invokes 3.)
2.) report the bug to Apple (they simple CANNOT change the principal URL on basic errors ... this functionality is acceptable only if server responds with 404 = HTTP not found or 301 = HTTP moved permanently)

or:

setup only one account for each user and use the delegation functionality in iCal.app/Calendar.app settings

or:

use CalDavZAP :-)

JM

Attachments:

smime.p7s (4.71 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads