James Moger
2011-12-19 916e848bd77cc0a63f083ff48e5a2e4e788e1f51
docs/01_setup.mkd
@@ -2,11 +2,13 @@
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.
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. Enter the default administrator credentials: **admin / admin** and click the *Login* button  
@@ -19,6 +21,7 @@
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*
    - *server.httpBindInterface* and *server.httpsBindInterface*  
@@ -89,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). 
@@ -107,11 +115,16 @@
### 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.
@@ -148,170 +161,83 @@
#### 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
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=!username1,!username2,!username3,repository1,repository2,repository3...
#### Usernames
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 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.
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.
Your user service class must be on Gitblit's classpath and must have a public default constructor.
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).
%BEGINCODE%
public interface IUserService {
## Groovy Hook Scripts
   /**
    * Setup the user service.
    *
    * @param settings
    * @since 0.7.0
    */
   @Override
   public void setup(IStoredSettings settings) {
   }
   /**
    * Does the user service support cookie authentication?
    *
    * @return true or false
    */
   boolean supportsCookies();
*SINCE 0.8.0*
   /**
    * Returns the cookie value for the specified user.
    *
    * @param model
    * @return cookie value
    */
   char[] getCookie(UserModel model);
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.
   /**
    * Authenticate a user based on their cookie.
    *
    * @param cookie
    * @return a user object or null
    */
   UserModel authenticate(char[] cookie);
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.
   /**
    * 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 Groovy scripts should be stored in the *groovy.scriptsFolder* as specified in `gitblit.properties` or `web.xml`.
   /**
    * Retrieve the user object for the specified username.
    *
    * @param username
    * @return a user object or null
    */
   UserModel getUserModel(String username);
Scripts must be explicitly specified to be executed.  A script can be run on *all repositories* by adding the script file name to *groovy.preReceiveScripts* or *groovy.postReceiveScripts* in `gitblit.properties` or `web.xml`. Alternatively, you may specify per-repository scripts in the repository settings.  Global/shared scripts are executed first in their listed order, followed by per-repository scripts in their listed order.
   /**
    * Updates/writes a complete user object.
    *
    * @param model
    * @return true if update is successful
    */
   boolean updateUserModel(UserModel model);
   /**
    * 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);
   /**
    * Deletes the user object from the user service.
    *
    * @param model
    * @return true if successful
    */
   boolean deleteUserModel(UserModel model);
   /**
    * Delete the user object with the specified username
    *
    * @param username
    * @return true if successful
    */
   boolean deleteUser(String username);
   /**
    * Returns the list of all users available to the login service.
    *
    * @return list of all usernames
    */
   List<String> getAllUsernames();
   /**
    * 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);
   /**
    * 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);
   /**
    * Renames a repository role.
    *
    * @param oldRole
    * @param newRole
    * @return true if successful
    */
   boolean renameRepositoryRole(String oldRole, String newRole);
   /**
    * Removes a repository role from all users.
    *
    * @param role
    * @return true if successful
    */
   boolean deleteRepositoryRole(String role);
   /**
    * @See java.lang.Object.toString();
    * @return string representation of the login service
    */
   String toString();
}
%ENDCODE%
Some primitive sample scripts are included in the GO and WAR distributions to show you how you can tap into Gitblit with the provided bound variables.
Hook contributions and improvements are welcome.
## Client Setup and Configuration
### Https with Self-Signed Certificates