philpep's blog

IPV6 step one two

Thu, 04 Mar 2010 22:13:28 GMT

La semaine dernière, j'expliquais comment j'avais intégré l'IPV6 dans mon réseau. Depuis la donne à fortement changé puisque j'ai mis ma freebox en mode non routeur, et donc mon propre routeur sous FreeBSD (ma nouvelle carte wifi marche pas sous OpenBSD).

Du coup on en arrive au problème de la freebox qui se comporte en routeur IPV6 même en mode non routeur, voyez plutôt cette discussion FRNOG ou on nous explique que ça va peut être changer bientôt. En attendant, pas moyen de router proprement l'IPV6 de Free sans passer par un proxy ndp ou un bridge logiciel, sans compter qu'il n'est pas possible d'avoir un reverse DNS avec l'IPV6 de Free.

Grâce à sieur bsdsx j'ai découvert tunnelbrocker.net qui est un service type tunnel broker en gros les paquet IPV6 sont encapsulés dans de l'IPV4 entre chez vous et le bout du tunnel (plusieurs sont disponibles suivant votre localisation), ils fournissent un /64 ou un /48 et surtout la possibilité d'avoir un reverse DNS.

Sachez qu'il y a encore une troisième façon d'avoir une connectivité IPV6, basé sur la RFC 3068 ou encore 6to4, qui permet à n'importe qui d'obtenir un /48 sans demander rien à personne (c'est la passerelle 6to4 la plus proche de vous qui prend en charge le routage de votre traffic), le prefixe est calculé à partir de votre IPV4 publique.

J'ai grosso modo donné les 3 manière communes d'accéder au réseau IPV6 quand on est abonné chez Free. Chaque méthode à son avantage (ou pas), vous pouvez lire ce mail.

Perso j'ai choisi le tunnel broker Huricane Electrics qui marche bien, il suffit de créer un compte et un tunnel, ils donnent même la config pour FreeBSD mais pour fixer ça en dur dans rc.conf :

ipv6_enable="YES"
ipv6_gateway_enable="YES"
gif_interfaces="gif0"
gifconfig_gif0="82.229.137.130 216.66.84.46" # Mon IP publique suivie de l'IP du tunnel
ipv6_ifconfig_gif0="2001:470:1f14:7bf::2 2001:470:1f14:7bf::1 prefixlen 128"
ipv6_defaultrouter="2001:470:1f14:7bf::1"
# On relie le réseau local (sur l'interface vr1 chez moi)
ipv6_ifconfig_vr1="2001:470:1f15:7bf:dead:c0de::1 prefixlen 96"

La conf pf qui va avec :

ext_if = "vr0"
int_if  = "vr1"
gif_if  = "gif0"
tun_end = "216.66.84.46" # Le bout du tunnel

localnet = $int_if:network

block log all
pass inet proto icmp all icmp-type { echoreq unreach }
pass inet6 proto icmp6 all icmp6-type { echoreq unreach timex toobig neighbrsol neighbradv }
pass out proto { tcp udp } all
pass out on $ext_if from $ext_if to $tun_end
# On peut filtre ici (là tout passe sans filtrage)
pass in on $gif_if inet6 proto { tcp udp icmp6 } to $localnet

En cas de doutes, vous pouvez faire des nmap depuis l'interface web de tunnelbroker.net.

Pour la config du reverse DNS c'est pas plus compliqué qu'en IPV4 (juste plus long) :

; master/local6.rev
$TTL 3600 ; 1 heure
f.b.7.0.5.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa.   IN  SOA ns.philpep.org. root.philpep.org. (
            2010022601  ; serial
            8H          ; refresh
            4H          ; retry
            4W          ; expire
            1D )        ; Min TTL

@       IN       NS ns.philpep.org.
1.0.0.0.0.0.0.0.e.d.0.c.d.a.e.d     IN      PTR solo.philpep.org.
; et named.conf
zone "f.b.7.0.5.1.f.1.0.7.4.0.1.0.0.2.ip6.arpa" {
    type master;
    file "master/local6.rev";
};

Autre chose à savoir, l'IPV6 c'est pas encore ça puisqu'on est encore obligé à un moment ou un autre d'encapsuler l'IPV6 dans l'IPV4 et de passer par des tunnels plus ou moins loin, la connectivité sortante en souffre énormément (allez faire un tour sur youtube.com en IPV6 en passant par un tunnel broker...), du coup ça peut être une bonne idée de préférer l'IPV4 sur la machine où il y a le browser :

/etc/rc.d/ip6addrctl prefer_ipv4
# ou alors QUE pour firefox about:config
network.dns.disableIPv6

Si quelqu'un à déjà mis en place son réseau IPV6 en 6to4 avec stf(4), j'ai lu que la connectivité entrante était moins fiable qu'avec un tunnel broker, je voudrais que quelqu'un m'explique ??

Quelques liens :

Astuce pf du jour

Tue, 23 Feb 2010 14:09:07 GMT

J'ai la chance d'avoir une bibliothèque avec un rayon informatique bien rempli dans mon Université, dernièrement j'y ai emprunté ce bouquin. Là dedans j'y ai vu une syntaxe pour décrire le réseau local que j'avais raté quand j'ai lu la doc :

ext_if = "rl0"
# Au lieu de
localnet = "{ 192.168.0.0/24, 2a01:e35:2e58:9820::/64 }"
# On peut mettre
localnet = $ext_if:network
# Ou encore
localnet = rl0:network

Pf va lui même calculer le réseau local à l'aide de l'IP du netmask et du prefixe.

Attention tout de même si vous avez plusieurs IP (v4 et v6) sur l'interface, ça peut produire des règles redondantes, en cas de doute :

pfctl -sr

EDIT (27/02/10) : En fait quand il y a des alias sur l'IP il va les évaluer mais pour ne spécifier que l'adresses (sans les alias) on peut mettre $ext_if:network:0

IPV6 step 1

Sun, 21 Feb 2010 23:31:21 GMT

Je viens de passer tout (ou presque) mes services en IPV6 (en gardant IPV4 of course) :

% host blog.philpep.org
blog.philpep.org is an alias for lenine.philpep.org.
lenine.philpep.org has address 82.229.137.130
lenine.philpep.org has IPv6 address 2a01:e35:2e58:9820::5

Donc l'idée c'est de faire un récit de mon passage étant donné le nombre de modifications que j'ai du faire sur la configurations des machines, des softs et des pare feu. Je vais faire tout ça en 2 ou 3 billets.

Mon FAI (free) me fournis un préfixe IPV6 2a01:e35:2e58:9820::/64, et ma topologie réseau permet sans se casser la tête de faire fonctionner tout ça. Le réseau est composé de 3 machines (+ quelques intrus en wifi), un routeur OpenBSD, un serveur FreeBSD avec 4 jails et mon laptop FreeBSD. Le mode routeur est activé sur la freebox (sans DHCP) et elle installe un 192.168.0.0/24 sur lequel sont toutes les machines (jails y compris) sont configurés, ainsi toutes les machines sont reliés physiquement sur la freebox ce qui permet d'éviter les problèmes de neighbor solicitation si seul mon routeur serait physiquement relié à la freebox (on peut passer outre avec ndp(8))

En ipv4 :

+-------------+      +----------------+       +---------+
| SRV + jails |<-----|     Routeur    |<------| Freebox |
+-------------+      +----------------+       +---------+
                      Filtrage/Routage

    En IPV4 tout le trafic passe par le routeur qui dispatche sur les jails.

Et en ipv6 :

+-------------+
| SRV + jails |<------+
+-------------+       |
                      |    +---------+
                      +----| Freebox |
                      |    +---------+
+------------+        |
|  Routeur   |<-------+
+------------+

En IPV6 le traffic est distribué par la freebox,
le routeur ne sert plus (à part les services qui
sont dessus).

La configuration ipv6 des machines sous FreeBSD :

# /etc/rc.conf
ipv6_enable="YES"
ipv6_ifconfig_rl0="2a01:e35:2E58:9820::2 prefixlen 64"
ipv6_defaultrouter="2a01:e35:2E58:9820::1"

# ... La config jail
jail_lenine_ip="192.168.0.5,2a01:e35:2E58:9820::5"
# ...

Un petit reboot (où un /etc/rc.d/pleins_de_trucs restart)

Sur OpenBSD :

# /etc/hostname.vr0
inet 192.168.0.1 255.255.255/0
inet6 2a01:e35:2E58:9820::3 64
# /etc/mygate (freebox)
192.168.0.254
2a01:e35:2E58:9820::1

Après il faut modifier votre pf.conf en supprimant inet de vos règles de filtrage comme ça on sous entend inet et inet6, concernant icmp c'est plus délicat parce qu'il y a deux protocoles.

# /etc/pf.conf
pass in inet proto icmp
pass in inet6 proto icmp6

Ensuite ça devrait tourner :

% ping6 -c 2 www.google.com
PING6(56=40+8+8 bytes) 2a01:e35:2e58:9820::2 --> 2a00:1450:8002::67
16 bytes from 2a00:1450:8002::67, icmp_seq=0 hlim=54 time=49.177 ms
16 bytes from 2a00:1450:8002::67, icmp_seq=1 hlim=54 time=53.867 ms

--- www.l.google.com ping6 statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 49.177/51.522/53.867/2.345 ms

% traceroute6 www.google.com
traceroute6: Warning: www.l.google.com has multiple addresses; using 2a00:1450:8002::6a
traceroute6 to www.l.google.com (2a00:1450:8002::6a) from 2a01:e35:2e58:9820::2, 64 hops max, 12 byte packets
 1  2a01:e35:2e58:9820::1  0.589 ms  0.530 ms  0.480 ms
 2  6to4-b8-e3.intf.routers.proxad.net  35.128 ms  33.359 ms  38.152 ms
....
# HO LE VILAIN TUNEL ! :>

Vous voilà en IPV6, la première chose à faire c'est reconfigurer votre parre feu, normalement vous n'aurez pas à doubler chaque lignes, enlevez juste inet là où il faut et ça passe. Les seules lignes à doubler sont les redirections (rdr), parce qu'il faut envoyer sur une adresse IPV4 ou sur une adresse IPV6.

Dans le prochain billet j'expliquerais comment passer petit à petit ses softs sur IPV6.

Dual screen avec X.org : the right way

Sun, 14 Feb 2010 23:02:19 GMT

Sur mon laptop, j'ai deux écrans, l'écran par defaut LVDS (en 1280x800) et un autre en VGA (en 1024x768), jusqu'ici pour avoir un dual screen je mettais un :

SubSection "Display"
    Virtual 2304 800
EndSubSection

Dans mon xorg.conf (2304 = 1280 + 1024 et 800 = max(800, 768)) et la configuration dans mon .xinitrc avec xrandr :

xrandr --output VGA --pos 1280x0 --mode 1024x768
xrandr --output LVDS --pos 0x0 --mode 1280x800
xrandr --output LVDS --left-of VGA

Ça pose quelques problèmes, par exemple quand je n'utilise pas le deuxième écran je suis obligé de commenter tout ça, il y a moyen de faire plus propre :

Section "ServerLayout"
    Identifier      "Single"
    Screen          "Screen0"
EndSection

Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
EndSection

Section "Device"
    Identifier  "Card0"
    Driver      "intel"
    VendorName  "Intel Corporation"
    BoardName   "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
    BusID       "PCI:0:2:0"
EndSection

Section "Monitor"
    Identifier  "Monitor0"
    Option      "Position"  "0 0"
    Option      "PreferredMode" "1280x800"
EndSection

Section "ServerLayout"
    Identifier      "Dual"
    Screen          "Screen1"
EndSection

Section "Screen"
    Identifier  "Screen1"
    Device      "Card1"
    Monitor     "Monitor0"
    SubSection "Display"
        Virtual 2304    800
    EndSubSection
EndSection

Section "Device"
    Identifier  "Card1"
    Driver      "intel"
    VendorName  "Intel Corporation"
    BoardName   "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
    BusID       "PCI:0:2:0"
    Option      "monitor-LVDS"  "Monitor0"
    Option      "monitor-VGA"   "Monitor1"
EndSection

Section "Monitor"
    Identifier  "Monitor1"
    Option      "Position" "1280 0"
    Option      "RighOf" "Monitor0"
    Option      "PreferredMode" "1024x768"
EndSection

Ici je spécifie deux ServerLayout : Single et Dual, je déclare les deux moniteurs avec les résolutions qui vont bien et leur place respective (VGA en 1024x768+1280+0 et LVDS en 1280x800+0+0)

Ainsi au démarrage je choisis mon layout (par défaut il prendra le premier : Single) :

startx -- -layout Dual

Jouons avec kvm

Sat, 13 Feb 2010 02:31:41 GMT

J'ai codé un petit programme tout simple qui fait clignoter les leds de mon routeur dès qu'un service est par terre. Ma méthode (qui ne doit pas être la meilleure mais je m'en fout un peu) consiste à regarder régulièrement la liste des processus et détecter l'arrêt d'un service quand le processus associé n'existe plus. J'ai commencé avec un script shell, puis étant assez mauvais pour tout ce qui ressemble de près ou de loin à du script j'ai décidé de le faire en C (langage d'excellence n'est ce pas...?).

Je me suis volontairement compliqué la tache en utilisant des fonctions très proches du système, ainsi s'il est possible d'obtenir une liste de processus via ps(1) avec un popen(3) super crade ou encore sysctl(3) j'ai voulu utiliser kvm(3) kernel memory interface qui est en programmation système la méthode la plus appropriée (d'ailleurs 'ps' est codé avec ça), c'est juste une interface qui va nous permettre d'accéder au données du kernel (une copie bien entendu), ici la liste des processus en cours.

Le hic c'est que si les fonctions de kvm sont très standard l'implémentation est très différente suivant les systèmes, comme à peu près toute implémentation, l'important c'est que l'interface soit standard. Ainsi à la lecture de la structure qui décrit les processus kinfo_proc de sys/user.h on se dit chouette pleins d'info à disposition, sauf que sur OpenBSD c'est pas du tout la même forme (ni le même fichier d'ailleurs). D'où l'importance d'une interface riche et c'est ce que nous promet kvm.

Assez causé passons au code (je n'explique pas ou peu le code en dehors des fonctions kvm)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <err.h>
#include <libgen.h>
#include <fcntl.h>
#include <limits.h>
#include <paths.h>
#include <kvm.h>
#include <sys/param.h>
#include <sys/sysctl.h>
#include <sys/wait.h>
#include <sys/user.h>

void
start_leds(void)
{
    /* Ici on execute /usr/sbin/gioctl -q gpio0 led3 (on|off)
     * suivant la parité du conteur statique 'i'
     * 60 fois avec une pause d'une seconde. */
    static int i = 1;
    switch(fork())
    {
        case -1:
            err(1, "fork");
            break;
        case 0:
            execl("/usr/sbin/gpioctl", "gpioctl", "-q", "gpio0",
                    "led3", (i%2) ? "on" : "off", (char*)NULL);
            err(1, "execl");
            break;
        default:
            wait(NULL);
            break;
    }
    sleep(1);
    if (i++ <= 60)
        return start_leds();
    return;
}

int
main(int argc, char *argv[])
{
    kvm_t *kd;
    char berr[_POSIX2_LINE_MAX];
    struct kinfo_proc *p, *procs;
    int n, j, k, found = 0;
    char **pargv;

    if (argc < 2)
        errx(1, "Usage check_proc procs ...");

    /* On accède aux données du kernel qui tourne actuellement (NULL) */
    if (!(kd = kvm_open(NULL, NULL, NULL, O_RDONLY, berr)))
        errx(1, "%s", berr);

    /* On demande la liste des processus, kinfo_proc est décrite
     * dans sys/sysctl.h sur OpenBSD et sys/user.h sur FreeBSD.
     * Il nous la donne dans un tableau continu de pointeurs de
     * taille qu'on récupère dans 'n'. */
    if (!(procs = kvm_getprocs(kd, KERN_PROC_ALL, 0, &n)))
        err(1, "kvm_getprocs: %s", kvm_geterr(kd));

    for (k = 1; k < argc; k++)
    {
        for (j = 0, p = procs; j < n; j++, p++)
        {
            /* On accède à la liste des arguments du programme qui a
             * généré le processus courant. */
            pargv = kvm_getargv(kd, p, 0);
            if (pargv && pargv[0] &&
                    strstr(pargv[0], argv[k]))
                {
                    found++;
                    break;
                }
        }
    }

    if (-1 == kvm_close(kd))
        err(1, "kvm_close");

    if (found != argc-1)
        start_leds();

    return 0;
}

Et l'exécution, on veut tester si un processus du nom de 'dhcpd' tourne sur le système, si ce n'est pas le cas on lance le clignotement de la led pendant une minute :

# gcc -o check_proc check_proc.c -lkvm
# ./check_proc dhcpd

Le mien s'exécute dans un cron toute les minutes :

* * * * * /root/bin/check_proc named dhcpd adsuck ntpd

Adsuck pour remplacer privoxy

Thu, 11 Feb 2010 02:27:05 GMT

Sur les trois machines clientes chez moi (dont deux avec l'OS à la pomme et de browsers douteux), filtrer les pubs du web au niveau du réseau tout entier est vital, puis il m'arrive de tester des browsers autres que firefox (dans le genre webkit-gtk/bindings vim) et là adblock ne m'est d'aucuns secours.

Pendant un temps j'utilisais privoxy sur mon routeur OpenBSD, mais je lui ai trouvé plusieurs defauts :

Les regexp de base sont très éfficaces mais il y a malheureusement beaucoup de faux positifs.
Le temps de traitement amène une lenteur parfois perceptible.
Je l'avais en proxy transparent, donc y'a toujours quelqu'un au bout du 'telnet machin 80' (ça peut être génant)
Configuration et maintenance pas franchement agréable.

Du coup en reinstallant le routeur j'ai cherché une alternative, et j'ai trouvé adsuck. C'est du filtrage dns, assez violent mais beaucoup plus rapide et tout aussi éfficace.

Pour le moment ce soft est codé par et pour OpenBSD, mais ça doit pas être méchant à compiler sur autre chose.

L'install :

# export PKG_PATH=ftp://ftp.fr.openbsd.org/pub/OpenBSD/4.6/packages/i386/
# pkg_add adsuck
# cat >> /etc/rc.local << EOF
if [ "" != "NO" -a -x /usr/local/sbin/adsuck ]; then
    echo -n ' adsuck'; /usr/local/sbin/adsuck $adsuck_flags
fi
EOF
# cat >> /etc/rc.conf.local << EOF
adsuck_flags="-c /var/adsuck -l 127.0.0.1 -p 54 -f /files/resolv.conf /files/hosts.small /files/Hosts.pub /files/local.pub"
EOF

Comme j'ai un vrai serveur DNS (pour le réseau local mais aussi pour mes domaines), j'ai lancé adsuck sur le port 54 (dns normal c'est 53) et fait une redirection pour le réseau local avec pf, adsuck va lui même servir de proxy entre le réseau local et le serveur DNS qui tourne sur localhost en particulier.

# echo "nameserver 127.0.0.1" > /var/adsuck/files/resolv.conf
# touch /var/adsuck/files/local.pub

On lance une première fois :

# adsuck -c /var/adsuck -l 127.0.0.1 -p 54 -f /files/resolv.conf /files/hosts.small /files/Hosts.pub /files/local.pub

Si ça se lance, on peut rediriger le traffic du réseau local vers adsuck :

table <local> const { 192.168.0.0/24 }
rdr pass on $ext_if proto udp from <local> to $ext_if port domain -> lo0 port 54
# Si vous êtes vraiment méchant vous pouvez enlever le 2ème $ext_if :)

Maintenant sur une machine du réseau local :

% host www.smartadserver.com dns1.proxad.net
www.smartadserver.com has address 91.103.138.65
% host www.smartadserver.com
Host www.smartadserver.com not found: 3(NXDOMAIN)

Et vous voilà avec un net plus très neutre mais épuré de toute publicité. Pour rajouter des sites, je vous ai fait créer un /var/adsuck/files/local.pub, la syntaxe est simple :

127.0.0.1 domaine_moisi.com

Et pour faire relire les listes à adsuck :

# kill -USR1 `pgrep adsuck`

Alix fail et OpenWrt

Mon, 08 Feb 2010 14:46:46 GMT

Ce week end j'ai essuyé pas mal d'échecs en tout genres, j'ai une superbe alix qui tourne sur OpenBSD et j'ai une carte wifi en minipci dessus qui marche passablement mal sur OpenBSD (tous les modes ne marchent pas et beaucoup de pertes de paquets quand ça marche).

Du coup je me mis en tête le fait que ça tournera mieux sous un autre OS, j'ai donc essayé dans l'ordre FreeBSD, Debian et OpenWrt. Aucuns n'a su faire tourner ma carte même avec les derniers drivers, j'avais même pas d'interface, comme quoi le support matériel sur OpenBSD est pas aussi mauvais qu'on le pense.

Donc si quelqu'un à réussi à faire tourner convenablement la carte Engenius NMP-8602+ 400mW a/b/g miniPCI sur un OS libre merci de me faire signe.

J'ai donc remis OpenBSD dessus et enlevé la carte wifi (si quelqu'un est intéressé je suis prêt à la céder d'ailleurs, toute neuve jamais servie :>)

J'ai quand même beaucoup joué avec le boot pxe sur sortie série Linux/BSD donc je suis bien rodé là dessus maintenant. Et surtout j'ai découvert OpenWrt, une toute petite distribution linux pour l'embarqué, faite à la base pour flasher les firmware proprio sur les routeurs du marché elle tourne aussi bien sur tout autre matériel et c'est un projet très dynamique et original. L'installation par pxe est super simple, il suffit de compiler un ramdisk et de démarrer dessus.

$ ls -l /usr/local/pxe/
total 1796
-rw-r--r--  1 phil  phil   1786396 Feb  7 15:41 openwrt-x86-vmlinuz
-rwxr-xr-x  1 root  wheel    16466 Feb  6 21:31 pxelinux.0
drwxr-xr-x  2 root  wheel      512 Feb  7 15:41 pxelinux.cfg
$ cat /usr/local/pxe/pxelinux.cfg/default
# Simplement spécifier la vitesse du port série
# 38400 ici
serial 0 38400 0
console 0
label linux
kernel openwrt-x86-vmlinuz
append init=/etc/preinit console=tty0 console=ttyS0,38400n8 reboot=bios

Après c'est du pxe classique, tftp et dhcpd et ça démarre :

Après il suffit d'envoyer l'image sur le disque dur (soit la votre, soit celle qui est distribuée) :

root@Solo:/# wget http://downloads.openwrt.org/kamikaze/8.09.2/x86/openwrt-x86-squashfs.image
root@Solo:/# dd if=openwrt-x86-squashfs.image of=/dev/hda

Et c'est tout !

À coté de ça vous avez une interface de configuration web convi, un petit sshd dropbear et pleins de packages disponible (très orienté réseau bien sûr). Ça doit être encore plus réjouissant quand on flashe un routeur wifi proprio :)

Mais bon, alix mérite qu'on l'exploite plus que ça, j'aime bien l'interface web mais j'aime mieux éditer mon pf.conf avec vim.

Lancer lighttpd dans un environnement propre

Thu, 28 Jan 2010 00:45:29 GMT

Cela fait quelque temps que je vois mes scripts cgi sous lighttpd hériter de l'environnement root (vous savez, les export et autres setenv dans votre ~/.$SHELLrc). Et si vous êtes un peu parano comme moi ou que vous avez des données sensibles dans votre environnement il peut s'avérer utile de les cacher du script cgi.

Pour cela j'ai modifié mon /usr/local/etc/rc.d/lighttpd, du coup j'en ai même fait un bug report chez FreeBSD histoire que tout le monde en profite. Il permet même de spécifier certaines des variables d'environnement que l'on veut conserver (comme PATH qui est souvent utilisé dans les script cgi).

Avec un peu de chance (et beaucoup de temps :>) il le prendrons et vous l'aurez bientôt dans vos ports. Sinon faite le vous même à partir du patch :

cd /root
fetch http://www.philpep.org/pub/lighttpd_rc.patch
cd /usr/local/etc/rc.d/
patch -p0 < /root/lighttpd_rc.patch

L'inconvénient c'est qu'il faut le refaire à chaque mise à jours de lighttpd.

git-daemon sous FreeBSD

Tue, 26 Jan 2010 21:09:39 GMT

Si vous avez un serveur git sous FreeBSD, vous aurez très rapidement des problèmes avec /usr/local/etc/rc.d/git_daemon, genre il démarre mal, et refuse de redémarrer.

En fait il suffit d'utiliser l'option --reuseaddr qui passe SO_REUSEADDR à setsockopt pendant la création du socket serveur. Du coup il peut redémarrer même si il y avait une connexion active sur le port.

En lisant le script rc, on peut même éviter de le modifier et devoir le refaire à chaque mise à jours de git, dans /etc/rc.conf

git_daemon_enable="YES"
git_daemon_directory="--reuseaddr --base-path=/usr/home/git/repositories"

EDIT : ce n'est plus nécessaire maintenant PR ports/143275

Dont be trop evil

Tue, 19 Jan 2010 04:03:12 GMT

J'ai toujours eu du mal à me positionner par rapport à google et les faits récents viennent renforcer l'opinion de Benjamin Bayard de chez fdn qui dit (en très gros) que Google n'a pas à nous inquiéter pour l'instant parce que ce sont encore les fondateurs qui sont aux manettes et l'esprit originel est encore là.

Pourtant les raisons d'avoir peur et de commencer le boycot sont bien là puisqu'il s'agit sans doute de la plus grande centralisation de données de l'Internet. Moteur de recherche, service mail, serveurs DNS récursifs ouverts, vidéo (youtube), service de blog (blogspot), creation de documents (Google Docs) et pour aller avec tout ça une énorme régie publicitaire (AdSense). Ils savent manipuler les données dans tous les sens, mais comme ils disent : "c'est pour mieux satisfaire le client". Moi qui n'utilise que le moteur de recherche (et un compte gmail qui sert de poubelle), j'ai déjà super peur à l'idée de croiser mon dossier chez Google qui je le rappelle est autorisé à vous tracer (en france) pendant 9 mois. Mais imaginez celui de ceux qui utilisent tous les services de google (et j'en connais). Ajoutez à cela deux faits marquants

Google.cn en chine censure son moteur de recherche parce qu'ils y sont forcés par la loi. (ce n'est plus le cas aujourd'hui cf plus bas)
Gros, gros dérapage d'Eric Schmidt président de google, sur la vie privée

Je pense qu'il faut faire preuve de jugeotte. S'il y a quelque chose que vous faites et que personne ne doit savoir, peut-être qu'il faudrait commencer par ne pas le faire. Si vous avez besoin qu'on respecte à ce point votre vie privée, le fait est que les moteurs de recherche – y compris Google – enregistrent et conservent des informations pendant un certain temps. Il faut bien réaliser que nous, aux USA, sommes soumis au Patriot Act et donc qu'il est possible que toutes ces informations soient mises à la disposition des autorités à leur demande.

Et pourtant, si vous suivez un peu les actualités récentes, Google suite à une vaste opération de piratage de comptes gmails de dissidents chinois (supposée venant des autorités chinoises), vient d'enlever la censure sur google.cn et menace de quitter le pays. On peut lire beaucoup d'informations à ce sujet allez voir sur Numérama si vous êtes vraiment à la ramasse.

Personnellement je n'ai pas compris comment une entreprise aussi menaçante se met soudain à faire pression sur un gouvernement quitte à perdre un max de pognon, juste pour protéger son image de marque et pour être du coté des gentils. En fait ça rappelle une vielle histoire où Yahoo! avait collaboré avec les autorités chinoises pour espionner les boites mails de dissidents. Google essaye de ne pas reproduire cette erreur qui a beaucoup coûté à l'image de Yahoo!. Et cette décision viendrait directement d'un des deux co-fondateurs de google. Ce portrait très flatteur de l'homme (Sergey Brin) qui vient d'un journal à peu près fiable (Libération) renforce donc l'idée d'une éthique chez Google malgré les enjeux financier, ce qui n'a pas l'air d'inspirer Microsoft (Bing) qui reste en chine et collabore du moment qu'on les arrose de pognon. Le patron de Mozilla s'était donc un peu emporté quand il invitait les utilisateurs de firefox à passer à Bing..

Difficile, vraiment difficile de se faire un avis, la solution est peut être de commencer à se passer totalement de moteur de recherche, ou encore mieux de faire votre propre moteur de recherche (hein rhaamo :>)