From 8f73a7cc630bb61d088c7cdad30a6708870184ee Mon Sep 17 00:00:00 2001
From: James Moger <james.moger@gitblit.com>
Date: Wed, 14 Sep 2011 09:13:51 -0400
Subject: [PATCH] Implemented Federation Sets. Documentation.
---
docs/01_setup.mkd | 167 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 164 insertions(+), 3 deletions(-)
diff --git a/docs/01_setup.mkd b/docs/01_setup.mkd
index a601e68..37605c9 100644
--- a/docs/01_setup.mkd
+++ b/docs/01_setup.mkd
@@ -20,11 +20,12 @@
Open `gitblit.properties` in your favorite text editor and make sure to review and set:
- *git.repositoryFolder* (path may be relative or absolute)
- *server.tempFolder* (path may be relative or absolute)
+ - *server.httpPort* and *server.httpsPort*
- *server.httpBindInterface* and *server.httpsBindInterface*<br/>
- **https** is strongly recommended because passwords are insecurely transmitted form your browser/git client using Basic authentication!
+ **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*.
-5. Open your browser to <http://localhost> or <https://localhost> depending on your chosen configuration.
+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/>
**NOTE:** Make sure to change the administrator username and/or password!!
@@ -87,6 +88,31 @@
**Example**
java -jar gitblit.jar --userService c:\myrealm.properties --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.
+
+Any important changes to the setting keys or default values will always be mentioned in the [release log](releases.html).
+
+### Upgrading Gitblit WAR
+1. Backup your `web.xml` file
+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).
+
+### 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).
+
+#### 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.
## Gitblit Configuration
@@ -104,6 +130,9 @@
accessRestriction = clone
isFrozen = false
showReadme = false
+ excludeFromFederation = false
+ isFederated = 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/>
@@ -130,7 +159,7 @@
User passwords are CASE-SENSITIVE and may be *plain* or *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.
@@ -139,6 +168,138 @@
Your user service class must be on Gitblit's classpath and must have a public default constructor.
+%BEGINCODE%
+public interface IUserService {
+
+ /**
+ * Does the user service support cookie authentication?
+ *
+ * @return true or false
+ */
+ boolean supportsCookies();
+
+ /**
+ * Returns the cookie value for the specified user.
+ *
+ * @param model
+ * @return cookie value
+ */
+ char[] getCookie(UserModel model);
+
+ /**
+ * Authenticate a user based on their cookie.
+ *
+ * @param cookie
+ * @return a user object or null
+ */
+ UserModel authenticate(char[] cookie);
+
+ /**
+ * 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);
+
+ /**
+ * Retrieve the user object for the specified username.
+ *
+ * @param username
+ * @return a user object or null
+ */
+ UserModel getUserModel(String username);
+
+ /**
+ * 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%
+
## 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.
--
Gitblit v1.9.1