Emile "iMil" Heitor 's home » FreeBSD

Un peu de réseau… ou presque

iMil — Sat, 09 Oct 2010 08:58:31 +0000

Au boulot, ce sont des routeurs Juniper J2350 qui se chargent d’acheminer les lutins de l’internet vers nos équipements. Depuis quelques temps, les routeurs en question s’occuppent entre autres d’annoncer nos plages d’IPs grâce au protocole BGP.

Si l’établissement des sessions eBGP avec nos fournisseurs d’accès n’a posé aucun problème, l’établissement de la session iBGP entre nos differents routeurs montrait une charge CPU, mais surtout une consommation mémoire anormales, jusqu’à provoquer recemment le crash de l’un d’entre eux.

J’ai toujours été fasciné par l’inutilité des services support des constructeurs ou autres grosses structures, et Juniper ne déroge pas à la règle. De fait, je décide donc d’exposer mon problème non pas au support officiel, qui mettra déjà une bonne 15aine de jours à comprendre ce que je veux bien dire par “iBGP”, mais plutot aux forums communautaires du fabriquant. Bien evidemment, comme dans tous les forums de la terre, on obtient en premier lieu quelques réponses des “know-it-all” qui vous ressortent le contenu d’une plaquette marketing: “I would agree, a J2320 is not designed to take a full set of routes.”, mais avec un minimum de patience, on finit par tomber sur quelqun qui sait de quoi il parle.

Un utilisateur catégorisé “Recognized Expert” me dit la chose suivante : “I have used also J2320 routers with 2x full feed on them. Works good. But I downgraded to the last JUNOS 9.3 that runs only in packet mode. That saves a couple of RAM.”

Et c’est là le tournant de l’histoire. En effet, lorsque je reçus mes jouets, je m’aperçus qu’ils tournaient sur une version bien ancienne de JunOS (le système d’exploitation dérivé de FreeBSD qui fait fonctionner ces routeurs), et comme tout bon administrateur impatient, je me jette sur les mises à jours. Grossière erreur. Ce que m’explique le monsieur du forum, c’est que depuis les releases 9.3R4 de JunOS, le démon en charge du forwarding de paquets n’est plus fwdd mais flowd_hm, une nouvelle mouture qui ne fonctionne plus en simple “mode paquet”, mais établit des sessions (stateful) afin d’inspecter le traffic (l’explication ici).

Le downgrade m’effrayant un peu, je tente 1001 méthodes pour alléger ce démon, mais rien n’y fait, ses 481M de taille font toujours souffrir mes routeurs. La seule solution: downgrader.

Bien évidemment, cette opération s’est réalisée dans la douleur; en effet, ce fameux mode flow based a impliqué des entrées dans la configuration du routeur qui ne sont pas backward compatibles. En particulier, une section zones qui définit des zones de sécurité, et plus précisemment, qui a le droit de “sortir” ou pas, et dans les versions supérieures à 9.3R3, sans cette section, le routeur est aveugle et ne peut pas récupérer sa mise à jour. L’espace du disque flash équipant le J2350 étant limité, il n’était pas possible de télécharger la mise à jour pour l’appliquer localement, j’étais donc obligé d’effectuer l’upgrade à travers le réseau, mais cette opération était vouée à l’échec puisque la mise à jour échouait en raison de l’incompatibilité de la configuration en place avec les versions antérieures. Quadrature du cercle.

Mais voila: JunOS est un UNIX, et Juniper a eu la bonne idée de laisser l’accès à cet UNIX (FreeBSD, donc) par le biais de la commande start shell.

Ainsi, tout en gardant la configuration running activée, je m’en vais modifier le fichier /config/juniper.conf.gz pour en retirer la section security, incompatible avec le downgrade. Un gunzip -c, vi, gzip plus tard, je peux tranquillement invoquer la commande CLI:

foo> request system software add validate no-copy unlink ftp://serveur/junos-jseries-9.3R3.8-domestic.tgz

Et constater que la “mise à jour” s’effectue parfaitement.

Notez qu’afin de ne pas générer de la charge inutile, j’ai au préalable désactivé les annonces vers mes voisins BGP grâce à la commande :

foo# deactivate protocol bgp group ma-session neighbor ip.de.mon.voisin
foo# commit

Un foo> request system reboot plus tard, j’admire :

--- JUNOS 9.3R3.8 built 2009-05-12 22:33:43 UTC

Et constate que cette pourriture de démon flowd_hm a disparu, avantageusement remplacé par fwdd, et que le routeur répond désormais au quart de tour, même avec toutes ses sessions BGP chargées.

Morale de l’histoire: avant de te jeter sur la dernière version d’un soft, vérifie que t’en as bien besoin… (version longue de “if it works, don’t fix it”).

Migration dspam/sqlite vers dspam/mysql

iMil — Sun, 01 Jun 2008 10:56:15 +0000

L’année dernière, je mettais en place dspam, sur mon serveur dédié. Naïf, je me disais que pour gerer mes propres mails, le backend sqlite serait amplement suffisant, et finalement tout ce petit monde a parfaitement fonctionné pendant quelques mois. Et puis la database a grossi, grossi, grossi au point d’etre lente à crever et provoquer ce type de réaction :

pid 71865 (dspam), uid 0: exited on signal 6 (core dumped)
pid 72017 (dspam), uid 0: exited on signal 6 (core dumped)
pid 72289 (dspam), uid 0: exited on signal 6 (core dumped)

Après que 2 attaques massives de spams aient écroulé la machine, je me suis enfin décidé à changer de backend… et la différence est simplement indescriptible.

L’opération s’est avérée plus simple que je ne l’imaginais. Tout d’abord, il est nécessaire de re-installer le port dspam en y ajoutant le support MySQL à l’aide de la commane make config

Un make deinstall reinstall plus loin, le binaire supporte les deux backends (sqlite et MySQL), et avant d’apporter les modifications à la configuration de dspam, nous nous assurons de créer une database dspam et de peupler cette dernière avec les commandes SQL fournies dans le package dspam :

$ mysql -u dspam -p dspam < /usr/local/share/examples/dspam/mysql/mysql_objects-4.1.sql

Nous pouvons alors modifier le fichier dspam.conf :

StorageDriver /usr/local/lib/libmysql_drv.so
# [...]
MySQLServer     /path/vers/mysql.sock
MySQLUser               dspam
MySQLPass               mangeducacaspammer
MySQLDb                 dspam
MySQLConnectionCache    10
MySQLUIDInSignature    on

Et redémarrer le serveur :

# /usr/local/etc/rc.d/dspam restart

Reste à nourrir notre nouvelle database à l’aide de deux corpus spam et ham d’environ 1000 mails chacun (voir le post de l’année dernière).

Pour finir, j’ajoute un cron-job qui nettoie la base de données tous les soirs, à l’aide d’un jeu de commandes SQL fourni par le package dspam :

30 01 * * * /usr/local/bin/mysql -u dspam --password=mangeducacaspammer dspam < /usr/local/share/examples/dspam/mysql/purge-4.1.sql

Et mon gentil dédié ne souffre plus.

Notez par ailleurs que devant une telle recrudescence, j'avais fini par réinstaller l'excellent milter-greylist du sieur Emmanuel Dreyfus, et que le résultat est sans appel: si certains MTAs tolèrent mal les codes 4xx et ne renvoient le mail que plusieurs heures plus tard, mon ratio de spams, lui, est passé de 800 / jour en moyenne à 30 / jour en moyenne. Le choix est vite fait...

Voodoo

iMil — Sun, 17 Feb 2008 17:21:31 +0000

J’ai topé ça dans une boutique à Montréal :

Vraiment pas mal. Si l’on possede quelques notions de C et de système, l’auteur nous fait manipuler du module kernel FreeBSD dès la 10eme page, et nous apprend à ruser dès la vingtieme. Je regrette qu’il soit si petit (à peine 130 pages), j’en aurait bien avalé le triple.

Ce ne sont pas ces droïdes que vous recherchez.

iMil — Sat, 26 May 2007 19:35:15 +0000

Sur mon serveur perso, par définition, y’a des trucs perso. De plus, à l’approche d’une société nouvelle, il n’est pas superflu de prendre quelques mesures afin de préserver un semblant d’intimité.
Pour cela, les bons génies de l’Internet on créé, il y a bien longtemps, SSL.
Mais voila, il y a d’autres trucs et bidules que je souhaite pouvoir exposer en place publique. J’entreprend donc de jouer avec les directives de lighttpd pour créer des exclusions et autres redirections.
Le lien qui eclaire tout, c’est celui là. En substance, nous allons rediriger tout ce qui matche mon.host.magique et faire passer ce traffic en SSL.
Voici la conf :

On déclare le serveur TLS :

$SERVER["socket"] == "mon.host.magique:443" {
  ssl.engine = "enable"
  ssl.pemfile = "/etc/ssl/certs/lighttpd.pem"
  server.document-root = "/vers/www/magique"
  server.name = "mon.host.magique"
  auth.backend.htpasswd.userfile = "/path/vers/lighttpd-htpasswd.user"
  auth.require = ( "/" =>
    (
       "method" => "basic",
       "realm" => "ce ne sont pas ces droïdes que vous recherchez.",
       "require" => "valid-user"
    )
  )
}

Puis la redirection, tout ce qui arrive sur le port 80 du host “mon.host.magique” sera redirigé vers son équivalent en HTTPS. On note les regexps compatibles Perl qui nous permettent de récupérer l’URL complète.

$SERVER["socket"] == "mon.host.magique:80" {
  $HTTP["host"] == "mon.host.magique" {
    url.redirect = ( "^/(.*)" => "https://mon.host.magique/$1" )
    server.name = "mon.host.magique"
  }
}

Et enfin les restrictions gentilles, on n’applique pas de restrictions à host1.host.magique, unautre.host.magique et blip.host.magique car ils ont leur propre déclaration dans le fichier lighttpd.conf. Pour le reste, seuls la racine, le repertoire public ainsi que les fichiers .php et .jpg sont autorisés.

$HTTP["host"] !~ "(host1|unautre|blip).host.magique" {
  server.document-root = "/var/ou/c/est/mignon"
  $HTTP["url"] !~ "(^/$|^/public|php$|jpg$)" { url.access-deny = ( "" ) }
}

C’est quand même un peu bien.

kimloli, la conf

iMil — Mon, 21 May 2007 10:26:14 +0000

y’a mon bouquetin et 2/3 autres qui me demandent la conf du kimloli, et plus particulièrement la conf des jails. Voici en quelques mots les divers points clé du bestiau. Rien de super novateur, mais ça me servira aussi de pense bête.

Tout d’abord, les jails. Ayant fait crouter la machine en utilisant les scripts rc.d fournis, et même si le bug a été corrigé recemment dans la branche FreeBSD 6.2, ça m’a refroidi d’utiliser les scripts officiels. Sur les conseils du sieur ic, je me suis donc rabattu sur jailctl, qui permet moult opérations sur les jails. Mon jails.conf ressemble à ceci :

IF="lo0"
JAIL_HOME="/home/jails/"
ROOT_PW='$1$blablapwetpwettoussa'
PROCFS="FALSE"
LINPROCFS="FALSE"
BACKUPDIR=$JAIL_HOME
BACKUP_EXCLUDE="--exclude ./usr/ports/* --exclude ./tmp/* --exclude ./var/tmp/* --exclude ./usr/src/*"
JAILS="web1:192.168.0.1"
INSTALLWORLD_FLAGS=""
RC_CONF='sendmail_enable="NONE" sshd_enable="YES" portmap_enable="NO" network_interfaces="" tcp_keepalive="NO" inetd_enable="YES"'
NAMESERVER="ip.du.kimloli"
BEFORESTATUS_HOOKS="/usr/bin/true"
AFTERSTATUS_HOOKS="/usr/bin/true"
BEFORESTART_HOOKS="/usr/bin/true"
AFTERSTART_HOOKS="/usr/bin/true"
BEFORESTOP_HOOKS="/usr/bin/true"
AFTERSTOP_HOOKS="/usr/bin/true"

Après avoir préparé un world dans le host en suivant cette documentation (et sans passer par la case make install*), on installe son environnement jailé via jailctl create nomdujail. Il sera de bon ton de manger cette doc avant de se lancer.
J’ai choisi d’”aliaser” mes interfaces jail sur le loopback plutot que sur l’interface NIC elle même simplement parce que j’ai été refroidi par la déconvenue sus-citée lors de l’utilisation d’/etc/rc.d/jail.

On appréciera la possibilité de fine-tuner la post-installation en utilisant les scripts et templates situés dans /home/jails/addons.

Comme il est assez probable qu’on voudra que notre jail puisse “sortir” sur Internet, nous devons mener deux opérations :

1. s’assurer que le host peut forwarder
2. lui faire faire du NAT des adresses jailées

Ce qui se traduit par :

$ grep forw /etc/sysctl.conf
net.inet.ip.forwarding=1

# /etc/pf.conf

int="vr0"
# NAT
# jails
nat pass on $int from 192.168.0.0/24 to any -> $int

De plus, la finalité étant de faire en sorte que ce soient nos jails qui répondent, par exemple, aux requetes HTTP, nous plaçons la redirection suivante :

# /etc/pf.conf

rdr pass on $int proto tcp from any to any port 80 -> 192.168.0.1 port 80

Reste maintenant à démarrer notre jail via la commande jailctl start nomdujail, puis à l’administrer comme un environnement classique. Dans la variable RC_CONF du fichier jails.conf, nous avons signifié qu’il fallait démarrer sshd, nous pouvons donc nous connecter à notre environnement restreint par ce biais. Pensez tout de même à désactiver le PermitRootLogin.

Afin de ne pas me trimballer deux arbres de ports, je mount /usr/ports via nullfs en read-only :

/usr/ports on /home/jails/web1/usr/ports (nullfs, local, read-only)

Puis dans le jail je configure ces quelques variables dans le make.conf

WRKDIRPREFIX=/var/ports/obj
PACKAGES=/var/ports/packages

Afin de me laisser la possibilité de compiler un port si besoin.
En fait, dans le jail, j’utilise simplement pkg_add et peuple donc l’environnement de packages binaires. Je spécifie ces variables dans mon ~/.cshrc :

setenv PACKAGEROOT ftp://ftp.fr.freebsd.org
setenv PACKAGES /var/ports/packages

afin de :

. récupérer des packages distants sur un miroir proche (pkg_add -vr)
. ajouter des packages locaux depuis un repertoire ad’hoc (pkg_create -b sur le host puis pkg_add -v dans le jail)

J’imagine actuellement un processus simple, basé sur un bête script shell, qui me permettra de tenir à jour les packages binaires du jail par rapport aux ports compilés sur le host. Si quelqun connait un projet similaire, qu’il me fasse signe ;)

wanna fayne ? yeah i wanna fayne

iMil — Wed, 28 Dec 2005 13:29:25 +0000

c’est du vil propriétaire, donc je posterai pas ca dans le jardin magique, mais comme je sais que vous etes nombreux à utiliser skype malgré tout, voici un petit howto-skype-on-FreeBSD

Pour FreeBSD 5 / 6
Pour FreeBSD 4

Et si tu te demandes quel peut bien etre l’interet de la manip étant donné qu’il existe déjà un port, regarde un peu la gueule des fontes par defaut…

ldap un jour…

iMil — Sat, 22 Oct 2005 11:10:09 +0000

Et c’est au tour d’apache. Très très simple :
cd /usr/ports/www/mod_vhost_ldap/ make install clean
Si votre apache n’est pas compilé avec le support LDAP vous vous ferez insulter.
À noter que, contrairement à ce que dit le port :
## WITH_LDAP: Enable LDAP support (mod_auth_ldap) (implies WITH_LDAP_MODULES)
Si je ne place pas explicitement WITH_LDAP=yes et WITH_LDAP_MODULES=yes, je me prend un unresolved symbol au démarrage d’apache.

Ajoutez maintenant dans votre httpd.conf (dans cet ordre) :
LoadModule ldap_module libexec/apache2/mod_ldap.so LoadModule vhost_ldap_module libexec/apache2/mod_vhost_ldap.so
puis
VhostLDAPEnabled on VhostLDAPUrl "ldap://127.0.0.1/ou=votre,dc=basedn" VhostLdapBindDN "cn=utilisateur,ou=qui,dc=binde" VhostLDAPBindPassword "mot de passe convivial"

Copiez le schéma fourni /usr/local/share/doc/mod_vhost_ldap/mod_vhost_ldap.schema dans /usr/local/etc/openldap/schema/ et ajoutez
include /usr/local/etc/openldap/schema/mod_vhost_ldap.schema
dans votre slapd.conf

Evidemment, redémarrez slapd et httpd.

Il ne vous reste plus qu’à provisionner avec votre editeur LDAP favori. Les attributs sont triviaux, par exemple :
# jard.in, apache, jardin dn: apacheServerName=jard.in,ou=apache,dc=jardin objectClass: top objectClass: apacheConfig apacheServerName: jard.in apacheDocumentRoot: /home/www
Je regrette toutefois que l’auteur n’ait pas prévu des champs relatifs aux logfiles, j’ai du utiliser une vieille bidouille à base de LogFormat :
LogFormat "%v %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined CustomLog /var/log/httpd-access-vhosts.log combined
Pour faire passer sur le fichier httpd-access-vhosts.log le script split-logfile fourni avec apache2 qui sépare ce type de log fonction du vhost. Par très classe.

Henri, sale con

iMil — Mon, 17 Oct 2005 13:27:49 +0000

Y’a un truc qui m’a toujours bien fait chier: l’impression. Chaipa pourquoi, c’est inexpliquable, ca marche juste jamais. Alors comme d’hab aujourd’hui je me suis pris la tête 2h avant de constater que :

. le backend /usr/local/libexec/cups/backend/parallel faisait locker cupsd au démarrage
. il faut parfois installer /usr/ports/print/foomatic-filters/, et notamment quand ton PPD fait appel à foomatic-rip et fait cracher a ton CUPS des messages aussi explicites que “Print file was not accepted (client-error-bad-request)!”

C’est ainsi, avant de pouvoir imprimer, il faut que j’en bave, c’est écrit, c’est inéluctable.

Bon sinon, cette impression avait pour but de sortir la demande d’inscription pour toper un stand au pavillon des associations de Solutions Linux 2006. On verra ce qu’ils en disent.

chula, chupala

iMil — Sun, 18 Sep 2005 10:14:54 +0000

note: cette nouvelle est sujette à modifications en fonction de mon avancement dans la mise en place et la configuration de ma plateforme

Quelques liens glânés de-ci de-la pour monter une plate-forme mail couillue :

. SMTP Auth avec sendmail et FreeBSD
. SMTP Auth, la doc officielle de sendmail.org
. Un overview de l’integration SASL par l’ami asyd
. l’excellent projet MiniVisp de l’ami Hug
. FABULEUSE doc sur l’interfacage sendmail / LDAP
. Sendmail + Auth + TLS
. Utilisation de STARTTLS avec sendmail et l’accessdb
. la liste des parametres compris par confLDAP_DEFAULT_SPEC (binddn, password…)
. à la fin de ce tuto vous trouverez de bons exemples de virtuser LDAP
. FreeBSD fast and secure mail server using sendmail and imap-uw (eeeet si)
. Secure Email Using Cyrus IMAP, Sendmail, and SASLv2
. Le classique mais toujours efficace OpenLDAP QuickStart Guide
. Le NSS / PAM LDAP HOWTO pour FreeBSD 5.x
. saslauthd + LDAP
. Des astuces pour rendre sendmail plus agressif
. les migration tools de padl.com
. OpenLDAP TLS HOWTO
. Installer le milter DomainKey
. Encore une doc sur domainkey

Voici la partie relative de mon /etc/make.conf
SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2 -DLDAPMAP -DSTARTTLS SENDMAIL_LDFLAGS=-L/usr/local/lib SENDMAIL_LDADD=-lsasl2 -lldap -llber
Et les parties reliées de mon sendmail.mc
define(`confLDAP_DEFAULT_SPEC', ` -h localhost -b dc=imil,dc=net') FEATURE(ldap_routing) LDAPROUTE_DOMAIN(`mail.imil.net')
[...]
TRUST_AUTH_MECH(`GSSAPI DIGEST-MD5 LOGIN') define(`confDEF_AUTH_INFO', `GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN') define(`confAUTH_MECHANISMS', `GSSAPI DIGEST-MD5 LOGIN') dnl p: uniquement TLS pour l'authentification type Login dnl A: Use the AUTH= parameter for the MAIL FROM command only when authentication succeeded. define(`confAUTH_OPTIONS', `A p')
[...]
define(`confCACERT_PATH', `/etc/mail/ssl')dnl define(`confCACERT', `/etc/mail/ssl/cacert.pem')dnl define(`confSERVER_CERT', `/etc/mail/ssl/sendmail.pem')dnl define(`confSERVER_KEY', `/etc/mail/ssl/sendmail.pem')dnl define(`confCLIENT_CERT', `/etc/mail/ssl/sendmail.pem')dnl define(`confCLIENT_KEY', `/etc/mail/ssl/sendmail.pem')dnl

Quelques trucs :

Dans le saslauthd.conf, ne pas oublier :
ldap_search_base: dc=domaine,dc=com ldap_filter: uid=%u # pour activer TLS ldap_start_tls: yes

Pour bénéficier de toutes les propriétés nécessaires, s’assurer d’avoir les includes suivants dans son slapd.conf :
include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/misc.schema

Le module ldap_routing de sendmail communique par defaut en LDAPv2, il faut ajouter l’option “-w 3″ à votre confLDAP_DEFAULT_SPEC pour le faire communiquer en LDAPv3.

Mon /etc/ldap.conf, linké à /usr/local/etc/ldap.conf et à /usr/local/etc/nss_ldap.conf
host 127.0.0.1 base dc=imil,dc=net uri ldap://127.0.0.1/ ldap_version 3 binddn cn=user,dc=imil,dc=net bindpw unpass port 389 pam_password clear # activer le TLS ssl start_tls

J’utilise dovecot pour l’acces pop / imap, j’ai eu l’agréable surprise de voir qu’il créait seul les mailboxes des utilisateurs à leur premier login, de fait, en settant “/repertoire_en_777/utilisateur” comme homedir dans l’entrée LDAP de l’utilisateur, on se retrouve avec un systeme de provisionning automatique du meilleur gout.

Addon

Après avoir migré l’ensemble des services en TLS, j’ai constaté que dovecot ne permettait malheureusement pas de réaliser l’authentification LDAP sur TLS. Sur les conseils de mon ami Eric, j’ai pondu un rapide patch qui rend ce fonctionnement possible après avoir ajouté :

start_tls = 1

dans le dovecot-ldap.conf

Add-on

Au sujet de domainkey et DKIM, ne pas oublier d’ajouter l’option -i /path/vers/les/hosts/locaux (man dkim-milter), le cas échéant seuls les les mails en provenance de 127.0.0.1 seront signés.

Pour finir, la seule application “standalone” (comprendre, qui n’a pas besoin d’apache / php et tous leurs amis) convenable pour manipuler une database LDAP reste “gq”. J’aurais imaginé que les choses avaient un peu évolué depuis 5 ans mais finalement non.

Add-on

N’oubliez pas de placer la directive :
define(`confLDAP_CLUSTER', `nom-convivial')
Et de renseigner le champs “sendmailMTACluster” dans toutes vos entrées LDAP.

le cas échéant les queries LDAP sont tout simplement ignorées.

De plus, il est inutile de protéger l’accès au subtree ou=sendmail, la doc OpenLDAP nous montre comment libérer ce scope :
access to dn.subtree="ou=sendmail,dc=dotpure,dc=net" by * read