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
