For the record too, this release of caldavd (4.2) has been working flawlessly on MacOS 10.6.8 running on a Mac Mini serving 6 clients for the past 3 months and may very well have saved my marriage :)
For anyone interested in a simple way to autostart the daemon on a MacOS client machine (not MacOS Server), I gave up on trying to use launchctl and just wrote a simple shell script I run as a "login item" from an account that's configured for auto-login on the server: #!/bin/sh cd ~matinee/CalendarServer/tags/release/4.2/ ./run -nd Brut force, but it works fine if you have an auto-login configured. In my case the machine is my home theater media server and it's configured to boot into Front Row using a restricted account named "matinee" that doesn't have permission to do anything. When I talked about running with different "permissions" this is what I meant. The original install was done from an admin level account, which is why I wanted to move it. Scott. On Sep 16, 2013, at 11:50 AM, Andre LaBranche wrote: > Forgot to cc the list on the resolution. > > -dre > > On Sep 16, 2013, at 10:47 AM, Andre LaBranche <d...@apple.com> wrote: > >> >> On Sep 14, 2013, at 9:41 PM, Scott Cherf <ch...@ambient-light.com> wrote: >> >>> Hi Andre - >>> >>> Thanks for the step by step guide, it all makes sense and like you I don't >>> have postgres installed systemwide either. In my install it's in the >>> directory above the CalendarServer (version 4.2) in >>> CalendarServer/tags/release. Using the commands from that location gives me >>> an error: >>> >>> psql: could not connect to server: No such file or directory >>> Is the server running locally and accepting >>> connections on Unix domain socket "/tmp/.s.PGSQL.5432"? >>> >>> >>> The CalendarServer is running and so is postgres but the socket mentioned >>> in the error doesn't exist. Is there a way from me to tell psql how to >>> connect to the DB? >> >> Yep; that /tmp location is the default for postgres, but we stash it >> someplace a bit more unique. Start the service, then get a list of running >> postgres processes: >> >> ps auxww | grep -i postgres >> >> You should see one something like this: >> >> ... >> /Volumes/whatever/Users/andre/work/icalserver/trunk/postgresql-9.2.4/_root/bin/postgres >> -c listen_addresses= -k /tmp/ccs_postgres_6c305e5a2a6852bf7f384e044de707ec >> -c shared_buffers=49 -c max_connections=33 -c standard_conforming_strings=on >> >> The value after the -k switch is the path to our postgres socket file, which >> you can use as the value for the -h option of postgres command line tools. >> For example: >> >> andre@xomg[postgresql-9.2.4/_root]./bin/psql -U caldav -h >> /tmp/ccs_postgres_6c305e5a2a6852bf7f384e044de707ec --list >> List of databases >> Name | Owner | Encoding | Collate | Ctype | Access >> privileges >> -----------+--------+----------+-------------+-------------+------------------- >> caldav | caldav | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> postgres | caldav | UTF8 | en_US.UTF-8 | en_US.UTF-8 | >> template0 | caldav | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/caldav >> + >> | | | | | >> caldav=CTc/caldav >> template1 | caldav | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/caldav >> + >> | | | | | >> caldav=CTc/caldav >> (4 rows) >> >> HTH, >> -dre >> >> >>> >>> This is a MacOS 10.6.8 installation. >>> >>> Regards, >>> Scott. >>> >>> On Sep 13, 2013, at 11:30 AM, Andre LaBranche wrote: >>> >>>> >>>> On Sep 13, 2013, at 8:26 AM, Scott Cherf <ch...@ambient-light.com> wrote: >>>> >>>>> Does anyone have a cheap trick for adding a "role" to the postgres DB >>>>> CalendarServer uses? I installed the server under one user ID and wanted >>>>> to move it to another but had to export the data, reinstall then import >>>>> so I could run it with different permissions. There must be a simple way >>>>> to just add a new role to the DB but it wasn't obvious? >>>> >>>> Official docs are here: http://www.postgresql.org/docs/9.2 >>>> >>>> It’s hard for me to predict what your exact steps would need to be, but >>>> one simple approach would be: >>>> >>>> * create the new user (role) in postgres >>>> * grant the new user the same rights as the existing user >>>> >>>> Example below. Note that in this example, I don’t have postgres installed >>>> system-wide (it’s installed to ~/pg), which is why I’m saying ./bin/psql >>>> instead of just psql. YMMV. I’m also not setting any passwords for the new >>>> role; if your postgres service can be reached over the network, you may >>>> want passwords. >>>> >>>> # First, list the current roles. >>>> >>>> {38} admin@linuxbuilder [~/pg] % ./bin/psql template1 -c '\du' >>>> List of roles >>>> Role name | Attributes | Member of >>>> -----------+------------------------------------------------+----------- >>>> admin | Superuser, Create role, Create DB, Replication | {} >>>> caldav | Superuser, Create role, Create DB | {} >>>> >>>> Let’s assume caldav is the ‘old’ account. >>>> >>>> >>>> # Create a new role, validate it >>>> >>>> {39} admin@linuxbuilder [~/pg] % ./bin/createuser newman >>>> {40} admin@linuxbuilder [~/pg] % ./bin/psql template1 -c '\du' >>>> List of roles >>>> Role name | Attributes | Member of >>>> -----------+------------------------------------------------+----------- >>>> admin | Superuser, Create role, Create DB, Replication | {} >>>> caldav | Superuser, Create role, Create DB | {} >>>> newman | | {} >>>> >>>> >>>> # Give newman the same access as caldav, validate it. >>>> >>>> {41} admin@linuxbuilder [~/pg] % ./bin/psql template1 -c 'grant caldav to >>>> newman' >>>> GRANT ROLE >>>> {42} admin@linuxbuilder [~/pg] % ./bin/psql template1 -c '\du' >>>> >>>> List of roles >>>> Role name | Attributes | Member of >>>> -----------+------------------------------------------------+----------- >>>> admin | Superuser, Create role, Create DB, Replication | {} >>>> caldav | Superuser, Create role, Create DB | {} >>>> newman | | {caldav} >>>> >>>> Note that newman is now shown as a member of caldav. This means newman is >>>> allowed to do all the things that the caldav role can do. You don’t need >>>> to delete the caldav role. >>>> >>>> Also, be advised that postgres roles and permissions are not at all >>>> related to filesystem permissions or system user accounts; except that if >>>> you don’t supply a postgres username when connecting, it will pick your >>>> current system user account name as the default. >>>> >>>> HTH, >>>> -dre >>> >>> Regards, >>> Scott Cherf >>> >>> Villa Montagne Equestrian B&B >>> >>> 28495 Big Basin Way, >>> Boulder Creek, CA >>> 95006 >>> >>> www.villamontagne.us.com >>> >> > > _______________________________________________ > calendarserver-users mailing list > calendarserver-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/calendarserver-users
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
