[CalendarServer-users] Adding a new "role" to the Calendar Server DB?

[Andre LaBranche]

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
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-users/attachments/20130916/592452bd/attachment.html>