From 78dc06a87f82ed19e3eebe1f16dc6c1bdaf5fbc5 Mon Sep 17 00:00:00 2001
From: James Moger <james.moger@gitblit.com>
Date: Tue, 31 Jan 2012 09:35:30 -0500
Subject: [PATCH] Merge pull request #6 from lemval/master
---
docs/01_setup.mkd | 345 +++++++++++++++++++++++++++++----------------------------
1 files changed, 177 insertions(+), 168 deletions(-)
diff --git a/docs/01_setup.mkd b/docs/01_setup.mkd
index 48955db..8b5702b 100644
--- a/docs/01_setup.mkd
+++ b/docs/01_setup.mkd
@@ -1,38 +1,42 @@
## Gitblit WAR Setup
-1. Download [Gitblit WAR %VERSION%](http://code.google.com/p/gitblit/downloads/detail?name=%WAR%) to the webapps folder of your servlet container.<br/>
+1. Download [Gitblit WAR %VERSION%](http://code.google.com/p/gitblit/downloads/detail?name=%WAR%) to the webapps folder of your servlet container.
2. You may have to manually extract the WAR (zip file) to a folder within your webapps folder.
-3. Copy the `WEB-INF/users.properties` file to a location outside the webapps folder that is accessible by your servlet container.
-4. The Gitblit webapp is configured through its `web.xml` file.<br/>
+3. Copy the `WEB-INF/users.conf` file to a location outside the webapps folder that is accessible by your servlet container.
+Optionally copy the example hook scripts in `WEB-INF/groovy` to a location outside the webapps folder that is accesible by your servlet container.
+4. The Gitblit webapp is configured through its `web.xml` file.
Open `web.xml` in your favorite text editor and make sure to review and set:
- <context-parameter> *git.repositoryFolder* (set the full path to your repositories folder)
- - <context-parameter> *realm.userService* (set the full path to `users.properties`)
+ - <context-parameter> *groovy.scriptsFolder* (set the full path to your Groovy hook scripts folder)
+ - <context-parameter> *realm.userService* (set the full path to `users.conf`)
5. You may have to restart your servlet container.
6. Open your browser to <http://localhost/gitblit> or whatever the url should be.
-7. Click the *Login* link and enter the default administrator credentials: **admin / admin**<br/>
+7. Enter the default administrator credentials: **admin / admin** and click the *Login* button
**NOTE:** Make sure to change the administrator username and/or password!!
## Gitblit GO Setup
-1. Download and unzip [Gitblit GO %VERSION%](http://code.google.com/p/gitblit/downloads/detail?name=%GO%).<br/>
+1. Download and unzip [Gitblit GO %VERSION%](http://code.google.com/p/gitblit/downloads/detail?name=%GO%).
*Its best to eliminate spaces in the path name.*
-2. The server itself is configured through a simple text file.<br/>
+2. The server itself is configured through a simple text file.
Open `gitblit.properties` in your favorite text editor and make sure to review and set:
- *git.repositoryFolder* (path may be relative or absolute)
+ - *groovy.scriptsFolder* (path may be relative or absolute)
- *server.tempFolder* (path may be relative or absolute)
- - *server.httpPort* and *server.httpsPort*<br/>
- - *server.httpBindInterface* and *server.httpsBindInterface*<br/>
- **https** is strongly recommended because passwords are insecurely transmitted form your browser/git client using Basic authentication!
+ - *server.httpPort* and *server.httpsPort*
+ - *server.httpBindInterface* and *server.httpsBindInterface*
+ **https** is strongly recommended because passwords are insecurely transmitted form your browser/git client using Basic authentication!
3. Execute `gitblit.cmd` or `java -jar gitblit.jar` from a command-line
-4. Wait a minute or two while all dependencies are downloaded and your self-signed *localhost* certificate is generated.<br/>Please see the section titled **Creating your own Self-Signed Certificate** to generate a certificate for *your hostname*.
+4. Wait a minute or two while all dependencies are downloaded and your self-signed *localhost* certificate is generated.
+ Please see the section titled **Creating your own Self-Signed Certificate** to generate a certificate for *your hostname*.
5. Open your browser to <http://localhost:8080> or <https://localhost:8443> depending on your chosen configuration.
-6. Click the *Login* link and enter the default administrator credentials: **admin / admin**<br/>
+6. Enter the default administrator credentials: **admin / admin** and click the *Login* button
**NOTE:** Make sure to change the administrator username and/or password!!
### Creating your own Self-Signed Certificate
Gitblit GO automatically generates an ssl certificate for you that is bound to *localhost*.
-Remote Eclipse/EGit/JGit clients (<= 1.0.0) will fail to communicate using this certificate because JGit always verifies the hostname of the certificate, regardless of the *http.sslVerify=false* client-side setting.
+Remote Eclipse/EGit/JGit clients (<= 1.1.0) will fail to communicate using this certificate because JGit always verifies the hostname of the certificate, regardless of the *http.sslVerify=false* client-side setting.
The EGit failure message is something like:
@@ -45,7 +49,8 @@
2. Set *your hostname* into the *HOSTNAME* variable.
3. Execute the script.<br/>This will generate a new certificate and keystore for *your hostname* protected by *server.storePassword*.
-**NOTE:**<br/>If you use `makekeystore_jdk.cmd`, the certificate password AND the keystore password must match and must be set as *server.storePassword* or specified with the *storePassword* command-line parameter!
+**NOTE:**
+If you use `makekeystore_jdk.cmd`, the certificate password AND the keystore password must match and must be set as *server.storePassword* or specified with the *storePassword* command-line parameter!
Additionally, if you want to change the value of *server.storePassword* (recommended) you will have to generate a new certificate afterwards.
@@ -53,7 +58,7 @@
Gitblit uses [Apache Commons Daemon](http://commons.apache.org/daemon) to install and configure its Windows service.
1. Review the contents of the `installService.cmd`
-2. Set the *ARCH* value as appropriate for your installed Java Virtual Machine.<br/>
+2. Set the *ARCH* value as appropriate for your installed Java Virtual Machine.
3. Add any necessary *--StartParams* as enumerated below in **Command-Line Parameters**.
4. Execute the script.
@@ -70,8 +75,8 @@
1. Execute `gitblitw.exe`
2. On the *Java* tab uncheck *Use default*.
3. Manually navigate your filesystem and specify the server VM with the `...` button<br/><pre>
- Java Virtual Machine:
- C:\Program Files\Java\jre6\bin\server\jvm.dll</pre>
+Java Virtual Machine:
+C:\Program Files\Java\jre6\bin\server\jvm.dll</pre>
#### Command-Line Parameters
Command-Line parameters override the values in `gitblit.properties` at runtime.
@@ -87,17 +92,22 @@
**Example**
- java -jar gitblit.jar --userService c:\myrealm.properties --storePassword something
+ java -jar gitblit.jar --userService c:\myrealm.config --storePassword something
## Upgrading Gitblit
Generally, upgrading is easy.
-Since Gitblit does not use a database the only files you have to worry about are your configuration file (`gitblit.properties` or `web.xml`) and possibly your `users.properties` file.
+Since Gitblit does not use a database the only files you have to worry about are your configuration file (`gitblit.properties` or `web.xml`) and possibly your `users.conf` or `users.properties` file.
Any important changes to the setting keys or default values will always be mentioned in the [release log](releases.html).
+Gitblit v0.8.0 introduced a new default user service implementation which serializes and deserializes user objects into `users.conf`. A `users.conf` file will be automatically created from an existing `users.properties` file on the first launch after an upgrade. To use the `users.conf` service, *realm.userService=users.conf* must be set. This revised user service allows for more sophisticated Gitblit user objects and will facilitate the development of more advanced features without adding the complexity of an embedded SQL database.
+
+`users.properties` and its user service implementation are deprecated as of v0.8.0.
+
### Upgrading Gitblit WAR
-1. Backup your `web.xml` file
+1. Backup your `web.xml` file
+Backup your `web.properties` file (if you have one, these are the setting overrides from using the RPC administration service)
2. Delete currently deployed gitblit WAR
3. Deploy new WAR and overwrite the `web.xml` file with your backup
4. Review and optionally apply any new settings as indicated in the [release log](releases.html).
@@ -105,15 +115,20 @@
### Upgrading Gitblit GO
1. Backup your `gitblit.properties` file
-2. Backup your `users.properties` file *(if it is located in the Gitblit GO folder)*
-3. Unzip Gitblit GO to a new folder
-4. Overwrite the `gitblit.properties` file with your backup
-5. Overwrite the `users.properties` file with your backup *(if it was located in the Gitblit GO folder)*
-6. Review and optionally apply any new settings as indicated in the [release log](releases.html).
+2. Backup your `users.properties` file *(if it is located in the Gitblit GO folder)*
+OR
+Backup your `users.conf` file *(if it is located in the Gitblit GO folder)*
+3. Backup your Groovy hook scripts
+4. Unzip Gitblit GO to a new folder
+5. Overwrite the `gitblit.properties` file with your backup
+6. Overwrite the `users.properties` file with your backup *(if it was located in the Gitblit GO folder)*
+OR
+Overwrite the `users.conf` file with your backup *(if it was located in the Gitblit GO folder)*
+7. Review and optionally apply any new settings as indicated in the [release log](releases.html).
#### Upgrading Windows Service
-You may need to delete your old service definition and install a new one depending on what has changed in the release.
-
+You may need to delete your old service definition and install a new one depending on what has changed in the release.
+
## Gitblit Configuration
### Administering Repositories
@@ -130,7 +145,11 @@
accessRestriction = clone
isFrozen = false
showReadme = false
-
+ federationStrategy = FEDERATE_THIS
+ isFederated = false
+ skipSizeCalculation = false
+ federationSets =
+
#### Repository Names
Repository names must be unique and are CASE-SENSITIVE ON CASE-SENSITIVE FILESYSTEMS. The name must be composed of letters, digits, or `/ _ - .`<br/>
Whitespace is illegal.
@@ -142,181 +161,171 @@
#### Repository Owner
The *Repository Owner* has the special permission of being able to edit a repository through the web UI. The Repository Owner is not permitted to rename the repository, delete the repository, or reassign ownership to another user.
-### Administering Users
-All users are stored in the `users.properties` file or in the file you specified in `gitblit.properties`.<br/>
-The format of `users.properties` follows Jetty's convention for HashRealms:
+### Teams
- username,password,role1,role2,role3...
+Since v0.8.0, Gitblit supports *teams* for the original `users.properties` user service and the current default user service `users.conf`. Teams have assigned users and assigned repositories. A user can be a member of multiple teams and a repository may belong to multiple teams. This allows the administrator to quickly add a user to a team without having to keep track of all the appropriate repositories.
+
+### Administering Users (users.conf, Gitblit v0.8.0+)
+All users are stored in the `users.conf` file or in the file you specified in `gitblit.properties`. Your file extension must be *.conf* in order to use this user service.
+
+The `users.conf` file uses a Git-style configuration format:
+
+ [user "admin"]
+ password = admin
+ role = "#admin"
+ role = "#notfederated"
+ repository = repo1.git
+ repository = repo2.git
+
+ [user "hannibal"]
+ password = bossman
+
+ [user "faceman"]
+ password = vanity
+
+ [user "murdock"]
+ password = crazy
+
+ [user "babaracus"]
+ password = grrrr
+
+ [team "ateam"]
+ user = hannibal
+ user = faceman
+ 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.
+
+### Administering Users (users.properties, Gitblit v0.5.0 - v0.7.0)
+All users are stored in the `users.properties` file or in the file you specified in `gitblit.properties`. Your file extension must be *.properties* in order to use this user service.
+
+The format of `users.properties` loosely follows Jetty's convention for HashRealms:
+
+ username=password,role1,role2,role3...
+ @teamname=&mailinglist,!username1,!username2,!username3,repository1,repository2,repository3...
#### Usernames
-Usernames must be unique and are case-insensitive.<br/>
+Usernames must be unique and are case-insensitive.
Whitespace is illegal.
#### Passwords
-User passwords are CASE-SENSITIVE and may be *plain* or *md5* formatted (see `gitblit.properties` -> *realm.passwordStorage*).
+User passwords are CASE-SENSITIVE and may be *plain*, *md5*, or *combined-md5* formatted (see `gitblit.properties` -> *realm.passwordStorage*).
#### User Roles
-There is only one actual *role* in Gitblit and that is *#admin* which grants administrative powers to that user. Administrators automatically have access to all repositories. All other *roles* are repository names. If a repository is access-restricted, the user must have the repository's name within his/her roles to bypass the access restriction. This is how users are granted access to a restricted repository.
+There are two actual *roles* in Gitblit: *#admin*, which grants administrative powers to that user, and *#notfederated*, which prevents an account from being pulled by another Gitblit instance. Administrators automatically have access to all repositories. All other *roles* are repository names. If a repository is access-restricted, the user must have the repository's name within his/her roles to bypass the access restriction. This is how users are granted access to a restricted repository.
## Authentication and Authorization Customization
-Instead of maintaining a `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.<br/>
+### 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.
-Your user service class must be on Gitblit's classpath and must have a public default constructor.
+Please subclass [com.gitblit.GitblitUserService](https://github.com/gitblit/gitblit/blob/master/src/com/gitblit/GitblitUserService.java) and override the *setup()* and *authenticate()* methods.
+Make sure to set the *serviceImpl* field in your *setup()* method.
-%BEGINCODE%
-public interface IUserService {
+You may use your subclass by specifying its fully qualified classname in the *realm.userService* setting.
- /**
- * Does the user service support cookie authentication?
- *
- * @return true or false
- */
- boolean supportsCookies();
+Your subclass must be on Gitblit's classpath and must have a public default constructor.
- /**
- * Returns the cookie value for the specified user.
- *
- * @param model
- * @return cookie value
- */
- char[] getCookie(UserModel model);
+### Customize Everything
+Instead of maintaining a `users.conf` or `users.properties` file, you may want to integrate Gitblit into an existing environment.
- /**
- * Authenticate a user based on their cookie.
- *
- * @param cookie
- * @return a user object or null
- */
- UserModel authenticate(char[] cookie);
+You may use your own custom *com.gitblit.IUserService* implementation by specifying its fully qualified classname in the *realm.userService* setting.
- /**
- * Authenticate a user based on a username and password.
- *
- * @param username
- * @param password
- * @return a user object or null
- */
- UserModel authenticate(String username, char[] password);
+Your user service class must be on Gitblit's classpath and must have a public default constructor.
+Please see the following interface definition [com.gitblit.IUserService](https://github.com/gitblit/gitblit/blob/master/src/com/gitblit/IUserService.java).
- /**
- * Retrieve the user object for the specified username.
- *
- * @param username
- * @return a user object or null
- */
- UserModel getUserModel(String username);
+## Groovy Hook Scripts
- /**
- * Updates/writes a complete user object.
- *
- * @param model
- * @return true if update is successful
- */
- boolean updateUserModel(UserModel model);
+*SINCE 0.8.0*
- /**
- * Adds/updates a user object keyed by username. This method allows for
- * renaming a user.
- *
- * @param username
- * the old username
- * @param model
- * the user object to use for username
- * @return true if update is successful
- */
- boolean updateUserModel(String username, UserModel model);
+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.
- /**
- * Deletes the user object from the user service.
- *
- * @param model
- * @return true if successful
- */
- boolean deleteUserModel(UserModel model);
+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.
- /**
- * Delete the user object with the specified username
- *
- * @param username
- * @return true if successful
- */
- boolean deleteUser(String username);
+### 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. 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.
+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.
- /**
- * Returns the list of all users available to the login service.
- *
- * @return list of all usernames
- */
- List<String> getAllUsernames();
+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.
- /**
- * Returns the list of all users who are allowed to bypass the access
- * restriction placed on the specified repository.
- *
- * @param role
- * the repository name
- * @return list of all usernames that can bypass the access restriction
- */
- List<String> getUsernamesForRepositoryRole(String role);
+Hook contributions and improvements are welcome.
- /**
- * Sets the list of all uses who are allowed to bypass the access
- * restriction placed on the specified repository.
- *
- * @param role
- * the repository name
- * @param usernames
- * @return true if successful
- */
- boolean setUsernamesForRepositoryRole(String role, List<String> usernames);
+### Pre-Receive
- /**
- * Renames a repository role.
- *
- * @param oldRole
- * @param newRole
- * @return true if successful
- */
- boolean renameRepositoryRole(String oldRole, String newRole);
+Pre-Receive scripts execute after the pushed objects have all been written to the Git repository but before the refs have been updated to point to these new objects.
- /**
- * Removes a repository role from all users.
- *
- * @param role
- * @return true if successful
- */
- boolean deleteRepositoryRole(String role);
+This is the appropriate point to block a push and is how many Git tools implement branch-write permissions.
- /**
- * @See java.lang.Object.toString();
- * @return string representation of the login service
- */
- String toString();
-}
-%ENDCODE%
+### Post-Receive
+
+Post-Receive scripts execute after all refs have been updated.
+
+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.
-**NOTE:**<br/>
-The default self-signed certificate generated by Gitlbit GO is bound to *localhost*.<br/>
-If you are using Eclipse/EGit/JGit clients, you will have to generate your own certificate that specifies the exact hostname used in your clone/push url.<br/>
-You must do this because Eclipse/EGit/JGit (<= 1.0.0) always verifies certificate hostnames, regardless of the *http.sslVerify=false* client-side setting.
+**NOTE:**
+The default self-signed certificate generated by Gitlbit GO is bound to *localhost*.
+If you are using Eclipse/EGit/JGit clients, you will have to generate your own certificate that specifies the exact hostname used in your clone/push url.
+You must do this because Eclipse/EGit/JGit (<= 1.1.0) always verifies certificate hostnames, regardless of the *http.sslVerify=false* client-side setting.
-- Eclipse/EGit/JGit
+- **Eclipse/EGit/JGit**
1. Window->Preferences->Team->Git->Configuration
2. Click the *New Entry* button
- 3. <pre>Key = *http.sslVerify*
- Value = *false*</pre>
-- Command-line Git ([Git-Config Manual Page](http://www.kernel.org/pub/software/scm/git/docs/git-config.html))
- <pre>git config --global --bool --add http.sslVerify false</pre>
+ 3. <pre>Key = <em>http.sslVerify</em>
+Value = <em>false</em></pre>
+- **Command-line Git** ([Git-Config Manual Page](http://www.kernel.org/pub/software/scm/git/docs/git-config.html))
+<pre>git config --global --bool --add http.sslVerify false</pre>
### Cloning an Access Restricted Repository
-- Eclipse/EGit/JGit<br/>Nothing special to configure, EGit figures out everything.
- <pre>https://yourserver/git/your/repository</pre>
-- Command-line Git<br/>*My testing indicates that your username must be embedded in the url. YMMV.*
- <pre>https://username@yourserver/git/your/repository</pre>
-
\ No newline at end of file
+- **Eclipse/EGit/JGit**
+Nothing special to configure, EGit figures out everything.
+<pre>https://yourserver/git/your/repository</pre>
+- **Command-line Git**
+My testing indicates that your username must be embedded in the url. YMMV.
+<pre>https://username@yourserver/git/your/repository</pre>
\ No newline at end of file
--
Gitblit v1.9.1