Re: [CalendarServer-users] Adding a new "role" to the Calendar Server DB?
Forgot to cc the list on the resolution. -dre On Sep 16, 2013, at 10:47 AM, Andre LaBranche <dre@apple.com> wrote:
On Sep 14, 2013, at 9:41 PM, Scott Cherf <cherf@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 <cherf@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
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@apple.com> wrote:
On Sep 14, 2013, at 9:41 PM, Scott Cherf <cherf@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 <cherf@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
On Sep 16, 2013, at 12:24 PM, Scott Cherf <cherf@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 <dre@apple.com> wrote:
On Sep 14, 2013, at 9:41 PM, Scott Cherf <cherf@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 <cherf@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
participants (2)
-
Andre LaBranche
-
Scott Cherf