]> git.8kb.co.uk Git - slony-i/user_replication/blobdiff - README.md
Initial check in of functions.
[slony-i/user_replication] / README.md
diff --git a/README.md b/README.md
new file mode 100644 (file)
index 0000000..db135c5
--- /dev/null
+++ b/README.md
@@ -0,0 +1,45 @@
+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