October 2009 - calendarserver-dev - lists.macosforge.org

[CalendarServer] #317: System install (run's -i option) ambiguities
by CalendarServer 09 Aug '10

09 Aug '10

#317: System install (run's -i option) ambiguities -----------------------------------+---------------------------------------- Reporter: AxelLuttgens@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Severity: Other Keywords: | -----------------------------------+---------------------------------------- I don't know how to classify this one. It may just prove to be strictly cosmetic, or contrary wise reveal some glitches in the logics of the run script; if the latter, this ticket could then be related to ticket #316. A system install seems to know about /System/Library and /Library. Those directories are typical of Mac OS X. But then, why does such an install put things into /usr/local/bin as well, instead of /usr/sbin or /usr/share for example? The installation location for caldavd.plist is rather surprising: /System/Library/Frameworks/Python.framework/Versions/2.5/caldavd: caldavd.plist... If a system install insists on putting things under /usr/local/bin, why does the default config (as of config.py) still consider that twistd's path is /usr/share/caldavd/bin/twistd? In the same vein, and this seems to be directly related to #316, a PATH is set to a non existing /System/Library/Frameworks/Python.framework/Versions/2.5/bin... As a result, the default layout yielded by run's -i option really appears as an hybrid install: many similarities with a home install and some reminiscences of what may be observed on Mac OS X Server. More generally, the rationale underlying the -i and -I options don't appear clearly. Unless some bug (typo) is at work. Unless I just don't understand those matters... TIA, Axel -- Ticket URL: <http://trac.calendarserver.org/ticket/317> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 3

[CalendarServer] #337: Hardcoded "WebDAV:" xattr prefix breaks Linux compatibility
by CalendarServer 14 Apr '10

14 Apr '10

#337: Hardcoded "WebDAV:" xattr prefix breaks Linux compatibility ----------------------------------------+----------------------------------- Reporter: christoph_apple@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 5: Not set | Milestone: Linux Port Component: Calendar Server | Severity: Other Keywords: | ----------------------------------------+----------------------------------- Linux requires a "user." prefix when setting extended attributes but CalendarServer uses a hardcoded "WebDAV:" prefix on various occasions. At least the following files seem to be affected: calendarserver/tools/fixcalendardata.py[[BR]] calendarserver/tools/doublequotefix.py[[BR]] contrib/tools/fix_calendar[[BR]] twistedcaldav/test/test_upgrade.py[[BR]] twistedcaldav/test/data/makelargefbset.py[[BR]] twistedcaldav/upgrade.py[[BR]] twistedcaldav/admin/util.py[[BR]] The attached patch fixes this problem for fix_calendar but has not been tested on non-Linux platforms. -- Ticket URL: <http://trac.calendarserver.org/ticket/337> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 2

[CalendarServer] #343: ./run on mac OS 10.5.7
by CalendarServer 15 Mar '10

15 Mar '10

#343: ./run on mac OS 10.5.7 -----------------------------+---------------------------------------------- Reporter: al@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Severity: Other Keywords: | -----------------------------+---------------------------------------------- Wonder if anyone can help. I've been following the instructions on building and running CalendarServer. Everything ran fine until the final ./run when it halted at the following line. 2009-07-14 16:15:56+0100 [-] os.chown(dbPath, uid, gid) 2009-07-14 16:15:56+0100 [-] OSError: [Errno 1] Operation not permitted: '/Library/CalendarServer/Data/mailgatewaytokens.sqlite' launchctl bsexec failed: No such file or directory Is this something I can fix? Thanks for any help! -- Ticket URL: <http://trac.calendarserver.org/ticket/343> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 4

[CalendarServer] #326: Compile error in PyOpenDirectory under Tiger - '::dsFillAuthBuffer'
by CalendarServer 25 Feb '10

25 Feb '10

#326: Compile error in PyOpenDirectory under Tiger - '::dsFillAuthBuffer' ---------------------------------------+------------------------------------ Reporter: softwarejanitor@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 1: Blocker | Milestone: Component: PyOpenDirectory | Severity: Serious Keywords: | ---------------------------------------+------------------------------------ Building PyOpenDirectory... src/CDirectoryServiceAuth.cpp:147: error: '::dsFillAuthBuffer' has not been declared src/CDirectoryServiceAuth.cpp: In member function 'bool CDirectoryServiceAuth::NativeAuthenticationDigestToNode(const char*, const char*, const char*, const char*, const char*)': src/CDirectoryServiceAuth.cpp:228: error: '::dsFillAuthBuffer' has not been declared I can't find dsFillAuthBuffer anywhere. I've installed Python2.5 from MacPorts. -- Ticket URL: <http://trac.calendarserver.org/ticket/326> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 7

[CalendarServer] #309: group and attendee bug
by CalendarServer 25 Feb '10

25 Feb '10

#309: group and attendee bug ------------------------------+--------------------------------------------- Reporter: jduffas1(a)free.fr | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 3: Important | Milestone: CalendarServer-2.x Component: Calendar Server | Severity: Serious Keywords: group attendee | ------------------------------+--------------------------------------------- if you create a group, then try to invite someone, from, or out of the group, (ATTENDEE), it freeze the group... (the well is turning all the time in ical.) to make it work back, all pepole of the group have to delete the faulty event. I use the xml configuration file. and the client is ical on OSX 10.5.5 -- Ticket URL: <http://trac.calendarserver.org/ticket/309> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 8

[CalendarServer] #305: Apache directory service types broken?
by CalendarServer 25 Feb '10

25 Feb '10

#305: Apache directory service types broken? ------------------------------------+--------------------------------------- Reporter: msantos(a)santosland.com | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: trunk Severity: Crash/data loss | Keywords: ------------------------------------+--------------------------------------- It appears that the Apache directory service types are broken. Code in udpateDirectoryService() in config.py seems to be trying to validate the directory service parameters from the config file against the known keywords, but there is no entry for them in serviceDefaultParams[], so the code takes a KeyError exception at this line: if param not in serviceDefaultParams[dsType]: because dsType is twistedcaldav.directory.apache.DigestDirectoryService, but the list in config.py only has entries for: twistedcaldav.directory.xmlfile.XMLDirectoryService twistedcaldav.directory.appleopendirectory.OpenDirectoryService Maybe that list is supposed to be updated somewhere else (from apache.py?), but I couldn't find any such place. -- Ticket URL: <http://trac.calendarserver.org/ticket/305> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 7

[CalendarServer] #285: Uses deprecated twisted interfaces
by CalendarServer 25 Feb '10

25 Feb '10

#285: Uses deprecated twisted interfaces -----------------------------+---------------------------------------------- Reporter: agx(a)sigxcpu.org | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Version: Severity: Other | Keywords: -----------------------------+---------------------------------------------- In Debian we splitted out things enough (so we don't have to ship our own twisted). We only ship the patched web2 plugin + twistedcaldav. With recent twisted we're seeing: /usr/lib/python2.5/site-packages/twisted/plugins/twisted_web2.py:22: DeprecationWarning: mktap and related support modules are deprecated as of Twisted 8.0. Use Twisted Application Plugins with the 'twistd' command directly, as described in 'Writing a Twisted Application Plugin for twistd' chapter of the Developer Guide. from twisted.scripts.mktap import _tapHelper This is 1.2 but the code in 1.3 looks pretty much the same. I assume you guys will want switch to newer twisted sooner or later. Any hints on how to fix this in a way that can go into your SVN. -- Ticket URL: <http://trac.calendarserver.org/ticket/285> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 10

[CalendarServer] #308: Minor doc nit: only one <Directory> source is legal at a time.
by CalendarServer 25 Feb '10

25 Feb '10

#308: Minor doc nit: only one <Directory> source is legal at a time. -----------------------------+---------------------------------------------- Reporter: ggm(a)apnic.net | Owner: wsanchez(a)apple.com Type: Defect | Status: new Priority: 5: Not set | Milestone: Component: Calendar Server | Severity: Other Keywords: | -----------------------------+---------------------------------------------- Please can you clarify in the documentation that only one form of Directory can be live at a time. Open/Apple Directory also allows multiple back-end information bindings which needs to be clarified. Can you also explain if with htpasswd/group form, you can perform all calendar operations, and how the __uuid__ value mappings for another directory source are handled, if you change directory (risk of information lossage) -- Ticket URL: <http://trac.calendarserver.org/ticket/308> CalendarServer </> HTTP/WebDAV/CalDAV Server

2 2

[CalendarServer] #348: Sunbird fails to populate calendars
by CalendarServer 04 Dec '09

04 Dec '09

#348: Sunbird fails to populate calendars ---------------------------------+------------------------------------------ Reporter: naoh123@… | Owner: cdaboo@… Type: Defect | Status: new Priority: 1: Blocker | Milestone: Component: CalDAV Client | Severity: Serious Keywords: sunbird | ---------------------------------+------------------------------------------ First off, excellent project. It's been exciting following along the past year. I have been running the server on an Ubuntu 8.04 server for sometime, and can connect and manipulate fine using iCal clients; however, I have been unable to get Sunbird clients to cooperate. A little backgound: my setup is stock with the exception of the documentroot directive in caldavd.plist, and my pool of users (accounts.xml). When I add an account (any account) in sunbird I use the prescribed path, http://example.com:8008/calendars/user/jdoe/calendar, after which I am met with the user/pass prompt, credentials are accepted, but no calendars populate. The logs report the following ad nauseum: 2009-09-17 21:47:23-0500 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.extensions#info] PROPFIND /calendars/users/jdoe/calendar/ HTTP/1.1 2009-09-17 21:47:23-0500 [-] [caldav-8009] [AMP,client] [twistedcaldav.extensions#info] OPTIONS /calendars/users/jdoe/ HTTP/1.1 2009-09-17 21:47:23-0500 [-] [caldav-8009] [AMP,client] [twistedcaldav.extensions#info] HEAD /calendars/users/jdoe/calendar/ HTTP/1.1 2009-09-17 21:47:23-0500 [-] [caldav-8009] [PooledMemCacheProtocol,client] [twistedcaldav.directory.principal#error] No principal found for UID: admin Any ideas what is going on here? Thanks! -- Ticket URL: <http://trac.calendarserver.org/ticket/348> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 4

[CalendarServer] #350: location in snow leopard, more explanation about the problem
by CalendarServer 29 Oct '09

29 Oct '09

#350: location in snow leopard, more explanation about the problem -----------------------------------+---------------------------------------- Reporter: jduffas1@… | Owner: wsanchez@… Type: Defect | Status: new Priority: 1: Blocker | Milestone: Later Component: Calendar Server | Severity: Other Keywords: location snow leopard | -----------------------------------+---------------------------------------- a <location> should not function as a <user>. normally, some people should be allowed to book locations (through <proxies>) but <locations> should always accept the booking (they have no choice to do this, they are not alive...) so, we can imagine that <locations> are programmated this way, and that the xml file should look like this: <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi(a)free.fr</email-address> <proxies> <member type="users">jduffas</member> </proxies> </location> that way, only the user "jduffas" can access that <location>. But the problem is that the <location> accepts half the appointments: it leaves the question mark on the event's user having asked, however, the room still appears as reserved in the availability tool... worse, if I use another user (who is not in <proxies>, the server reacts completely identical. Now, if I add a <auto-schedule/>, the <location> accepts routinely the appointment, whatever the user is (in the <proxies> or not.) wholesale <proxies> in <locations> is not active, which represents a big security hole. the same in french (my language... i'm bad in english) un lieu ne devrait pas fonctionner comme un user. normalement, certaines personnes devraient être autorisées à réserver des lieux (grâce au proxi) mais les lieus devraient toujours accepter les réservation (ils n'ont pas le choix à faire, ce ne sont pas des être vivants) pour cellà, soit on se dit que les lieus sont programmés ainsi, et qu'il suffit de rentrer dans le .xml quelque chose de ce genre : <location> <uid>rfi</uid> <guid>F2F2B56A-7B0E-498C-816F-1DA30D8A4168</guid> <password>dddd</password> <name>rfi</name> <email-address>rfi(a)free.fr</email-address> <proxies> <member type="users">jduffas</member> </proxies> </location> ainsi seul le user "jduffas" pourra accéder au lieu. mais le hic est que le lieu accepte à moitié le rendez-vous : il laisse le point d'interrogation sur l'événement du user l'ayant demandé, en revanche, la salle apparait quand même comme réservée dans l'outil de disponibilité pire, si j'utilise un autre user (qui ne se trouve pas dans <proxies>, le serveur réagit de façon totalement identique. maintenant, si j'ajoute un <auto-schedule/>, le lieu est accepté systématiquement, quelque soit le user (qu'il soit dans le <proxies> ou non.) en gros, <proxies> dans les <locations> n'est pas actif, ce qui représente une grosse faille de sécurité. -- Ticket URL: <http://trac.calendarserver.org/ticket/350> CalendarServer </> HTTP/WebDAV/CalDAV Server

1 3