Jeremy's Weblog

The Gentoo Prefix project is still alive and still kicking. There has not been any major noteworthy highlights so you may not heard from us in some time. The number of users increases and the number of active contributors seems to stay the same or increase much more slowly. Gentoo Prefix was the reason I become a Gentoo Linux developer, so get involved..it is an easy gateway to being a Gentoo Developer if you are interested.

Some interesting things to note that I have been working on:

• My ~x86-linux binpkg repo for Gentoo Linux hosts is still running every night. I use this to easily find simple build errors in packages before they hit too many users.
• I started a ~amd64-linux binpkg repo to add coverage to my nightly automated testing. So, I’ve updated the instructions from the above post. This means that you can install your very own Gentoo Prefix installation on a Gentoo Linux host in 5 minutes for 32bit or 64 bit now.
• While those are updating everynight. I am now bootstrapping everynight too. I set up a small script that debootstraps a Debian Lenny chroot and then sets up an Gentoo Prefix inside the chroot. This will help finding bootstrapping bugs that brand new users may hit. Often times bootstrapping is more sensitive/fragile to tree changes than just updating.
• We are still migrating packages from the Gentoo Prefix tree to the Gentoo Linux tree. This is going slower than planned but there are not too many people working on it. Current: Over ~2000 packages migrated, still over 700 to go in our overlay. (Gentoo Prefix tree has over 7000 packages in it, but not all are tested/keyworded.)

There seems to be a semi-meme going around on some of the planets I read.

My concern is long directory paths and I wanted a dymanic solution for it. Surely, I cannot be the first person to think of it, but I haven’t seen it in use anywhere else.

jolexa @ helios :: ~ %%

and
jolexa @ helios :: ~ %% cd projects/prefix-tinderbox/really_long_dirname_so_that_binpkgs_can_be_shortened/a/b/
jolexa @ helios :: .../a/b %%

(the colors and wrapping are representitive only)

and the code that produces that:

_chomp_path() {
    local path=${1/${HOME}/\~}
    local last=${path} sedout= count=0 count2=0
    sedout=$(echo ${path} | sed -e 's:/: :g')
    for i in ${sedout}; do
        (( count++ ))
    done
    if ((count > 2)); then
        last="..."
        for i in ${sedout}; do
        (( count2++ ))
        if (( count2 >=  count - 1 )); then
            last+="/$i"
        fi
        done
    fi
    echo ${last}
}

PS1='\[\033[1;34m\]\u \[\033[1;32m\]@\[\033[1;34m\] \h \[\033[1;30m\]::\[\033[1;37m\] $(_chomp_path $(pwd)) \[\033[1;30m\]%%\[\033[0m\] '

If anyone wants to improve that function, let me know. It “fails” on directories with spaces in it.

It should be no secret that this site and my other co-location needs are hosted at Linode.com, for which I am a happy customer running Gentoo Linux.

The reason for this post is that after an announcement today. All I had to do was reboot and then I received a 42% RAM increase. Yay.

Thanks Linode, you are exceeding your competition!
(Shameless plug for my referral code )

Prenote: According to tunnelbroker.net there are only 426 days until IPv4 exhaustion, at the time of this writing.

You might have seen me say that the mirror-admin team will support IPv6 rotations “soon” multiple times. It took much discussion, mainly because it is a low priority subject, and thus much time as well. I say it is low priority because on our official IPv6 (rsync.ipv6.gentoo.org) rotation we only see about ~10-15 client syncs per day out of ~23000. Yes, there will be some stats generated “soon” for some value of soon . We decided to move away from dedicated v4 and v6 rotations and instead used mixed rotations.

But, I digress, the point of this post is to highlight that the rsync.de.gentoo.org rotation will be the first to get full IPv6 support. That is, if the sponsor has IPv6. I just added one IPv6 mirror to the rotation now. In a few days, I’ll make a call to other members in the de rotation and then it will be declared full support to the extent possible. From there, the timeline will go something like this:

1. Call for more .de mirrors that have IPv6 to get added to the rotation
2. Call for the rest of the community mirrors that have IPv6 to get added to the rotations, not just .de.
3. Wait some time to let that settle out and see if there are any problems that develop.
4. Enable mixed rotations on the country rotations using the individual country v6 addresses collected above.
5. Enable mixed rotation on rsync.gentoo.org and deprecate rsync.ipv6.gentoo.org

For clients, the default behavior of rsync on an IPv6 capable system is to use IPv6 if the DNS query returns some v6 address. If you want to explicitly use IPv4 you need to pass “-4″ to rsync. You can specify that in /etc/make.conf with the PORTAGE_RSYNC_EXTRA_OPTS variable. Rsync does the proper thing most of the time as my testing has revealed. With that said, I don’t anticipate any issues here, but please file a bug to mirror-admins if something comes up. I would be very interested in hearing about it. I’m assuming no issues, so the future plans will not be announced and it will just happen.

Just a quick note to say that http://sources.gentoo.org/, our web view for source repositories, has moved to a new host a few days ago. Some of you have noted on it being “faster” This was the goal as it is now on much improved hardware. (Thanks goto our Gentoo Linux sponsors for providing hardware/colocation)

The templates for that site are hosted at gentoo-viewvc-templates.git repo. If you want to make any improvements, I can evaluate. Please submit requests/patches to bugs.gentoo.org, not me directly.

For some reason, Linode.com (my review) sets up their hosts to use dhcpd to grab the static IPv4 address on boot. This is in contrast to Host Virtual which uses the “Gentoo-way” to set static addresses. Now, there isn’t anything exactly wrong with using dhcpd on hosts with static addresses, actually, it may be simpler (and this is probably why they did it). However, I don’t like it for a few reasons, booting takes longer as it probes for IPs and it uses extra space for dhcpd binary on a low resource host – this includes extra time for updating. I know these are minor issues, but they bother me, at least. So, let’s take the easy way and assign eth0 the IP is should have:

Snippet from: /etc/conf.d/net
config_eth0=(
    "69.164.197.24 netmask 255.255.255.0 broadcast 69.164.197.255"
    )
routes_eth0=(
    "default via 69.164.197.1"
    )

So, that makes sense for all the right reasons and there is not much more to say. Let’s shift the attention to IPv6. Linode doesn’t offer IPv6 by default unlike their competition. To be honest, I don’t need IPv6, but it is something fun to play with and I have been learning something. It turns out that my tunnel from HE.net (free) is actually lower latency to some parts of the world than my IPv4 route and almost always less hops. Using the great examples from Robin (robbat2), I was able to put my IPv6 tunnel in /etc/conf.d/net too, so that is it created on reboot as tun0. Makes sense to do, right?

Snippet from: /etc/conf.d/net
HE="2001:0470" # 2001:470::/32 is the HE.net allocation
v6net64="${HE}:1f0f:2a0" # your initial /64 allocation from HE.net

# HE.net tunnel configuration
link_tun0="eth0" # tunnel IFACE (internet-facing iface, eg ppp0/eth0)
# tunnel IPv4 endpoint, remote, HE.net tells you this
iptunnel_tun0_remote="216.218.224.42"
# tunnel IPv4 endpoint, local
# this is the address of IFACE ${link_tun0}
iptunnel_tun0_local="69.164.197.24"

iptunnel_tun0="mode sit remote ${iptunnel_tun0_remote} local
${iptunnel_tun0_local} ttl 255 dev ${link_tun0}"
mtu_tun0=1280
config_tun0="${v6net64}::2/64" # /126
routes_tun0="default via ${v6net64}::1"

This is not exactly perfect, because I am using my tunnel’s /64 as my IPv6 address. The purists might say something about this practice, I respect that, but don’t really mind for my personal use. Of course, if you didn’t have a tunnel and instead had native IPv6, it would look a lot simpler because you just add the IP and route to the interface it is on, probably eth0.

In the past few months, there have been a number of things going on. I want to share those with the readers:

• New Document: http://www.gentoo.org/main/en/mirrors-rsync.xml The tools-portage team has made app-portage/mirrorselect use this document to help users select rsync mirrors in a similar fashion as distfile mirrors. Additionally, I have a bug open to include this page in docs and/or the homepage.
• http://mirrorstats.gentoo.org – tracks community distfile mirrors for freshness. This page has been around before, but now it supports rsync and IPv6 as well.
• http://mirrorstats.gentoo.org/rsync – tracks community gentoo-portage mirrors for freshness. This page is brand new. There was an old implementation but it wasn’t kept up to date as we added new mirrors.
• New mirror-admin team member, Mark (Halcy0n).

Coming up next: Better IPv6 support, including new rotations for IPv6 only and mixed rotations.

Target Audience: Gentoo Linux developers or people otherwise interested in trying out Gentoo Prefix on a Gentoo Linux host.

The most often asked questions I hear are either: What is Gentoo Prefix about? or How is this Gentoo Prefix change going to work on normal Gentoo Linux hosts? As such, I have taken the time to put together a small, concise instruction document, here. If you have 20 minutes and 600M of free disk space, I encourage you to try out Gentoo Prefix on your Gentoo Linux host. This way, you can find out “what Gentoo Prefix is about” for yourself instead of just listening to us.

Resources:

• Linked above: http://dev.gentoo.org/~darkside/prefix/gentoo/bootstrap-gentoo.xml
• Gentoo Prefix Homepage: http://www.gentoo.org/proj/en/gentoo-alt/prefix/
• Common bootstrapping instructions (works for linux too): http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml
• #gentoo-prefix on FreeNode.
• gentoo-alt@lists.gentoo.org