TORNEVALL

Jag har länge pratat vitt och brett om ett filter jag ska göra för i första hand Chrome-läsare.

Kort handlar det om att söka igenom sociala medier efter ”ovälkomna element”. Initialt var det ”roliga Facebook-tester” jag ville slippa se, men insåg ganska fort att man kan utöka filtret till att plocka bort rasistiska webblänkar också. Tiden fanns dock inte för att åtgärda problemet, men embryon skapades och bekräftade att det är fullt möjligt att utföra det här. I dagarna insåg jag, efter en avstängning på grund av överanvändande av ordet ”mansgris” i ett antal tester – vilka bekräftade att Facebook ger sig i kast på en nivå som i det närmaste kan betraktas som antifeministiskt.

Där någonstans kände jag att ett filter inte kommer vara tillräckligt för mina syften. Risken är att min bitterhet över slapphänta ”communityregler” som tenderar att skada gemene man initierar ett projekt som förklarar krig mot hela internet. Jag inser att jag inte längre bara kan sitta stilla och tiga och se på när allt händer, så jag ska i möjligaste mån börja bygga en alphaversion av något slags embryo på en mycket grundläggande nivå. Sen får vi se var det leder.

Jag brukar säga att jag ska ta tag i saker och sen går det tre år utan att sakerna blivit tagna i. Denna gången har jag dock lyckats ta tag i både layouter och länkar på den här sidan så då kanske det kan bli intressant snart igen. För mg alltså. Det är väl föga troligt att jag dragit något speciellt intresse till mig med de senaste årens skrivande.

Jag lade dock märke till, i takt med att jag blev äldre, att gamla inlägg börjat bli ganska tramsiga. De som orkat följa ett inlägg vart tredje år, har förmodligen insett att åtskilligt antal skrivelser har blivit rensade för att passa bättre. Nu tänkte jag dock äntligen våga göra något jag inte gjort tidigare: Dela upp saker. Och än så länge är jag antagligen inte helt nöjd.

Va?

Eftersom jag ständigt försöker hitta på projekt som aldrig kommer någon vart har jag på något sätt lyckats uppnå en milsten i projektandet. Det betyder alltså att om man verkligen vill följa med vad som händer på den fronten så skall man kunna följa det arbetet på https://developer.tornevall.net i stället. Men det förutsätter också att det inte är något av ytterst personligt intresse. Det finns iallafall fler länkar till likvärdiga saker här på sidan också.

tldr; Det har i det stora hela hänt så pass mycket grejer att det kommer ta tid att gå igenom allt. Allt kan inte skrivas öppet heller, eftersom det finns en privat sfär också, som i viss mån – så att säga – kan vara känsligt.

Väl mött. Så länge.

I’ve been working on a gre tunneling interface for a while, but had wishes to make my OpenVZ host take care of the services that should host the tunnel – like for example, instead of assigning each single IPv6-address manually via vzctl, addressing should be handled from the container. And as long as vzctl and the venet-interfaces is used, it has to be done this way. With OpenVZ this is not entirely obvious, since documentation is not always collected in the same place.

As a matter of fact, after searching half of the day, I think I’ve got it covered. First, make sure you’re not using vzctl –ipadd, when you’re adding a larger subnet. Let’s use an example:

vzctl set <ctid> ---ipadd 2a01:299:a0:7000::/64

The example above will only assign one ip – 2a01:299:a0:7000:: – to your container, not the entire subnet. To have more addresses in this case, you have to make vzctl set them up in the same way: 2a01:299:a0:7000::1/64, 2a01:299:a0:7000::2/64, etc. The real magic occurs when you’re starting to use veth and brctl correct. To make it quick:

vzctl set <ctid> --netif_add eth0 --save

# Find the right veth-interface and ...
brctl addif br0 veth-interface

In the OpenVZ release I use, the bridging is set up by linking br0 with the created vethinterface – how to identify this interface when having more containers than one is currently undicovered ground as, again, documents are not very clear on this. I’ve found names like veth101.0 have been used, but in my case – with Virtuozzo 7.x – I get interfaces like veth123a4bcd, and they are a bit hard do identify and connect to the right containter. This should be automatically fixed with scripts that is running during the openvz startup sequences, but that part is still undiscovered.

Instead, I’ve created a cron-job that makes sure that all the interfaces are really linked up after the server boot (which is probably a high security issue if you host many containers for many users as bridging opens up networks a bit more than you probably wish):

#!/bin/bash PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin 

veth=$(ifconfig|grep veth|sed 's/:/ /'|awk '{printf $1 " "}')
echo "Bridging VE interfaces..."

for interface in $veth
do
    hasInterface=$(brctl show | grep ${interface})
    if [ "" = "$hasInterface" ] ; then
        echo brctl addif br0 ${interface}
        brctl addif br0 ${interface
    fi
done

With this little ugly one, we’re making sure that unbridged interfaces are really bridged, and only once, so brctl does not need to rerun creation all the time. I think there are much better ways of doing this, however. The last thing to do after this setup is to actually assign the subnets properly. On the host server:

ip route add <A:B:C:D::/64> dev br0

At the container:

#!/bin/bash

# Local bridge
ip -6 addr add A:B:C:D::/64 dev eth0

# Gateway
ip -6 route add <gateway> dev eth0

# Do not route ipv6 via venet0
ip -6 route del default dev venet0

# Route default via this router
ip -6 route add default via <gateway> dev eth0

# Route ipv6 via eth0
ip -6 route add default via <gateway> dev eth0