The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.
Funtoo:Metatools/Advanced Usage/Gitolite Setup
Overview
For our local development setup, we will be using gitolite. Gitolite will make things quite a bit easier by managing git repositories for us. Think of gitolite as your own private GitHub that has no Web user interface (we modify its settings by pushing to its special gitolite-admin repo) and you'll have a pretty good idea of what gitolite does. To keep things simple, we will be using a single development system in our setup example below. However, because gitolite can be accessed over the network, you can easily set up gitolite on another system on your LAN or a remote system on the Internet and securely access it simply by modifying the git URL.
This document assumes you have basic knowledge of ssh-keygen and how to generate public/private SSH key pairs. If you don't know how to to this, see Generating SSH Keys for quick steps or OpenSSH Key Management, Part 1 for a more detailed introduction. For this article, you'll probably want to generate a private keys without a passphrase, which is more convenient but a much greater security risk if the private key gets compromised, or one with a passphrase but using keychain to manage ssh-agent for you.
Gitolite
Installation
To set up gitolite, we will use a repos user on your local development system. On this system, perform the following steps as root:
repohost # useradd -m repos
The repos user will be a dedicated user account on the system that will have gitolite enabled and will house our git repositories. Now, we are going to su to this new user and perform gitolite configuration:
repohost # su --login repos user $ git clone https://github.com/sitaramc/gitolite user $ install -d ~/bin
Now, as the repos user, add the following within your ~/.bashrc file:
~/.bashrc export PATH=$HOME/bin:$PATH
What we're doing is setting up a bin directory where the gitolite command will be installed, which will be in your path, so that you can use it more easily. With this done, perform the following steps:
user $ source ~/.bashrc user $ gitolite/install -ln
Now, your repos account is almost ready to be used for hosting repositories. The way gitolite works is that it is going to basically take over ssh access to the account, so that when you connect via ssh with git, it will perform its own authentication. For this to work, you will need to enable your own "master key" to access gitolite.
To do this, you'll want to decide from which account you'll want to administer gitolite itself. I prefer to use my "drobbins" account on local system, so I will copy my ssh public key from ~/.ssh/id_ed25519.pub to /var/tmp/drobbins.pub, and then perform the following steps to "prime" gitolite with this admin public key -- do this as the repos user:
user $ gitolite setup -pk /var/tmp/drobbins.pub
Gitolite will now be initialized to recognize the drobbins account as an administrator, which will allow this account to clone from repos@localhost:gitolite-admin and push any changes to this special git repository which contains the master configuration for gitolite. This is important because we will be performing the rest of gitolite setup over ssh, using this account.
OK, gitolite is installed! From this point forward, we will be using the drobbins (or equivalent) account on your development workstation to configure gitolite.
If you are setting up gitolite on a separate server, and assuming you have ssh properly configured, it would be prudent at this point to test the connection to the remote server from your local workstation . Perform ssh -T, or ssh test command appropriate to your setup, as shown below to verify you can connect:
user $ ssh -T repos@remote-server-name
You should receive confirmation message similar to:
hello repos, this is repos@remote-server-name running gitolite3 v3.6.11-3-g39293e6 on git 2.19.1 R W gitolite-admin R W testing
If you receive the following message during testing:
perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), ...
then localization settings for the remote server have not been completed. If remote server is Funtoo-based, complete the steps on the page Funtoo Linux Localization on the remote server.
gitolite-admin Clone
Now that gitolite is ready under the repos user on your local system, we can configure the rest by cloning the gitolite-admin repo and commiting configuration changes to it. I am going to use the drobbins account on the same system to do this, and you will use whatever account is associated with the public key you loaded into gitolite. I like storing my development repos in ~/development , so I'll go ahead and clone the gitolite-admin repo to that location so it can live along all my other git repos. Feel free to put this git repo wherever you like to store git repos that you develop on:
user $ cd ~/development user $ git clone repos@localhost:gitolite-admin user $ cd gitolite-admin
We are now ready to configure gitolite. We'll do this by modifying conf/gitolite.conf in the git repo and adding new ssh public keys to keydir/ as needed. You will see that the initial public key you used to "prime" gitolite already exists in keydir/. Once we change the configuration, and potentially add new public ssh keys that we want to grant access to gitolite-managed repositories, we'll perform a git commit and git push, and if gitolite doesn't complain about our changes, they'll take effect immediately. We'll go through our initial configuration steps below.
gitolite Configuration
Since I will be generating meta-repo and kits using my drobbins user, this account will need to have permissions to create repositories in gitolite.
We're ready to edit conf/gitolite.conf so that it looks like this:
gitolite.conf # Group definitions below, starting with @. This makes it easy to associate multiple ssh keys with a particular person.
# Admins will have full control over gitolite.
@admins = drobbins
# Developers will be able to create, read and write git repositories.
@developers = drobbins
# Users will have read-only access.
@users = drobbins
# repositories:
# SPECIAL ADMIN REPO BELOW -- modify with care!
repo gitolite-admin
RW+ = @admins
# AUTO-CREATED (wild) REPOS: gitolite will auto-create repos under wildrepo/ for us
# upon initial clone of any path within, if the repo doesn't already exist.
repo wildrepo/..*
C = @developers
RW+ = @developers
R = @developers @users
Now, we will want to commit and push our changes in the gitolite repo so they take effect -- This is how gitolite configuration changes are applied:
user $ git add . user $ git commit -a -m "Initial setup" user $ git push Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 12 threads Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 607 bytes
Configuration
Now, as your own user account, on your development system (which could be the same Funtoo system), you will want to emerge metatools or use git to clone the master branch of metatools. Here's how we would use the master branch:
user $ emerge --onlydeps metatools user $ mkdir development user $ cd development user $ git clone https://code.funtoo.org/bitbucket/scm/~drobbins/funtoo-metatools.git
If using the git master version, you will need to add the following to your ~/.bashrc :
export PYTHONPATH=~/development/funtoo-metatools
export PATH=~/development/funtoo-metatools:$PATH
Create Your Own Kit-Fixups
You will now want to clone kit-fixups from code.funtoo.org, and create a commit that updates ~/kit-fixups/releases/next/repositories.yaml to adjust the remotes as follows:
releases/next/repositories.yaml (yaml source code) # Have all of our remote configurations defined in one place for ease of maintenance
remotes:
dev:
url: repos@gitolitehost:wildrepo/staging/{repo}
prod:
url: repos@gitolitehost:wildrepo/staging/{repo}
Push this commit up to your personal kit-fixups.
Generating New Kits
With this all configured, you are ready to generate new kits. These kits will be generated as root on your development system, and will be pushed up to repos@localhost/staging/repo_name. The next is the release of Funtoo.
user $ merge-kits next --prod --fixups_url=ssh://git@code.funtoo.org:7999/myusername/kit-fixups.git --create_branches
merge-kits will proceed to create new kits and meta-repo, and will push them up to repos@localhost:wildrepo/staging/meta-repo, repos@localhost:wildrepo/staging/core-kit, etc. This process can take quite a while but has been optimized to run quickly on multi-core systems and use caching extensively so successive runs will complete quickly.
Using New Kits
Now that the new meta-repo and kits are created, here's how you'll use them on an existing Funtoo system, instead of your official Funtoo meta-repo and kits. First, we'll want to modify /etc/ego.conf as follows:
/etc/ego.conf [global]
sync_user = drobbins
sync_base_url = repos@gitolitehost:wildrepo/staging/{repo}
# Yes, you are supposed to have a literal "{repo}", above. Ego recognizes this special pattern.
# You can have whatever [kits] section you want, below...
Since we are syncing as a regular user, we will need to make sure that our user account is in the portage group and that /var/git is writable by, in this case, drobbins:
root # chmod g+rwx /var/git
Let's also move the current meta-repo out of the way -- you can also simply delete the existing meta-repo. And then we'll re-run ego sync:
root # cd /var/git root # mv meta-repo meta-repo.official root # exit user $ ego sync Running as regular user. Syncing meta-repo Cloning into '/var/git/meta-repo'... X11 forwarding request failed on channel 0 remote: Enumerating objects: 13, done. remote: Counting objects: 100% (13/13), done. remote: Compressing objects: 100% (11/11), done. remote: Total 13 (delta 1), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (13/13), done. Resolving deltas: 100% (1/1), done. Syncing browser-kit branch 1.4-release
If you type emerge -auDN @world, ego will now be using your custom kits, rather than the official Funtoo ones. This means that you can perform a variety of things you couldn't before. You can now add your own custom ebuilds to your fork of kit-fixups, and merge-kits will automatically incorporate these changes into your own custom kits. This will allow you to locally test any changes before submitting them as pull requests to Funtoo. You will also be able to maintain your own meta-repo and kits with your own local modifications, and have your systems use these meta-repo/kits instead of the official Funtoo ones.
Using New Kits with Metro
Rather than using new kits on a local Funtoo Linux system, you may want to use the kits to perform a metro build. This is desirable when you may want to use metro to perform continuous integration by attempting to perform a full stage1, 2 and 3 build, which is what the steps in this example accomplish, or simply test some hypothetical changes to the tree before creating a PR. Let's look at how to do this.
First, since metro runs as root, you will need to ensure that the root user on your local system has read access to gitolite. Perform the following steps:
root # cp /root/.ssh/id_ed25519.pub /var/tmp/root.pub root # exit user $ cd ~/development/gitolite-admin/keydir user $ cp /var/tmp/root.pub . user $ git add *
Now, give the root.pub key the ability to have read-only access to the repository (showing only the changes required):
~/development/gitolite-admin/conf/gitolite.conf @users = drobbins root
Now, commit changes:
user $ git add . user $ git commit -a -m "gitolite config updates"
Now, the root user, which is used by Metro to perform the ego sync, should be able to connect to the repository.
Next, we will want to instruct Metro to grab the custom meta-repo instead of the official one. To do this, first set up Metro on your system.
Then, prior to running metro, set the EGO_SYNC_BASE_URL in your environment as follows:
root # export EGO_SYNC_BASE_URL="repos@localhost:wildrepo/staging/{repo}"
Metro should grab these settings and automatically adjust the ego.conf it uses based on these settings, to grab your meta-repo instead of the official one. You should now be able to perform
local or CI testing of your changes. It's always a good idea to put this setting in ~/.bashrc of a CI user account so that it is always set correctly.