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