In recent months I have spent more of my time working on projects immediately above/related to the core libvirt library, such as libvirt-glib, libosinfo and virt-sandbox. To that list I have now added OpenStack, where my goal is to ensure that the libvirt driver is following all the best practices and start to take advantage of libosinfo for optimizing virtual hardware configuration. I’m familiar with hacking on python so that’s no big issue, but what is new about OpenStack is dealing with Gerrit. For the sake of reference, here were the steps I went through on Fedora 16 for my first patch (a tweak to the tools/install_venv.sh file)
- Get the initial Nova GIT checkout
$ mkdir $HOME/src/cloud
$ cd $HOME/src/cloud
$ git clone git://github.com/openstack/nova.git
$ cd nova
- Install some basic pre-reqs, and ensure python-distutils-extra is not present since that conflicts with part of the openstack build system
$ sudo yum install gcc python-pep8 python-virtualenv m2crypto libvirt libvirt-python libxslt-devel libxml2-devel
$ sudo yum remove python-distutils-extra
- Visit the OpenStack Gerrit Website, and follow ‘Sign In’ link which redirects to LaunchPad for authentication
- Back on Gerrit site, now signed in, follow ‘Settings’ link, select ‘SSH Public Keys’ page, and paste your SSH public key (eg contents of
$HOME/.ssh/id_rsa.pub)
- Test SSH connectivity from the CLI
$ ssh -p 29418 berrange@review.openstack.org
The authenticity of host '[review.openstack.org]:29418 ([173.203.103.119]:29418)' can't be established.
RSA key fingerprint is ee:2f:ac:1b:f8:25:d0:39:be:55:02:c7:76:5e:39:53.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[review.openstack.org]:29418,[173.203.103.119]:29418' (RSA) to the list of known hosts.
**** Welcome to Gerrit Code Review ****
Hi Daniel Berrange, you have successfully connected over SSH.
Unfortunately, interactive shells are disabled.
To clone a hosted Git repository, use:
git clone ssh://berrange@review.openstack.org:29418/REPOSITORY_NAME.git
Connection to review.openstack.org closed.
- Install commit hook to ensure ‘ChangeId’ fields get added to your commits
$ scp -p -P 29418 berrange@review.openstack.org:hooks/commit-msg .git/hooks/
- Add the gerrit remote to GIT config
$ git remote add gerrit ssh://berrange@review.openstack.org:29418/openstack/nova.git
- Start a new branch for your work
$ git checkout -b venv-install-fixes
- Make whatever code changes you need todo
$ vi tools/virtual_venv.py
$ git add -u
(Don't forget to add yourself to Authors if this is your first change)
- Commit the changes, checking the commit message gets a ‘Change-Id’ line added just prior to the signed-off-by line
$ git commit -s
$ git show
commit fd682a28fb4591c65f20129d4bfb4eccf1232cb8
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Thu Jan 5 13:15:15 2012 +0000
Tell users what is about to be installed via sudo
Rather than just giving users the sudo password prompt immediately,
actually tell them what is about to be installed, so they know what
privileged action is being attempted.
Change-Id: Ic0c1de812be119384753895531a008075b13494e
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
If the commit is fixing a OpenStack bug, then the commit message should include a line “BugXXXX” where XXXX is the bug number. Gerrit uses this to link to the bug tracker
- Run the unit test suite, and the python pep8 syntax test suite; Be prepared to wait a long time
$ ./run_tests.sh
$ ./run_tests.sh --pep8
- Send the changes to Gerrit for review
$ git push gerrit HEAD:refs/for/master
- Wait for email notifications of review, or watch the OpenStack Gerrit Website.
- If problems are found by reviewers, or the automated smoke stack tests. Repeat steps 9->l;12, but use ‘git commit –amend’ to ensure you preserve the original “Change-Id” line in the commit message. This lets gerrit track followup patches.
- If everything passes review & testing, it will be automatically merged into master.
There is also a GIT plugin “git review” available in the git-review RPM, which can provide syntactic sugar for step 12, but personally I don’t find it adds significant value to be worth my while using.
I can see the attraction of Gerrit, but I personally still prefer the practice of using git send-email for reviewing on mailing lists. My problems with Gerrit are
- The email notifications sent out for new patches are almost worse than useless as an information source
- While very pretty, the web UI for browsing the diffs is really quite cumbersome to use
- Poor support for reviewing large patch series
- Use of merge commits makes navigating GIT history cumbersome, forcing the use of the graphical gitk viewer tool
I am pleased to announce a new release 0.3.1 of Entangle, a GTK3 desktop application for tethered camera control & capture, is available for download from the usual location. This release has focused exclusively on bug fixing following the major refactoring that went into the previous release. If you were having trouble with the previous release crashing, then I hope this new one should improve things significantly.
- Fix crash in handling camera control combo list
- Add notice about need to set XDG_DATA_DIRS when installing into unusual directories
- Add workaround to avoid immediate crash if schemas were not found in XDG_DATA_DIRS
- Compile schema files after installation
- Fix crash updating widget sensitivity
- Fix crashes & race conditions during capture of images
- Fix infinite preview error message popups which can hang the window manager
- Fix crash when retrying a failed connection attempt
- Fix thread locking when hiding status display
- Avoid running multiple threads for monitoring status
- Fix initial sensitivity of camera control panels
- Update README with new URLs for bugs/mailing lists
Since the latest release I have also registered Entangle with GNA!, to get support for mailing lists and bug tracking.
A few months back the Red Hat KVM team held a mass keysigning party to setup a web of trust between each others keys. IIRC, there were approximately 20 people participating in this, which potentially meant alot of tedious typing of GPG commands, with the potential for error such tedium implies. Fortunately we had Jim Meyering on hand to give us some tips for facilitating/optimizing the process, the most important of which was to introduce us to the ‘Pius‘ tool. To quote from its website
pius (PGP Individual UID Signer) helps attendees of PGP keysigning parties. It is the main utility and allows you to quickly and easily sign each UID on a set of PGP keys. It is designed to take the pain out of the sign-all-the-keys part of PGP Keysigning Party while adding security to the process.
…
That can already be time consuming, but preferrably, you want to verify the identity in each UID, which means verifying the email addresses. There are a few ways to do this, but one of them is to sign each UID on the key individually (which requires import-sign-export-delete for each UID), encrypt-emailing that key to the email address in the UID. This can be incredibly time consuming.
That’s where pius comes in. Pius will do all the work for you – all you have to do is confirm the fingerprint for each key. It will then take care of signing each UID cleanly, minimizing the key, and using PGP/Mime email to send it, encrypted, to the email address in the UID.
The steps Jim defined for us to follow using Pius were as follows
- Collate a list of everyone’s key IDs. Our list looked like this (cut down to save space)
# cat > keyids.txt <<EOF
4096R/000BEEEE 2010-06-14 Jim Meyering
4096R/E1B768A0 2011-10-11 Richard W.M. Jones
4096R/15104FDF 2011-10-11 Daniel P. Berrange
...
EOF
- Download all the keys from a key server (it is assumed everyone has already uploaded their own key to a server)
# id_list=$(perl -nle 'm!^\d{4}R/(\S{8}) ! and print $1' keyids.txt)
# gpg --recv-keys $(echo $id_list)
- Generate a list of fingerprints for all keys that are to be signed
# gpg --fingerprint $(echo $id_list)
- Verify all the fingerprints and their owners’ identities.
This is the security critical part. You generally want to meet the person face-to-face, verify their identity via some trusted means (passport, driving license, etc). They should read their key fingerprint out to you, and you should verify that it matches the fingerprint of that downloaded from the key server.
- Use Pius to sign all the keys whose fingerprints were verified.
MAIL_HOST=smtp.your.mail.server.com
me=your@email.address.com (eg dan@berrange.com)
my_id=XXXXXXXXXXX (Your GPG Key ID eg 15104FDF)
# pius --mail-host=MAIL_HOST --no-pgp-mime --mail=$me --signer=$my_id $(echo $id_list)
What Pius does here is that for each key ID it is given, it will sign each individual identity (email address). The signature will be ascii-armoured and then sent to the email address associated with that identity. If a user has multiple email addresses on their key, they will receive one signature email per address. The email contains instructions for what the receipient should do. The email will look something like this
From: eblake@redhat.com
To: berrange@redhat.com
Subject: Your signed PGP key
[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.7K --]
Hello,
Attached is a copy of your PGP key (0x15104fdf) signed by my key
(0xa7a16b4a2527436a).
If your key has more than one UID, than this key only has the UID associated
with this email address (berrange@redhat.com) signed and you will receive
additional emails containing signatures of the other UIDs at the respective
email addresses.
Please take the attached message and decrypt it and then import it.
Something like this should work:
gpg -d | gpg --import
Then, don't forget to send it to a keyserver:
gpg --keyserver pool.sks-keyservers.net --send-key 15104fdf
If you have any questions, let me know.
Generated by PIUS (http://www.phildev.net/pius/).
[-- Attachment #2: 15104fdf__berrange_at_redhat.com_ENCRYPTED.asc --]
[-- Type: application/octet-stream, Encoding: 7bit, Size: 4.6K --]
The final thing, once everyone has dealt with the emails they received, is to refresh your local key database to pull down all the new signatures
# gpg --recv-keys $(echo $id_list)
I should point out that Pius isn’t just for mass key signing parties. Even if you only have 1 single key you want to sign, it is still a very convenient tool to use. The simplified set of steps to go through would be
# gpg --recv-key XXXXXXXX
# gpg --fingerprint XXXXXXXX
# ...verify person's identity & fingerprint
# pius --mail-host=MAIL_HOST --no-pgp-mime --mail=$me --signer=$my_id XXXXXXX
# ....some time later...
# gpg --recv-key XXXXXXXX
Thanks again to Jim Meyering for pointing out Pius and doing the organization for our key signing party & defining the steps I describe above. BTW, Pius is available in Fedora from F16 onwards.
As mentioned previously, today I presented a talk at FOSDEM 2012, titled “Building application sandboxes on top of LXC and KVM with libvirt”. As promised I have now uploaded the PDF slides for public access. For further information about libvirt-sandbox, consult this previous blog post on the subject. Also keep an eye on this site for further blog posts in the future. Thanks to everyone who attended the talk. I look forward to returning again in a year’s time for another update.
As many readers are no doubt aware, the FOSDEM 2012 conference is taking place this weekend in Brussels. This year I was organized enough to submit a proposal for a talk and was very happy to be accepted. My talk is titled “Building app sandboxes on top of LXC and KVM with libvirt” and is part of the Virtualization & Cloud Dev Room. As you can guess from the title, I will be talking in some detail about the libvirt-sandbox project I recently announced. Richard Jones is also attending to provide a talk on libguestfs and how it is used in cloud projects like OpenStack. There will be three talks covering different aspects of the oVirt project, a general project overview, technical look at the management engine and a technical look at the node agent VDSM. Finally the GNOME Boxes project I mentioned a few weeks ago will also be represented in the CrossDesktop devroom.
Besides these virtualization related speakers, there are a great many other Red Hat people attending FOSDEM this year, so we put together a small flyer highlighting all their talks. In keeping with the spirit of FOSDEM, these talks will of course be community / technically focused, not corporate marketing ware :-) I look forward to meeting many people at FOSDEM this year, and if all goes well, make it a regular conference to attend.