]> git.8kb.co.uk Git - slony-i/user_replication/blobdiff - README.md
Remove irrelevant grant
[slony-i/user_replication] / README.md
index db135c5cf5b7150f4669ab66a464a8eb16db5f4e..6ab8a0ae9eda9540c30a906c09f99d11a8f3ccd3 100644 (file)
--- a/README.md
+++ b/README.md
@@ -1,45 +1,46 @@
-user_replication\r
-================\r
-\r
-A basic table and trigger based user replication example for use\r
-with PostgreSQL and Slony-I.\r
-\r
-About\r
------\r
-\r
-This is something I created back in 2008 to easily keep users in sync \r
-across a slony cluster.\r
-\r
-The supplied functions have various limitations, one of which is the "options" \r
-field only being useful for managing role membership, anything more complicated \r
-will most likely fail without further work.\r
-\r
-It has the option to store the standard postgresql md5 encrypted passwords, or \r
-or allow unencrypted password retrieval via a PGP encryption using a symmetric-key\r
-obfuscated during construction with a (rather horrible) c function named "hkey".\r
-\r
-If you want to use the hkey obfuscation functionality see *Using the hkey obfuscation*\r
-below.\r
-\r
-To use execute the sql script on each node:\r
-\r
-    # psql -d <db> user_replication.sql\r
-\r
-Now put the 'replicated_users' table into replication using slony and users\r
-can be managed by the create_replicated_user etc functions.\r
-\r
-SELECT create_replicated_user('superted', 'test', 'IN GROUP users');\r
-SELECT detail_replicated_user('superted');\r
-SELECT alter_replicated_user('superted', 'test', 'IN GROUP admins');\r
-SELECT alter_replicated_user('superted', 'test', 'IN GROUP admins');\r
-\r
-Using the hkey obfuscation\r
---------------------------\r
-\r
-    # cd hkey\r
-    # make\r
-    # make install\r
-    # /usr/local/pgsql/bin/psql -d <db> -U <user> < hkey.sql\r
-\r
-Then alter "v_use_hkey := false" to "v_use_hkey := true" in both the\r
-decrypt_replicated_users and encrypt_replicated_users functions.
\ No newline at end of file
+user_replication
+================
+
+A basic table and trigger based user replication example for use
+with PostgreSQL and Slony-I.
+
+About
+-----
+
+This is something I created back in 2008 to easily keep users in sync 
+across a slony cluster.
+
+The supplied functions have various limitations, one of which is the "options" 
+field only being useful for managing role membership, anything more complicated 
+will most likely fail without further work.
+
+It has the option to store the standard postgresql md5 encrypted passwords, or 
+or allow unencrypted password retrieval via a PGP encryption using a symmetric-key
+obfuscated during construction with a (rather horrible) c function named "hkey".
+
+If you want to use the hkey obfuscation functionality see *Using the hkey obfuscation*
+below.
+
+To use execute the sql script on each node:
+
+    # psql -d <db> user_replication.sql
+
+Now put the 'replicated_users' table into replication using slony and users
+can be managed by the create_replicated_user etc functions.
+
+SELECT create_replicated_user('superted', 'test', 'IN GROUP users');
+SELECT detail_replicated_user('superted');
+SELECT alter_replicated_user('superted', 'test', 'IN GROUP admins');
+SELECT alter_replicated_user('superted', 'test', 'IN GROUP admins');
+
+Using the hkey obfuscation
+--------------------------
+
+    # cd hkey
+    # make
+    # make install
+    # /usr/local/pgsql/bin/psql -d <db> -U <user> < hkey.sql
+
+Then alter "v_use_hkey := false" to "v_use_hkey := true" in both the
+decrypt_replicated_users and encrypt_replicated_users functions. 
+Note the pgcrypto contrib module is required for this.