| | |
|---|
| | |
|
|---|
| | | ### How do I use it?
|
|---|
| | |
|
|---|
| | | Lucene indexing is an opt-in feature which means that no repositories are automatically indexed. |
|---|
| | | First you must ensure that *web.allowLuceneIndexing* is set *true* in `gitblit.properties` or `web.xml`. Then you must understand that Lucene indexing is an opt-in feature which means that no repositories are automatically indexed. |
|---|
| | | Like anything else, this design has pros and cons.
|
|---|
| | |
|
|---|
| | | #### Pros
|
|---|
| | | 1. no wasted cycles on repositories you will never search
|
|---|
| | | 1. no wasted cycles indexing repositories you will never search
|
|---|
| | | 2. you specify exactly what branches are indexed; experimental/dead/personal branches can be ignored
|
|---|
| | |
|
|---|
| | | #### Cons
|
|---|
| | | 1. you have to opt-in a repository _after_ it is created and has some commits
|
|---|
| | | 2. you specify exactly what branches are indexed
|
|---|
| | | 1. you specify exactly what branches are indexed
|
|---|
| | |
|
|---|
| | | #### I have 300 repositories and you want me to specify indexed branches on each one??
|
|---|
| | |
|
|---|
| | | Yeah, I agree that is inconvenient.
|
|---|
| | |
|
|---|
| | | If you are using Gitblit GO there is a utility script `add-indexed-branch.cmd` which allows you to specify an indexed branch for many repositories in one step.
|
|---|
| | |
|
|---|
| | | If you are using Gitblit WAR then, at present, you are out of luck unless you write your own script to traverse your repositories and use native Git to manipulate each repository config.
|
|---|
| | |
|
|---|
| | | git config --add gitblit.indexBranch "default"
|
|---|
| | | git config --add gitblit.indexBranch "refs/heads/master"
|
|---|
| | |
|
|---|
| | | #### Indexing Branches
|
|---|
| | | You may specify which branches should be indexed per-repository in the *Edit Repository* page. New/empty repositories may only specify the *default* branch which will resolve to whatever commit HEAD points to or the most recently updated branch if HEAD is unresolvable.
|
|---|
| | |
|
|---|
| | | Indexes are built and incrementally updated on a 2 minute cycle so you may have to wait a few minutes before your index is built or before your latest pushes get indexed.
|
|---|
| | |
|
|---|
| | | **NOTE:** |
|---|
| | | After specifying branches, only the content from those branches can be searched via Gitblit. Gitblit will automatically redirect any queries entered on a repository's search box to the Lucene search page. Repositories that do not specify any indexed branches will use the traditional commit-traversal search.
|
|---|
| | |
|
|---|
| | | #### Adequate Heap
|
|---|
| | |
|
|---|
| | | The initial indexing of an existing repository can potentially exhaust the memory allocated to your Java instance and may throw OutOfMemory exceptions. Be sure to provide your Gitblit server adequate heap space to index your repositories. The heap is set using the *-Xmx* JVM parameter in your Gitblit launch command (e.g. -Xmx1024M).
|
|---|
| | |
|
|---|
| | | #### Why does Gitblit check every 2 mins for repository/branch changes?
|
|---|
| | |
|
|---|
| | | Gitblit has to balance its design as a complete, integrated Git server and its utility as a repository viewer in an existing Git setup.
|
|---|
| | |
|
|---|
| | | Gitblit could build indexes immediately on *edit repository* or on *receiving pushes*, but that design would not work if someone is pushing via ssh://, git://, or file:// (i.e. not pushing to Gitblit http(s)://). For this reason Gitblit has a polling mechanism to check for ref changes every 2 mins. This design works well for all use cases, aside from adding a little lag in updating the index.
|
|---|
| | |
|
|---|
| | | #### Indexing Branches
|
|---|
| | | You may specify which branches should be indexed per-repository in the *Edit Repository* page. New/empty repositories can not pre-specify indexed branches; you can only specify indexed branches for a repository with commits. Indexes are built and incrementally updated on a 2 minute cycle so you may have to wait a few minutes before your index is built or before your latest pushes get indexed.
|
|---|
| | |
|
|---|
| | | **NOTE:** |
|---|
| | | After specifying branches, only the content from those branches can be searched via Gitblit. Gitblit will automatically redirect any queries entered on a repository's search box to the Lucene search page. Repositories that do not specify any indexed branches will use the traditional commit-traversal search.
|
|---|
| | |
|
|---|
| | | ## Client Setup and Configuration
|
|---|
| | | ### Https with Self-Signed Certificates
|
|---|
| | |
|---|
| | | <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> |
|---|
| | | <pre>https://username@yourserver/git/your/repository</pre>
|
|---|
| | |
|
|---|
| | | ## LDAP Support
|
|---|
| | | *SINCE 1.0.0*
|
|---|
| | |
|
|---|
| | | LDAP can be used with Gitblit to read Users and the Teams that they belong to. If configured, LDAP will be queried upon every login to the system, and synchronize that information with the traditional Gitblit backed file (.conf or .properties). This "lazy" reading approach provides for fast reaction times, but will force a user to log in before you can maintain them (or their teams).
|
|---|
| | |
|
|---|
| | | ### Example Diagram (with attributes)
|
|---|
| | | 
|
|---|
| | |
|
|---|
| | | Please see <gitblit>/tests/com/gitblit/tests/resources/ldapUserServiceSampleData.ldif to see the data in LDAP that reflects the above picture.
|
|---|
| | |
|
|---|
| | | ### GitBlit Properties (See gitblit.properties for full description)
|
|---|
| | | The following is are descriptions of the properties that would follow the sample layout of an LDAP (or Active Directory) setup above.
|
|---|
| | |
|
|---|
| | | <table border="1" cellpadding="1" cellspacing="1">
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.server</td><td>ldap://localhost:389</td>
|
|---|
| | | <td>Tells Gitblit to connect to the LDAP server on localhost, port 389. URL Must be of form ldap(s)://<server>:<port> with port being optional (389 for ldap, 636 for ldaps).</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.username</td><td>cn=Directory Manager</td>
|
|---|
| | | <td>The credentials that will log into this gitblit server</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.password</td><td>password</td>
|
|---|
| | | <td>The credentials that will log into this gitblit server</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.backingUserService</td><td>users.conf</td>
|
|---|
| | | <td>Where to store all information that is used by Gitblit. All information will be synced here upon user login.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.maintainTeams</td><td>true</td>
|
|---|
| | | <td>Are users maintained in LDAP (true), or manually in Gitblit (false).</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.accountBase</td><td>OU=Users,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
|
|---|
| | | <td>What is the root node for all users in this LDAP system. Searches will be subtree searches starting from this node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.accountPattern</td><td>(&(objectClass=person)(sAMAccountName=${username}))</td><td>The LDAP Search filter that will match a particular user in LDAP. ${username} will be replaced with whatever the user types in as their user name.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.groupBase</td><td>OU=Groups,OU=UserControl,OU=MyOrganization,DC=MyDomain</td>
|
|---|
| | | <td>What is the root node for all teams in this LDAP system. Searches will be subtree searches starting from this node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.groupMemberPattern</td><td>(&(objectClass=group)(member=${dn}))</td><td>The LDAP Search filter that will match all teams for the logging in user in LDAP. ${username} will be replaced with whatever the user types in as their user name. Anything else in ${} will be replaced by Attributes on the User node.</td>
|
|---|
| | | </tr>
|
|---|
| | | <tr>
|
|---|
| | | <td>realm.ldap.admins</td><td>@Git_Admins</td><td>A space delimited list of users and teams (if starting with @) that indicate admin status in Gitblit.</td>
|
|---|
| | | </tr>
|
|---|
| | | </table>
|
|---|
| | |
|
|---|
| | | You may notice that there are no properties to find the password on the User record. This is intentional, and the service utilizes the LDAP login process to verify that the user credentials are correct.
|
|---|
| | |
|
|---|
| | | You can also start Gitblit GO with an in-memory (backed by an LDIF file) LDAP server by using the --ldapLdifFile property. It will listen where ever gitblit.settings is pointed to. However, it only supports ldap...not ldaps, so be sure to set that in gitblit.settings. It reads the user / password in gitblit.settings to create the root user login.
|
|---|
| | |
|
|---|
| | | Finally, writing back to LDAP is not implemented at this time, so do not worry about corrupting your corporate LDAP. Many orgnizations are likely to go through a different flow to update their LDAP, so it's unlikely that this will become a feature. |
|---|
