Got proper admin working. Turns out this wasn't a problem with
calendar server itself. It's default config is to use caldavd-
dev.plist instead of caldavd.plist:
config="${wd}/conf/caldavd-dev.plist";
Another admin here installed the app and I configured it, so I wasn't
intimate with the install/run process. I was hacking on caldavd.plist
and accounts.xml. Which makes sense: If your background is
configuring apache, samba, asterisk and other such services, you
haven't come across things like -dev or -test as default config
options. I went to what I thought were the 'real' config files. I'm
sure that the DCS team had a good reason for setting things up the way
they did, so I won't harp on that point. What I will say is that I
DID "read the f* manual" and it didn't help me learn the nature of the
default configs. So I'd chalk this up as a documentation snafu.
Cheers,
tack
On May 29, 2008, at 10:26 AM, Cyrus Daboo wrote:
> Hi tack,
>
> --On May 29, 2008 10:24:14 AM -0700 tack <[EMAIL PROTECTED]> wrote:
>
>> I've also run into the problem of the admin I set in caldavd.plist
>> not
>> really being an admin. The way I worked around it is I used the
>> command line client to log in as each user and set the ACL's I wanted
>> that way. That wasn't so bad (we're a small shop). But I could see
>> it being a lot to do if you're serving a larger group.
>
> The admin principal set in the .plist must be specified using the /
> principals/__uids__/<<guid>> form of the principal URL. Was that
> what you used?
>
> --
> Cyrus Daboo
>
>
_______________________________________________
calendarserver-users mailing list
calendarserver-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/calendarserver-users
