[CalendarServer-users] Adding a new "role" to the Calendar Server DB?
Scott Cherf
cherf at ambient-light.com
Mon Sep 16 12:24:05 PDT 2013
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 <dre at apple.com> wrote:
>
>>
>> On Sep 14, 2013, at 9:41 PM, Scott Cherf <cherf at 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 at 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 <cherf at 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 at 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 at linuxbuilder [~/pg] % ./bin/createuser newman
>>>> {40} admin at 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 at linuxbuilder [~/pg] % ./bin/psql template1 -c 'grant caldav to newman'
>>>> GRANT ROLE
>>>> {42} admin at 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 at lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/calendarserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20130916/a69438c4/attachment.html>
More information about the calendarserver-users
mailing list