philpep's blog - tag FreeBSD

Backup zfs

Thu, 23 Jun 2011 00:00:00 GMT

J'ai mis en place un système de backup de mon serveur FreeBSD (dédié) vers un autre serveur FreeBSD (@home). Les deux machines sont en zfs, c'était pour moi l'occasion de tester zfs (send|recv) over ssh. L'idée c'est qu'on envoie les donnés de manière incrémentale entre un snapshot du jour et un snapshot de la veille. Ce que l'on gagne par rapport à des solutions comme rsync c'est de la rapidité et moins d'accès disques (zfs sait exactement ce qui a bougé entre deux snapshot), l'autre avantage c'est sur la machine de backup on a un snapshot par jour, on peut donc facilement retrouver des fichiers supprimés.

#!/bin/sh

set -e

# Used in ssh command, example user@host -p 2222
REMOTE_HOST="diophante"

# Source zfs pool
POOL_SRC="tank"

# zfs sets to backup (relative to POOL_SRC)
SETS="usr/local/vmail usr/local/data usr/local/pgsql/backups usr/home usr/local/git var/backups"

# Destination pool
POOL_DST="tank/backup/${REMOTE_HOST}"

# We use ssh connection sharing
SSH_ARGS="-o ControlPath=~/.ssh/%r@%h:%p"

# zfs snapshot prefix => tank/foo@bck-2011-05-25
PREFIX="bck-"

# Remote zfs command
REMOTE_ZFS="ssh ${SSH_ARGS} ${REMOTE_HOST} sudo zfs"

# Local zfs command
LOCAL_ZFS="sudo zfs"

# Launch master ssh for sharing connections
ssh -MNn ${SSH_ARGS} ${REMOTE_HOST} &
ssh_master_pid=$!

for zfs_set in ${SETS}
do
    # Test if destination exist
    ${LOCAL_ZFS} list -H ${POOL_DST}/${zfs_set} >/dev/null

    date_suffix="${PREFIX}`date +%F`"
    snap="${POOL_SRC}/${zfs_set}@${date_suffix}"
    old_snap=`${REMOTE_ZFS} list -Ht snapshot 2>/dev/null | grep "^${POOL_SRC}/${zfs_set}@${PREFIX}" 2>/dev/null| awk -F' ' '{ print $1 }' 2>/dev/null`
    if [ "${old_snap}" ]
    then

        if [ "${old_snap}" != "`echo ${old_snap} | head -n 1`" ]
        then
            echo "[!] Multiple zfs snapshot found: ${old_snap}"
            echo "[!] Consider changing PREFIX or fix the issue yourself"
            continue
        fi

        if [ "${old_snap}" = "${snap}" ]
        then
            echo "[!] ${snap} exists"
            continue
        fi
    fi
    echo ${REMOTE_ZFS} snapshot "${snap}"
    ${REMOTE_ZFS} snapshot "${snap}"

    if [ "${old_snap}" ]
    then
        extra_args="-i ${old_snap}"
    else
        extra_args=""
    fi

    echo ${REMOTE_ZFS} send $extra_args "${snap}" '|' ${LOCAL_ZFS} recv -F "${POOL_DST}/${zfs_set}"
    ${REMOTE_ZFS} send $extra_args "${snap}" | ${LOCAL_ZFS} recv -F "${POOL_DST}/${zfs_set}"

    if [ "${old_snap}" ]
    then
        echo ${REMOTE_ZFS} destroy "${old_snap}"
        ${REMOTE_ZFS} destroy "${old_snap}"
    fi
done

kill $ssh_master_pid

Le script est aussi disponible sous forme de gist github.

Sur mes deux machines j'ai un user backup qui peut exécuter zfs avec sudo, l'user backup sur la machine de backup peut accéder en ssh à l'user backup (vous suivez ?) sur la machine à sauvegarder au moyen d'une clé ssh dédiée sans mot de passe.

Le script se lance donc sur la machine de backup (en ayant pris soin de créer tous les sets zfs qu'on va sauvegarder). La première fois il va transférer le set en entier, et les jours suivants il va envoyer de l'incrémental, il faut au minimum un jour entre chaque backup mais rien ne vous empêche de mettre l'heure dans le nom du snapshot.

Commentaires, patchs bienvenus.

PS: Ça fait 6 mois que j'ai pas posté sur ce blog, c'est parce que je travaille et même si je trouve encore un peu de temps pour faire mon propre code c'est moins le cas quand il faut le décrire ici. Par contre je maintient une liste de posts à faire sur ce blog, je rattraperais mon retard bientôt.

Mon réseau

Sat, 18 Dec 2010 00:00:00 GMT

Ça faisait un petit moment que je devais refaire ma homepage. C'est chose faite (rechargez la page si vous avez encore l'ancienne en cache, c'est full statique avec un trèèèès long ttl).

J'y décris un peu ce qui se passe dans les trois serveurs que j'administre, pour moi, pour les amis, pour des logiciels libres comme wmfs et pour les causes que je défends avec une association, le cerf de grésigne et un miroir wikileaks.

En modifiant ma map nagios j'ai réussi à faire quelque chose de pas mal pour mieux visualiser la chose :

Ça fait maintenant deux ans que l'aventure a commencée, objectif auto-hébergement et auto-formation à l'administration systèmes. Je dois dire que ça a plutôt bien marché puisque l'infrastructure et mes connaissances n'ont cessés de progresser.

Fin 2008 Pendant les 3 premiers mois philpep.org n'existait que sur mon portable (sous gentoo, allumé 24h/24), c'était un serveur git pour partager mon code.
Début 2009 j'ai récupéré un vieux pentium III gracieusement donné par une association Toulousaine sur lequel j'ai installé FreeBSD (7.0 puis 7.1) qui a commencé à faire du mail.
Mai 2009 je récupère un pentium 4 avec plus de RAM.
Fin 2009 je m'achète une alix2d3
Début 2010 je prends une machine virtuelle chez lost-oasis (sous FreeBSD puis Debian) pour fournir un MX et DNS secondaire.
Juillet 2010 je m'achète une nouvelle machine avec plus de RAM et qui consomme moins
Fin 2010, la machine virtuelle est maintenant chez Hetzner, et sous FreeBSD 8.1 avec un vpn entre mes deux locations.

Installer et booter une FreeBSD zfs on root depuis Debian/Grub2

Mon, 29 Nov 2010 00:00:00 GMT

J'ai une partition primaire de libre sur mon laptop sous Debian , je comptais y installer une FreeBSD full zfs. Le problème c'est que mon laptop n'a pas (plus) de lecteur cd, et que je me voyais mal faire une installation zfs un peu ardue en pxe et sans avoir la doc dans $BROWSER.

Alors je me dis qu'installer FreeBSD sur la partition libre depuis ma Debian testing avec zfs-fuse est possible. Évidement pas de chroot possible, mais y'a même pas besoin. Le plus dur ça a été de démarrer la FreeBSD avec grub2, mais je suis tombé sur la bonne doc. Voilà la manip sans attendre que qemu se lance.

On installe les petits (gros) tools qu'il nous faut (zfs-fuse est dans testing ou sid) :

sudo apt-get install bsdtar zfs-fuse lftp

On récupère une distribution binnaire de FreeBSD (ici 8.1-RELEASE i386)

mkdir ~/freebsd && cd ~/freebsd
lftp -c "open ftp://ftp.fr.freebsd.org/pub/FreeBSD/releases/i386/8.1-RELEASE/; mirror base"
lftp -c "open ftp://ftp.fr.freebsd.org/pub/FreeBSD/releases/i386/8.1-RELEASE/; mirror kernels"
# Et si vous voulez les man
lftp -c "open ftp://ftp.fr.freebsd.org/pub/FreeBSD/releases/i386/8.1-RELEASE/; mirror manpages"

Ensuite on crée sa pool zfs sur la partition cible (en forçant la version en 14, version de zfs sur FreeBSD)

sudo zpool create -o version=14 tank /dev/sda3
sudo zfs create tank/root
# Ici on peut créer tous les datasets qu'il nous faut

On extract tout ça :

cd ~/freebsd/base && cat base.?? | sudo bsdtar --unlink -xpzf - -C /tank/root
cd ~/freebsd/kernels && cat generic.?? | sudo bsdtar --unlink -xpzf - -C /tank/root/boot
cd ~/freebsd/manpages && cat manpages.?? | sudo bsdtar --unlink -xpzf - -C /tank/root

Les finitions :

# On utilisera le kernel GENERIC
sudo rmdir /tank/root/boot/kernel && sudo mv /tank/root/boot/GENERIC /tank/root/boot/kernel

# On copie le cache zpool pour que la freebsd retrouve "tank"
sudo cp /var/lib/zfs/zpool.cache /tank/root/boot/zfs/

# On évite un warning
sudo touch /tank/root/etc/fstab

# On se fait un rc.conf
cat << EOF | sudo tee /tank/root/etc/rc.conf
hostname="shen.philpep.org"
keymap="fr.iso.acc"
zfs_enable="YES"
EOF

# On met mountpoint / pour tank/root (comme ça tank/root/... se montera à partir de /)
sudo zpool export tank
sudo zpool import -R /mnt tank
sudo zpool set mountpoint=/ tank/root

Et maintenant le plus dur, grub2 :

menuentry 'FreeBSD' {
    insmod zfs
    search -s -l tank
    kfreebsd /root@/boot/kernel/kernel
    kfreebsd_module_elf /root@/boot/kernel/opensolaris.ko
    kfreebsd_module_elf /root@/boot/kernel/zfs.ko
    kfreebsd_module /root@/boot/zfs/zpool.cache type=/boot/zfs/zpool.cache
    set kFreeBSD.vfs.root.mountfrom=zfs:tank/root
}

Donc avec cette syntaxe on peut charger des modules au boot et écrire dans des variables sysctl (chose qu'on fait dans /boot/loader.conf avec le bootloader de FreeBSD).

Ça juste marche, et je trouve ça bien pratique, surtout qu'on peut se servir du pool zfs depuis Debian, et on peut aussi monter l'ext3 depuis FreeBSD.

EDIT: Je ne peut pas garantir que ce soit très fiable tout ça. Prudence donc. Si vous avez des problèmes au boot de FreeBSD (truc du style "alloc magic is broken") vous pouvez essayer de remplacer search -s -l tank par set root=(hd0,3) (avec la pool en /dev/sda3 chez moi).

NSD pour remplacer BIND

Wed, 17 Nov 2010 18:31:30 GMT

Je loue une machine virtuelle chez lost-oasis à (12€ par mois, 256Mo de RAM) pour faire du monitoring nagios, du mx/dns secondaire et du mirror http pour mes autres machines dans mon appart. Elle tourne sur Debian (en paravirtualisation kvm, virtio etc), avec de l'openvz par dessus. 256Mo ça fait pas beaucoup, et en browsant sur mon top, j'ai remarqué que c'était bind qui prenait le plus de mémoire (loin devant postgresql et php-cgi).

Je me met donc à la recherche d'un serveur dns qui serait plus léger que bind et qui fasse aussi bien dns primaire et secondaire pour mes 5 petites zones et je me souviens avoir vu passer une news à propos de l'intégration récente de nsd dans OpenBSD-Current. Ni une ni deux je dégaine mon apt-get install nsd3 et après quelques jours d'utilisation j'en suis très content.

Ce qu'il faut savoir à propos de nsd :

C'est un serveur authoritative only (contrairement à bind qui fait aussi cache et récursion)
Il est utilisé par quelques uns des root dns servers (on peut donc lui louer une certaine robustesse)
Il sait lire les même fichiers de zones que bind
La configuration est extrêmement simple
Il est bien plus léger en RAM que bind même configuré pour faire la même chose.
Il fonctionne très bien avec bind en master (j'ai pas testé dans l'autre sens)

Que du bon donc, laisser moi vous montrer un bout de config comme c'est simple :

server:
    hide-version: yes

# Une config master avec deux slaves 
zone:
    name: "philpep.org"
    zonefile: "master/philpep.org"

    notify: 217.70.177.40 NOKEY
    provide-xfr: 217.70.177.40 NOKEY

    notify: 212.85.155.53 NOKEY
    provide-xfr: 212.85.155.53 NOKEY

# Une config slave avec un master
zone:
    name: "philpep.org"
    zonefile: "slave/philpep.org"

    allow-notify: 82.229.137.130 NOKEY
    request-xfr: AXFR 82.229.137.130 NOKEY

# Apparemment nsd master ne gère que les transferts de zone AXFR (et pas IXFR)
# Ça n'a pas d'incidence l'un est testé puis l'autre si ça marche pas. Mais vous pouvez éviter
# un message de log en mettant AXFR dans request-xfr dans le cas d'un nsd master et slave.

Les zones sont strictement les mêmes que celles de bind.

Bien sûr il est possible de faire des config bien plus velues avec des clés pour faire des zones dynamiques, du chroot etc, voyez nsd.conf(5)

Il y a aussi un utilitaire bien convi pour controler le serveur : nsdc(8). Avant de démarrer le serveur pour la première fois, il faut compiler les zones avec nsdc rebuild.

J'ai trouvé nsd tellement pratique que je l'ai aussi installé en master sur mon serveur FreeBSD (dns/nsd), bind sert toujours pour le cache,récursion et mes zones en local, mais je vais certainement le remplacer par un djbdns ou un dnsmasq

Le script rc de nsd sur FreeBSD /usr/local/etc/rc.d/nsd est pas terrible, utilisez plutôt nsdc ou attendez que mon patch soit accepté :-)

NanoBSD avec / en nfs

Wed, 03 Nov 2010 00:00:00 GMT

Dans un précédent post j'expliquais comment utiliser le script /usr/src/tools/tools/nanobsd.sh des sources FreeBSD pour construire un système FreeBSD pour l'embarqué.

Dans le processus de création d'un tel système, il peut être utile de tester son système sans utiliser la carte flash. On peut adapter le système en le testant sur NFS et n'écrire l'image finale sur la carte flash que quand on a fini.

kernel

Il faut compiler le kernel avec support NFS et NFS comme système de fichier racine

options NFSCLIENT
options NFS_ROOT

dhcpd.conf

Avec l'option root-path on spécifie le path du montage nfs au client dhcp.

filename "pxeboot";
next-server 192.168.0.20; # le serveur tftpd
option root-path "192.168.0.20:/usr/obj/nanobsd.solo/_.w; # le montage NFS

inetd.conf

Le bootloader pxeboot est récuperé via tftp, lui même activé par inetd

tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -s /tftpboot

pxeboot

On compile pxeboot avec un baud de 115200 sur la sortie série.

cd /usr/src/sys/boot
make BOOT_PXELDR_ALWAYS_SERIAL=1 BOOT_COMCONSOLE_SPEED=115200
mkdir /tftpboot
cp i386/pxeldr/pxeboot /tftpboot

nfs

Juste une ligne dans /etc/exports, 192.168.0.1 étant l'IP donnée par mon serveur dhcp à la machine cible.

/usr/obj/nanobsd.solo/_.w -alldirs -maproot=root 192.168.0.1

rc.conf

On active tout ça dans /etc/rc.conf

 inetd_enable="YES"
 nfs_server_enable="YES"
 rpcbind_enable="YES"
 mountd_flags="-r"
 dhcpd_enable="YES"

Et on démarre les services :

 /usr/local/etc/rc.d/isc-dhcpd start
 /etc/rc.d/inetd start
 /etc/rc.d/rpcbind start
 /etc/rc.d/nfsd start

Maintenant il faut modifier le système généré par NanoBSD car il s'attend à avoir la carte flash comme système de fichier.

J'ai juste crée une fonction dans ma config nanobsd (fonction à enlever quand on crée les images disques bien entendu) :

post_nfsroot {
    rm ${NANO_WORLDDIR}/etc/fstab
    rm ${NANO_WORLDDIR}/conf/default/etc/remount
    echo "" > ${NANO_WORLDDIR}/conf/base/etc/fstab
}

late_customize_cmd post_nfsroot

Voilà, n'oubliez pas l'option -i pour gagner le temps de construction des images disques et bon debug :)

Ma conf NanoBSD

Fri, 17 Sep 2010 00:00:00 GMT

Je suis l'heureux possesseur d'une alix 2D3, un temps elle a tournée sous OpenBSD mais quand est venue la carte wifi non supportée j'ai du changer d'OS pour FreeBSD et les drivers madwifi. Un jour j'en ai eu marre de me battre avec mount -uw / et les devices md(4) et j'y ais mis une pfsense, au début l'interface web c'est convi, mais vite on se sent limité, et ne pas éditer mon pf.cont(5) avec vim me rendait malade.

Puis j'apprends qu'il existe un script dans les sources FreeBSD qui permet de faire une FreeBSD pour l'embarqué (ie, petite taille, lecture seule + ram disk). C'est marqué dans le titre, il s'agit de nanobsd(8).

C'est très bien foutu et on est assez émerveillé quand on connait pas les techniques de l'embarqué comme moi.

En gros vous faites un fichier de config en shell, /usr/src/tools/tools/nanobsd/nanobsd.sh se charge de vous compiler le world et le kernel et mettre tout ça dans une image disque.

Il y a beaucoup de paramètres customisables, une simple lecture du script vous les donnera tous. Nanobsd génère 2 images, une image disque complete (.disk.full) et une image avec seulement une partition (.disk.image). L'image complète comporte 3 partitions, les deux premières sont identiques en tailles et contiennent les mêmes données que .disk.image, lors de la première installation vous utilisez .disk.full, et pour mettre à jour vous utilisez _.disk.image à écrire sur la partition que vous n'utilisez pas actuellement (comme ça pas besoin de sortir la carte flash pour mettre à jour).

Nanobsd monte une des deux partitions sur / (en read-only), et deux ram disk pour /etc et /var (/tmp est linké avec /var/tmp, /usr/local/etc sur /etc/local). Pour rendre les changements sur /etc persistants, on utilise la troisième partition qui se monte sur /cfg, tout les fichiers de /cfg sont écrits sur /etc au boot.

Il y a un script simple pour comparer /etc et /cfg pour sauvegarder les changements.

% mount /cfg
% touch /cfg/rc.conf # si le fichier n'existe pas dans /cfg il n'est pas copié
% umount /cfg
% sh /root/save_cfg
/etc/rc.conf --> /cfg/rc.conf
%

Voyez le tgz avec ma config, vous y trouverez la config kernel, la config nanobsd, et les fichiers que j'ai mis dans /usr/src/tools/tools/nanobsd/Files/

Avec en particulier dnsmasq.conf qui bloque au niveau dns les publicités (avec une liste updatée tous les jours).

Mon alix sert donc de routeur, serveur dns/dhcp/impression. Sendmail relaye vers mon serveur interne, et syslog envoie tout à mon serveur.

% cd /usr/src/tools/tools/nanobsd/
% cp ~/solo/alix.cfg .
% cp -r ~/solo/Files/* Files/
% cp ~/solo/SOLO /usr/src/sys/i386/conf/
% sh nanobsd.sh -c alix.cfg
% wait
% qemu -hda /usr/obj/nanobsd.solo/_.disk.full -m 512 -no-acpi -nographic -cpu pentium
# Hmm quelque chose ne va pas, mais j'ai pas envie de rebuild world et/ou kernel
% sh nanobsd.sh -h

Mon script utilise des packages préconstruits, si vous voulez les compiler vous même il y a une fonction pour ça dans nanobsd.sh

Pour finir (ou commencer), voici la doc nanobsd

Voilà, ma config est certainement loin d'être parfaite niveau taille système mais ma carte flash fait 4G (donc 2G utilisable pour le système) et c'est largement suffisant pour faire tourner une FreeBSD "pas trop dépouillée".

Pour mettre à jours (j'ai gzip mon image avant) en supposant que le système tourne sur la partition 1:

% ssh phil@aldo cat /usr/obj/nanobsd.solo/_.disk.image.gz | zcat | sh updatep2
% reboot

J'ai modifié updatep{1|2} en ajoutant gpart set -a active -i PARTITION_INDEX ad0 en raison d'un problème que vous aurez peut être (la nouvelle partition est pas marquée active...)

Si le sujet vous intéresse, il y a un projet linux embarqué sympa qui s'appelle buildroot où là on peut carrément construire sa chaîne de compilation croisée (arm, mips etc), et construire un système embarqué très personalisé. Dommage qu'il n'existe pas un tel projet basé sur le kernel BSD (un jour peut être...)

Réplication de tables PostgreSQL avec londiste

Sat, 14 Aug 2010 00:00:00 GMT

Je me suis mis un petit mx secondaire, ce n'est pas vraiment utile dans mon cas, mais j'ai des pulsions d'admin en ce moment je ne peux pas résister.

Et j'ai même fait pire en termes de simplicité, ma liste d'adresse n'étant pas très mouvante répliquer les tables postgresql est vraiment inutile dans mon cas. Mais le sujet m'intéresse alors allons y.

Les besoins :

master/slave (pas d'écriture sur la table répliquée)
Quand le master tombe (même pendant plusieurs jours) on doit pouvoir lire sur le slave
Quand le slave tombe, ça ne doit pas empêcher d'écrire sur le master

Donc il me fallait un système asynchrone, facile à utiliser et à resynchroniser quand un des deux serveurs tombe.

En gros pour répondre à ces besoins il y a deux systèmes de réplication PostgreSQL, slony et londiste. Slony m'avait l'air assez complexe à utiliser, et la resynchronisation après une panne risquée, londiste fait partie des Skytools un ensemble d'utilitaires en python, dont PGQ un système de réplication des résultats basés sur les trigger postgresql.

Quand on écrit sur le master, via les trigger ça met dans une queue, et un daemon s'occupe de donner les résultat de la queue aux slaves qui le demandent (tout ce fait à travers postgresql). Du coup en termes de réseau, il faut juste que les slaves aient accès aux tables répliquées.

Une utilisation sympa de londiste, c'est pour migrer de version postgresql. Si la base est grosse, faire un pg_dump/pg_restore prend du temps et si l'application est critique et fait beaucoup d'écritures, le dump est déjà obsolète quand il est fait. Pour éviter d'avoir à bloquer l'application pendant la migration, on peut faire une réplication (vers un slave avec la nouvelle version de PostgreSQL), qui prendra son temps mais une fois finie, on aura deux base identiques (à quelques secondes près). Alors on peut faire une basculement sur le slave et la coupure du service ne dure que quelques minutes.

Moi je veux juste répliquer une table (les alias de postfix), entre mon mx primaire et secondaire, avec deux serveurs sous FreeBSD, il faut installer skytools (sur les deux) :

[root] % portmaster databases/skytools

Ensuite créer un utilisateur (ou utiliser un déjà existant).

[pgsql] % createuser -S -D -R -P replication
Enter password for new role: rirififiloulou

On va répliquer la table alias de la base postfix, il faut créer la base et la table sur le slave et donner des droits sur le master. La base et la table peuvent avoir des noms différents sur les deux serveurs (ce n'est pas le cas ici).

[pgsql] % psql -d postfix
postfix# GRANT ALL ON alias TO replication;

Autoriser la connexion du slave vers le master. (à faire sur le master naturellement)

[root] % $EDITOR ~pgsql/data/pg_hba.conf
host    postfix    replication    IP_SLAVE/32    md5

Faites en sorte que le firewall laisse passer tout ça

Depuis le slave, créez la base et copiez le schéma de la table, on en profite pour rajouter une entrée dans le ~pgsql/.pgpass pour ne plus avoir besoin du password :

[pgsql] % cat >> .pgpass << EOF
MASTER:PORT:postfix:replication:rirififiloulou
EOF
[pgsql] % createdb postfix
[pgsql] % pg_dump -h MASTER -p PORT -U replication -d postfix -t alias -s | pgsql -d postfix

Ensuite créez la configuration du daemon pgq (à lancer sur le master, avec l'user pgsql), dans ~pgsql/postfix.ini

[pgqadm]
job_name = postfix_ticker

db = dbname=postfix
# how often to run maintenance [seconds]
maint_delay = 600

# how often to check for activity [seconds]
loop_delay = 0.1
logfile = ~/%(job_name)s.log
pidfile = ~/%(job_name)s.pid

Install de pgq sur la base et lancement du daemon :

[pgsql] % pgqadm.py postfix.ini install
[pgsql] % pgqadm.py postfix.ini ticker -d

Maintenant sur le slave, configuration de londiste (toujours avec l'user pgsql), postfix.ini

[londiste]
job_name = postfix_alias

provider_db = dbname=postfix port=PORT host=MASTER user=replication
subscriber_db = dbname=postfix port 5432 host=localhost
pgq_queue_name = postfix
logfile = ~/%(job_name)s.log
pidfile = ~/%(job_name)s.pid

On installe (qu'une seule fois) et on lance le daemon londiste (toujours depuis le slave) :

[pgsql] % londiste.py postfix.ini provider install
[pgsql] % londiste.py postfix.ini subscriber install
[pgsql] % londiste.py postfix.ini replay -d

Ensuite on peut ajouter des tables à la réplication (aussi des séquences avec add-sec) :

[pgsql] % londiste.py postfix.ini provider add public.alias
[pgsql] % londiste.py postfix.ini subscriber add public.alias

Et voilà la réplication lancée, il y a un tas d'autres commandes sympa, notamment repair/compare qui permet une resynchronisation.

% man pgqadm
% man londiste

Et un tuto bien sympa ainsi qu'une publication dans GNU/Linux magazine.

installation serveur git avec gitosis, lighttpd et cgit

Wed, 11 Aug 2010 03:35:42 GMT

Pour faire revivre un peu ce blog déserté (en particulier par moi même), un petit billet sur la config de mon serveur git.

Les dépôts git peuvent se trouver sous deux formes :

Une forme pour le développeur/contributeur, c'est ce qu'on obtient avec git clone
Une forme pour le serveur, que l'on a avec git clone --bare

En fait on clone toujours depuis un dépôt bare, de la même manière on push sur un dépôt bare.

% git clone --bare git://git.wmfs.info/wmfs.git
Initialized empty Git repository in /tmp/wmfs.git/
remote: Counting objects: 5011, done.
remote: Compressing objects: 100% (1096/1096), done.
remote: Total 5011 (delta 3909), reused 5011 (delta 3909)
Receiving objects: 100% (5011/5011), 844.06 KiB, done.
Resolving deltas: 100% (3909/3909), done.

% ls wmfs.git
branches  config  description  HEAD  hooks  info  objects  packed-refs  refs

% git clone ./wmfs.git
Initialized empty Git repository in /tmp/wmfs/.git/

% ls wmfs
CMakeLists.txt  cmake_uninstall.cmake.in  COPYING  rc  README  src  TODO  wmfs.1  wmfs.desktop  wmfs.doxygen.in  wmfsrc.in

Dans ce dépôt bare il y a tout un tas de choses, notamment les hooks qui permettent de lancer des commandes avant/après un push et tout autre sortes d'événements.

Git permet de cloner/pusher depuis/vers des dépôts bare d'au moins trois manières différentes.

Par ssh
Par le protocole git (sur le port 9418 par défaut)
Par http

Pour ssh, si la sécurité nécessite d'avoir des droits par utilisateurs on peut utiliser gitosis qui va créer un utilisateur git avec un ~git/.ssh/authorized_keys qui limite l'accès aux utilisateurs.

L'install et l'utilisation est simplisme, voyez la doc de gitosis pour faire des choses plus velues :

% make -C /usr/ports/devel/py-gitosis install
% sudo -H -u git gitosis-init < /votre/clef/ssh/publique/id_rsa.pub
% git clone git@serveur:gitosis-admin.git
% cd gitosis-admin    
% >> gitosis.conf
[repo foo]
daemon = yes
^D
% git commit -a -m "Ajout depot foo" && git push
% mkdir /tmp/foo && cd /tmp/foo
% echo "foo" > bar
% git init
% git add bar
% git remote add origin git@serveur:foo.git
% git push origin master:refs/heads/master

Et voilà votre premier dépot git.

Bon là par ssh, seuls les utilisateurs autorisés pourront cloner. Il nous faut un moyen public pour permettre à quiconque de cloner.

Par le protocole git c'est très facile :

% >> /etc/rc.conf
git_daemon_enable="YES"
git_daemon_directory="--base-path=/usr/local/git/repositories"
^D
% /usr/local/etc/rc.d/git_daemon start
# Testons par le protocole git
% git clone git://serveur/foo.git

Mais si vous voulez offrir un service un peu plus complet comme github, il faut permettre le clone par http parce que si les utilisateurs sont derrière un firewall nazi qui laisse passer que le port 80 sortant ils ne pourrons pas contribuer à vos softs.

Pour celà il suffit de configurer le serveur web qui sert /usr/local/git/repositories, ainsi nos amis nazis pourront faire du git clone http://serveur/foo.git.

Allons y avec lighttpd puisqu'il faut faire un choix.

% >> /usr/local/etc/lighttpd.conf
$HTTP["host"] == "serveur" {
    server.document-root = "/usr/local/git/repositories"
}
% /usr/local/etc/rc.d/lighttpd reload
% git clone http://serveur/foo.git
# Arf ça marche pas, permission denied
% cd /usr/local/git/repositories
% chmod o+rx foo.git
% git clone http://serveur/foo.git
# Arf, ça marche toujours pas, il me cause d'un git update-server-info
% cd /usr/local/git/repositories/foo.git
% git update-server-info
% cp hooks/post-update.sample hooks/post-update
% git clone http://serveur/foo.git
\o/

Bon et pour faire un peu plus "pro", il nous faut un gitweb celui par défaut en perl me plait pas trop, je préfère nettement cgit

% make -C /usr/ports/devel/cgit
% >> /usr/local/etc/cgitrc
clone-prefix=git://serveur
virtual-root=/
snapshots=tar.gz tar.bz2

repo.url=foo.git
repo.path=/usr/local/git/repositories/foo.git
^D

Comme on est malins, on va le mettre sur le même virtualhost. Et on va faire même encore plus fort, on va le mettre le gitweb ET le clone sur http://serveur/foo.git.

Pour ça il faut matcher le client git dans la conf lighttpd :

$HTTP["host"] = "serveur" {
    server.document-root = "/usr/local/git/repositories"
    # Et si ce n'est pas le client git
    $HTTP["useragent"] !~ "^git" {
         server.document-root = "/usr/local/www/cgit/"
         index.file.name = ("cgit.cgi")
         cgi.assign ("cgi.git" => "")
         server.error-handler-404 = "cgit.cgi"
         url.rewrite-once = ("^/([^?/]+/[^?]*)?(?:\?(.*))?$" => "/cgit.cgi?url=$1&$2")
     }
}

(D'ailleurs je me demande si y'a pas un morceau de code qui fait ça tout seul dans cgit... à voir).

Voilà, mettez vos petits softs sur le nainternet et attendez les contributions ;)

Si vous voulez aller encore plus loin, mettez un bot irc qui parle quand ça push sur le dépôt git.

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