philpep's blog - tag FreeBSD

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.

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

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

Upgrade FreeBSD 8.0 et jails

Wed, 06 Jan 2010 20:11:03 GMT

J'ai upgradé ma FreeBSD (ce serveur) et ses 4 jails de FreeBSD 7.2-RELEASE vers FreeBSD 8.0-RELEASE, voilà donc le récit de ce qui est toujours une épopée.

Dans un premier temps il faut récupérer les sources du système. J'ai fait ça à coup de csup depuis cvsup1.fr.FreeBSD.org (qui n'est autre que cvsup.free.org).

# cat /usr/local/etc/stable-supfile
*default host=cvsup1.fr.FreeBSD.org
*default base=/var/db
*default prefix=/usr
*default release=cvs tag=RELENG_8_0
*default delete use-rel-suffix
*default compress
src-all
# csup /usr/local/etc/stable-supfile

Pendant ce temps au lieu de te tourner les pouces fais toi un /etc/src.conf(5) pour customiser un peu ce qu'on va compiler dans le world. Moi je n'utilise plus sendmail, authpf, bind (j'ai déjà un bind sur mon routeur), bluetooth, les jeux, IPfilter (j'utilise pf) ni zfs.

# cat /etc/src.conf
WITHOUT_AUTHPF=YES
WITHOUT_BIND=YES
WITHOUT_BLUETOOTH=YES
WITHOUT_GAMES=YES
WITHOUT_IPFILTER=YES
WITHOUT_SENDMAIL=YES
WITHOUT_ZFS=YES

Quand csup à finit son boulot on peut lancer la compilation qui tue :

# cd /usr/src
# make buildworld

Bois une grosse tasse de café et attend sagement en lisant config(8) et $EDITOR ta config kernel dans /usr/src/sys/<arch>/conf/LAPIN, sinon le kernel GENERIC marche bien hein :-).

Une fois le buildworld terminé lance la compilation de ton kernel :

# cd /usr/src/
# make buildkernel KERNCONF=LAPIN

Pendant ce temps mettons à jours les jails. Moi j'arrête complètement les jails, je préfère un service injoignable qu'un service qui pourrait planter. Pour que le mergemaster(1) soit moins long j'ai mis quelques options dans /root/.mergemasterrc.

# cat /root/.mergemasterrc
FREEBSD_ID=yes
# /etc/rc.d/jail stop
# cd /usr/src
# make installworld DESTDIR=/path/to/jail
# mergemaster -i -C -D /path/to/jail

Réponds aux questions de mergemaster, c'est long mais nécessaire, si ça te parait trop long rajoutes -U aux options de mergemaster.

Refait la manip pour toutes tes jails. Enfin installe le nouveau kernel et reboot en Single user mode.

# cd /usr/src
# make installkernel KERNCONF=LAPIN
# shutdown -r now
## MAINTENANT EN SINGLE USER MODE ##
# adjkerntz -i
# mount -a -t ufs
# mergemaster -p
# cd /usr/src/
# make installworld
# mergemaster -i -C
# reboot

Nous voilà en FreeBSD 8.0-RELEASE-p1, maintenant il faut réinstaller tous les ports pour que les softs soient liés avec les libs de la 8.0. Alors là plusieurs méthodes possibles.

Par compilation => portupgrade -a (va faire un tour sur google.com pour plus d'info sur les options crousti de portupgrade).
En binaire, c'est ce que j'ai fait via un hack plus crade qu'un porno thaïlandais mais qui marche.

Attention lapin ! , ce script va t'installer des packages avec les options de compilation par défaut des ports. Ça va enlever ton support PGSQL de dovecot et te rajouter toute la libx11 :-), à manipuler avec précaution donc.

Mon petit script magique pkg_reinstall:

#!/bin/sh
# Force la réinstallation des
# packages pour la nouvelle release
# http://blog.philpep.org/post/Upgrade-FreeBSD-8.0-et-jails
# Je ne suis pas responsable de la casse éventuelle :-)

# Mirroir pour choper les packages voyez pkg_add(1)
# section ENVIRONEMENT.
export PACKAGEROOT="ftp://ftp.fr.freebsd.org"

# Liste des packages sur la machine
PKG_LIST=`pkg_info | cut -d' ' -f1`

for pkg in $PKG_LIST
do
    # On coupe la version du package
    # et on force la réinstallation
    pkg_add -rvF "${pkg%-*}"
done

Je lance donc mon script dans un shell de la jail (dont le JID m'est donné par jls(1)) :

# jexec 1 sh
# sh /root/pkg_reinstall

Ensuite tu peux normalement supprimer les anciennes libs et anciens fichiers de ta vielle FreeBSD :

# cd /usr/src
# yes | make delete-old DESTDIR=/path/to/jail
# yes | make delete-old-libs DESTDIR=/path/to/jail

Tu peux faire pareil pour l'hote maintenant, un coup de pkg_reinstall et yes | make delete-old(|-libs) et te voilà en 8.0 avec un système super clean.

Bonus spécial pour toi lapin !

Personnellement j'aime bien rester avec mes packages de RELEASE, donc je met pratiquement jamais à jours. Par contre l'idée d'avoir des packages avec des failles de sécurité ça m'insupporte. Donc j'utilise le grand portaudit et si il trouve un package foireux je l'upgrade vers les build de STABLE (qui sont plus récents).

# export PACKAGEROOT="ftp://ftp.fr.freebsd.org"
# pkg_add -r portaudit
# /usr/local/sbin/portautit -Fda
Problem found with phplol see http://machintruc.com/64867/php/6764

Et pour tous les packages faillibles :

# export PACKAGESITE="ftp://ftp.fr.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/Latest/"
# pkg_add -rF phplol

Te voilà avec un système très nice nice qui te laissera dormir jusqu'au prochain local root voir même jusqu'à la prochaine release.

Ssmtp pour remplacer sendmail

Mon, 04 Jan 2010 23:10:53 GMT

Sur mon serveur FreeBSD j'ai 4 jails et par défaut le système envoie régulièrement des security run output à root@localhost pour l'informer de ce qu'il se passe sur le système (nouveau fichiers etc). Tout ça c'est très bien sauf que un hote et 4 jails ça fait 5 compte mail à visiter, c'est pas trop convi et en plus on a pas envie de faire tourner sendmail juste pour ça.

J'ai donc décidé d'utiliser un MTA très simple appelé (devinez comment) : Simple smtp agent. Chaque mail envoyé depuis la machine (en appelant sendmail) partira vers un serveur smtp de mon choix, ainsi je récupère tous les mails sur mon compte mail usuel.

# cd /usr/ports/mail/ssmtp
# make install
Information for ssmtp-2.62.3:
Install notice:
sSMTP has been installed successfully.
To replace sendmail with ssmtp type "make replace"
# make replace

Ensuite j'ai crée mon /usr/local/etc/ssmtp/ssmtp.conf :

# Serveur de mail à contacter pour l'envoi + le port
# par defaut c'est le port 25
mailhub=mail.philpep.org:578
# Domaine d'où semble venir le mail
rewriteDomain=philpep.org
# Domaine à donner pendant le HELO
# À accorder avec le reverse DNS de votre machine
# vu depuis le serveur de mail.
hostname=shen.philpep.org

Arrangez vous pour que le serveur de mail accepte de vous relayer, moi c'est le cas parce que je suis en local et mon postfix relaie ce qui vient du réseau local. Mais si ce n'est pas le cas (genre vous utilisez le serveur mail de votre fournisseur de mail), on peut configurer l'authentification SMTP, SSL/TLS et tout le reste.

Ensuite désactivez sendmail dans /etc/rc.conf puisqu'il ne sert plus :

sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

Pour tester l'envoi :

$ dmesg | mail -s "works ?" lapin@barreenfer.com
$ if [[ $? -ne 0 ]]; then man ssmtp; fi

EDIT 5/01/10 17:15

client smtp -> MTA

Upgrader ses packages FreeBSD

Mon, 28 Dec 2009 02:41:09 GMT

J'ai un problème depuis longtemps avec les ports FreeBSD. Dans un premier temps je compilais tout, puis à la longue c'est assez lassant parce que ça prend du temps, des ressources et sur une machine peu puissante c'est pas franchement conseillé. Donc dans la plupart des cas j'utilise maintenant des paquet binaires compilés et distribués par le projet FreeBSD.

Je ne vais pas m'attarder à peser le pour et le contre puisqu'en réalité j'utilise aussi bien les ports que les paquets binaires suivant les dépendances du logiciel et le temps de compilation.

Environnement : FreeBSD 8.0-RELEASE i386 (à vous de changer suivant votre version et votre CPU)

Déjà une bonne chose à savoir :

$ ftp ftp://ftp.fr.freebsd.org/pub/FreeBSD/ports/i386/
....
250-descriptions of each subdirectory.
...
250-packages-*-release directories are built from the ports collection
250-shipped with the release, and are not updated thereafter.
250-
250-packages-*-stable and packages-*-current are updated roughly once a
250-week.
....

Les paquets qui nous intéressent sont donc dans packages-8-stable.

Pour installer un soft, il suffit d'un

# export PACKAGESITE="ftp://ftp.fr.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/Latest/"
# pkg_add -r firefox3

Pour mettre à jours c'est nettement moins marrant, surtout si vous utilisez conjointement un arbre des ports à jours dans /usr/ports. Les outils comme portmaster et portupgrade sont assez dur à utiliser pour mettre à jours en se basant non pas sur l'INDEX de /usr/ports mais sur celui du ftp.

D'ailleurs si quelqu'un à déjà réussi à faire proprement la manip je veux bien son /usr/local/etc/pkgtools.conf en commentaire de ce billet.

bapt est en train de porter pkgin sur FreeBSD, mais il n'est pas encore tout à fait prêt (il le sera bientôt j'espère, je ferrai un billet pour l'occasion).

Il y a une solution que j'ai trouvé sympatique en attendant pkgin, c'est les bsdadminscripts avec l'outil pkg_upgrade. C'est du shell, pas très rapide donc, mais au moins ça marche et c'est facile.

# make -C /usr/ports/sysutils/bsdadminscripts install clean

Ensuite c'est enfantin, pour tout mettre à jours et en mode verbeux :

# setenv PACKAGEROOT ftp://ftp.fr.freebsd.org
# setenv BRANCH 8-stable
# pkg_upgrade -av

Et ça marche ! Il se base sur le md5 du fichier INDEX du ftp pour savoir s'il faut mettre à jours sa base de donnée sur les ports puis compare les version installés avec les versions disponibles.

La page de man de pkg_upgrade vous donnera beaucoup d'information sur la manière dont il fonctionne.