WEB-INF/users.properties file to a location outside the webapps folder that is accessible by your servlet container.web.xml file.web.xml in your favorite text editor and make sure to review and set:
users.properties)gitblit.properties in your favorite text editor and make sure to review and set:
gitblit.cmd or java -jar gitblit.jar from a command-lineGitblit GO automatically generates an ssl certificate for you that is bound to localhost.
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:
Cannot get remote repository refs.
Reason: https:/myserver.com/git/myrepo.git: cannot open git-upload-pack
If you want to serve your repositories to another machine over https then you will want to generate your own certificate.
makekeystore.cmd or makekeystore_jdk.cmdNOTE:
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.
Gitblit uses Apache Commons Daemon to install and configure its Windows service.
installService.cmdAfter service installation you can use the gitblitw.exe utility to control and modify the runtime settings of the service.
Additional service definition options and runtime capabilities of gitblitw.exe (prunmgr.exe) are documented here.
NOTE:
If you change the name of the service from gitblit you must also change the name of gitblitw.exe to match the new service name otherwise the connection between the service and the utility is lost, at least to double-click execution.
By default, the service installation script configures your Windows service to use your default JVM. This setup usually defaults to a client VM.
If you have installed a JDK, you might consider using the gitblitw.exe utility to manually specify the server VM.
gitblitw.exe... button
Java Virtual Machine:
C:\Program Files\Java\jre6\bin\server\jvm.dll
Command-Line parameters override the values in gitblit.properties at runtime.
--repositoriesFolder Git Repositories Folder
--userService Authentication and Authorization Service (filename or fully qualified classname)
--useNio Use NIO Connector else use Socket Connector.
--httpPort HTTP port for to serve. (port <= 0 will disable this connector)
--httpsPort HTTPS port to serve. (port <= 0 will disable this connector)
--storePassword Password for SSL (https) keystore.
--shutdownPort Port for Shutdown Monitor to listen on. (port <= 0 will disable this monitor)
--tempFolder Folder for server to extract built-in webapp
Example
java -jar gitblit.jar --userService c:\myrealm.properties --storePassword something
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.
web.xml fileweb.xml file with your backupgitblit.properties fileusers.properties file (if it is located in the Gitblit GO folder)gitblit.properties file with your backupusers.properties file with your backup (if it was located in the Gitblit GO folder)You may need to delete your old service definition and install a new one depending on what has changed in the release.
Repositories can be created, edited, renamed, and deleted through the web UI. They may also be created, edited, and deleted from the command-line using real Git or your favorite file manager and text editor.
All repository settings are stored within the repository .git/config file under the gitblit section.
[gitblit]
description = master repository
owner = james
useTickets = false
useDocs = true
showRemoteBranches = false
accessRestriction = clone
isFrozen = false
showReadme = false
federationStrategy = FEDERATE_THIS
isFederated = false
skipSizeCalculation = false
federationSets =
Repository names must be unique and are CASE-SENSITIVE ON CASE-SENSITIVE FILESYSTEMS. The name must be composed of letters, digits, or / _ - .
Whitespace is illegal.
Repositories can be grouped within subfolders. e.g. libraries/mycoollib.git and libraries/myotherlib.git
All repositories created with Gitblit are bare and will automatically have .git appended to the name at creation time, if not already specified.
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.
All users are stored in the users.properties file or in the file you specified in gitblit.properties.
The format of users.properties follows Jetty's convention for HashRealms:
username,password,role1,role2,role3...
Usernames must be unique and are case-insensitive.
Whitespace is illegal.
User passwords are CASE-SENSITIVE and may be plain, md5, or combined-md5 formatted (see gitblit.properties -> realm.passwordStorage).
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.
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.
Your user service class must be on Gitblit's classpath and must have a public default constructor.
%BEGINCODE%
public interface IUserService {
/**
* 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();
/**
* 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%
You must tell Git/JGit not to verify the self-signed certificate in order to perform any remote Git operations.
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.
Key = http.sslVerify Value = false
git config --global --bool --add http.sslVerify false
https://yourserver/git/your/repository
https://username@yourserver/git/your/repository