Not a calendar resource?
Hello, I am experimenting with calendarserver 2.4 on Debian stable. After failures to connect from both, Sunbird and CalDAV-Sync for Android, I started investigating what was going on. The CalDAV-Sync author noted, that the response for /calendars/__uids__/d817aaec-7d24-5b38-bc2f-6369da72cdd9/calendar/ does not include something like <calendar xmlns='urn:ietf:params:xml:ns:caldav'/> and is thus not a valid calendar resource. Here is the URI: http://77.109.139.85:8008/calendars/users/test/calendar/ or http://77.109.139.85:8008/calendars/__uids__/d817aaec-7d24-5b38-bc2f-6369da7... User/password: test/test I notice the four .ics files in there as having been created by Sunbird, but Sunbird cannot display them, and CalDAV-Sync cannot set up this resource. Sunbird's error console also says that this is not a CalDAV resource. If I use the credentials admin/admin and the appropriate URIs, then it all seems to work. Did I mess something up? I cannot be expected to make all users admins, can I? How is admin access determined anyway? The accounts.xml entries look identical, so is this in sudoers.plist? <dict> <key>username</key> <string>superuser</string> <key>password</key> <string>superuser</string> </dict> How does this work? Or is the name 'admin' hardcoded? Thanks, -- martin | http://madduck.net/ | http://two.sentenc.es/ a friend is someone with whom you can dare to be yourself spamtraps: madduck.bogus@madduck.net
On Jan 19, 2012, at 7:59 AM, martin f krafft wrote:
Hello,
I am experimenting with calendarserver 2.4 on Debian stable.
After failures to connect from both, Sunbird and CalDAV-Sync for Android, I started investigating what was going on. The CalDAV-Sync author noted, that the response for /calendars/__uids__/d817aaec-7d24-5b38-bc2f-6369da72cdd9/calendar/ does not include something like
<calendar xmlns='urn:ietf:params:xml:ns:caldav'/>
and is thus not a valid calendar resource.
Here is the URI:
http://77.109.139.85:8008/calendars/users/test/calendar/ or http://77.109.139.85:8008/calendars/__uids__/d817aaec-7d24-5b38-bc2f-6369da7...
User/password: test/test
These URLs are simply 404s for me. How are you authenticating? My understanding is that the Sunbird project is dead, though. Have you tried Thunderbird with Lightning instead? (I don't know anything about CalDAV-Sync. I've set that up somewhat successfully.
Or is the name 'admin' hardcoded?
This one I can answer at least :). No, 'admin' isn't hard-coded. Look in the configuration file (caldavd.plist) for the AdminPrincipals section. -glyph
also sprach Glyph <glyph@twistedmatrix.com> [2012.01.19.1934 +0100]:
http://77.109.139.85:8008/calendars/users/test/calendar/ or http://77.109.139.85:8008/calendars/__uids__/d817aaec-7d24-5b38-bc2f-6369da7...
User/password: test/test
These URLs are simply 404s for me. How are you authenticating?
Works for me, I have meanwhile set up a forward to SSL and changed digest to basic auth due to repeated nonce problems, but they work…
My understanding is that the Sunbird project is dead, though. Have you tried Thunderbird with Lightning instead?
Have not, since it won't install on Debian's Icedove and I cannot be bothered to look further right now.
Or is the name 'admin' hardcoded?
This one I can answer at least :). No, 'admin' isn't hard-coded. Look in the configuration file (caldavd.plist) for the AdminPrincipals section.
Oh, okay, thought so. So admin is actually not an admin by default. Now I wonder why it works and 'test' does not. Do calendars have to be created or do they just exist for each user? -- martin | http://madduck.net/ | http://two.sentenc.es/ "by accepting this brick through your window, you accept it as is and agree to my disclaimer of all warranties, express or implied, as well as disclaimers of all liability, direct, indirect, consequential or incidental, that may arise from the installation of this brick into your building." -- seen on irc spamtraps: madduck.bogus@madduck.net
On Jan 19, 2012, at 12:51 PM, martin f krafft wrote:
Oh, okay, thought so. So admin is actually not an admin by default. Now I wonder why it works and 'test' does not. Do calendars have to be created or do they just exist for each user?
No calendars exist by default. A default calendar is provisioned for a user when they log in. -dre
also sprach Andre LaBranche <dre@apple.com> [2012.01.19.2203 +0100]:
Oh, okay, thought so. So admin is actually not an admin by default. Now I wonder why it works and 'test' does not. Do calendars have to be created or do they just exist for each user?
No calendars exist by default. A default calendar is provisioned for a user when they log in.
Right, so I don't need to do anything. And to a remove a calendar, I simply remove the directory of the associated UUID in the data directory? -- martin | http://madduck.net/ | http://two.sentenc.es/ "a human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. specialization is for insects." -- robert heinlein spamtraps: madduck.bogus@madduck.net
On Jan 19, 2012, at 1:08 PM, martin f krafft wrote:
also sprach Andre LaBranche <dre@apple.com> [2012.01.19.2203 +0100]:
Oh, okay, thought so. So admin is actually not an admin by default. Now I wonder why it works and 'test' does not. Do calendars have to be created or do they just exist for each user?
No calendars exist by default. A default calendar is provisioned for a user when they log in.
Right, so I don't need to do anything.
And to a remove a calendar, I simply remove the directory of the associated UUID in the data directory?
The proper way to mutate *any* calendar data is always to use CalDAV, and never to operate on the back-end data directly. Any reasonable CalDAV client should be able to delete a calendar collection. If not, you could use an admin tool such as CalDAVClientLibrary to perform the delete. Operating on the back-end data directly usually means your changes are invisible to clients, and may cause errors. Using CalDAV allows the appropriate change notifications to bubble up, so things work as expected. -dre
-- martin | http://madduck.net/ | http://two.sentenc.es/
"a human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. specialization is for insects." -- robert heinlein
spamtraps: madduck.bogus@madduck.net _______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
participants (3)
-
Andre LaBranche
-
Glyph
-
martin f krafft