Many years ago now I setup IPv6 across all my machines, both at home and public servers. Back then (2007), only 1 of my 3 ISPs (Bytemark) was offering any IPv6 support at all, so for my Linode server I used a static tunnel from Hurricane Internet, and for home connectivity a dynamic tunnel from Sixxs. Now, 5 years on, the situation has improved somewhat. Linode offer IPv6 as standard with any virtual machine hosted on their network. I get my home DSL connectivity from UKFSN, who resell Enta.net services and sometime last year I learnt that they are providing IPv6 service to their customers.
In my home network, I used a LinkSys modem for the ADSL PPP login. A separate OpenWRT 54GL provides the LAN/WLAN subnet, and routes traffic to the subnet used by the LinkSys modem. While OpenWRT supports IPv6 very well, my LinkSys modem has zero support. So over the past 5 years, the LinkSys has done the IPv4 PPP login, while the aiccu tunnel daemon on my OpenWRT machine does the IPv6 tunnel login. This was never ideal, but functionally it works fine. With native IPv6 connectivity though, the PPP client is responsible for both IPv4 and IPv6 connectivity. So I faced the problem of how to enable this given, that the LinkSys ADSL modem has zero IPv6 support.
The answer to this conundrum is to move the responsibility for the PPP login off the ADSL modem entirely, by putting it into “Bridged” mode. In such a setup, the modem is solely responsible for negotiating the DSL link on the line. It then forwards all traffic from the DSL link to its LAN port, using the PPPoE (PPP-over-Ethernet) protocol. The OpenWRT box now runs the PPP daemon to establish the IP layer connectivity to the DSL ISP. This sounds complicated, but it is all surprisingly easy to configure.
- On the LinkSys router, find the DSL setup options and change the mode from “PPPoA” to “Bridged”. The loginname/password details are now irrelevant here (and indeed grayed out on my router admin page)
- On the OpenWRT router, edit the /etc/config/network section and add PPPoE config section, taking care to add the ‘ipv6=1’ option. Contrary to instructions from my ISP, I didn’t need to configure any IPv6 address/subnet on the ppp0 interface, it is automatically handled via link-local addresses.
config 'interface' 'wan'
option 'ifname' 'eth0.1'
option 'proto' 'pppoe'
option 'username' 'NNNNNNN@adsllogin.co.uk'
option 'password' 'XXXXXXX'
option 'defaultroute' '1'
option 'peerdns' '1'
option 'ipv6' '1'
- Restart networking on the OpenWRT box (/etc/init.d/network restart). If all went to plan the OpenWRT box now has a login to the DSL ISP with both IPv4 and IPv6 connectivity
ppp0 Link encap:Point-to-Point Protocol
inet addr:XX.YY.ZZ.AA P-t-P:BB.CC.DD.EE Mask:255.255.255.255
inet6 addr: fe80::XXXX:YYYY::ZZZZ/10 Scope:Link
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:169629 errors:0 dropped:0 overruns:0 frame:0
TX packets:120721 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:228671985 (218.0 MiB) TX bytes:11603336 (11.0 MiB)
- Provide IPv6 connectivity to the LAN using RADVD. With OpenWRT this is trivially achieved by editing /etc/config/radvd. UKFSN/Enta provided me with a /56 subnet for local LAN use. I just allocated the first /64 of this to my LAN for now. The rest I will for creating various subnets between virtual machines I test with
config prefix
option interface 'lan'
option prefix '2001:XXXX:YYYY:ZZZZ::/64'
option AdvOnLink 1
option AdvAutonomous 1
option AdvRouterAddr 0
option ignore 0
- Don’t forget to ensure that a firewall is up for the IPv6 link – there’s no NAT to “protect” you, so you want to setup a “deny all” rule for incoming connectivity on the “ppp0” device.
The upshot is that 5 years on from my initial setup, I now have native IPv6 connectivity everywhere. No more IPv6-in-IPv4 tunnels required. I’ve not compared the download speeds of my native IPv6 connection against the Sixxs IPv6 tunnel I used previously, but I can say that the ping times have improved. Previously IPv6 pings were about 10ms slower than IPv4 pings. Now the ping times are identical, which is nice :-)
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.