QnA

Until I find a better place for this, I will be adding answers to some pertinent questions I get asked privately about the project.

Why don’t you just license it under MIT like the thing it’s based on?

The “based on” probably a wrong term. The code is “based” on 2 python WSGI middleware (server layers) URL handler selector and static server component. Both are LGPL-licensed libraries from Luke Arno (http://lukearno.com/)

I read both code bodies: Grack and C-based git-http-backend. One is in MIT, the other is GPL 2.0

To my recollection, short for fractions of regex strings, inspiration and insight into the Smart HTTP RPC protocol, I borrowed pretty much nothing significant / notable in terms of paraphrased logic from Grack. I actually did not like Grack’s handling of static content so, pretty much majority of Grack’s glue code i just glazed over and replaced with off-the-shelf static server, slightly tweaked to the need. There are likely general similarities in code structure to Grack largely because it targets Rack, which is a Ruby implementation of python’s WSGI PEP 333.

In the documentation, I probably overemphasized the influence of Grack on this project. That’s mostly out of respect and gratitude for translating the much less readable code that is C-based implementation to something that is more readable. Since there is no public documentation on git Smart RPC, availability of Grack as a proxy for that is a God send.

How do I run / use it?

See “examples” folder. I will post setting and write ups applicable to different variations of WSGI servers.

What’s the plan?

The server is “Python WSGI servelet” which means it should run against all WSGI compatible servers.This should include the mod_wsgi under apache. various WSGI plug ins under IIS, stand-alone WSGI servers.

The git_http_backend.py was designed for specific simple deployment scenarios. The deployment scenarios are purposefully different from those targeted by native, c-based git-http-backend. All of the “rights management” hook ups that rely on “manager’s” ability to SSH into the server and create / manage files in repo folders on file-system-based repos are COMPLETELY, INTENTIONALLY IGNORED. All deployment scenarios specifically target complete absence of need for any SSH clients, SSH servers, uploading or management of SSH keys, SSH signatures and other insanity. (it is “insanity” for multi-OS, multi-machine users like me.)

My goal is to avoid for as long as possible writing a server-side UI for the repo management. I am finding all possible tricks to push the management and viewing onto user’s git client infrastructure, GUI-based git clients. (I use GitExtensions on Windows and can do everything with a remote repo though it, short of browsing between repos on the server.) At some point a simple web-based repo browser + user management code will come or, more likely, be adapted from some other project. For now, use existing repo browsers like gitweb etc.

Primary mission of the project is to fill a “simple” GIt server need on intrAnet (think “workgroup”), where security is provided by outside firewall. Secondary mission is to provide flexible rights management hookups that would allow this server to be exposed to outside world. At the tail-end is the goal to allow switching of git backend from actual c-based git executable to something like Dulwich (python-based git implementation that allows to manage virtual repos in memory / persisted to a db.) which should allow git_http_backend.py to run on massive scale and against memory or object-based repo storage. (I am contemplating Google AppEngine deployment scenarios.)

The first provided example – command-line deployment method – runs against a WSGI server built into Python runtime itself. Hence, it’s very easy to run it, but it cannot be a service without making the script itself a service. There was intentionally no user-rights management built into the “command-line” deployment mode.
This is the most basic deployment scenario – when you need an ad-hoc git server that you would serve temporarily (Use remove desktop / ssh into a server, run the git_http_backend.py in command-line mode and close the remote session when you don’t need the server any more.)

I do intend to wire up user/rights management next. That feature will heavily rely on the hosting server (apache, MS IIS) for user authentication. Because of my specific corporate requirements, my first target is MS Windows IIS, with ActiveDirectory-based user authentication and rights management based on “All or nothing” access where “authed” user can write and read to any repo..
Apache will come next with the same “rights” logic.

Last will come “layered” rights management, where users are allowed Git functions based on ACL-like rules, which would allow group ownerships of repos, control over who can “auto-create repo on Push” and read / write granularity. “rights” Storage requires some sort of DB storage backend that is non-standard (cannot be attached easily to LDAP / AD) and I don’t want to bog down with that just yet.

“Cloud”-based repo storage / interface backend will come from me only if i will have a real need for it or if someone helps. I don’t commit to that feature yet, but I keep the internal code generally compatible with an idea of non-file-system-based repo storage.

Depending on where on the “user rights management complexity” scale you fall, you will either have to wait a while (for code to be written and examples to be provided), or very little (just for examples and very minimal code to be written).