The following blog posts appear on Planet Debian. Please visit my main blog page for all my posts.
Dear Debian: I haven’t had much of a chance to stay in touch lately, but I don’t want to forget to wish you well on this 17th birthday of yours. You have set standards and you continue to do so. You are the operating system of choice, and you excel at it. Keep up the level of quality, and keep up the spirit. I am looking forward to more contact in the future.
Thanks to everyone who has dedicated and (or) continues to dedicate their time to our project!
Love, -m
Posted Mon 16 Aug 2010 20:01:18 CESTBravo Greenpeace Switzerland! At Nestlé’s annual shareholder meeting 2010 last week, you descended from the ceiling in the middle of the presentations with flyers and a banner asking for the company to take responsibility for their reckless actions in Indonesia.
Thousands of square kilometres of forest are cleared every day so that companies like Nestlé can make vast sums of money off consumers.
Meanwhile, Orangutans outside the venue were protesting Nestlé and asking for a break (copying Nestlé’s own slogan “Have a Break! Have a …”). The Orang Utans are pushed towards extinction by capitalist interest.
One of my closest friends was part of the act, and he recounts breaking into the ventilation system before sawing through the ceiling, and descending on a rope. The police detained them for more than 24 hours, but the message has been sent.
Bravo!
Read more (and watch videos of the spectacular descent) on the Greenpeace webpage, the Greenpeace press announcement and their blog (all in German), or on 24heures (in French). Planetsave has a decent coverage in English.
NP: Emerson, Lake & Palmer: Brain Salad Surgery
Posted Mon 19 Apr 2010 14:04:59 CESTVia internotes.ch:
NP: Emerson, Lake & Palmer: Tarkus
Posted Sat 17 Apr 2010 13:14:58 CESTDebian seems to be ready for IPv6 (although there are still some problems). In less than a day, I put a few of my machines online and joined the Internet of the future. In the following, I’d like to share with you how I did it.
Throughout this document, I use IPv6 addresses out of the
2001:db8::/32 subnet, which is reserved for documentation
purposes. You will need to use your own prefix(es) when running
the command. Similarly, I use 10.111.222.33 as example
IPv4 address of the PoP endpoint, which you will need to alter.
Configuring the packet filter
The first thing I did was to configure the packet filter on each
host appropriately. Unfortunately, this is harder than it should
be, because — to quote one of the netfilter developers — “when ip6tables
was conceived, someone had a big bad brainfart”: rather than adding
IPv6 rules to your existing iptables ruleset, you have
to create a new ruleset, duplicate all chains, networks, hosts, and
individual rules, and maintain the two in parallel. Even though
there are efforts of unification on the way, I speculate it’ll take
another couple of years until PF_INET6 will be fused
into PF_INET and one will be able to do sensible
cross-address-family packet filtering with Linux. Since I’ve
recently started to look (again) at pyroman, maybe the most
logical way forward would be to extend it to write both, IPv4 and
IPv6 rulesets from its knowledge about the hosts and networks you
configured.
Anyway, we want to get stuff working now! Thus, let’s configure
ourselves a packet filter. (Almost) all IPv6-related filtering must
be configured via ip6tables (read on further down
about IPv6 in IPv4 tunneling, the reason I said “almost”). The
following is a simple default ruleset to start with, which I put
into /etc/network/ip6tables to load with
ip6tables-restore:
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
:in-new - [0:0]
### INPUT chain
# allow all loopback traffic
-A INPUT -i lo -j ACCEPT
# RT0 processing is disabled since 2.6.20.9
#-A INPUT -m rt --rt-type 0 -j REJECT
# allow all ICMP traffic
-A INPUT -p icmpv6 -j ACCEPT
# packets belonging to an establish connection or related to one can pass
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# packets that are out-of-sequence are silently dropped
-A INPUT -m state --state INVALID -j DROP
# new connections unknown to the kernel are handled in a separate chain
-A INPUT -m state --state NEW -j in-new
# pass SYN packets for SSH
-A in-new -p tcp -m tcp --dport 22 --syn -j ACCEPT
# log and reject everything else
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[INPUT6]: "
-A INPUT -j REJECT
### OUTPUT chain
# RT0 processing is disabled since 2.6.20.9
#-A OUTPUT -m rt --rt-type 0 -j REJECT
# allow outgoing traffic, explicitly (despite chain policy)
-A OUTPUT -j ACCEPT
### FORWARD chain
# RT0 processing is disabled since 2.6.20.9
#-A FORWARD -m rt --rt-type 0 -j REJECT
# disallow forwarded traffic, explicitly (despite chain policy)
-A FORWARD -j REJECT
COMMIT
Note that this recipe is pretty much unusable on pre-2.6.20 kernels due to their broken implementation of stateful connection tracking.
The ruleset should be fairly obvious, but you might wonder about
my use of REJECT and allowing all ICMP — after all, you’ve
heard for the past 30 years that ICMP is a “bad hacker
protocol”, and Internet security is no domain for being nice to
people, so to prevent any information disclosure, you should
DROP connections, not let people know that they’re
simply not allowed.
Well, to hell with all that! I don’t see a single reason or
attack vector that is foiled by DROP or disallowing
ICMP. In fact, it’s just security by obscurity, and
mighty inconvenient at the same time. ICMP is also
much more important with IPv6 than with IPv4 (it replaces ARP,
for instance), and it’s actually useful to be able to
ping hosts, or get back informational messages on why
something failed. Finally, rejecting traffic rather than dropping
it doesn’t suggest to a hacker that something’s hidden here.
Then there is RFC 4890, which almost made me puke. This document is part of the reason why I say: let’s fix problems in the kernel, rather than shielding them with unreadable and unmanageable rulesets!
Setting system parameters
The /proc/sys/net/ipv6 filesystem exports a number
of parameters that you might want to set. The Linux IPv6 HOWTO
explains all
available parameters, so let me just show you the ones I set in
/etc/sysctl.conf and load with a call to
sysctl:
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.accept_ra_defrtr = 0
net.ipv6.conf.default.accept_ra_rtr_pref = 0
net.ipv6.conf.default.accept_ra_pinfo = 0
net.ipv6.conf.default.accept_source_route = 0
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.default.forwarding = 0
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.accept_ra_defrtr = 0
net.ipv6.conf.all.accept_ra_rtr_pref = 0
net.ipv6.conf.all.accept_ra_pinfo = 0
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.all.forwarding = 0
Obviously, for gateways, you want to enable forwarding, and on
machines where you want to use autoconfiguration, those
accept_ra* entries ought to be 1 accordingly.
If you’re curious, the default values (the first
seven lines) set the defaults for new interfaces, while the
all values override the values for all interfaces. I
am not sure whether this is a permanent overwrite, or just
overwrites all existing interfaces, which is why I simply set the
parameters for both.
Unfortunately, this does not seem to work. It
seems as if writing to all does not affect
existing interfaces, as documented in this thread
on the linux-kernel mailing list.
At this moment, I suggest that you add pre-up
headers to the iface stanzas of all interfaces to be
sure:
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/autoconf
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra_defrtr
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra_pinfo
pre-up echo 0 > /proc/sys/net/ipv6/conf/$IFACE/accept_ra_rtr_pref
Getting connected
If you already have an IPv6 address, you’re basically ready to go, but may want to read further down on how to connect your local network to the IPv6 Internet as well. If you are searching for a provider, have a look at the list of providers with native IPv6 connectivity over at sixxs.net.
If you are reading up to here, I assume you are connected to the
‘Net with IPv4. There are two ways for you to move towards IPv6:
6to4 or by way of a
tunnel provider. A Kiwi website explains how to setting up 6to4
connectivity, and thus I will concentrate only on the tunnel
approach. Even though everyone can set up
6to4 in a breeze without any accounts or waiting,
there are a number of security considerations,
it’s pretty ugly to debug (due in part to asymmetric routing), and
makes your life unnecessarily difficult when all you have is a
dynamic IP that changes from time to time. If you are stuck behind
a NAT gateway, you cannot use 6to4 either. Thus, I
prefer the tunnel approach.
With the tunnel approach, IPv6 packets are wrapped up in IPv4
packets on your host, and sent to the IPv4 address of your tunnel
provider, who has native IPv6 connectivity. The tunnel provider
unwraps your packet and shoves the contained IPv6 packet onto the
backbone. The IPv6 address you used as source address is routed to
the tunnel provider, so any replies arrive at their machines, where
they’re again wrapped into IPv4 packets and sent to your
(publicly-accessible) IPv4 address. Those IPv4 packets specify
payload type 41 (“ipv6”), which is why we need -p ipv6 -j
ACCEPT rules in the IPv4 iptables ruleset (see
below).
There are a few tunnel providers out there. I chose SixXS and have not regretted my choice. I shall thus assume that you do the same: sign up for an account right now, so that you have it by the time you finished reading this document! SixXS works on a credit system: tunnels and subnets cost credits, which you can accumulate by maintaining your tunnels properly. This ensures that everyone can play around, but to do more advanced stuff, you need to first display competence with the basic concepts.
Tunnel types
Your first step with SixXS will be to request a tunnel. SixXS offers three types of tunnels:
- static tunnels, for those with static IPs,
- heartbeat tunnels, for those with dynamic IPs, and
- AYIYA tunnels, for those behind NAT gateways.
Each of these tunnels have advantages and disadvantages, as
everything does: the first two types of tunnels use IP protocol 41
packets to encapsulate the IPv6 packets. As such, there are
security considerations involving the impersonation by spoofing,
and all upstream firewalls must let protocol 41 pass.
AYIYA addresses these problems by using signed
packets, but that solution comes with extra computation overhead
and smaller MTUs.
I suggest to use the first type of tunnel that fits your
situation. Debian’s aiccu package can take care
of heartbeat and AYIYA tunnels for you, and it can
even set up static ones.
During registration, you will also need to choose a “PoP”, which
stands for “Point of Presence”. If your country only has a single
PoP, that’s the one you will end up using (unless you have a good
reason for another one), but if there are more options, I strongly
suggest that you go through the list of PoPs and select the
one with the best roundtrip time and lowest latency from your
location! Note that you must answer ping requests
(ICMP echo-request) from the PoP you
chose, or else the tunnel will not be created.
Other tunnel brokers include HE, which give you up to four tunnels and subnets within minutes, but they only support proto-41 tunnels (“static tunnels”), which do not work everywhere.
Setting up the tunnel
Once your tunnel request gets approved, you’ll get a
/64 prefix, in which you only use two addresses: the
PoP will configure the :1 address and you need to
configure your host to use the :2 address on the
tunnel interface. You’ll also be told the IPv4 address of your PoP
“endpoint”.
Joey Hess taught me that aiccu can set up the
interface for you, using the data it queries from the SixXS
registration (TIC) server. I tried it, and it works. However, I
prefer the pure ifupdown approach, as it
makes things explicit and allows me to use the hooks for stuff like
loading the packet filter. So in my
/etc/network/interfaces, you can find (remember that
these are fake addresses and you need to use your own prefixes and
PoP endpoint address):
auto sixxs
iface sixxs inet6 v4tunnel
endpoint 10.111.222.33
address 2001:db8:ff00:3b::2
netmask 64
gateway 2001:db8:ff00:3b::1
ttl 64
pre-up ip6tables-restore < /etc/network/ip6tables
up ip link set mtu 1480 dev $IFACE
up invoke-rc.d aiccu start
down invoke-rc.d aiccu stop
Make sure to read about MTU values of the tunnel and adjust the 1480 value in the above to your tunnel settings and ISP connectivity.
The last two lines are only needed for heartbeat tunnels and
assume that you have configured aiccu
appropriately.
Also, when using /etc/network/interfaces, make sure
to set noconfigure true in
/etc/aiccu.conf, or else aiccu will bring
up a duplicate/additional interface. If your version of
aiccu does not honour this configuration option, you
can set ipv6_interface sixxs instead: if you tell it
to configure the same interface as specified in
/etc/network/interfaces, it will actually execute all
the same commands (which will fail), but won’t report any
errors.
For AYIYA tunnels, the following can be used, if you prefer to
be able to bring up the interface with the usual ifup
command, rather than having it appear when the daemon starts.
auto sixxs
iface sixxs inet manual
pre-up invoke-rc.d aiccu start
up sleep 1
up ip link set mtu 1280 dev $IFACE
post-down invoke-rc.d aiccu stop
It is also a good idea to prevent aiccu from
starting at boot when using this method:
update-rc.d aiccu disable
Allowing proto-41 traffic
Unfortunately, these methods are likely to fail, because your
regular IP packet filter (iptables, without the 6)
doesn’t let those encapsulating IPv4 packets pass, unless you tell
it to; you probably want to do this early on in the chain, and also
limit it to the tunnel peer, so in my case, I use the following
rule:
iptables -I INPUT -p ipv6 -s 10.111.222.33/32 -j ACCEPT
For AYIYA, you need to open port 5072, either for UDP, TCP, or SCTP, depending on how you configured it. Also have a look at this FAQ entry on what a firewall needs to pass. If it still doesn’t work, you have an upstream packet filter that needs some of those holes poked. Good luck.
In most situations, the FORWARD chain does not get
such a rule, since the tunnel terminates at the gateway, which
routes to a native IPv6 network, or another tunnel. Allowing
tunnels through a gateway is almost always a bad thing, as it would
allow undetected and untraceable traffic from compromised boxes in
the local network. The OUTPUT chain also does not need
such a rule, if you have configured stateful filtering
properly.
Now bring up the interface and verify the connection:
# ifup sixxs
# ping6 -nc1 2001:db8:ff00:3b::1
PING 2001:db8:ff00:3b::1(2001:db8:ff00:3b::1) 56 data bytes
64 bytes from 2001:db8:ff00:3b::1: icmp_seq=1 ttl=64 time=74.0 ms
[...]
# ping6 -nc1 ipv6.aerasec.de
PING ipv6.aerasec.de(2001:a60:9002:1::184:1) 56 data bytes
64 bytes from 2001:a60:9002:1::184:1: icmp_seq=1 ttl=55 time=91.5 ms
[...]
Welcome to the Internet of the future!
Setting up an IPv6-capable gateway
Your IPv6 connection works, but it’s limited to a single
address, and you do not get to specify the reverse DNS
PTR record for it. Since the concept of NAT is mostly
absent from IPv6 (thanks! thanks! thanks!), you will not be able to
connect any other hosts to the IPv6 network. If your local network
has a few hosts behind a gateway, you will need to request a subnet
from SixXS and configure your gateway (which has the tunnel
connection) appropriately. Don’t worry, this is not really very
difficult.
First, request a subnet for your tunnel from your PoP via your
SixXS homepage. Once approved, you will get a /48
prefix for your own use: 2^80 — 1.2 heptillion addresses which are
yours to assign to every dust particle in your office or
home, if you so desire.
The way I set it up is to add the first of these addresses to
your internal interface on the gateway, by adding the following two
lines to the interface’s stanza in
/etc/network/interfaces; you will need the iproute package installed
(which you should be using for everything network-related
anyway; remember to substitute your own prefixes):
up ip -6 addr add 2001:db8:ff12::1/64 dev $IFACE
down ip -6 addr del 2001:db8:ff12::1/64 dev $IFACE
Instead of bringing the interface down and up, just run ip
-6 addr add <your prefix> dev eth0. Note the use of
the /64 prefix instead of the /48 that
got assigned, leaving only 20 pentillion addresses. Oh no! The
reason for this is buried in the specs: basically, /48
is a site prefix, but individual networks should not be larger than
/64, which is the prefix length of links in the IPv6
domain.
The /64 prefix is only one of 65536 different
/64 prefixes you can use from your /48
prefix. Since it’s unlikely that you’ll use them all, it’s a good
idea to route unused ones to an unreachable destination, such as
the loopback interface, which conveniently causes packets to any
addresses outside the used /64 networks to be answered
with ICMP destination network unreachable. You could route them to
the special unreachable target instead, which would
cause host unreachable messages, but the following is more explicit
(again, remember to use your own prefix in place of the one used in
this document):
up ip -6 route add 2001:db8:ff12::/48 dev lo
down ip -6 route del 2001:db8:ff12::/48 dev lo
Enabling forwarding
Now is also a good time to enable IPv6 forwarding, e.g. like so:
# echo net.ipv6.conf.all.forwarding = 1 >> /etc/sysctl.conf
# sysctl -p
Obviously, you will also need to change the policy on the
ip6tables FORWARD chain. For now, let’s
just set it to accept all traffic between the local network behind
eth0 and the Internet behind eth1. You
should later create a proper ruleset, though! (remember to use your
own prefix)
# ip6tables -I FORWARD -i eth0 -o eth1 -s 2001:db8:ff12::/64 -j ACCEPT
# ip6tables -I FORWARD -i eth1 -o eth0 -d 2001:db8:ff12::/64 -j ACCEPT
Advertising addresses on your local network
The final step is to spread the love to your local network. Refrain from selecting addresses from your subnet and assigning them to the local hosts, or wondering how to configure the DHCP server, because IPv6 does it differently: your gateway will advertise its routes (which includes a default route) to your network, and each host will pick an address based on its MAC address (unless it already has an EUI-64 address assigned. This all happens automagically, at least with current Debian and Windows machines.
On the gateway, you need to install radvd and simply tell it
which prefix to use on which interface. My
/etc/radvd.conf looks like this, and I won’t explain
it (remember to use your own prefix, not the one used in this
document):
interface eth0
{
AdvSendAdvert on;
prefix 2001:db8:ff12::/64
{
};
};
Note again how we advertise a /64 network rather
than the /48 we “own”. You cannot advertise smaller
networks if you want automatic configuration to work, and you
should not use networks larger than /64 in any case.
If 2^64 addresses are not enough for you, I trust you’ll be able to
figure out how to advertise another of your 65536 /64
prefixes in the /48 subnet to appropriate hosts.
Restart radvd and run over to another host to
witness how it automagically gets connected to the IPv6 network by
scanning /var/log/kern.log and watching the output of
ip -6 addr and ip -6 route. Try
ping6ing from there! Find the dancing turtle! It should all work.
If you don’t like the automagic aspect of this, look into stateful configuration, using DHCPv6, as provided by dibbler-server and wide-dhcpv6-server.
Choosing source addresses
Even though you have obtained a /48 network and
configured the gateway appropriately, connections originating from
the gateway itself will have the tunnel endpoint IP as source
address. This is because Linux picks the address of the outgoing
interface when it sends packets, and we only slapped the address
from our own subnet onto the LAN interface. However, if the
firewall answers to 2001:db8:ff12::1 (or whatever
address you gave it from your prefix space), it ought to use that
address for sending, too.
Unfortunately, there’s no guaranteed way to achieve this, due to RFC 3484, which is explained nicely on this page.
The best solution is to add 2001:db8:ff12::1/128 as
last address to the external interface, which will cause Linux to
use it in most cases. When it doesn’t, you ought to just ignore it
(remember to use your own prefixes instead):
iface sixxs inet6 v4tunnel
[…]
up ip -6 addr add 2001:db8:ff12::1/128 dev $IFACE
down ip -6 addr del 2001:db8:ff12::1/128 dev $IFACE
Here is a thread on the issue on the SixXS forum.
Resolving names
Take note of the IPv6 address of each host. There’s a way to
determine it given the host’s MAC address, but this is easier
(ipv6calc is also
useful). You might want to let your local DNS server know by adding
AAAA records in parallel to the existing
A records, and possibly even adding PTR
entries.
If you’re serious about IPv6, you can tell SixXS to delegate
reverse lookups for the IPv6 addresses to your DNS servers, but you
ought to refrain from polluting the DNS
namespace. The dig tool and its
+trace option are awesome to debug and analyse reverse
delegations:
dig +trace -x 2001:41e0:ff1a::1
Note that bind9-host provides
an improved host tool, which fetches all kinds of
information about names, not just the one single information
configured as default:
% host pulse.madduck.net
pulse.madduck.net has address 130.60.75.48
pulse.madduck.net has IPv6 address 2001:41e0:ff1a::1
pulse.madduck.net mail is handled by 99 b.mx.madduck.net.
pulse.madduck.net mail is handled by 10 a.mx.madduck.net.
% host 2001:41e0:ff1a::1
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.f.f.0.e.1.4.1.0.0.2.ip6.arpa
domain name pointer pulse.madduck.net.
Oh, and if you’re really that curious about how IPv6 addresses
are computed from MAC addresses, read RFC 2464. Basically,
given a prefix 2001:db8:ff1a:: and a MAC address
aa:bb:cc:dd:ee:ff, the resulting IPv6 address is
obtained by:
- inserting
ff:feinto the middle of the MAC address to yieldaa:bb:cc:ff:fe:dd:ee:ff; - removing the odd colons to yield
aabb:ccff:fedd:eeff, the EUI-64; - flipping the second lowest bit of the first octet to yield
a8bb:ccff:fedd:eeff; this marks the EUI-64 globally unique. - concatenating the prefix and this result to get
2001:db8:ff1a::a8bb:ccff:fedd:eeff.
Other (easier) ways to determine the local component of an IPv6 address are:
- look at the output of
ip -6 addrand find the address starting withfe80::on the interface you want to connect to the IPv6 network; following the two colons is the interface’s EUI-64. - use ipv6calc or sipcalc.
If you find your (Windows) IPv6 addresses changing all the time, you might be faced by “privacy features”.
Remaining issues
Even though my IPv6 connectivity works, I have two remaining issues.
Mapping names to laptops
Laptops generally have two interfaces, one with a cable, and the other wireless. Both of these interfaces will have separate MAC addresses, and by extension, the laptop will have different IPv6 addresses depending on how it is connected to the local network.
I want to be able to connect to laptops without knowing the medium they use to connect to the network. Unfortunately, there seems to be no feasible way. The solutions I see are:
- override the MAC address of one interface with that of the other, which is going to cause bgi problems in the case when the laptop (accidentally) gets connected to the same network twice;
- add both IPv6 addresses as
AAAArecords to the laptop’s DNS name, which will cause random delays when connecting as the resolver may return the currently inactive address first; - set up mobile IPv6, e.g. by following this Mobile IPv6 how-to, which would allow accessing the laptop uniformly, no matter where in the world it is. Unfortunately, Debian’s support for Mobile IPv6 is severly lacking at time of writing. Also, Yves-Alexis Perez notes that this how-to is horribly outdated and promised to tend to it Real Soon Now™.
The second solution works for me for now, but I am interested in the third.
In response to this document, Andreas Henriksson has suggested
the replace the stateless configuration (radvd) with
stateful configuration, using DHCPv6. I have yet to
investigate this option.
Jeroen Massar suggests to unite cable and wireless into a bridged interface, which seems like a very good idea.
Kernel versions and stateful connection tracking
Even though the default kernel of Debian etch, our current stable release, speaks IPv6, I cannot recommend it for deployment, as the 2.6.18 kernel does not support proper stateful connection tracking for IPv6, and thus makes it impossible to firewall hosts in a sensible manner (I always add local packet filters to all my hosts, and if only to guard against the situation when a user installs a malicious programme to listen on a high port). Of course, it is possible to configure a packet filter statelessly in an acceptable manner once you know the use case, so do with this information what you wish; I prefer to stay general for now.
A remedy exists, however: Debian “etch” 4.0r4 adds the so-called
etch-and-a-half
kernels, e.g. linux-image-2.6.24-etchnhalf.1-686. The
2.6.24 kernel seems to support stateful connection tracking for
IPv6. Alternatively, you could use the 2.6.24 linux kernel packages
on backports.org.
Xen and IPv6
One drawback of switching to 2.6.24 is that you cannot run a
dom0 on that machine any longer, so by practical
extension, you cannot connect it to the IPv6 network with a packet
filter in place. Supposedly, running 2.6.24 instances on a 2.6.18
dom0 is reported to work, however.
Debian “lenny” 5.0 fixes this: it comes with a patched 2.6.26
kernel and can be used for both, as dom0 as well as
regular IPv6 citizen.
Credits
Thanks to Bernhard Schmidt, William Boughton, and Jeroen Massar,
and everyone on #ipv6/irc.freenode.org
for their help over the past few weeks, and all those who fed back
comments in response to this document!
My relationship with Puppet is one of love and hate. I am forced to use it simply because there is no better tool around, but I hate it in so many ways that I don’t even want to start to enumerate (hint: most have to do with Ruby, actually).
Today I decided to put an end to one thing that has been driving
me insane: the fact that puppetd (the client) and
puppetmasterd (the server) use the same working
directory, /var/lib/puppet. Since I consider and would
like to treatthe machine on which puppetmasterd is
running just another puppet client, I was running into funky issues
related to SSL certificate
confusion, obscure
errors, and SSL revocation
horrors.
The following hence assumes that you have installed or are
planning to install puppetd on the machine running
your puppetmaster, and that you have two fully-qualified domain
names for the machine. For instance, I run puppetmaster on
vera.madduck.net, and
puppetmaster.madduck.net is an alias for the same
machine. I’ll use these names in the following as examples.
The following may be Debian-specific, as I am solely using the puppet and puppetmaster packages for my experimentation and verification. Your mileage may vary, but the concept shall be the same.
-
Stop everything:
/etc/init.d/puppetmaster stop /etc/init.d/puppet stop(also verify that you have not instructed
cronto restart these services) -
Rename the working directory:
mv /var/lib/puppet /var/lib/puppetmasterand amend
/etc/puppet/puppet.confaccordingly:[main] # … vardir=/var/lib/puppetmaster ssldir=$vardir/ssl # … [puppetmasterd] certname=puppetmaster.madduck.net # …I am doing this in
[main], planning to override it forpuppetdlater, becausepuppetdis the only program which makes sense to be separated from the rest. Since only the puppetmaster needs a special certificate name, that is set specifically in the[puppetmasterd]section.If you use apache2 or nginx in front of your puppetmasters, make sure to amend the SSL file locations in the virtual host definition and restart (!) the service.
You can verify that the configuration has been amended by making sure that there is no output from the following command:
# puppetmasterd --genconfig | grep -q '/var/lib/puppet/' && echo SOMETHING IS WRONG -
Now restart puppetmaster:
/etc/init.d/puppetmaster startand verify that it starts.
If your puppetmaster previously ran under a different name, it will create itself a new certificate and sign it.
Since the client will get its own working directory (and thus a new SSL certificate), you want to remove all records of the old certificate:
# puppetca --list --all + puppetmaster.madduck.net + vera.madduck.net # puppetca --clean vera.madduck.net -
Change the configuration file to tell
puppetdabout its working directory:[puppetd] server=puppetmaster.madduck.net vardir=/var/lib/puppet ssldir=$vardir/ssl # …This you can verify with the following command, which should not print anything:
# puppetd --genconfig | grep -q '/var/lib/puppet[^/]' && echo SOMETHING IS WRONG -
Now install puppet, or (re)start it if it’s already installed:
# /etc/init.d/puppet stop # puppetd --no-daemonize --onetime --verbose --waitforcert 30 & info: Creating a new SSL key for vera.madduck.net warning: peer certificate won't be verified in this SSL session info: Caching certificate for ca info: Creating a new SSL certificate request for vera.madduck.net # puppetca --list vera.madduck.net # puppetca --sign vera.madduck.net notice: Signed certificate request for vera.madduck.net notice: Removing file Puppet::SSL::CertificateRequest vera.madduck.net at '/var/lib/puppetmaster/ssl/ca/requests/vera.madduck.net.pem' # fg info: Caching certificate for vera.madduck.net info: Caching certificate_revocation_list for ca […] # puppetca --list --all + puppetmaster.madduck.net + vera.madduck.net # /etc/init.d/puppet startDo yourself the favour and check that it’s all working.
-
Optionally, you can now clean up the client stuff in the server’s working directory, for instance like this (it worked for me, but this is the sledgehammer approach):
# /etc/init.d/puppetmaster stop # cd /var/lib/puppetmaster # tar -cf /tmp/puppetmaster.workingdir-backup.tar . # find ../puppet -type f -printf '%P\n' | xargs rm # /etc/init.d/puppetmaster start -
If you stopped
cronbefore (and your puppet recipes have not since restarted it):/etc/init.d/cron start
All done. I wish puppet, or at least Debian’s puppet packages would do this by default. Please let me know if the above conversion works for you. Then I might start working on an automated migration.
NP: Genesis: Selling England by the Pound
Posted Tue 23 Mar 2010 07:24:31 CETThe most common criticism of the Anti-Counterfeiting Trade Agreement (ACTA) is the lack of transparency. Before the nations disclose the terms of the agreement under negotiation, we are unable to gain an idea of the big picture, let alone voice our opinions and push for changes. Our politicians don’t want us to know. We rely on leaked documents for our information. This is backwards in a world where a state should represent its people. This smells foul to me.
There are undoubtedly some good reasons for the treaty, and if we can contain worldwide, large-scale trade of counterfeited goods and medicine, then that would be a net benefit to us all. However, we must not allow certain governments to succomb to the pressure of (commercially-motivated) lobbyists, to extend that pressure onto other nations using trade as a means of pressure, and to slash our freedom as if it were an inconvenient obstacle in their way.
Only if the terms under negotiation become publicly available, and the public is given a voice, then we can help our governments in entering an agreement that is in the interest of its people, rather than a threat to us.
It is hardly surprising that total capitalist nation USA are the strongest opponents of transparency, because the public might delay or even prevent the treaty. I was also not surprised to see South Korea and Germany in the list of supporters of secrecy either. It is interesting to see that the leaders of Singapore, Belgium, Portugal, and Denmark also seem to believe that these negotiations should be withheld from the public. Does anyone know about Switzerland?
I tip my hat to New Zealand, Canada, Australia, Netherlands, Sweden, Finland, Ireland, Hungary, Poland, Estonia, and Austria for their support of transparency.
Posted Fri 26 Feb 2010 08:05:44 CETISPs fight a raging war over net neutrality because their infrastructure cannot keep up with the increasing demand (or rather supply) of content. Therefore, ISPs want to charge the users premiums if they wish to use certain services on the Net. For instance, since videos are usually large in size, one would have to purchase e.g. the “platinum package” to be able to access video hosting sites. It would be a serious loss of freedom if they won, and the Internet would never be the same.
Let’s turn that idea around: since sites that use advertising make money off every visitor, they are really the ones that should pay the ISPs so that they can improve their infrastructure. The same applies to sites that make money off visitors in other ways.
At the moment, users pay to access the network (which is like paying a taxi to get to the market), so that they can visit sites where advertisers make money showing ads to the visitor, which might actually let them to pay a manufacturer for a product — the end user pays twice, and the advertisers take in money, leeching off the ISPs investing into their infrastructure.
I think that the advertiser and not the consumer should pay the ISP to keep the infrastructure afloat — improve it even. The manufacturer should then pay the advertisers for displaying the ad, and the user consumes if s/he chooses to — and everyone only pays once, for services they want. This will help improve competition among providers, which should always be the goal.
If my ISP would start to record the volume of HTTP traffic I produce for each target site, charge the targets appropriately (they could start with a couple at first), and I’d get free connectivity in turn, I’d be quite happy. The ISP wouldn’t have to look at the contents at all for that.
I don’t yet know what to do if the target sites choose not to pay up. ISPs could block them, or throttle or deprioritise traffic, but either of those might simply lead to an exodus of users, just like “premiums” would.
As usual, this just needs to be done by many ISPs in concert. Are you listening?
Posted Sat 20 Feb 2010 23:02:56 CETThe coffee place around the corner from where Penny and I lived for the past two months — Caffé Mode — offers to make your food using free-range eggs for NZ$1. Free-range eggs are more expensive than normal ones, but the price difference is not one dollar. Therefore, the cafe makes a profit every time a customer makes the right choice.
I went in this morning to ask them about it, and the guy taking my coffee order admitted stale-mate. When I suggested that the cafe should use free-range eggs exclusively, he agreed. Let’s hope that he lets those making that decision know, and that the cafe soon stops making money on ethical choices.
Posted Sat 20 Feb 2010 12:05:32 CETTomorrow, Penny and I head off back home, and two months of living in NZ come to an end. (did you hear that, pleaserobme.com?)
Maybe I’ll find the time to write about my impressions of living on this side of the planet, and being immersed in Kiwi culture while going after my daily routine and trying to work as much as I could. But there is one thing that should not wait:
Thank you, Catalyst IT for giving us workspaces! For the better part of 6 weeks, you gave us our own room, monitors, keyboards, mice, and connectivity. And more than that: you welcomed us, let us participate in sessions, invited us to your parties, received our parcels, sent out letters, and generally provided us with a great environment to work. This was certainly well above what we had dreamed of.
At times, I was forced to stay into the middle of the night — 12 hours time difference with Europe is not always easy — and spent waking hours in your building alone. Thank you for your trust!
Catalyst is a fully New Zealand owned company who deliver critical open source business systems to some of NZ’s largest organisations, and organisations worldwide. Catalyst was also a major enabler of LCA2010, and a sponsor of Kiwi Foo Camp, both events that I had the privilege to attend.
Let me know when you’re in my part of the world. ;)
NP: The Mamaku Project: Karekare
Posted Thu 18 Feb 2010 06:15:58 CETShortly after I wrote my last article about ACTA and the lack of transparency, I was delighted to find out that a report of the recent negotiations in Mexico has been leaked. I find it a bit disconcerting that our politicians, who are theoretically supposed to represent our interests, are writing documents that can “leak” to the public, when they should have been available to the public from the start.
The document and the coverpage are available for direct download.
Michael Geist has a first analysis
A brief report from the European Commission authored by Pedro Velasco Martins (an EU negotiator) on the most recent round of ACTA negotiations in Guadalajara, Mexico has leaked, providing new information on the substance of the talks, how countries are addressing the transparency concerns, and plans for future negotiations. (read more…)
NP: Dimmer: Degrees of Existence
Posted Wed 17 Feb 2010 23:59:38 CET
