On Sep 16, 2013, at 12:24 PM, Scott Cherf <ch...@ambient-light.com> wrote:
> 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 :) That's pretty fantastic. We are totally not writing the unit test for the marriage-saving behavior, since that would require testing the failure case :) > 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. If you want to make it work even without console login, you can still use good old fashioned crontab (no need to bother with launchd plists for something this simple). http://hints.macworld.com/article.php?story=20041105070509783 HTH, -dre > > 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
