[Bps-public-commit] r14131 - Pushmi/trunk/Pushmi-Admin/doc
jesse at bestpractical.com
jesse at bestpractical.com
Tue Jul 15 18:17:41 EDT 2008
Author: jesse
Date: Tue Jul 15 18:17:41 2008
New Revision: 14131
Added:
Pushmi/trunk/Pushmi-Admin/doc/admin-ui-notes.txt
Pushmi/trunk/Pushmi-Admin/doc/admin-ui-sketch.pdf
Log:
rough admin ui sketching
Added: Pushmi/trunk/Pushmi-Admin/doc/admin-ui-notes.txt
==============================================================================
--- (empty file)
+++ Pushmi/trunk/Pushmi-Admin/doc/admin-ui-notes.txt Tue Jul 15 18:17:41 2008
@@ -0,0 +1,117 @@
+Pushmi 2.0
+
+
+
+Goal: A standalone virtual appliance which can act as a read-write subversion mirror for a company's branch office.
+
+
+Protocols:
+
+ * SVN over HTTP
+ * We need to provision vhosts?
+ i think just svnparentpath for now
+ does that mean all the various mirrors are on the same host? ok.
+ * SVN over HTTPS
+ * We need to provision vhosts with SSL certificates?
+ so we only need one SSL certificate to be installed? yes
+ * SVNServe
+ * do we support it or not? yes. i think it's a good start because this doesn't require auth* and apache to be configured. but we might not officially support it later. (start as in in our development stages)
+ as an appliance, setting up apache is a non-issue ;) let's talk auth below
+
+
+Components:
+
+ * Subversion server configured with Pushmi replication
+ * Web interface for managing Pushmi replicas
+ * Add a replica
+ * List replicas
+ * Check replica health
+ * Delete a replica
+ * Manually start a replica synchronization?
+ * cronjob ?
+ (is this "only ever once")?
+ * with bootstrap dump (for initial sync)
+
+ * Manage replica options (pushmi level)
+ * master url
+ * authentication if used in shared_commit_credential mode
+ * Manage replica configuration (svn level)
+ * apache auth options:
+ * Apache::AuthCommit (relay auth check to the master)
+ * authn/authz files and/or external auth config
+
+
+
+Authentication
+
+It's very important that Pushmi act as a simple extension of your existing
+subversion authentication and authorization configuration.
+
+Authentication methods users might use:
+
+There are two different authentication mechanisms we need to worry about:
+ * What users will use to talk to the master server
+ * What users will use to talk to the replica.
+Do they need to be the same?
+ C it has to be http basic so we can hijack the auth info
+ J we can't do clever things as a MITM attack and just proxy a challenge from the master?
+ J or if we clone the authz file or ldap configuration from upstream, can't we use other auth mechanisms?
+
+ C cloning only shortcircuits the check so it doesn't have to go to master. but master still needs credential from the replica on commit. MITM is doable, i am only saying what we already have
+
+
+ J got it. I just want to understand what's today/possible/stupid ;)
+
+ J So we force HTTP basic and support Digest-MD5 and HTTP-Basic when talking upstream?
+
+ C alternatively we use a separate commit channel (a different credential just for the replica) and then tweak the svn:author afterwards, but the total-integration of such script is not done yet
+
+ J that sounds scary. 2.0. on the list it was actually implemented by someone
+
+ J: which authn methods do we need to speak to upstream "master" svn repos?
+ J what auth methods _can_ we support talking to the upstream?
+ J: well, we can't support client certs since we can't proxy them, no?
+ C: auth method in which layer? anything. this is all encapsulated by libsvn_ra*, ya, just passwords.
+
+
+ J isn't it important that we have some way to clone credentials to local for access when the master is offline?
+
+ - if it's partially read-protected then we need the credential and authz at all times. if it's only write-protected we need to talk to the master anyway. any authn/authz in the replica is just helping to speed things up
+
+ J: is it a 2.0 admin ui feature?
+
+ C: do your mean managing external authn/authz fetching / syncing?
+ J: yes
+ C: sure, i'd leave it, and let the advanced user to configure a block of apache config with their settings. say you are auth against ldap
+ J: eep. that's a bit scary sounding. I guess I'd be happy if we had "for LDAP, enter the DN, username and password, for htpasswd, enter an ssh username and password and scp line and for more complex, "edit this apache auth config"
+ C definitely not m1, possibly m2, yes. but the edit thing is easily presentable right now
+ J: OK
+
+
+ * HTTP Basic
+ * Digest-MD5
+ * SSL Client certificates
+ * What else does svn support?
+
+
+Authorization
+
+ commit hook based
+ If subversion has pre-commit hook authz - how do we keep that up to date?
+ in this case we suggest to let this fail through the master commit's pre-commit check
+ svn authz file
+ how do we clone this from the master?
+ the user should specify external source to fetch / rsync the file
+ so we need to cache passwords? :/
+ again, authz can be left to be guarded by the master, it's just shortcircuit in the replica to make it faster)
+ (see questions with ??? above)
+
+
+[what else does it need to do?]
+
+when replica gets commit through it, it automatically sycns. but a cronjob is needed to keep it synced in case no one is committing through it
+what about being pinged from the master on commit? (post-commit hook)
+
+ not implemented yet
+
+half-baked active push notification on a branch
Added: Pushmi/trunk/Pushmi-Admin/doc/admin-ui-sketch.pdf
==============================================================================
Binary files (empty file) and Pushmi/trunk/Pushmi-Admin/doc/admin-ui-sketch.pdf Tue Jul 15 18:17:41 2008 differ
More information about the Bps-public-commit
mailing list