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. We will be using the following systems in these examples:
repohost- this system will be running gitolite under thereposuser account and will house git repositories for meta-repo and kits so that they are stored at a handy central location. If you are going to be using your dev workstation as your "repohost", you can simply replace all references torepohostwithlocalhostbelow :)ryzen- in these examples, this will be the primary development workstation, which will be used for editing cloned git code as well as generating custom kits. Once generated, the custom meta-repo and kits are pushed up torepohost.
When you follow this guide, it is certainly possible to have repohost and ryzen be the same computer. If you set things up this way, simply use localhost instead of repohost in all command-line steps and configuration files.
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 on your LAN, first choose a system that will be used to house your meta-repo and kits git repositories. You can do this on the same system you will be using for testing (and even development), or you can set it up on a dedicated system. It's actually fine to set this up anywhere on the Internet, as git will use ssh to access this repository, but for the purposes of this article, we're assuming you're setting it up somewhere on your LAN. We will refer to this system as repohost.
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 on repohost 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 to the end of 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 my development workstation ryzen, so I will copy my ssh public key from ~/.ssh/id_rsa.pub to /var/tmp/ryzen-drobbins.pub on the gitolite system, and then perform the following steps to "prime" gitolite with this admin public key:
user $ gitolite setup -pk /var/tmp/ryzen-drobbins.pub
Gitolite will now be initialized to recognize the drobbins remote account as an administrator, which will allow this remote account to clone from repos@repohost: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 on repohost! From this point forward, we will be using the drobbins (or equivalent) account on your development workstation to configure gitolite remotely.
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 on repohost, we can do everything else remotely. I am going to use the drobbins account on my development workstation ryzen, and you will use whatever account is associated with the public key you loaded into gitolite. I like storing my development repos in /var/src on ryzen, 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 /var/src user $ git clone repos@repohost: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 on ryzen, this system will need to have permissions to create repositories in gitolite. Although I do my regular development as the drobbins user, I will be running the meta-repo generating script on ryzen as root, so the root user on ryzen needs to be granted access to gitolite. I would typically do this on ryzen as follows. First, as root, grab root's public ssh key:
root # cp /root/.ssh/id_rsa.pub /var/tmp
If /root/.ssh/id_rsa.pub doesn't exist, you can create it by typing ssh-keygen -t rsa as root and specifying no passphrase for encryption.
Then, as my regular drobbins user that I typically use to perform development, I will install root's public key in my cloned gitolite repository. This is the first step to grant
the ryzen root user direct access to gitolite:
user $ cd /var/src/gitolite-admin user $ cp /var/tmp/id_rsa.pub keydir/ryzen-root.pub user $ git add keydir/*
It's important to change the filename of the public keys you are adding to the gitolite-admin repository. I typically use the format host-user.pub.
Now, 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.
@drobbins = ryzen-drobbins
@repomgr = ryzen-root
# To enable read-only access to your meta-repo and kits, use this along with
# commented-out line under wildrepo. You will need to add box1-root.pub and
# box2-root.pub to keydir/ as well. This is good for boxes that will be testing
# your meta-repo and kits only but should not be able to modify them.
#@reporead = box1-root box2-root
# repositories:
# SPECIAL ADMIN REPO BELOW -- modify with care! I've switched over to using the @drobbins group instead of
# referencing the individual ryzen-drobbins key directly.
repo gitolite-admin
RW+ = @drobbins
# 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 = @repomgr
RW+ = @repomgr @drobbins
# NOTE: to enable read-only access for certain boxes, uncomment this line:
# R = @reporead
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
This section is somewhat out-of-date and is in the process of being updated. The current tool used for generating meta-repo is metatools, setup of which is documented here. Because metatools was based on merge-scripts, the configuration is nearly identical and besides initial setup of metatools, the following instructions should generally apply.
Now that merge-scripts is cloned, we will need to create a ~/.merge configuration file. Here is an example file that can serve as a starting point. In this example, developer bcowan has forked the kit-fixups repository on code.funtoo.org, and wants to test his personal changes by generating a complete meta-repo of his own:
/root/.merge [sources]
flora = https://code.funtoo.org/bitbucket/scm/co/flora.git
kit-fixups = ssh://git@code.funtoo.org:7999/~bcowan/kit-fixups.git
gentoo-staging = https://code.funtoo.org/bitbucket/scm/auto/gentoo-staging.git
[destinations]
base_url = repos@repohost:wildrepo/staging
[branches]
flora = master
kit-fixups = master
meta-repo = master
Sources Section
Let's walk through this configuration file. The [sources] section defines locations of repositories that the merge scripts will use as sources for creating kits and meta-repo. In the above sample config, we are using the official Flora repository from Funtoo, and the official gentoo-staging repository used by Funtoo, but we are using our own fork of kit-fixups, which will allow us to add new ebuilds that will appear in kits, such as bug fixes to existing ebuilds in kits, as well as security fixes. For a core Funtoo Linux developer, this is a good way to start. If you are more interested in contributing third-party ebuilds, then you may instead choose to create your own fork of flora, and use our standard kit-fixups repository. Or, you could choose to create forks of both. The recommended best practice is to use our upstream repos when possible, and fork only those repos you want to customize. This way, you'll ensure that you have the most up-to-date versions of ebuilds in those unforked repos.
Branches Section
The [branches] section is used to define the default branches that are used by the merge-scripts. In general, sticking with master is fine, but if you need the flexibility, you can point the merge scripts to a particular feature branch to use instead, for example.
Work Section
The [work] section is used to define paths where the merge-scripts will do their work. The source and destination settings above are good defaults, and define where the merge-scripts will clone source repositories and destination (written to) repositories, such as kits and meta-repo. These are kept in two separate hierarchies so they don't get mixed up.
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 stored on repohost. Here are the steps you'd perform:
root # merge-kits 1.4-release
Before starting the script for the first time, you should emerge jinja and configure your git user.name and user.email variables.
root # emerge -u jinja root # git config --global user.email "you@example.com" root # git config --global user.name "Your Name"
merge-all-kits will proceed to create new kits and meta-repo, and will push them up to repos@repohost:wildrepo/staging/meta-repo, repos@repohost:wildrepo/staging/core-kit, etc. This process can take quite a while but has been optimized to run quickly on multi-core systems.
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 = root
sync_base_url = repos@repohost: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...
You will want to make sure that whatever system is connecting to repohost is permitted by gitolite, and has its /root/.ssh/id_rsa.pub file stored and committed to the gitolite-admin repository's keydir/ and is referenced in conf/gitolite.conf. Otherwise, gitolite will not allow this system to connect. Of course, if you are configuring this on the system that's running merge-all-kits.py, it already has RW permissions to these repositories. Otherwise, you will want to make sure that gitolite has the system's keys as part of its @reporead group.
We change the sync_user to root to force ego sync to use /root/.ssh/id_rsa for authentication. By default, ego sync will attempt to use the portage user which does not have a private key installed, and thus will not be able to authenticate with gitolite. Rather than mess with the portage user and give it a proper home directory and ssh key pair, it's easier just to not drop perms to portage in the first place.
Now, let's 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 # ego sync Syncing xorg-kit branch 1.20-release Cloning into '/var/git/meta-repo/kits/xorg-kit'... Initialized empty Git repository in /home/repos/repositories/wildrepo/staging/xorg-kit.git/ fatal: Remote branch 1.20-release not found in upstream origin root ##r##ERROR: Could not clone kit 'xorg-kit' into '/var/git/meta-repo/kits/xorg-kit'. fatal: the remote end hung up unexpectedly
Ego will now sync your custom repository, but it will fail.. This is OK -- it is failing because gitolite does not have local copies of independently-maintained (ie. not auto-generated) kits. To fix this, you can either create mirrors of the independent kits on your gitolite, or alternatively perform this simple work-around. Go to https://code.funtoo.org/bitbucket/projects/INDY and for each kit listed there, clone to /var/git/meta-repo/kits as root, as follows:
root # cd /var/git/meta-repo/kits root # git clone https://code.funtoo.org/bitbucket/scm/indy/gnome-kit.git root # git clone https://code.funtoo.org/bitbucket/scm/indy/python-kit.git ... etc ...
Once this is complete, try an ego sync again, and with local copies of the independent kits it should all work:
root # ego sync --in-place ... root ##g##Sync successful and kits in alignment! :) Updating /etc/portage/repos.conf... Updating profiles at /etc/portage/make.profile/parent...
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-all-kits.py 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. To do this, first set up metro on your system:
root # cd /root root # git clone https://code.funtoo.org/bitbucket/scm/core/metro.git root # cd metro root # scripts/autosetup
Now, we will set the ego, administration tool of Funtoo/Linux. The way it is used with metro is independent from app-admin/ego installed on your box. Setup is easy as follows:
root # cd /root root # git clone https://code.funtoo.org/bitbucket/scm/core/ego.git
This way you will have /root/ego directory with ego binary that is then used by metro.
After following the interactive prompts, you'll then want to perform the following steps to install an ego.conf for use by metro:
root # install -d /etc/metro/chroot/etc root # vim /etc/metro/chroot/etc/ego.conf
To ensure that ego uses your custom local meta-repo, you'll want to ensure that the following lines are in your /etc/metro/chroot/etc/ego.conf:
[global]
sync_user = root
sync_base_url = repos@repohost:wildrepo/staging/{repo}
Without these ego options, metro will use the official meta-repo instead of your local custom meta-repo. Of course, be sure to specify any custom kit branches to use as well.
Once your ego.conf is installed, you can perform a metro build with something similar to the following commands:
root # cd /root/metro root # scripts/ezbuild.sh funtoo-current x86-64bit intel64-haswell full
For a full continuous integration loop, which includes regeneration of new meta-repo contents, the following script can be used:
#!/bin/bash
/root/merge-scripts/bin/merge-all-kits push
rm /home/mirror/funtoo/funtoo-current/snapshots/portage-*
/root/metro/scripts/ezbuild.sh funtoo-current x86-64bit intel64-haswell full
The extra "rm" command is included to clean out any previous daily snapshots, to force metro to regenerate snapshots. Otherwise, any existing daily portage snapshots will be used and new ones will not be generated.
If you are "switching back and forth" between different versions of kits, it may be necessary to wipe metro's binary package cache to avoid build failures caused by emerge trying to install binary packages built for a different environment. A symptom of a package cache needing to be wiped out are builds failing because they depend on a masked slot/subslot combination (and emerge asking you to remove a mask.) In this case, you will want to recursively remove the contents of /var/tmp/metro/cache/package-cache. For periodic updates of a consistent set of kits, this is typically not necessary.