githubFork/gitblit.git - Solinfo Gitblit

			@@ -94,6 +94,76 @@

			java -jar gitblit.jar --userService c:\myrealm.config --storePassword something

			#### Overriding Gitblit GO's Log4j Configuration

			You can override Gitblit GO's default Log4j configuration with a command-line parameter to the JVM.

			java -Dlog4j.configuration=file:///home/james/log4j.properties -jar gitblit.jar <optional_gitblit_args>

			For reference, here is [Gitblit's default Log4j configuration](https://github.com/gitblit/gitblit/blob/master/src/log4j.properties). It includes some file appenders that are disabled by default.

			## Running Gitblit behind Apache

			Gitblit runs fine behind Apache. You may use either mod_proxy (GO or WAR) or mod_proxy_ajp (GO).

			Each Linux distribution may vary on the exact configuration of Apache 2.2.
			Here is a sample configuration that works on Debian 7.0 (Wheezy), your distribution may be different.

			1. First we need to make sure we have Apache's proxy modules available.
			<pre>
			sudo su
			cd /etc/apache2/mods-enabled
			ln -s ../mods-available/proxy.load proxy.load
			ln -s ../mods-available/proxy_balancer.load proxy_balancer.load
			ln -s ../mods-available/proxy_http.load proxy_http.load
			ln -s ../mods-available/proxy_ajp.load proxy_ajp.load
			</pre>
			2. Then we need to make sure we are configuring Apache to use the proxy modules and to setup the proxied connection from Apache to Gitblit GO or from Apache to your chosen servlet container. The following snippet is stored as `/etc/apache2/conf.d/gitblit`.
			%BEGINCODE%
			# Turn off support for true Proxy behaviour as we are acting as
			# a transparent proxy
			ProxyRequests Off

			# Turn off VIA header as we know where the requests are proxied
			ProxyVia Off

			# Turn on Host header preservation so that the servlet container
			# can write links with the correct host and rewriting can be avoided.
			#
			# This is important for all git push/pull/clone operations.
			ProxyPreserveHost On

			# Set the permissions for the proxy
			<Proxy *>
			AddDefaultCharset off
			Order deny,allow
			Allow from all
			</Proxy>

			# Turn on Proxy status reporting at /status
			# This should be better protected than: Allow from all
			ProxyStatus On
			<Location /status>
			SetHandler server-status
			Order Deny,Allow
			Allow from all
			</Location>

			# The proxy context path must match the Gitblit context path.
			# For Gitblit GO, see server.contextPath in gitblit.properties.

			#ProxyPass /gitblit http://localhost:8080/gitblit
			#ProxyPass /gitblit ajp://localhost:8009/gitblit
			%ENDCODE%
			Please make sure to:
			1. Review the security of these settings as appropriate for your deployment
			2. Uncomment the ProxyPass setting for whichever connection you prefer (http/ajp)
			3. Correctly set the ports and context paths both in the ProxyPass definition and your Gitblit installation
			If you are using Gitblit GO you can easily configure the AJP connector by specifying a non-zero AJP port.
			Please remember that on Linux/UNIX, ports < 1024 require root permissions to open.
			4. Set web.mountParameters=false in `gitblit.properties` or `web.xml` this will use parameterized URLs.
			Alternatively, you can respecify web.forwardSlashCharacter.

			## Upgrading Gitblit
			Generally, upgrading is easy.

			@@ -195,6 +265,8 @@
			user = murdock
			user = babaracus
			repository = topsecret.git
			mailingList = list@ateam.org
			postReceiveScript = sendmail

			The `users.conf` file allows flexibility for adding new fields to a UserModel object that the original `users.properties` file does not afford without imposing the complexity of relying on an embedded SQL database.

			@@ -204,7 +276,7 @@
			The format of `users.properties` loosely follows Jetty's convention for HashRealms:

			username=password,role1,role2,role3...
			@teamname=!username1,!username2,!username3,repository1,repository2,repository3...
			@teamname=&mailinglist,!username1,!username2,!username3,repository1,repository2,repository3...

			#### Usernames
			Usernames must be unique and are case-insensitive.
			@@ -218,7 +290,7 @@

			## Authentication and Authorization Customization

			### Choice 1: Customize Authentication Only
			### Customize Authentication Only
			This is the simplest choice where you implement custom authentication and delegate all other standard user and team operations to one of Gitblit's user service implementations. This choice insulates your customization from changes in User and Team model classes and additional API that may be added to IUserService.

			Please subclass [com.gitblit.GitblitUserService](https://github.com/gitblit/gitblit/blob/master/src/com/gitblit/GitblitUserService.java) and override the setup() and authenticate() methods.
			@@ -228,7 +300,7 @@

			Your subclass must be on Gitblit's classpath and must have a public default constructor.

			### Choice 2: Customize Everything
			### Customize Everything
			Instead of maintaining a `users.conf` or `users.properties` file, you may want to integrate Gitblit into an existing environment.

			You may use your own custom com.gitblit.IUserService implementation by specifying its fully qualified classname in the realm.userService setting.
			@@ -240,22 +312,24 @@

			SINCE 0.8.0

			The preferred hook mechanism is Groovy. This mechanism only executes when pushing to Gitblit, not when pushing to some other Git tooling in your stack.
			Gitblit uses Groovy for its push hook mechanism. This mechanism only executes when pushing to Gitblit, not when pushing to some other Git tooling in your stack.

			The Groovy hook mechanism allows for dynamic extension of Gitblit to execute custom tasks on receiving and processing push events. The scripts run within the context of your Gitblit instance and therefore have access to Gitblit's internals at runtime.

			### Rules, Requirements, & Behaviors
			1. Your Groovy scripts must be stored in the groovy.scriptsFolder as specified in `gitblit.properties` or `web.xml`.
			2. All script files must have the .groovy extension. Because of this you may omit the extension when specifying the script.
			3. Scripts must be explicitly specified to be executed, no scripts are automatically executed by name or extension.
			4. A script can be specified to run on all repositories by adding the script file name to groovy.preReceiveScripts or groovy.postReceiveScripts in `gitblit.properties` or `web.xml`. Be mindful of access retrictions and global properties like mail.mailingLists if specifying sendmail to run on all repositories.
			5. Scripts may also be specified per-repository in the repository's settings.
			6. Globally specified scripts are excluded from the list of available scripts in a repository's settings
			7. Globally specified scripts are executed first, in their listed order, followed by per-repository scripts, in their listed order.
			8. A script may only be defined once in a pre-receive list and once in a post-receive list.
			3. Script filenames must not have spaces!
			4. Scripts must be explicitly specified to be executed, no scripts are automatically executed by name or extension.
			5. A script can be specified to run on all repositories by adding the script file name to groovy.preReceiveScripts or groovy.postReceiveScripts in `gitblit.properties` or `web.xml`.
			6. Scripts can be specified for a team.
			7. Scripts may also be specified per-repository in the repository's settings.
			8. Globally-specified scripts and team-specified scripts are excluded from the list of available scripts in a repository's settings
			9. Globally-specified scripts are executed first, in their listed order; followed by team-specified scripts in their listed order by alphabetical team order; followed by per-repository scripts, in their listed order.
			10. A script may only be defined once in a pre-receive chain and once in a post-receive chain.
			You may execute the same script on pre-receive and post-receive, just not multiple times within a pre-receive or post-receive event.
			9. Gitblit does not differentiate between what can be a pre-receive script and what can be a post-receive script.
			10. If a script returns false then the pre-receive or post-receive hook chain is aborted and none of the subsequent scripts will execute.
			11. Gitblit does not differentiate between what can be a pre-receive script and what can be a post-receive script.
			12. If a script returns false then the hook chain is aborted and none of the subsequent scripts will execute.

			Some sample scripts are included in the GO and WAR distributions to show you how you can tap into Gitblit with the provided bound variables. Additional implementation details may be specified in the header comment of these examples.

			@@ -273,6 +347,34 @@

			This is the appropriate point to trigger continuous integration builds or send email notifications, etc.

			## Push Email Notifications

			Gitblit implements email notifications in sendmail.groovy which uses the Groovy Hook Script mechanism. This allows for dynamic customization of the notification process at the installation site and serves as an example push script.

			### Enabling Push Notifications

			In order to send email notifications on a push to Gitblit, this script must be specified somewhere in the post-receive script chain.
			You may specify sendmail in one of three places:

			1. groovy.postReceiveScripts in `gitblit.properties` or `web.xml`, globally applied to all repositories
			2. post-receive scripts of a Team definition
			3. post-receive scripts of a Repository definition

			### Destination Addresses

			Gitblit does not currently support individual subscriptions to repositories; i.e. a user can not subscribe or unsubscribe from push notifications.

			However, Repository Managers and Administrators can specify subscribed email addresses in one of three places:

			1. mail.mailingLists in `gitblit.properties` or `web.xml`, globally applied to all push-notified repositories
			2. mailing lists in a Team definition, applied to all repositories that are part of the team definition
			3. mailing lists in a Repository definition

			All three sources are checked and merged into a unique list of destination addresses for push notifications.

			NOTE:
			Care should be taken when devising your notification scheme as it relates to any VIEW restricted repositories you might have. Setting a global mailing list and activating push notifications for a VIEW restricted repository may send unwanted emails.

			## Client Setup and Configuration
			### Https with Self-Signed Certificates
			You must tell Git/JGit not to verify the self-signed certificate in order to perform any remote Git operations.