Gitblit从一个服务器，迁移到另外一个服务器

http://gitblit.com/federation.html

A Gitblit federation is a mechanism to clone repositories and keep them in sync from one Gitblit instance to another.

Federation can be used

to maintain a mirror of your Gitblit instance,

to aggregate使聚集 repositories from developer workstations,

or to initially clone groups of repositories to developer workstations.

If you are/were a Subversion user you might think of this as svn-sync, but better.

If your Gitblit instance allows federation and it is properly registered with another Gitblit instance, each of the non-excluded repositories of your Gitblit instance can be mirrored, in their entirety, to the pulling Gitblit instance.

You may optionally allow pulling of user accounts and backup of server settings.

The federation feature should be considered a security backdoor and enabled or disabled as appropriate for your installation.
Please review all the documentation to understand how it works and its limitations.

Important Changes to Note

The Gitblit 0.8.0 federation protocol adds retrieval of teams and referenced push scripts. Older clients will not know to request team or push script information.

The Gitblit 0.7.0 federation protocol is incompatible with the 0.6.0 federation protocol because of a change in the way timestamps are formatted.

Gitblit 0.6.0 uses the default google-gson timestamp serializer which generates locally formatted timestamps.

Unfortunately, this creates problems for distributed repositories and distributed developers.

Gitblit 0.7.0 corrects this error by serializing dates to the iso8601 standard.

As a result 0.7.0 is not compatible with 0.6.0.

A partial backwards-compatibility fallback was considered but it would only work one direction and since the federation mechanism is bidirectional it was not implemented.

Origin Gitblit Instance Requirements

• git.enableGitServlet must be true, all Git clone and pull requests are handled through Gitblit's JGit servlet
• federation.passphrase must be non-empty
• The Gitblit origin instance must be http/https accessible by the pulling Gitblit instance.
  That may require configuring port-forwarding on your router and/or opening ports on your firewall.

federation.passphrase(用来生成共享的token，并非将它提供给其他人[区分大小写])

The passphrase is used to generate permission tokens that can be shared with other Gitblit instances.

The passphrase value never needs to be shared, although if you give another Gitblit instance the ALL federation token then your passphrase will be transferred/backed-up along with all other server settings.

This value can be anything you want: an integer, a sentence, an haiku俳句, etc.

You should probably keep the passphrase simple and use standard Latin characters to prevent Java properties file encoding errors.

The tokens generated from this value are affected by case, so consider this value CASE-SENSITIVE.

The federation feature is completely disabled if your passphrase value is empty.

NOTE:
Changing your federation.passphrase will break any registrations you have established with other Gitblit instances.

Pulling Gitblit Instance Requirements

• consider setting federation.allowProposals=true to facilitate使容易 the registration process from origin Gitblit instances
• properly registered Gitblit instance including, at a minimum, url, federation token, and update frequency

Controlling What Gets Pulled  [需要将源Gitblit的url和token提供给pulling的Gitblit，token可以在日志以及webui中找到]

If you want your repositories (and optionally users accounts and settings) to be pulled by another Gitblit instance,

you need to register your origin Gitblit instance with a pulling Gitblit instance by providing the url of your Gitblit instance and a federation token.

Gitblit generates the following standard federation tokens:

String allToken = SHA1(passphrase + "-ALL");
String usersAndRepositoriesToken = SHA1(passphrase + "-USERS_AND_REPOSITORIES");
String repositoriesToken = SHA1(passphrase + "-REPOSITORIES");

The ALL token allows another Gitblit instance to pull all your repositories, user accounts, server settings, and referenced push scripts.
The USERS_AND_REPOSITORIES token allows another Gitblit instance to pull all your repositories and user accounts.
The REPOSITORIES token only allows pulling of the repositories.

Individual Gitblit repository configurations such as description and accessRestriction are always mirrored.

If federation.passphrase has a non-empty value,

the federation tokens

are displayed in the log file

and are visible, to administrators, in the web ui.

在日志里可以找到

2017-05-20 16:21:09 [INFO ] Federation ALL token = 519c5f7dedfd8a5d52845e2e3ddfbbeab1343f03
2017-05-20 16:21:09 [INFO ] Federation USERS_AND_REPOSITORIES token = 30ff1e40ced5f48d33a9f4336f6d4b1d482b4420
2017-05-20 16:21:09 [INFO ] Federation REPOSITORIES token = 7ab4adcc149a3785d36cfaddafb6b24ae1956d61

The three standard tokens grant access to ALL your non-excluded repositories.

However, if you only want to specify different groups of repositories to be federated then you need to define federation sets.

Federation Sets

Federation Sets (*federation.sets*) are named groups of repositories.

The Federation Sets are defined in gitblit.properties and are available for selection in the repository settings page.

You can assign a repository to one or more sets and then distribute the federation token for the set.

This allows you to grant federation pull access to a subset of your available repositories.

Tokens for federation sets only grant pull access for the member repositories.

Gitblit的编辑界面，有一个是针对federation的

 

# Federation pull registrations
# Registrations are read once, at startup.
#
# RESTART REQUIRED
#
# frequency:
# The shortest frequency allowed is every 5 minutes
# Decimal frequency values are cast to integers
# Frequency values may be specified in mins, hours, or days
# Values that can not be parsed or are unspecified default to *federation.defaultFrequency*
#
# folder:
# if unspecified, the folder is *git.repositoriesFolder*
# if specified, the folder is relative to *git.repositoriesFolder*
#
# bare:
# if true, each repository will be created as a *bare* repository and will not
# have a working directory.
#
# if false, each repository will be created as a normal repository suitable
# for local work.
#
# mirror:
# if true, each repository HEAD is reset to *origin/master* after each pull.
# The repository will be flagged *isFrozen* after the initial clone.
#
# if false, each repository HEAD will point to the FETCH_HEAD of the initial
# clone from the origin until pushed to or otherwise manipulated.
#
# mergeAccounts:
# if true, remote accounts and their permissions are merged into your
# users.properties file
#
# notifyOnError:
# if true and the mail configuration is properly set, administrators will be
# notified by email of pull failures
#
# include and exclude:
# Space-delimited list of repositories to include or exclude from pull
# may be * wildcard to include or exclude all
# may use fuzzy match (e.g. org.eclipse.*)

#
# (Nearly) Perfect Mirror example
#

#federation.example1.url = https://go.gitblit.com
#federation.example1.token = 6f3b8a24bf970f17289b234284c94f43eb42f0e4
#federation.example1.frequency = 120 mins
#federation.example1.folder =
#federation.example1.bare = true
#federation.example1.mirror = true
#federation.example1.mergeAccounts = true

Federation Proposals (Origin Gitblit Instance)

Once you have properly setup your passphrase and can see your federation tokens, you are ready to share them with a pulling Gitblit instance.

The registration process can be partially automated by sending a federation proposal to the pulling Gitblit instance.
To send a proposal:

1. Login to your Gitblit instance as an administrator
2. Select and click the propose link for the appropriate token on the federation page
3. Confirm the publicly accessible url of your (origin) Gitblit instance
4. Enter the url of the pulling Gitblit instance you want to federate with
5. Optionally enter a message for the administrators
6. Click propose

Not all Gitblit instances accept federation proposals, there is a setting which allows Gitblit to outright reject them. In this case an email or instant message to the administrator of the other Gitblit instance is required. :)

If your proposal is accepted, the proposal is cached to disk on the pulling Gitblit server and, if properly configured, the administrators of that Gitblit server will receive an email notification of your proposal.

Your proposal includes:

1. the url of your Gitblit instance
2. the federation token you selected and its type
3. the list of your non-excluded repositories, and their configuration details, that you propose to share

Submitting a proposal does not automatically register your server with the pulling Gitblit instance.
Registration is a manual process for an administrator.

 

 

 总结：

第一步：在origin的Gitblit中设置git.enableGitServlet=true;【默认为true】

           并且federation.passphrase设置为非空的值;【默认是空】

           同时确保打开了http/https

第二步：federation.allowProposals=true